Make armv7-android a tier-1 platform

[rillian]

I understand from the 1.13.0 stable release notes that ARM is currently considered a 2nd tier platform for Rust releases. Android is one of the major software platforms in the world today, and the mobile OS most open to third-party native code. Being able to target it is an important part of Rust's story.

More specifically, Firefox treats arm android as a tier-1 platform. Being able to rely on the same level of support in official rust releases would be a great aide in our deployment of Rust code in the Gecko rendering engine.

I therefore propose that armv7-linux-androideabi be promoted to tier-1.

[rillian]

This was inspired by rust-lang/rust#37691 just missing the release, and the corresponding warning about code generation on armhf in the release notes.

cc @alexcrichton, @kentuckyfriedtakahe.

[alexcrichton]

Ah yes of course! I actually had no idea armv7 Android was a tier 1 platform for Firefox. It's definitely a bad sign that Firefox has more tier 1 platforms than Rust! (or at least a certain cause of pain, as we're seeing).

The change we need to make armv7 tier 1 is likely to just add an auto bot running tests, which should hopefully become very easy very soon!

[dschaeffer]

Are there current plans for when armv7 Android will become a tier 1 platform for Rust?
This is currently preventing me from starting to adopt rust.

[eddyb]

I think we've been running tests on ARM for a while now? Not sure where the canonical tiers are defined though.

[arielb1]

We don't run the compiler on ARM tho, so we are vulnerable to unpleasantnesses such as rust-lang/rust#40593.

[dschaeffer]

so does the lack of response mean there are no current plans for making android a tier 1 platform?

[arielb1]

ARM is pretty much Tier 1.5 - running rustc on an armv7 host is not CI-tested (because that would require us to find a fast ARM build machine to do CI on), but compiling targeting armv7 is supported.

[dschaeffer]

@arielb1 That makes sense. Thanks for the explanation.

[infinity0]

BTW, it's possible to create a 32-bit armv7 ("armv8l") chroot on a fast 64-bit aarch64 machine, then run the rustc armv7 test suite inside that. It's what I've been doing on Debian. This isn't exactly androideabi but I imagine there's a quite a lot of overlap and fixing errors here could improve the android situation. I see test failures all the time on armhf(armv7) Debian unfortunately.

[arielb1]

@infinity0

For that, we'll need an armv8 build server. Our CI infrastructure is all in the cloud - do you know of good cloud ARMv8 servers?

[infinity0]

I don't personally know about them in detail, but you could ask ircs://irc.oftc.net/#debian-arm about what they're doing and/or browse the list of Debian machines here and contact the companies listed.

For tests.reproducible-builds.org we have some machines donated by codethink.co.uk. This isn't a public offer but it might be worth contacting them to see if they would do a similar thing for Rust.

[rillian]

In the past I've used Linaro for arm testing. They offered brief loaners for experiments, but might be amenable to a dedicated host for something like language support.

The only armv8 cloud service I've been able to find is Scaleway. Reviews say their emphasis is more on price than reliability, but it's worth an experiment. They also offer actual armv7 machines, but I don't know how easy it is to run an android image on them.

For Gecko we're just run emulators on x86 cloud hosts. That's very slow of course, but fast x86 cloud hosts are available, and it lets one use established adb-based tools designed for handset development.

Does qemu support native execution of armv7 on aarch64 the way people use i386-android images for development on amd64 hosts? That could be another way to test armv7-android directly.

[Centril]

Triage: still tier 2.