Conversation
|
r? @Kobzol (rustbot has picked a reviewer for you, use r? to override) |
|
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 |
|
cc @chriswailes |
|
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) |
|
Happy to see this land, as it looks like it will also allow simplifying away rust-lang/backtrace-rs#570 from backtrace-rs, too. |
|
ping @Mark-Simulacrum - it looks like it still says "waiting on author", but Chris has LGTM'd. |
|
@rustbot ready |
|
@bors r+ rollup=iffy |
Update Android in CI We are currently using a 10+ year old Android image, and it has caused trouble when working on rust-lang#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](https://github.com/android/ndk/wiki/Changelog-r26) deprecating 19 and 20 as targets. 2. Activates aarch64 testing on the emulator, since the base image is now a 64-bit image. 3. Bumps the NDK to 26b
|
💔 Test failed - checks-actions |
|
Appears CI got stuck shortly after @bors try- |
|
Hmm doesn't seem to have picked up the cancel, but maybe the new job will override it? @bors try |
|
Seems like it is stuck at the same point, which appears to be just before "pushing server" based on logs from https://github.com/rust-lang-ci/rust/actions/runs/10101022677/job/27933675737. @maurer any ideas here? |
|
That would normally mean that the virtual device wasn't coming up, so it was hanging on connecting... but wasn't this working before? |
This comment has been minimized.
This comment has been minimized.
|
It did pass at https://github.com/rust-lang-ci/rust/actions/runs/10049405628/job/27775374879. The dropped patch 005ab82 ("Add aarch64-android testing") included a change to the arm dockerfile ENTRYPOINT, as well as android-start-emulator.sh - any chance that could be it? |
|
|
We were running testing on API 18, which was already out of support for NDK 25, and some of the ancient behavior in that image was causing trouble when developing `rustc` features (rust-lang#120326). Update to the current LTS NDK 26, and to its minimum supported API 21. Fixes: rust-lang#120567
|
@bors try |
|
☀️ Try build successful - checks-actions |
|
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 |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Note that try builds cannot be cancelled using the current bors bot. |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (6ef11b8): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis 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. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 772.066s -> 770.248s (-0.24%) |
|
Congratulations on getting this merged, it seems to have been incredibly difficult. Thanks for the persistence. |
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.
Ditto. This seems to imply the minimum NDK version is 26b now, which should be similarly documented. |
|
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. |
|
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. |
|
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. |
|
@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. |
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:
try-job: arm-android