Update Android in CI

[maurer]

We are currently using a 10+ year old Android image, and it has caused trouble when working on #120326.

Our current NDK (25) only supports API 19+, so we were already out of spec. This PR:

1. Bumps the API used by the emulator in CI to 21, as per NDK-26's release notes deprecating 19 and 20 as targets.
2. Bumps the NDK to 26b

try-job: arm-android

[rustbot]

r? @Kobzol

(rustbot has picked a reviewer for you, use r? to override)

[maurer]

r? @pietroalbini

Pietro, I've added you explicitly since you're the only one to ever touch this lockfile, which means you're likely to be the one who can run update-mirror, which I lack the credentials for.

[maurer]

cc @chriswailes

[Mark-Simulacrum]

The new files should be uploaded to the mirror. However, I'd like to get a +1 from another android target maintainer on this PR before moving ahead.

cc @chriswailes @mgeisler (per platform support docs)

[chriswailes]

Lgtm!

[workingjubilee]

Happy to see this land, as it looks like it will also allow simplifying away rust-lang/backtrace-rs#570 from backtrace-rs, too.

[maurer]

ping @Mark-Simulacrum - it looks like it still says "waiting on author", but Chris has LGTM'd.

[workingjubilee]

@rustbot ready

[Mark-Simulacrum]

@bors r+ rollup=iffy

[bors]

📌 Commit 7c39eee has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 7c39eee with merge 23c8dec...

[bors]

💔 Test failed - checks-actions

[tgross35]

@bors try

[bors]

⌛ Trying commit 8bf9aea with merge 591f78e...

[bors]

☀️ Try build successful - checks-actions
Build commit: 591f78e (591f78ef5c8299ba49e2fe7e211b8850f6e57552)

[tgross35]

Great, time for the real thing. Only change from the previous approval was to drop the patches that add aarch64.

@bors r=Mark-Simulacrum,workingjubilee

[bors]

📌 Commit 8bf9aea has been approved by Mark-Simulacrum,workingjubilee

It is now in the queue for this repository.

[rust-log-analyzer]

The job arm-android failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

file:.git/config remote.origin.url=https://github.com/rust-lang-ci/rust
file:.git/config remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
file:.git/config gc.auto=0
file:.git/config http.https://github.com/.extraheader=AUTHORIZATION: basic ***
file:.git/config branch.try.remote=origin
file:.git/config branch.try.merge=refs/heads/try
file:.git/config submodule.library/backtrace.url=https://github.com/rust-lang/backtrace-rs.git
file:.git/config submodule.library/stdarch.active=true
file:.git/config submodule.library/stdarch.url=https://github.com/rust-lang/stdarch.git
file:.git/config submodule.src/doc/book.active=true
---
+ export SHELL=/bin/bash
+ exec /checkout/src/ci/run.sh
+ 
[CI_JOB_NAME=arm-android]
emulator: ERROR: Unknown AVD name [armeabi-v7a-18], use -list-avds to see valid list.
HOME is defined but there is no file armeabi-v7a-18.ini in $HOME/.android/avd
(Note: Directories are searched in the order $ANDROID_AVD_HOME, $ANDROID_SDK_HOME/avd and $HOME/.android/avd)
[CI_JOB_NAME=arm-android]

[tgross35]

The job arm-android failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)

(this is just the job that started 4 hours ago timing out)

[bors]

⌛ Testing commit 8bf9aea with merge 6ef11b8...

[Kobzol]

Hmm doesn't seem to have picked up the cancel, but maybe the new job will override it?

Note that try builds cannot be cancelled using the current bors bot.

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum,workingjubilee
Pushing 6ef11b8 to master...

[rust-timer]

Finished benchmarking commit (6ef11b8): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 772.066s -> 770.248s (-0.24%)
Artifact size: 328.93 MiB -> 329.00 MiB (0.02%)

[danakj]

Congratulations on getting this merged, it seems to have been incredibly difficult. Thanks for the persistence.

[briansmith]

Bumps the API used by the emulator in CI to 21, as per NDK-26's release notes deprecating 19 and 20 as targets.

This implies that API level 21 is the new minimum supported (at least minimum tested) API level, which should be documented...somewhere, especially somewhere in (or linked from) the platform support documentation.

Bumps the NDK to 26b

Ditto. This seems to imply the minimum NDK version is 26b now, which should be similarly documented.

[workingjubilee]

I think the actually germane element here is the API level. If you compile Rust with the oldest NDK that supports our minimum API level, it should work, in theory?

Not that we're testing it, so we should be clear that that's the NDK we support, but I draw the distinction because the API level is the hard limit.

[maurer]

In a blog post for 1.68, we noted that we were moving to a policy of targeting the most recent LTS NDK. This is further documented in the NDK/API Update Policy under Platform Support.

I'd agree with you that it would be worth an extra notification if we were bumping the API beyond that, but we're bumping the min API exactly the way we messaged we would - we currently support all API levels supported by the supported NDK, which is the LTS NDK, and results in a minimum of 21.

[briansmith]

Do we still intend to support API level 19 even though we're not testing it? Or are we now allowing the use of API level 20/21 features in future commits? This is the kind of clarification that I would like to see.

In my experience with MSRV, soon after I stop testing with the MSRV toolchain, the build with that toolchain breaks. More generally, "supported but not tested" minimum supported toolchain versions tend not to be "supported" very well.

[workingjubilee]

@briansmith No? And I'm not sure how you apprehended that conclusion.

I was only commenting about the API/NDK distinction because older NDKs can theoretically compile for that API level. The API level still represents the hard minimum. The API level is what defines the actual implementation of the standard library.