←back to thread

Transition to using 16 KB page sizes for Android apps and games

(android-developers.googleblog.com)
95 points ingve | 6 comments | 11 Jul 25 07:04 UTC | HN request time: 0.415s | source | bottom
Show context
nubinetwork ◴[15 Jul 25 02:01 UTC] No.44567177[source]▶
I can understand the desire for google to want devs to recompile their apps, but I don't see the need to dump old apps from the app store... who cares if an old app that works wastes 12k if it only needs a single 4k page?
replies(7): >>44567219 #>>44567321 #>>44567891 #>>44567924 #>>44568023 #>>44568923 #>>44571850 #
ryao ◴[15 Jul 25 02:11 UTC] No.44567219[source]▶
I am not familiar with Android, but Linux ELF binaries that specify 4KB alignment will not work on systems with 16KB page sizes, since the ELF interpreter will refuse to load them. This hit me recently when trying to run a 32-bit binary on a Linux ARM system that had 16KB size pages, since the 32-bit OpenSSL libraries specified 4KB alignment. Presumably, this was done for maximizing entropy available to ASLR, but it breaks the binaries when the page size increases.

In any case, I assume that there is something similar affecting Android.

replies(2): >>44567516 #>>44571146 #
1. mapt ◴[15 Jul 25 13:48 UTC] No.44571146[source]▶
As a user not involved in android or linux development: I don't care. Fix it. You just don't break the entire ecosystem of unmaintained apps for a 3% performance improvement.

We maintained win32-x86 executable compatibility for decades. Keeping things working might require some sort of emulation layer, and it might impact performance substantially, and that's fine. I can accept that.

"Everything just stops working" is not an option for a real operating system. I don't expect to put my workshop tools away and wake up in the morning to find the toolchest manufacturer sent them to the landfill because they didn't efficiently fit their new drawers.

One of the areas that Android is common in that I couldn't possibly recommend is home automation. Your light switches are 50-year purchases. Odds that the app based light switches are working in five years are 50/50... Compound odds of longer are miniscule.

replies(2): >>44571312 #>>44573214 #
2. Grazester ◴[15 Jul 25 14:05 UTC] No.44571312[source]▶
Is anything industrial is going to be built on Android. There are no ATM's, no manufacturing CNC machines etc. One my say everything that runs on Android is throw away. It is only recently Samsung and Google started to aim at 7 year life spans. At 7 years for an industrial piece of equipment, I may not have even paid it off as yet, then again is the software on these things even updated?
replies(1): >>44571434 #
3. cbarrick ◴[15 Jul 25 14:20 UTC] No.44571434[source]▶
Point of sale systems, like Toast. Media systems on airplanes. Infotainment systems in cars.

In fact, NCR does sell an Android-based ATM solution. [1]

Android is actually used somewhat widely in embedded systems that need to provide a nice GUI to the user.

[1]: https://www.zdnet.com/article/ncr-launches-kalpana-an-androi...

replies(1): >>44578656 #
4. ars ◴[15 Jul 25 16:50 UTC] No.44573214[source]▶
I think most apps are written in Java, and according to the blog post will not be affected.

It's only the apps written in c++ that need to be compiled, and those are probably large games and heavily performance critical apps.

replies(1): >>44587805 #
5. userbinator ◴[16 Jul 25 04:24 UTC] No.44578656{3}[source]▶
Fortunately, like a truly embedded system, those are usually completely independent of Google or its app store.
6. iggldiggl ◴[16 Jul 25 23:08 UTC] No.44587805[source]▶
Checking some random apps on my phone, it's very much not just games, and not just apps you'd naively suspect of being "heavily performance critical", either.

I suspect that code reuse of existing libraries not written in Java is another important use case.