64-bit CPUs deliver faster, richer experiences for your users. Adding a 64-bit version of your app provides performance improvements, makes way for future innovation, and sets you up for devices with 64-bit only hardware.
We want to help you get ready and know you need time to plan. We’ve supported 64-bit CPUs since Android 5.0 Lollipop and in 2017 we first announced that apps using native code must provide a 64-bit version (in addition to the 32-bit version). Today we’re providing more detailed information and timelines to make it as easy as possible to transition in 2019.
Important information for Android developers regarding requirements around 64bit support.
I don’t buy the idea that all apps need to be able to handle 8 bytes of data at once, I believe this is a preparation move by Google so they can clean up certain things in the future.
I think though Google is a jerk on this and 32-bit executables should still be served on 64-bit devices, because there are lots of old unmaintained games and old unmaintained gadget “companion apps” (for all kinds of wireless speakers, USB TV modules etc) out there that are 32-bit only. Android already has retro Android games from the early days of the OS and it ‘d be great if they still worked on new devices.
I agree! In general, I do not get the push towards 64-bit in general. While it makes absolute sense in the x86 world, where x86-64 introduced a plethora of new registers and features, I find it makes little sense in the RISC world, where the only advantage of 64-bits is longer pointers/arithmetic.
Additionally, there’s a huge downside for RISC architectures: instructions are now 64-bit in length, instead of 32, effectively doubling the size of every program for little positive benefits. For Android, this is particularly troublesome, considering a large majority of devices do not have >4GB of RAM, and also have limited storage space.
It’s about a device being able to use 64-bit integers at once and do SIMD (same instruction on multiple data) on 64-bit floating point numbers.
Don’t know if 64-bit floating arithmetic on plain variables is exclusive on ARMv8 or not. Keep in mind 32-bit CPUs can do 64-bit floating if the instruction set defines the necessary instructions (x86-32 could do it).
In any case, 64-bit is mostly of interest to modern graphical apps who can benefit from the performance benefit of doing 64-bit floating point natively. The deprecation of 32-bit is so OS vendors can keep things clean.
kurkosdr,
x86 CPUs have long supported 80bit floating point (going all the way back to the 8087 math coprocessor) even on it’s 16bit CPUs.
https://en.wikipedia.org/wiki/Extended_precision
The newer SSE instruction set reduced that to 64bit doubles and 32bit floats. I don’t don’t as much about ARM architecture & history, but as you noted a 64bit CPU isn’t prerequisite to 64bit floating point (or more). 32bit applications can and do have 64bit floating points. What’s more, 64bit registers can be used regardless of 32bit/64bit addressing modes. It’s important for people to understand it’s not an all or nothing proposition, you can make use of more&larger registers without committing to 64bit memory.
Ironically many GPGPU applications are going the other way (support 32bit and even 16bit but not 64bit).
You may be right though, the vendors may deprecate 32bit because they don’t wan’t to support it any more, rather than because 64bit addressing is better for everything (it clearly isn’t for many applications that won’t benefit from it at all).
ARMv8 instructions are still 32-bits in size, so code size isn’t going to be much bigger. Only load/store operations than need a memory address would be larger.
For that matter, Sparc v9 also uses 32-bit instructions, even though it’s a 64-bit architecture, as does 64-bit MIPS.
I think the main goal is just to drop 32-bit support on 64-bit Android. It make OS images smaller since 32-bit libraries won’t need to be kept.
First, not all RISC CPU’s use 64-bit wide instructions in 64-bit mode. ARMv8 does not, and that’s what Android cares about here.
The big advantage here though is actually _smaller_ ROM images. To support 32-bit apps on a 64-bit ROM, you need all the public libraries _twice_, because you can’t switch execution modes when calling into another library. The practical difference this makes in system size can be really significant. For example, on my laptop (running Gentoo Linux), the 32-bit support files account for about 1/10 of the space taken up by the OS, and that’s with less than half of the libraries I have installed built for 32-bit support. On a typical Windows 64-bit system, 32-bit support accounts for more than 1/3 of the space taken up by the OS. Android is probably closer to roughly 1/5 to 1/4, which on many Android phones works out to at least 1GB of space that could be saved.
Secondary advantages include the ability for applications to use a bit more address space (even with less than 4G of RAM), improved computational performance (yes, 64-bit actually does help here a bit even on ARM), easier interaction with some hardware, and usage of some ARMv8 features that only work in 64-bit mode.
Very interesting stat. Can you explain how you found out that number? Did you just find it somewhere or did someone write a tool that goes through every file to check for (non)-64bitness?
teco.sb,
I agree with you, 32bit (2/4GB addressing) is plenty for the vast majority of software, especially on mobile. There’s not much to be gained with 64bit integers & pointers for the majority of software in existence. The circumstances for x86-64 are a bit unique because AMD simultaneously added new registers and did away with a lot of legacy x86 architecture, which can be greatly beneficial, but 64bit in and of itself is only marginally useful for typical software even to this day. This isn’t to say I’m not glad to have it, but in my opinion it makes sense to let developers target 32bit in cases where 64bit doesn’t add value.
I think ahferroin7 makes a decent argument below:
However I’m not entirely convinced the shared library problem is an issue on android without more research. If it is, then in principal, it ought to be fairly easy to make dalvik/art automatically generate 32bit stub functions that call the 64bit libraries. It also ought to be fairly easy to modify the global 64bit allocator to limit itself to 32bit addresses and return out of memory when more than 4GB is requested for 32bit android programs. These two changes should address ahferroin7’s concerns without requiring any duplicated libraries. There could be a bit more overhead but it’s likely an acceptable trade-off when running legacy software programmed for older CPUs.
>>While it makes absolute sense in the x86 world, where x86-64 introduced a plethora of new registers and features, I find it makes little sense in the RISC world, where the only advantage of 64-bits is longer pointers/arithmetic.
—
ARMv8 is much more important than x86-64.
Register files are increased from 16 to 32 registers.
SIMD engine is IEEE754, supports 64-bit floating point math and can actually be used in real calculations.
New instruction set to make OoO engine simpler and faster.
>>Additionally, there’s a huge downside for RISC architectures: instructions are now 64-bit in length, instead of 32, effectively doubling the size of every program for little positive benefits.
—
No, that’s not how 64-bit processors work.
>>For Android, this is particularly troublesome, considering a large majority of devices do not have >4GB of RAM, and also
have limited storage space.
—
32-bit pointers are extremely limited.
You can’t map a large enough file in virtual address space.
Language runtime can’t use pointer tags supported by ARMv8 hardware.
viton,
For database/scientific applications/etc I’d agree with you, but when we’re speaking about typical mobile apps though, the vast majority are not constrained by 32bit limits. Even assuming the use of memory mapping (which is rare for java software), 32bit should still be plenty compared to the typical APK size; google’s doubled the max from 50MB to 100MB in 2015, So for the average app, 64bit doesn’t do much. I’m not saying it’s impossible for a mobile app to benefit from more than 32bits worth of address space, but IMHO it seems like the exception rather than the norm. However I’m certainly interested in hearing about counter examples, non-theoretical examples would be better 🙂
To be clear, I’m not really arguing against 64bit, not at all, but 32bit still seems perfectly sufficient for most cases..
edit: @post by Alfman 2019-01-17 4:08 pm EST (threading again didn’t work, grr)
Though they size of APK doesn’t automagically translate to RAM usage…
zima,
I am perplexed as well, although given my habit of addressing my posts up front, it’s a little less of an issue.
Sorry I wasn’t clear, In my response I was referring to memory mapping specifically, which viton brought up. MMIO is most often used to map existing data files into ram. For mobile APK files, the 32bit address space doesn’t seem especially problematic in most cases.
64bit addressing has obvious benefits in the long run, but I still think normal user applications that benefit from it today are in the minority. Google’s new policy will undoubtedly result in wide-scale migration to 64bit code, but I really don’t expect most mobile apps will see much if any benefit.
Anyways, I didn’t mean to hammer the point as much as I have, it was merely intended as passing commentary, haha.