What will it take for Google to bring 64-bit support to Android?
Last week, I posed the question concerning how much credit Apple deserves for the coming 64-bit evolution. The TL:DR version goes like this: 64-bit was already in the works in mobile in various ways. Apple certainly built the base quickly, and switched over its platform quite seamlessly, but being first to fully push into 64-bit doesn't necessarily mean that Apple deserves credit for something that was inevitable, especially since the ARMv8 architecture that the A7 uses was first unveiled two years ago. However, it is obvious that Apple deserves credit for making the switch so quickly, and such a long time before any other mobile platform. Apple also deserves credit for making the issue so public, and forcing the competition to move faster on their plans because of how quickly iOS is making the switch.
Interestingly, the comment thread of the editorial didn't focus so much on the question that I had posed, but rather on a run of information from a reader by the name of JakeLee. JakeLee didn't so much refute the points I had laid out as he claimed that Google has a long, difficult road ahead if it expects to optimize Android for 64-bit in the near future. The info from JakeLee has helped to inform this article. Although, my own research into the matter, and help from the Android Developers community on Google+ has shown that the future may not be as troubled for Android as JakeLee made it sound.
First off, I need to clear up a misconception that is often made, and one that I had myself before doing the research for this piece: when talking about mobile devices, there is no real reason to talk about the 4GB RAM limit that 64-bit helps to surpass. 64-bit is actually a misdirection in the mobile space, because the real issue is moving to the ARMv8 processor architecture. ARMv8 and its brand new instruction set architecture (ISA) are responsible for the real performance boosts that we will see, and it just so happens that this change coincides with the switch to 64-bit. The reason that 64-bit is mentioned and not ARMv8 is because 64-bit is a term that even average consumers and mass media understands to a certain extent. There are plenty of performance benefits to be had on devices that are nowhere near 4GB of RAM, like the iPhone 5s.
As we just learned from HTC, chipset makers build the drivers for processors when Google releases the source code for a new Android release, so ARMv8 support is probably already in the works, but Google still needs to optimize Android for the new hardware.
There are pieces of the puzzle that are already in place for Android. As has been mentioned before, the Android kernel includes 64-bit support, which it has inherited from Linux. It is also known that multiple manufacturers are working on 64-bit processors for the next generation of Android handsets. Samsung let it be known very soon after Apple's announcement of the iPhone 5s and A7 SoC that it was working on a 64-bit version of its Exynos chipset. Qualcomm obviously had a bit of a PR fiasco after Apple's announcement, but then recently introduced its first 64-bit mobile processor, the Snapdragon 410, with the implication being that the mid and high-end Snapdragon 610 and 810 would be on the way at some point, and also support 64-bit.
Some also mistakenly try to point to Android 2.3 Gingerbread as a point where Google trying to push Android into a 64-bit world. When Gingerbread came out about three years ago, Google made it a requirement when compiling the actual Android system software to use a 64-bit environment. But, this requirement didn't actually bring the Android software itself any closer to 64-bit support, it was only done in order to reduce the time it took to build the system software.
Yep. That's it. That's all that has been done. Some of you may have expected that last section to be longer, but so far Google has not been taking many steps to bring 64-bit to Android. In fact, there has been no change to the Android Developers documentation, which still states that “Android is currently expected to run on 32-bit platforms. In theory it could be built for a 64-bit system, but that is not a goal at this time.”
All of the Android runtime libraries (media, graphics, file system, etc) and the drivers for the myriad devices are all 32-bit, and would need to up rebuilt for 64-bit, but this shouldn’t be too difficult to do. Really, I could end this section right here, because that’s all the work that needs to be done to move Android to 64-bit compatibility, at least on Google’s side.
Right now, both the Dalvik VM and ART use a 32-bit register, and there is really no way to change that with the current implementation. But, these registers are abstract entities not related to hardware, so they wouldn’t really cause any problems in switching Android to 64-bit. As stated above, the app code is executed directly, so any apps written in Java would be able to run without issue. At most, an app might have to pass through an interpreter, because of minor differences in coding for 32 and 64-bit in Java. But ultimately, using Dalvik or ART makes it easier for Android to move to new hardware (ARMv7, ARMv8, x86, etc) rather than making it more difficult.
The work that has been done
 |
