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

Status: VERIFIED FIXED

(Release Engineering :: General, defect)

Description

[Nick Thomas [:nthomas] (UTC+12)]

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 https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/updater/UpdateServiceHelper.java#119

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

https://hg.mozilla.org/build/tools/file/default/lib/python/release/platforms.py#l22 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.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

So from 
  .replace("%BUILD_TARGET%", "Android_" + AppConstants.MOZ_APP_ABI + pkgSpecial)
in [1] we want MOZ_APP_ABI, which leads 
  DEFINES['MOZ_APP_ABI'] = CONFIG['TARGET_XPCOM_ABI']
at [2]. And in a nightly build for aarch64 on m-c [3] we have 
  -DTARGET_XPCOM_ABI='"aarch64-gcc3"'

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.

[1] https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/updater/UpdateServiceHelper.java#119
[2] https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/generate_build_config.py#96
[3] https://public-artifacts.taskcluster.net/ebmb1mG-RV2WPkVBAxsopA/0/public/logs/live_backing.log

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [tools] Add mapping for android-aarch64

jlorenzo, do you know this code well enough to review ?

Comment 4

[Johan Lorenzo [: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. 

[1] https://ibotpeaches.github.io/Apktool/

Comment 5

[Johan Lorenzo [:jlorenzo]]

Quick question, should we add a new entry at: https://dxr.mozilla.org/build-central/rev/80bb3804461b113d1193a7d4ee3f7ec71ffb169f/buildbot-configs/mozilla/config.py#1560 ?

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

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.

https://hg.mozilla.org/build/tools/rev/cf2d91645dddc86dfe0513ed8ccecc76ae8994c5

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

(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.

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

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.