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

What will it take for Google to bring 64-bit support to Android?
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),
What will it take for Google to bring 64-bit support to Android?
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
What will it take for Google to bring 64-bit support to Android?
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.

What will it take for Google to bring 64-bit support to Android?
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)



1. starandmountain

Posts: 53; Member since: Apr 01, 2012

nice story again! thanks:)

10. rf1975

Posts: 264; Member since: Aug 01, 2011

Only different is, if this was done by any other manufacturer or Google, then most of them including PA will call it as a real innovation.

18. Ashoaib

Posts: 3269; Member since: Nov 15, 2013

What will it take from google to bring 64bit support? very simple answer.... a hard work for few months, and thats it... ;)

29. androiphone20

Posts: 1654; Member since: Jul 10, 2013

I recommend you go through the article again, it wont go down that easy pushing 64bit support will likely be seen next to Nexus 7 (2014) and is also too early. Google will have to ask developers who use native code (NDK) to move to 64bit. Manufactures and developers would have to wait for Google's call but some already rushed to it (Sammy)

52. tedkord

Posts: 17131; Member since: Jun 17, 2009

Very few apps in Android use native code. Most are written in Java. Hardware drivers, the ROM itself, yes. Those aren't Google's responsibility. The other consideration is we don't know what work Android has already done. It doesn't become open source until they release it. This isn't going to be nearly as difficult as some partisans want to paint it.

82. JakeLee

Posts: 1021; Member since: Nov 02, 2013

What do you think is in the ROM? AOSP by none other than Google. And what does make you think most apps are written in Java? Google introduced NDK around the launch of Eclair, and it's exactly the time Android apps became interesting.

87. arcone1

Posts: 18; Member since: Dec 28, 2013

Most apps are written in java, most games are written in native - this is why Google introduced NDK, to allow seamless and easy way to port games.

102. JakeLee

Posts: 1021; Member since: Nov 02, 2013

I'd say most simple client apps. I don't think PowerAmp is written in Java. Hard to imagine fft running properly when written in Java.

117. KRONeage

Posts: 144; Member since: Apr 17, 2011

Java is actually a great language to code in. Because of it being a containerized Application layer. That can be written in any language for near any system. Including 64bit Apps and games on PC's to mobiles. Even the greatest games can run in the Dalvik VM and it.... unlike Java can run more than one App at a time. You can stuff a monster 4K video in a java VM. Because it's designed as a cross platform equalizing container capable of even running a whole OS if a developer wants it to inside a VM. Not unlike Sun's Looking Glass Project! But..... Google has a whole new ground up written replacement in Android Kit-Kat for a runtime replacement and it's actually no longer compiled at run time with a "Just in time Compiler (JIT)". The libraries for Android aren't just Java you know. They've written some of their own code and all they're doing is making it easier for developers to code in a high level language they already know! Would any developer in his right mind stuff any high end game to run in a Java VM today? Not on your life! ....but Android is a different story. Especially with the new Dalvik replacement compiled at install. Like games on desktops or Consoles!

118. tedkord

Posts: 17131; Member since: Jun 17, 2009

What is in the ROM depends on the OEM. If it were simply AOSP, updates would be almost instantaneous. Most apps are written in java because it's simpler, easier to debug and has almost no penalty because of Dalvik.

81. JakeLee

Posts: 1021; Member since: Nov 02, 2013

An extremely hard work for a whole year at least, and lots of extra workloads for many years to come - all thanks to the fragmentation.

124. arcone1

Posts: 18; Member since: Dec 28, 2013

Iit's at most few month of work (which is probably done already).

32. Droid_X_Doug

Posts: 5993; Member since: Dec 22, 2010

+1 on thanks for the informative article. Given the timeline for 64-bit to fully populate (hardware, O/S and apps), it would seem that rushing to upgrade to 64-bit in the Android space until probably 2015 is something of a fools errand.

65. steedsofwar unregistered

To me the article is saying that a) it isn't really to do with 64bit but more to do with armv8? which the i5s has? b) even though the i5s has armv8 and 64bit ready and has optimised its OS to be compatible, the app store apps are yet to update and enjoy the benefits. i.e. Apple is two thirds of the way there. c) even in its current form, the improvements in real world usage over the other 32bit non armv8 devices is still arguably negligible RIGHT NOW. d) It isn't hard for Google to do the same as Apple but they ARE behind. Samsung will simply meet one third of the equation by providing the hardware for the other two parts to catch up i.e. the OS (up tp Google to optimise) and the apps (up to individual apps to optimise).

2. Rajanvir

Posts: 56; Member since: Dec 11, 2013

I m just waiting for LG G3 with NVIDIA Tegra 5 inside

16. Teja171 unregistered

According to the rumours, the LG G3 will come with their home grown LG ODIN octa-core soc.... Even i wish that it comes with an Nvidia Soc. :)

19. Ashoaib

Posts: 3269; Member since: Nov 15, 2013

Shhhhh! LG is reading n they will release with tegra5 for you :p

33. Droid_X_Doug

Posts: 5993; Member since: Dec 22, 2010

Hopefully the manufacturers will focus on other areas to innovate. Like camera modules with full OIS and low-noise image processing. That would helpd bridge the roughly 2 year gap before 64-bit was fully populated.

3. Loubielou

Posts: 603; Member since: Jul 11, 2012

Samsung deserves the Credit not Apple for creating the 64gb bit processor,thats whats people have got stop praising Apple to much,without Samsung ,Apple would find it hard to get someone else to do this for them,just can"t wait to see the new Samsung Galaxy S5 at the MWC

4. PapaSmurf

Posts: 10457; Member since: May 14, 2012

... You mean ARM?

9. rf1975

Posts: 264; Member since: Aug 01, 2011

There is a big different between manufacturing & designing.

12. bigstrudel

Posts: 574; Member since: Aug 20, 2012

Thats like saying you created a peice of furniture that came out of Ikea.

13. Quezdagreat

Posts: 428; Member since: Apr 05, 2012

Apple designed, samsung manufactured and copied

54. tedkord

Posts: 17131; Member since: Jun 17, 2009

Samsung copied something that ARM announced as coming out in Q1 2014 a full year before the A7? That's prescient.

69. Quezdagreat

Posts: 428; Member since: Apr 05, 2012

How come they called it a marketing gimmick when Apple came out with it even though Samsung manufactured it?

119. tedkord

Posts: 17131; Member since: Jun 17, 2009

Because the 64bit was a marketing gimmick aimed at people who think 64bit means twice as good as 32bit. They retracted it because they are and have been for some time planning their own 64bit mobile SOCs (also based on ARMs new instruction set) and knew that the comments would haunt them later.

121. Quezdagreat

Posts: 428; Member since: Apr 05, 2012

64 bit is a gimmick for android because the os is not 64 bit ready

84. kabhijeet.16

Posts: 884; Member since: Dec 05, 2012

Samsung created the 64-bit chip for Apple.. Apple used it.. So apple is innovative... LOL

20. Ashoaib

Posts: 3269; Member since: Nov 15, 2013

this is a thing, people praise apple for making designs on paper although it doesnt has a capacity to create anything physically, while the one(sammy) who has a capacity n capability to do things practicly is booed for copy

30. bigstrudel

Posts: 574; Member since: Aug 20, 2012

Dude its normal procedure for every smartphone maker to part out their manufacturing. Every Galaxy device sold in the US in the last couple years is using processors designed in the US by Qualcomm and fabricated in Taiwan.

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.