Some also mistakenly try to point to Android 2.3 Gingerbread as a point where Google trying to push Android into a 64-bit world. When Gingerbread came out about three years ago, Google made it a requirement when compiling the actual Android system software to use a 64-bit environment. But, this requirement didn't actually bring the Android software itself any closer to 64-bit support, it was only done in order to reduce the time it took to build the system software.
The work left to be done
Yep. That's it. That's all that has been done. Some of you may have expected that last section to be longer, but so far Google has not been taking many steps to bring 64-bit to Android. In fact, there has been no change to the Android Developers documentation, which still states that “Android is currently expected to run on 32-bit platforms. In theory it could be built for a 64-bit system, but that is not a goal at this time.”
All of the Android runtime libraries (media, graphics, file system, etc) and the drivers for the myriad devices are all 32-bit, and would need to up rebuilt for 64-bit, but this shouldn’t be too difficult to do. Really, I could end this section right here, because that’s all the work that needs to be done to move Android to 64-bit compatibility, at least on Google’s side.
**Beginning technical section. It has been simplified as much as possible, but feel free to skip down if you don't want to muddle through the jargon.**
Another issue that came up quite a bit in JakeLee’s comments was the fact that Android’s Dalvik Virtual Machine uses a 32-bit register, but that turns out to not really be an issue at all. To simplify the explanation of how an Android app works - a developer will write the app code in Java which gets compiled and packaged as an APK. There are then two ways APK is run on an Android device - either the Dalvik VM will execute it directly as bytecode using the Dalvik just-in-time (JIT) compiler. Or, the new ART (Android Runtime introduced in Android 4.4),
Android will move to an ahead-of-time (AOT) runtime, which means the app is broken down to bytecode at the time of installation and only the necessary portions of code will be run at the time it is needed.
Another issue that came up quite a bit in JakeLee’s comments was the fact that Android’s Dalvik Virtual Machine uses a 32-bit register, but that turns out to not really be an issue at all. To simplify the explanation of how an Android app works - a developer will write the app code in Java which gets compiled and packaged as an APK. There are then two ways APK is run on an Android device - either the Dalvik VM will execute it directly as bytecode using the Dalvik just-in-time (JIT) compiler. Or, the new ART (Android Runtime introduced in Android 4.4),
 |
Right now, both the Dalvik VM and ART use a 32-bit register, and there is really no way to change that with the current implementation. But, these registers are abstract entities not related to hardware, so they wouldn’t really cause any problems in switching Android to 64-bit. As stated above, the app code is executed directly, so any apps written in Java would be able to run without issue. At most, an app might have to pass through an interpreter, because of minor differences in coding for 32 and 64-bit in Java. But ultimately, using Dalvik or ART makes it easier for Android to move to new hardware (ARMv7, ARMv8, x86, etc) rather than making it more difficult.
**End technical section**
The only real issue that Google would face as far as apps and compatibility is with apps that use Android’s NDK to code with C/C++. Those apps would need to have the native bits rewritten for 64-bit compatibility, or else Android would have to have two different versions of the runtime to accommodate those apps, which could lead to performance and battery life issues.
All of that aside, you hit the only real roadblock, which is the same roadblock that has caused problems with Android since its first days. Google would have to do something that it has never been able to do before with Android - getting developers and manufacturers to follow the plan, not jump the gun on hardware, and push software updates quickly.
This has been a constant struggle for Android, and one that has been getting better over time, but one that still isn't fixed enough to make the transition to 64-bit any easier. As we’ve seen with tablets and multi-core processors, Android hardware makers never want to wait for the system to be optimized before introducing new hardware. Android tablets first shipped well before the system
was ready, leading to the forgotten Android 3.0 Honeycomb update, which was just a stop-gap on the way to the proper Android 4.0 Ice Cream Sandwich update.
The real work will be in getting developers to update apps with native code for the new 64-bit platform; but it is obvious that the 64-bit hardware is coming soon, much sooner than it will take Google to update Android for 64-bit. This will lead the whole ecosystem to end up in the same vicious cycle where manufacturers will push hardware before the software is ready, and then will likely be slow to update software once the optimizations are done. The first part of the problem will likely occur not through any fault of Google's, but rather because manufacturers (read: Samsung) will want to make sure they have that 64-bit processor in the newest flagship device - and more importantly, in its marketing campaign - before Android is ready to handle it. Then, once Android does get the update to 64-bit, users will have to wait a bit for manufacturers to push out that update.
Of course, this isn’t necessarily a problem for consumers per se, more of an annoyance for those of us who pay attention and understand the real story. All it means is that we will all be subjected to marketing campaigns touting features that offer no real value, which is nothing new. We've seen plenty of features gracing various marketing campaigns that don't really make much difference to the majority of users, like Air Gestures, Face Unlock, and Siri. Samsung and others will undoubtedly market that their products have 64-bit processors, and will conveniently leave out that they offer little to no benefit because the software isn’t ready. But, that is the way marketing works all around anyway, and the average consumer won’t know the difference anyway.
While hardware manufacturers plan to jump the gun and put out 64-bit hardware running software that isn’t optimized, Google hasn’t mentioned at all when we should expect a 64-bit optimized version of Android. Getting there will doesn’t look to be that rough of a road, but it will certainly take time to get there. So, it’s impossible to say when Android will be fully optimized from top to bottom.
The only real issue that Google would face as far as apps and compatibility is with apps that use Android’s NDK to code with C/C++. Those apps would need to have the native bits rewritten for 64-bit compatibility, or else Android would have to have two different versions of the runtime to accommodate those apps, which could lead to performance and battery life issues.
The same major roadblock as always
All of that aside, you hit the only real roadblock, which is the same roadblock that has caused problems with Android since its first days. Google would have to do something that it has never been able to do before with Android - getting developers and manufacturers to follow the plan, not jump the gun on hardware, and push software updates quickly.
This has been a constant struggle for Android, and one that has been getting better over time, but one that still isn't fixed enough to make the transition to 64-bit any easier. As we’ve seen with tablets and multi-core processors, Android hardware makers never want to wait for the system to be optimized before introducing new hardware. Android tablets first shipped well before the system
 |
