ndk
ndk copied to clipboard
android
Drop 32-bit x86 support
Description
32-bit x86 has dropped to a very small number of active devices, and Studio is no longer shipping new emulator images for that ABI, so that ABI can't be tested very well any more. We should drop the ABI.
There's still quite a few devices API 21+ on Intel active in prod. For me it's still 2K users on ZenPhone/Tab / Medion & Lenovo tablets. Any idea of the performance impact of using the v7a on those devices?
For me it's still 2K users on ZenPhone/Tab / Medion & Lenovo tablets.
Really? x86 and not x86_64? I don't think I can share the number I have (I really wish I could, fwiw), but let's just say say that one app having as many as 2k x86 users would surprise me. Assuming your users aren't hugely skewed toward x86 devices, I would expect this segment of your user base to be trivially small. I don't suppose you'd be willing to share what that is as a percentage of your total users?
ZenPhone is old enough that i suspect they're about to fall off the end of NDK support when Lollipop is the oldest supported OS release (https://github.com/android/ndk/issues/1751)?
It looks like some of those were upgradable to API 21, and the second one shipped with that, so at least some are still in the supported API window.
I took the Play Console filtered on API 21 and x86, checked those I mention do not have the x64 support.
That app is particular as it's first feature is being a remote( but advanced with media list, streaming,....) So I have many users with old dedicated devices for that. (The app is on Play Store since 10 years, this start to be long :p) And seems there was a few x86 tablets.
Anyway the ndk is used for small encryption and ffmpeg for audio only. So if the v7a works and perf is not abysmal this is less an issue as that app is not an app bundle I do not anticipate an issue if I remove the x86 so it should auto switch.
I expect the performance impact of using arm binaries for that sort of thing is unnoticeable. It's likely noticeable for high performance workloads like games, but it's doubtful that high end games are running successfully on 32 bit devices anyway. Also, aiui, most games (and apps in general) don't bother shipping x86 libraries in the first place.
Well actually thanks for posting this and the perf confirmation, removing x86 covers nearly 85% of the size gained after NDK 22. (And probably more if I take in account ffmpeg) so that unblock me if Exoplayer ffmpeg requires a new NDK soon.
Really? x86 and not x86_64? I don't think I can share the number I have (I really wish I could, fwiw), but let's just say say that one app having as many as 2k x86 users would surprise me.
For termux around 1.8 % of users are on x86 devices based on downloads over the last 14 days. It's harder to tell exact number of users (I don't have stats for all mirrors) but at least a few thousand. There are less users on x86_64, around 1.2 % of all downloads.
I don't suppose you can differentiate between emulators and real devices? That is, how many of those x86 users could become x86_64 users by flipping a switch?
I don't suppose you can differentiate between emulators and real devices?
Cannot unfortunately, but I don't see why users would want to use this app in an emulator (other than termux development), I expect most to be on real devices. If I look at the few x86 bug reports we have where device details have been included then we have just 1 emulator user (reported using "Genymotion Google Pixel 2 API 8") out of 12, with the rest of the users using:
- 4 x Samsung Chromebook Pro running android 7 or 9
- 2 x ASUS Chromebook Flip C302 running android 9
- 1 x ASUS_Z00AD running android 5
- 1 x ASUS_T00G running android 5
- 1 x Alco RCT6873W42 running android 6
- 1 x Intel Apollo Lake Chromebook running android 9
- 1 x HP Chromebook 13 G1 running android 9
So average x86 user for us has some Chromebook with android 9 (based on this very small sample size). I can imagine that termux is more popular on this type of device than the average android app, so maybe statistics look a bit different for us.
@DanAlbert Does x86_64 have more users than x86 in the statistics you have? Can you say roughly how many more?
I can't share an exact number, but there are roughly 600 times as many users that have x86_64 support of some form than are affected by this deprecation. There are also roughly 1400 times as many users whose devices support x86 that will be still be supported after this change (because the device also supports other ABIs) than are affected by this change.
The users that are affected by this to the extent that they will not be able to get new app updates after developers update to a new NDK are a vanishingly small subset of the population.
The portion that are affected because they might end up using emulated arm code and might have worse performance is larger, but is still quite small, and honestly I very much doubt that it's much of an issue for users on those devices anyway. If the device supports x86 only, it's likely a very old and low end device that isn't capable of anything performance intensive regardless of which ABI is running.
I'm going to move this out of r26. We'll keep the level of support we currently have (as I said above, it's impossible for us to test anything newer than API 29 for this ABI) until something forces us to either invest or cut, or until the testing situation gets even worse.
Great. Thanks for the update.
On Thu, Apr 20, 2023 at 1:46 PM Dan Albert @.***> wrote:
I'm going to move this out of r26. We'll keep the level of support we currently have (as I said above, it's impossible for us to test anything newer than API 29 for this ABI) until something forces us to either invest or cut, or until the testing situation gets even worse.
— Reply to this email directly, view it on GitHub https://github.com/android/ndk/issues/1772#issuecomment-1516924301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALK5ZLF6H4B2IIK2NWSGIDXCGOD7ANCNFSM6AAAAAAQ55ZOU4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Is Armv7 going to follow x86 soon?
define "soon"... Auto has been 64-only for years (for longevity reasons), and as armv9 cores move to 64-only, all devices using new cores will lose 32-bit support. (64-only is already a shipping possibility: https://android-developers.googleblog.com/2022/10/64-bit-only-devices.html)
it's still possible to ship armv7 non-phone (Go, Wear, and TV) devices, though, and devices that haven't upgraded to armv8 don't seem particularly likely to jump straight to armv9...
but we are seeing some app developers drop 32-bit support anyway. (the Play rules require that you ship a 64-bit version if you have a 32-bit version, but if you have a 64-bit version, you're not required to ship a 32-bit version.) obviously it's easier for an app to make a decision like that (because they can see their user numbers directly) than it is for middleware, so at the moment, i'd say:
- for apps, check your Play console and see whether supporting 32-bit is still worth it for your specific app.
- for middleware, either check your own telemetry if it exists, or ask your customers whether they still care.
there's definitely a bit of a catch-22 here, but the end of new 32-bit cores (https://www.arm.com/blogs/blueprint/64-bit) has set the ball rolling...
(and, yes, at some point the same issues we have being able to test 32-bit x86 will kick in for 32-bit arm, and probably worse --- you can always test x86 on x86-64 servers, but i'm not aware of any arm64 server hardware that can run 32-bit code.)
define "soon"...
Let's think of it from, say, a 3-year perspective - shall we expect armv7 to still be supported by the NDK? Or is it that because of the non-phone devices, it will stay supported forever?
there's definitely a bit of a catch-22 here
Yeah business as usual. I guess if we were to drop 32-bit that would affect the horizon quite a bit.
but the end of new 32-bit cores...
...looked promising until 8Gen2 used the latest 64-bit only cores. all but 2 of them which are A710 and capable of running 32bit...
Is the 2% 32-bit-only devices in the world estimate from Arm close to what you are seeing?
Let's think of it from, say, a 3-year perspective - shall we expect armv7 to still be supported by the NDK? Or is it that because of the non-phone devices, it will stay supported forever?
i'd assume the NDK will go last, as always, because it has to wait for devices to "age out" of the market. (and there are new devices still coming out in these low-end niches that are 32-bit only. so the NDK's clock doesn't really start until they stop. or at least stop selling. it doesn't really matter if someone makes a device and no-one buys it :-) )
Yeah business as usual. I guess if we were to drop 32-bit that would affect the horizon quite a bit.
yeah, i didn't want to say that because obviously that's a business decision for you and your partners, but obviously middleware dropping 32-bit is even more helpful to the general move to 64-only than individual apps. (if nothing else, it stops new apps from supporting 32-bit.)
...looked promising until 8Gen2 used the latest 64-bit only cores. all but 2 of them which are A710 and capable of running 32bit...
there's only so many years that trick can realistically work though :-) (and it's probably more relevant to keeping legacy stuff running than being able to run new stuff.)
Is the 2% 32-bit-only devices in the world estimate from Arm close to what you are seeing?
i think the thing that makes it complicated is that we see that it varies wildly between apps. to take an extreme example, since there are no 64-bit Go/TV/Wear devices yet, 100% of Go/TV/Wear app users are on 32-bit devices. funnily enough, the opposite extreme is probably "high-end games", where we are seeing that app developers aren't always bothering with 32-bit builds at all, and so by definition 100% of those users are on 64-bit[-capable] devices.
I haven't seen data on armv7 only devices in a while (I've started asking around), but within 3 years would shock me. It feels far enough in the future to me that I don't think about it. Perhaps the data will come back and paint a very different picture, but that'd surprise me.
That's for the whole Android population though. I suspect games could choose to drop 32-bit support pretty soon without too much trouble. Those 32-bit chips are not going to be able to run most modern games anyway.
looked promising until 8Gen2 used the latest 64-bit only cores. all but 2 of them which are A710 and capable of running 32bit
Rumor is that the upcoming Snapdragon 8 Gen 3 finally drops AArch32 support, and that will drive down to other chips at lower price levels, so you will probably see something like 30-40% of active devices no longer supporting AArch32 in 3 years. I don't know what the NDK devs' threshold is, but I'm still using an 8.5 year-old armv7 tablet, so I expect armv7 may still be supported in 5 years, after which nobody may miss it.
30-40% of active devices... I don't know what the NDK devs' threshold is
I don't have a hard and fast rule, but I generally aim to support anything with more than 1% of users still requiring it. That's always dependent on what it costs us to keep that support alive though. It would not shock me at all if avoiding arm32 regressions started to take a significant amount of our time long before we got that low.
What @DanAlbert said, 1% is a threshold where you can consider stopping to support the devices. (especially that there's always a lag in adopting the latest version of the NDK)
I have doubts that 8Gen3 dropping AArch32 has any significant effect on the market within 3 years. If mid-layers chips do it though, the situation will be different.
(I'm glad to hear that totally by accident you and I seem to have picked the same target)
I have doubts that 8Gen3 dropping AArch32 has any significant effect on the market within 3 years. If mid-layers chips do it though, the situation will be different.
ARM said a couple years ago that all their designs this year will be 64-bit only, and they pretty much hit that last year, with the only exception that their refreshed A510 now has an optional 32-bit mode, though that is probably primarily aimed at non-mobile markets:
"Interestingly, the revamped A510 can be configured with AArch32 support — the original was AArch64 only — to bring the core to legacy mobile, IoT, and other markets. So it’s a bit more flexible in terms of how Arm’s partners can use the core."
So upcoming SoCs will have to either choose old cores to keep supporting AArch32 and ditch the efficiency and performance gains of going with all new cores, or drop AArch32 support. I expect the 8 Gen 3 later this year to kick off the drive to drop AArch32, which will drive down to mid-range chips like the 6 Gen and 4 Gen next year.
@finagolfin what you are saying is very correct... but may be limited to the high-end market only.
Recent stats: quite few of the most popular devices are backed by Cortex A55. It's a (little!) core design from 2017 or so. So if you look wider - whatever Arm does now, affects the mass market with a delay of 5+ years. Unless you're only targeting the high end, you have to consider that most of the customers will be running older CPUs, some of them in quite a weird configuration. :(
Yep, the upcoming flagship Snapdragon 8 Gen 3 appears to be AArch64 only, as all its Armv9 cores do not support AArch32, which should then drive down to lower price points in the coming years.
My statistics for 1 week, based on more than 100,000 users. (The application is a game.)
[Arch] [Percentage] arm64-v8a 68.66 armeabi-v7a 30.38 x86_64 0.71 x86 0.26
Thanks! I don't get to see "real" data very often. The whole-ecosystem stats aren't always a reliable indicator of what people are actually doing. That's a considerably higher proportion of x86 than I would have guessed, but still quite low overall.