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
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.
So from .replace("%BUILD_TARGET%", "Android_" + AppConstants.MOZ_APP_ABI + pkgSpecial) in  we want MOZ_APP_ABI, which leads DEFINES['MOZ_APP_ABI'] = CONFIG['TARGET_XPCOM_ABI'] at . And in a nightly build for aarch64 on m-c  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.  https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/updater/UpdateServiceHelper.java#119  https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/generate_build_config.py#96  https://public-artifacts.taskcluster.net/ebmb1mG-RV2WPkVBAxsopA/0/public/logs/live_backing.log
Created attachment 8900548 [details] [diff] [review] [tools] Add mapping for android-aarch64 jlorenzo, do you know this code well enough to review ?
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. 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.  https://ibotpeaches.github.io/Apktool/
Quick question, should we add a new entry at: https://dxr.mozilla.org/build-central/rev/80bb3804461b113d1193a7d4ee3f7ec71ffb169f/buildbot-configs/mozilla/config.py#1560 ?
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
(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.
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.
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.