Closed Bug 1393312 Opened 3 years ago Closed 3 years ago

android-aarch64 is probably the wrong %BUILD_TARGET% to use for aarch64 Balrog submission


(Release Engineering :: General, defect)

Not set


(Not tracked)



(Reporter: nthomas, Unassigned)




(1 file)

Various queries for app update, gmp updates, blocklist, etc include a %BUILD_TARGET% which expands like this for Android builds:

arm:      Android_arm-eabi-gcc3
x86:      Android_x86-gcc3
aarch64:  android-aarch64

At least that's what we have in the Fennec-mozilla-central-nightly-20170823100559 release in Balrog, but the aarch64 seems very likely to be wrong based on will need a new value once we know what a device actually queries with. The balrogworker that does the submission looks at the platform in the manifest of the upstream task, which is android-aarch64. buildbot2updateplatform() passes that value on since it doesn't have a mapping.
So from 
  .replace("%BUILD_TARGET%", "Android_" + AppConstants.MOZ_APP_ABI + pkgSpecial)
in [1] we want MOZ_APP_ABI, which leads 
at [2]. And in a nightly build for aarch64 on m-c [3] we have 

pkgSpecial depends on MOZ_PKG_SPECIAL, which I don't think gets defined for mobile builds.

So I think it should be Android_aarch64-gcc3.

jlorenzo, do you know this code well enough to review ?
Attachment #8900548 - Flags: review?(jlorenzo)
Comment on attachment 8900548 [details] [diff] [review]
[tools] Add mapping for android-aarch64

Review of attachment 8900548 [details] [diff] [review]:

I don't really know that code, but I can tell the values are correct! The string "Android_aarch64-gcc3" is defined in the APK. More precisely, it's encoded within classes.dex. Once the APK unzipped, you can `grep -r 'Android_aarch64-gcc3'` and see there's a match in that binary file. Searching for 'Android_arm-eabi-gcc' doesn't return anything in the aarch64 APK (but does in the ARM one).

To be even more sure, that file can be decoded thanks to apktool[1]. You can grep again, and see that the string is part of smali/org/mozilla/gecko/updater/UpdateServiceHelper.smali, which aligns with the file you pointed out.

We're all good, then! Thanks for spotting this out, Nick :D

By the way, just for the record aarch64 isn't shipped. It's currently for testing only. 

Attachment #8900548 - Flags: review?(jlorenzo) → review+
Comment on attachment 8900548 [details] [diff] [review]
[tools] Add mapping for android-aarch64

Thanks for verifying directly in the apk, good idea.

I understand that we don't use this now, and won't unless we add updates for single locale repacks. I noticed this as part of bug 1380605, when I needed to know the target for aarch64 to serve the openh264 plugin, and we didn't have it in the mapping.
Attachment #8900548 - Flags: checked-in+
(In reply to Johan Lorenzo [:jlorenzo] from comment #5)

No, I don't think so. That looks like leftover config from when we ran the builds on buildbot, and there's no mention of aarch64 in there.
Closed: 3 years ago
Resolution: --- → FIXED
Turns out we have to do more work to get the tools change into the funsize workers, but bug 1396092 will likely take care of that for us.
See Also: → 1396092
Bug 1396092 comment #5 fixed that up - we have an Android_aarch64-gcc3 platform in Fennec-mozilla-central-nightly-latest now. I've done some cleanup at bug 1396092 comment #7.
You need to log in before you can comment on or make changes to this bug.