Rust support for Android versions

[tweksteen]

Opening an issue here, as this is somewhat related to issue #2.

There is currently no agreement on which Android API version should be supported by Rust. Rust used to support version 9 of the Android API. This version is still referenced in the documentation.

An update of the NDK used in CI was done in October 2017, to the latest version then (r15c). As API 14 was the minimum supported version for that NDK, 14 effectively became the new minimum for the API version. Here is the rational captured in that pull request:

2. Updated NDK to r15c.
   Because why not

3. -

4. Raised minimum API level of 32-bit targets from 9 (2.3) to 14 (4.0)
   NDK r15c dropped support for android-9. (The minimum API level for 64-bit targets remains at 21 (5.0))

In October 2020, a PR was put forward to upgrade the API level to 21. This request was not merged and an alternative was implemented (using low-level syscall in this case). One argument raised during the review was that about 5% of devices still only support API versions lower than 21.

NDK r15c is now unsupported. The current versions of the NDK (r21 LTS and r22) support at the lowest API level 16. It's worth noticing that there is already a conscious decision by the Android NDK release team to support a wide range of devices (this is why level 16 is still supported).

Hence, a suggestion would be that Rust supports the lowest API available in the currently supported NDK. This would ensure that a supported version of the NDK is being used (for Rust CI and app developers) while maintaining the maximum compatibility for older devices.

[joshtriplett]

I'd like to suggest, as an alternative, that we set a threshold on the basis of both age and percentage of devices. For instance, "We support API levels that are supported by the current NDK, represent at least 5% of devices, and are less than 6 years old." (Suggesting a general form for the requirement; we could adjust the exact numbers.)

[j-vanderstoep]

I can see how the flexibility of additional deprecation triggers could be attractive. Do we have any examples where that would have been useful? What I anticipate will happen is that it will be straightforward for Rust to support all versions supported by the current NDK, because the NDK team works hard to provide that stability, prevent breakage, and fix breakage if it occurs. If those additional triggers are never actually exercised, which is what I would expect, then I would prefer to not have them as they will only have downsides such as:

1. Uncertainty among Rust developers. Confusing and unexpected potential disagreement between tools/tooling/toolchains of what Android versions are supported. Instead of following the deprecation policies that the rest of the Android developer ecosystem follow, developers will have to figure out if Android supports an API version AND Rust supports it.
2. Instead of relying on release versions cutoffs instituted by the rather conservative NDK team (like the rest of the Android ecosystem), Rust developers will find themselves worrying about the number of users on specific API versions which could trigger Rust not supporting API versions that (for example) their C++ or Java code still support.
3. An overall impression that Rust's commitment to support in the Android ecosystem is less than what developers can expect from other toolchains.

[sanxiyn]

Note that PR to document supported Android versions are up, without any discussion as far as I can tell: rust-lang/rust#101780. PR author seems to be a Googler.

Here is the precise wording:

Rust will support the most recent Long Term Support (LTS) Android Native Development Kit (NDK). By default Rust will support all API levels supported by the NDK but a higher minimum API level may be required if deemed necessary.

[chriswailes]

Note that PR to document supported Android versions are up, without any discussion as far as I can tell: rust-lang/rust#101780. PR author seems to be a Googler.

I'm sorry for not providing more background information in the PR. There was a discussion on Zulip that can be found here. In addition, several of our team members had a discussion with Josh Triplett about the issue at RustConf which was why I added him as the reviewer.

I'll post this information in the other PR as well. Thanks for bringing this to my attention.