Android builds are failing on servo-linux-cross3

[aneeshusa]

We've tried re-highstating servo-linux-cross3; jury is still out on the last highstate, but previous attempts have not fixed the problem.

I'm not well versed with Android, but I have a new idea about what might be going wrong:

• The relevant builds (e.g. http://build.servo.org/builders/android/builds/6778/steps/compile/logs/stdio) are currently failing in the /mach build --android --dev step
• In buildbot_steps.yml, we only override the ANDROID_SDK variable for the ./mach package step, not the ./mach build step, so the current SDK symlink takes precedence
• #644 has not yet been deployed to -cross1 and -cross2, only -cross3:
  • Both -cross1 and -cross2 still have the older r24.4.1 SDKs on disk, while all three have the new r25.2.3 SDK on disk.
  • -cross1 and -cross2 have the old SDK as current, while -cross3 has the new SDK as current.

Is it feasible that ./mach build --android --dev is failing due to getting the new r25.2.3 SDK on -cross3, while working OK with the r24.4.1 SDK on -cross1 and -cross2?

cc @larsbergstrom @MortimerGoro

[aneeshusa]

OK, reproduced the failure on servo-linux-cross2 with the above test PR (see http://build.servo.org/builders/android/builds/6786), SDK 25.2.3 breaks ./mach build --android --dev.

[MortimerGoro]

This line in blurdroid dependency is the one causing the problem:

https://github.com/szeged/blurdroid/blob/master/build.rs#L64

The problem is that when SDK 25.2.3 is enabled, only android-25 platform is installed. When r24.4.1 is enabled only android-18 platform is installled. Blurdroid dependency has android-18 path hardcoded...

Possible solutions:

• Add an array of platforms to saltfs instead of using a unique android-platform
• Fix hardcoded path in blurdroid dependency

[aneeshusa]

Making platforms into an array in saltfs is a fairly easy change. However, IMO it makes more sense to update blurdroid, then send a servo/servo PR with that change (and also fixing buildbot_steps.yml to pass the ANDROID_SDK var for ./mach build) for a few reasons:

• Easier to test servo/servo changes since there's no need to revert as with saltfs changes
• It doesn't seem like anyone else depends on blurdroid: https://crates.io/crates/blurdroid/reverse_dependencies
• This avoid having multiple platforms, which seems like it could easily cause problems later

Also, I just noticed we should update the servobuild.example file as well at some point.

[aneeshusa]

It might also make sense to use an environment variable for the platform version in blurdroid, and set that from buildbot_steps.yml / saltfs.

[MortimerGoro]

Yes, good reasons to update blurdroid.

I'll do the PR to blurdroid, it's a easy change too.

[aneeshusa]

Thanks for the PRs @MortimerGoro! I just grepped servo/servo and I still see android-18 in a few places and saw it used in the build log for servo/servo#16812, so I think we need to update this in more places if you want to take a look. I'm going to run a force build on cross3 to check in the meantime.

[MortimerGoro]

@aneeshusa the android-18 in the log are related to Android NDK (C++) which is a different SDK (it has all the platforms included). I think that there aren't more dependencies in Servo that use Android SDK (java). So the cross3 build should work

[aneeshusa]

I didn't know that about SDK vs. NDK, thanks for the explanation. Indeed, the force build succeeded: http://build.servo.org/builders/android/builds/6858

I'm going to roll out #644 to cross2 and cross1 now, since this appears to be working. Closing this issue.