Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Android API level to 21 in CI #78601

Closed
wants to merge 1 commit into from

Conversation

de-vri-es
Copy link
Contributor

@de-vri-es de-vri-es commented Oct 31, 2020

I ran into a problem with #78572 because the Android API level in CI is pretty old. The accept4() function is exposed by the libc crate, but it is added in Android 5.0 with API level 21 (released in June 2014). Currently, the CI is still on API level 14 in most cases.

So I was wondering: should we just update the API level in CI to 21? I think the alternative would be to remove the accept4() function from the libc crate for Android, but that would break crates that use it.

This is required to use accept4() on Android, which is already exposed
by the libc crate.
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 31, 2020
@m-ou-se m-ou-se added the O-android Operating system: Android label Oct 31, 2020
@de-vri-es
Copy link
Contributor Author

I also implemented an alternative fix for libc to keep supporting old Android: rust-lang/libc#1968

If that is preferable, these is no need to merge this.

@jyn514 jyn514 added the T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. label Nov 1, 2020
@est31
Copy link
Member

est31 commented Nov 1, 2020

Does this mean that people who use the android related Rust targets can't target older Android devices any more? If so, I think this shouldn't be merged, because Android distribution numbers show that API levels < 21 were still in use by 5.9% of deployed devices:

android distribution numbers

Related: rust-lang/release-team#2

@de-vri-es
Copy link
Contributor Author

Well, as it stands, there is at-least one issue in the libc crate for older Android targets with the accept4() function not being present in the native libc. Impact is probably quite limited at the moment though. As long as an application doesn't directly or indirectly call accept4() things will probably compile and link fine.

If the aim is to keep supporting older Android targets then it doesn't make sense to merge this. In that case I think rust-lang/libc#1968 is a better solution. That will fix accept4() for older Android targets.

So it really boils down to: should Rust keep supporting older Android targets?

@est31
Copy link
Member

est31 commented Nov 1, 2020

I think there are three questions here:

  1. The question I asked above, whether this update will mean that people won't be able to target older androids at all unless they custom-build std artifacts for it. As in, can they use the generated native artifacts and distribute them in apps that have a minimum SDK version of lower than 21.

  2. Whether, as of Use SOCK_CLOEXEC and accept4() on more platforms. #78572, breaking code that tries to listen on network connections is a concern or not

  3. What this update means for the future. Maybe it's decided that listening on the network is not a common thing to do on Android, thus it's acceptable but generally one wants to keep support for those old androids. In that case, how can one ensure potential breakage is identified early in the process?

The last increase was in #45580 , oct 2017 when the level was changed from 9 to 14. This post says that in nov 2017, API version 10 was used by 0.5% of users. It was the only listed API version before 15, and given honeycomb has barely been deployed at all, I guess it amounted to all users. So back when the update to 14 happened, basically >99% of deployed devices already had API level 14.

If you use this "two nines" rule, requiring that at least 99% of users support the new minimum version, then one could only update to API level 17.

If the aim is to keep supporting older Android targets then it doesn't make sense to merge this. In that case I think rust-lang/libc#1968 is a better solution. That will fix accept4() for older Android targets.

According to man, the accept4 syscall was added in Linux 2.6.28. According to Wikipedia, Android 1.6 (API 4) already used this kernel version by default. I presume that OEMs do ship older kernel versions with newer OS/API versions, so maybe newer phones might still use the kernel, or the OEM's kernel fork might just have updated the version number. But I doubt that this is going to be a problem here. Edit: forgot the conclusion: I think it's fine to call the syscall directly and make the android target use it. If it turns out to be a problem one can always reconsider.

@kennytm
Copy link
Member

kennytm commented Nov 1, 2020

note: we tried to raised to API 17 in #71123 half a year ago, but the PR was closed due to inactivity.

bors added a commit to rust-lang/libc that referenced this pull request Nov 2, 2020
Implement accept4 on Android as raw syscall.

This PR implements `accept4()` on Android using `syscall()` instead of the `accept4()` wrapper.

This is done because the `accept4()` wrapper wasn't added to Androids `libc` until version 5.0 (API level 21). By using `syscall` directly, `accept4` will also work on older  Android versions.

The kernel itself has supported it since Linux 2.6.28, which was shipped with stock Android since version 1.6 already: https://en.wikipedia.org/wiki/Android_version_history#Android_1.6_Donut_(API_4)

At the moment, the CI for the rust repo still uses API level 14. Although I also opened a PR to bump that too: rust-lang/rust#78601. However, it might make sense to keep the old API level in CI if this is merged.
bors added a commit to rust-lang/libc that referenced this pull request Nov 3, 2020
Implement accept4 on Android as raw syscall.

This PR implements `accept4()` on Android using `syscall()` instead of the `accept4()` wrapper.

This is done because the `accept4()` wrapper wasn't added to Androids `libc` until version 5.0 (API level 21). By using `syscall` directly, `accept4` will also work on older  Android versions.

The kernel itself has supported it since Linux 2.6.28, which was shipped with stock Android since version 1.6 already: https://en.wikipedia.org/wiki/Android_version_history#Android_1.6_Donut_(API_4)

At the moment, the CI for the rust repo still uses API level 14. Although I also opened a PR to bump that too: rust-lang/rust#78601. However, it might make sense to keep the old API level in CI if this is merged.
@de-vri-es
Copy link
Contributor Author

Considering that rust-lang/libc#1968 is almost certainly getting merged, and this seems to be a hairy topic, I'm closing this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-android Operating system: Android S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants