What will it take for Google to bring 64-bit support to Android?

This article may contain personal views and opinion from the author.
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.

The work that has been done


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.

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. 

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. 

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 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.

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)

FEATURED VIDEO

128 Comments

126. networkdood

Posts: 6330; Member since: Mar 31, 2010

Reading all of these comments - people need to relax - smartphones have not reached their true potential with amount of cores, amount of RA, 64-bit architecture, battery life - optimization in general, etc. Apple is just using 64-bit as another marketing gimmick for the ignorant masses. This will all take care of itself over time...

107. jackto

Posts: 19; Member since: Sep 17, 2013

the future exynos processor will be a monster it will be a octacore with the new armv8 64bit architecture. it will have a quad-core cortex a57(for performance which is more powerful than the a15) and a quad core cortex a53(for power efficiency which is more powerful and more power efficent than the a7) and the new implementation of the hmp solution (meaning true octacore ,and more power efficent than the current exynos on the galaxy note 3). there is also the widcon technology which reduce heating a lot.

125. AppleHateBoy unregistered

I will believe it when I see it. After the Exynos 5410 fiasco, I am not believing whatever Samsung claims about their SoCs.

94. Charlie_boy

Posts: 71; Member since: Jan 04, 2013

JakeLee schooled everyone in microprocessor engineering in the last article. Props for bringing educated discussion back and into PA threads!

120. tedkord

Posts: 17532; Member since: Jun 17, 2009

Looks like Jake is getting schooled in this thread.

122. arcone1

Posts: 18; Member since: Dec 28, 2013

Well he had some misconception how modern VM works (it's actually pretty common since in last decade a lot of new concepts were introduced) so he construct a bit delusioned forecast about future of Android but at least part of his remarks (about ARMv8 efficiency) were valid.

127. elitewolverine

Posts: 5192; Member since: Oct 28, 2013

Not really, i think he gets more so than anyone here, how going from 32 bit instruction to 64bit, natively, efficeintly, is where delvik is faulting at. If all programs wrote in assembly, they would be the fastest programs on earth. Ever try to write assembly? Hence, C, C++, Java, Python (my fav), and the list goes on. They will need a dalvik64 that is good, no great. If not the 64bit arm will not be running 32bit code and 64bit code within the same app because of penalties. I would bet hands on that Jake here, would out code anyone here in assembly, or a program.

128. arcone1

Posts: 18; Member since: Dec 28, 2013

>Not really, i think he gets more so than anyone here, how going from 32 bit instruction to 64bit, natively, efficeintly, is where delvik is faulting at. He has no idea how JIT (or compilers in general) works. >If all programs wrote in assembly, they would be the fastest programs on earth. Ever try to write assembly? Hence, C, C++, Java, Python (my fav), and the list goes on. Microoptimization at machine code level rarely effect in measurable gains (especially with nowadays compilers and OOE). You can gain much more by changing algorithm or data structures (cache coherency). Writing in assembly it's not difficult per se (that is it's not more difficult than writing in high level language) it's just tedious and error prone.

92. livyatan

Posts: 867; Member since: Jun 19, 2013

I still don't see what's the problem here. ARMv8 is running the 32bit code in exactly the same way as the ARMv7. And it has many other areas in which it improves the performance and efficiency. So until the 64bit software is out, things will be absolutely fine for anyone who doesn't want to run full Photoshop, AutoCAD, etc. on Android.

90. Ric.B

Posts: 8; Member since: Jun 17, 2013

Another thing that the Android team is probably focusing more on is perfecting Android Runtime to fully replace the Dalvik VM for running android apps. If I may hazard a guess, I think this ART could be the first step in getting Android apps to run in Chrome OS. This again for me is a bigger win for Android than adopting 64-bit processing.

89. Ric.B

Posts: 8; Member since: Jun 17, 2013

As sexy as 64-bit computing sounds, I reckon it's not something that Google's Android team should worry about. More urgent I reckon is the need to provide a way for OEMs to provide a custom UI without compromising the upgradeability of the OS. Something like a customisable UI layer over the OS core that will ,say, allow Samsung or HTC devices to get upgraded from Android 5.0 to 6.0 without breaking the Touchwiz/Sense UI layer. Conversely, Sammy and HTC can post Touchwiz/Sense updates without affecting the Android core OS. If Google's Android team pulls something like this off, that will be awesome and in my opinion a far better Android OS feature than going from 32-bit to 64-bit processing.

76. jpkelly05

Posts: 110; Member since: Nov 13, 2012

I think this was a great article... but 64 bit, as much of a need as it is to the future, is just as much of a need as 2k displays is for next year. I would rather see more independent processors,like in Moto x or IOS Cameras. I really would love to see a hollographic display device instead of a flexible display. But whatever. Also battery life should be at the top of the list! 16 or 32 GB should be increased 10 fold for device storage. My GS4 or any other current device runs great on 32 bit. Even if you think it has lag. Look at where we were just 5 years ago.

62. InspectorGadget80 unregistered

Why giving so much prop on a 64bit processor? What ever happened to OCTACORE?

67. AppleHateBoy unregistered

You know. Intel said a decade ago that they would have octa core processors in computers by 2008. They are still on 4 cores. Because the extra 4 cores are USELESS. When will you guys get that??

60. roozbeh101

Posts: 99; Member since: Mar 31, 2012

It is a performance battle ! no one gives a damn for who placed it first on the device or OS ! unless u want to brag about how legendary it would be if your device is first on this and everybody got behind! ahemm**hipsters*** ahemm! just a matter of time till we use A8 and its performance boost benefits for portable devices!

59. tedkord

Posts: 17532; Member since: Jun 17, 2009

Google Now is great, but as to it's text to speech in regard to search queries, in so honesty I never use it except to get the phone to read definitions of funny dirty words.

51. Ant34

Posts: 193; Member since: Aug 10, 2013

I think if Android OEMs push for it then Google will implement it. Right now, there's no discernible difference between high end Android smartphones and the iPhone.

49. IHatePhones

Posts: 99; Member since: Aug 12, 2009

I'd imagine that any move on Google's part to go to x64 would end up in even more of a delay in manufacturers Android update timlines, as the manufacturers would have to write 32bit and 64bit drivers for their low end and high end phones hardware respectively. You would all but have to buy a 64bit phone if you wanted "timleIy" updates. Low end devices would be even more obsolete than they already are... I can hear the haters using that damnable word "fragmentation" all over the place again as well. I see no way for this to happen smoothly until all the hardware introduced is already 64bit ready, marketing be damned.

47. Taters

Posts: 6474; Member since: Jan 28, 2013

Android doesn't really have to worry too much. Apple has created a society where Everyone and their grandma will rush to code their apps to support 64 bit. By the time all the developers have everything running on 64bit, Android will be ready for it and smooth sailing from there. And yes, jake lee is wrong like most ifans are.You don't need an article to tell us that. We just know.

48. bigstrudel

Posts: 621; Member since: Aug 20, 2012

JakeLee provides details. He's not the only one that actually supports his arguments. Got any support for your statements? Oh right. "We just know."

71. Taters

Posts: 6474; Member since: Jan 28, 2013

Haha you Apple fans are so dense and clueless that it is hilarious. The whole article is support that Jake Lee was wrong about how difficult it is for Android to upgrade to 64 bit. I need more support than referring to the article? On which planet? Apple land? Lol

50. MichaelHeller

Posts: 2734; Member since: May 26, 2011

Jake Lee was wrong in terms of how he thought Dalvik worked, but he was dead on when it came to explaining the performance benefits of ARMv8 (which is what really gives the A7 its pop, not the fact that it's 64-bit.)

64. tedkord

Posts: 17532; Member since: Jun 17, 2009

The new instruction set will provide benefits, but that has nothing to do with 64bit. A new 32bit instruction set could have easily added similar benefits. 64bit is the red herring, and the majority of the benefit to the 64bit address space is increased memory addressing. It's exactly what we have been saying - Apple is marketing to people who think 64 must be twice as good as 32. Intel did the same thing with their Pentium 4 clock speed, knowing that the average consumer would think that 2Ghz CPUs must be much faster than 1.5GHZ AMD CPUs. Quite the opposite was true.

72. Taters

Posts: 6474; Member since: Jan 28, 2013

Exactly.

80. JakeLee

Posts: 1021; Member since: Nov 02, 2013

Ever heard of flac decoder? It does heavy math in 64-bit integer. On ARM32 it's better doing this with NEON while ARM64 can do this on its own, thus consuming much less power. Ever heard of iDCT? NEON64 does it in a single pass while NEON32 requires at least 4 passes. People discounting 64-bit claim that smartphones are primarily for media consumption, and 64-bit is not needed. I'd say it's exactly where 64-bit computing makes sense the most since iDCT is required for decoding vast majority of image formats : jpeg, h.264, etc.

73. Droid_X_Doug

Posts: 5993; Member since: Dec 22, 2010

"...he was dead on when it came to explaining the performance benefits of ARMv8 (which is what really gives the A7 its pop, not the fact that it's 64-bit.)" Which tends to support the assertion that 64-bit is a bit of a gimmick. Since ARMv8 is not exclusive to 64-bits.

77. Taters

Posts: 6474; Member since: Jan 28, 2013

Your bang on unlike Jake Lee and his Apple posse which are bang off.

78. JakeLee

Posts: 1021; Member since: Nov 02, 2013

First, I'm really impressed and amazed by your well-researched article. You are showing the world how journalism is supposed to be. I really appreciate your efforts. However, I cannot quite agree with you on Dalvik and that I was wrong. I never implied Dalvik will be a hurdle in the way of Android's transition. Dalvik is a 32-bit machine, a 32-bit virtual CPU. An APK file contains dex, the Dalvik executable, byte codes for the 32-bit Dalvik. You can write an interpreter/JIT for ARM64 that works flawlessly, no doubts in that, and vast majority of HLL programmers will be fine with that. However, it just can't run as fast as when the Dalvik machine was a 64-bit one. For example, I could write a simple program that converts ARM32 machine codes to ARM64 ones. But it wouldn't be very useful since it will run noticeably slower than ARM64 codes generated by a compiler directly from the source code. That's what I've been talking about : Java(Dalvik) apps won't benefit from 64-bit computing as much as native ones. The next question would be then : Will there be a Dalvik64 in near future? (not the current Dalvik32 running on ARM64) Probably not, because : - It would be a transition on its own and will worsen the current situation with fragmentation - Java isn't simply a proper language for performance critical apps in first place. Granted, Dalvik will help make Android's transition less painful to some degree. Apps like Twitter will be automatically "64-bit apps" on the day it's installed on Android64. But what's the point? What do customers expect from the 64-bit flagships they just purchased? It's certainly not Twitter waiting for their inputs twice as fast. They want those demanding apps that drove their former phones to their knees to run smoothly. And those are most probably native apps. Now here we are. Android's real problem during the transition : native apps and Dalvik apps relying on native components will take lots of time to be 64-bit ready due to the fragmentation. And since ARMv8 doesn't allow switching the bit numbers it operates in within a task, Dalvik apps with a single 32-bit native component require a separate 32-bit Dalvik interpreter/JIT/ART environment. - an additional burden for Google and OEMs for many years to come.

91. arcone1

Posts: 18; Member since: Dec 28, 2013

Bitness of virtual dalivik registers has nothing to do with underlying HW bitness. JVM is also 32bit VM (stack cell is 32bit). In interpreted mode it doesn't matter and in compile mode (JIT or AOT) compiler will generate correct architecture code (dalvik uses RISC like bytecode and 64k registers but it doesn't stop Intel for implementing JIT for x86). There is bunch of framework code that is not 64bit ready (almost all framework packs pointer into 32 bit java int) but fixing it more tedious than hard and Intel probably did most of the hard work. Since Android is already platform agnostic and support multiple architectures adding new one is not a big deal. Apps with native components can already pack .so for multiple architectures. So the only question is if ARMv8 devices will include legacy ARMv7 apps support (my guess is that they won't but we will see). Truth to be told biggest roadblock is lack of ARMv8 SoC - Apple did spectacular job by creating highly optimized custom SoC 18 (or possibly 24) month before Qualcomm, Samsung'll probably use arm a57 design but hard to say if it already manufacture ready.

95. JakeLee

Posts: 1021; Member since: Nov 02, 2013

We are not talking about a Java compiler, nor about a JVM JIT. We are talking about Dalvik JIT/AOT/interpreter or whatever. And Dalvik is a 32-bit virtual machine. It's a register based one and behaves quite differently from the stack based JVM. The whole Dalvik runtime environment is nothing else than an emulator for the 32-bit Dalvik virtual CPU. A smart JIT compiler could generate decent machine codes benefiting from the 64-bit wide architectural registers when 64-bit arithmetics are done, but you cannot expect it to be always the case. A very common practice dealing with division by constant is a long q32 multiplication like. res = (a*b)>>32; res += c; . . If the register is 64-bit wide, it will be compiled pretty much in a 1:1 manner with a right shift and an addition at the end, indicating that the fraction bits are not required anymore. X0 = a*b; X0 >>= 32; X0 += c; However, Dalvik -being a 32-bit machine- has to span this 64-bit value over two 32-bit registers like : [high:low] = a*b; high += c; . . When the code above is executed on ARM32, it's just fine, but ARM64 is confused and will probably do the following : X0 = a*b; X1 = X0>>32; W1 += c; X0 &= 0xffffffff; X0 += (X1, lsl 32) [continued in next comment]

Latest Stories

This copy is for your personal, non-commercial use only. You can order presentation-ready copies for distribution to your colleagues, clients or customers at https://www.parsintl.com/phonearena or use the Reprints & Permissions tool that appears at the bottom of each web page. Visit https://www.parsintl.com/ for samples and additional information.
FCC OKs Cingular's purchase of AT&T Wireless