The real work will be in getting developers to update apps with native code for the new 64-bit platform; but it is obvious that the 64-bit hardware is coming soon, much sooner than it will take Google to update Android for 64-bit. This will lead the whole ecosystem to end up in the same vicious cycle where manufacturers will push hardware before the software is ready, and then will likely be slow to update software once the optimizations are done. The first part of the problem will likely occur not through any fault of Google's, but rather because manufacturers (read: Samsung) will want to make sure they have that 64-bit processor in the newest flagship device - and more importantly, in its marketing campaign - before Android is ready to handle it. Then, once Android does get the update to 64-bit, users will have to wait a bit for manufacturers to push out that update.
Of course, this isn’t necessarily a problem for consumers per se, more of an annoyance for those of us who pay attention and understand the real story. All it means is that we will all be subjected to marketing campaigns touting features that offer no real value, which is nothing new. We've seen plenty of features gracing various marketing campaigns that don't really make much difference to the majority of users, like Air Gestures, Face Unlock, and Siri. Samsung and others will undoubtedly market that their products have 64-bit processors, and will conveniently leave out that they offer little to no benefit because the software isn’t ready. But, that is the way marketing works all around anyway, and the average consumer won’t know the difference anyway.
A slow path to faster speeds
While hardware manufacturers plan to jump the gun and put out 64-bit hardware running software that isn’t optimized, Google hasn’t mentioned at all when we should expect a 64-bit optimized version of Android. Getting there will doesn’t look to be that rough of a road, but it will certainly take time to get there. So, it’s impossible to say when Android will be fully optimized from top to bottom.
 |
The earliest we could hope to see Android with proper 64-bit support and optimization throughout the system would be in the summer along with the Nexus 7 (2014), but even that is pushing it too much. More likely, we’ll see a minor update to Android 4.4 KitKat at Google I/O, and Android 5.0 (Laffy Taffy, maybe?) with proper 64-bit optimization in the fall with the Nexus 5 (2014). Even then, users will have to wait for manufacturers to update devices; and, to make things worse, that hardware is likely going to be claiming 64-bit on spec sheets well before Android is ready.
All of this needs to be sorted out, because ARM processors are quickly hitting a performance plateau, because of an outdated instruction set architecture (ISA). ARMv8 has introduced a completely new ISA, and made the switch to 64-bit, both changes which will lead to faster speeds as long as software is optimized properly. Unlike on desktops, the argument about hitting the 4GB RAM limit is nowhere near the most important factor when talking about the performance benefits of moving to ARMv8 and 64-bit. Clock speeds can’t get much faster without causing heat and battery issues, and adding more cores will only get you so far, unless they are specialized cores to offload low-power processes, like we’ve seen with the motion and voice coprocessors in the Moto X and iPhone 5s. The most efficient way to increase performance on an ARM chip is to switch to the ARMv8 architecture because it can do the same in a single transfer as 32-bit ARM can in as many as 32 transfers, but that requires the software optimizations before you see the real performance increase.
So, we should all prepare ourselves for a lot of empty promises from Android hardware makers over the next year. But, if we keep an eye on Google, and the news coming out about the official software optimizations, we should get a much better idea of when to expect the real changes. 64-bit is certainly on the way, but the real news will be when Android is properly optimized for ARMv8.
reference: Is Android 32-bit or 64-bit?, Android Developers 1 & 2, +Android Development Community (a special thanks to Bartlomiej Janusz for being so patient with my questions)
All of this needs to be sorted out, because ARM processors are quickly hitting a performance plateau, because of an outdated instruction set architecture (ISA). ARMv8 has introduced a completely new ISA, and made the switch to 64-bit, both changes which will lead to faster speeds as long as software is optimized properly. Unlike on desktops, the argument about hitting the 4GB RAM limit is nowhere near the most important factor when talking about the performance benefits of moving to ARMv8 and 64-bit. Clock speeds can’t get much faster without causing heat and battery issues, and adding more cores will only get you so far, unless they are specialized cores to offload low-power processes, like we’ve seen with the motion and voice coprocessors in the Moto X and iPhone 5s. The most efficient way to increase performance on an ARM chip is to switch to the ARMv8 architecture because it can do the same in a single transfer as 32-bit ARM can in as many as 32 transfers, but that requires the software optimizations before you see the real performance increase.
So, we should all prepare ourselves for a lot of empty promises from Android hardware makers over the next year. But, if we keep an eye on Google, and the news coming out about the official software optimizations, we should get a much better idea of when to expect the real changes. 64-bit is certainly on the way, but the real news will be when Android is properly optimized for ARMv8.
reference: Is Android 32-bit or 64-bit?, Android Developers 1 & 2, +Android Development Community (a special thanks to Bartlomiej Janusz for being so patient with my questions)
