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

VERIFIED FIXED

Status

Release Engineering
General
VERIFIED FIXED
2 months ago
a month ago

People

(Reporter: nthomas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 months ago
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
(Reporter)

Comment 1

2 months ago
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.
(Reporter)

Comment 2

2 months ago
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
(Reporter)

Comment 3

2 months ago
Created attachment 8900548 [details] [diff] [review]
[tools] Add mapping for android-aarch64

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. 

[1] https://ibotpeaches.github.io/Apktool/
Attachment #8900548 - Flags: review?(jlorenzo) → review+
Quick question, should we add a new entry at: https://dxr.mozilla.org/build-central/rev/80bb3804461b113d1193a7d4ee3f7ec71ffb169f/buildbot-configs/mozilla/config.py#1560 ?
(Reporter)

Comment 6

2 months ago
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
Attachment #8900548 - Flags: checked-in+
(Reporter)

Comment 7

2 months ago
(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.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
(Reporter)

Comment 8

2 months ago
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: → bug 1396092
(Reporter)

Comment 9

a month ago
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.