We tested Android 5.0 using the Moto X, Moto G, LG G3 and Galaxy S5 smartphones. Here's how it went down...
This article is a long time coming.
Google released Android 5.0 'Lollipop' last November, a major milestone in the life of today's most popular mobile operating system. Like with most Android revisions, the update was pushed over-the-air to Nexus devices and all was well in the vanilla Android camp. Google took the opportunity to launch new devices, too, the Nexus 6 smartphone and Nexus 9 tablet, complete with Android 5.0 support out of the box.
But again, like with every major Android software update, those without a Nexus device have had to anxiously wait for new software to hit their phone. Contrast this to iOS or Windows Phone, both of which come with fast upgrade pathways, and Android's update rollout scheme seems severely outdated and frustrating for users.
However this article isn't meant to expose how awful the Android upgrade system is, because frankly, everyone knows this already. Instead, I'm seeking to explore how updates to the core architecture in Android 5.0 have improved performance and battery life on existing handsets. For that, I needed to wait until official updates hit for some of the leading devices out there, something that took a lot of patience.
Before I dive into some of the improvements in Android 5.0 "Lollipop", it's interesting to explore the global rollout of the software across some of the devices I have in my possession.
The first thing to note is that not every version of the one smartphone was created equally. Devices like the Galaxy S5 have many different SKUs that are littered around the globe, and software development teams within the company work at different rates on different SKUs. Sometimes even regional versions of the same SKU aren't updated at the same time: a perfect example is the SM-G900I Galaxy S5 I have with me, which has been updated to Android 5.0 in Taiwan, but not in Australia. Other variants, like the G900H, are still stuck on Android 4.4.4.
Of the ten Android smartphones I have in my office, global Android 5.0 rollouts for some SKUs have only begun for four of them: the Moto X 2014, Moto G 2014, LG G3 and Galaxy S5, in that order. Of those four, the Moto X 2014 is the only smartphone that that allowed me to update over the air to Android 5.0 in Australia. The other three were either just about to get Lollipop, or a local rollout hasn't begun.
As for the other six handsets, most of them are set to receive Android 5.0 at some point in the future, or so their manufacturers promise. The Galaxy Note 3 appears on the cusp of receiving an update, while updates for the Xperia Z2 and Z1 aren't far off. Motorola announced an update for the Moto X 2013, though who knows when that will arrive.
The newly released Galaxy A5 shipped without Android 5.0 and I have no hope for the BenQ-manufactured Kogan Agora 4G.
Having a newer device isn't an immediate ticket to Android 5.0 either. Devices I've recently reviewed, such as the Galaxy Note 4, Note Edge and Galaxy Alpha, Sony Xperia Z3, and Huawei Ascend Mate 7 haven't received Android 5.0. The only other recent phone that has received the update that I can immediately think of is the HTC One M8.
Anyway, enough talk about the update process, it's time to talk about Android 5.0 itself. How could Google have squeezed more performance and more battery life out of a simple software update, you ask? Well, it comes down to ART, AOT compilation, and Project Volta.
ART, or the Android Runtime, has actually been available since Android 4.4 as an optional developer feature that could be enabled if you so choose. However with Android 5.0, ART is set as the default, effectively replacing the old 'Davlik' runtime that has been around for years. This change has many performance implications.
Davlik used a just-in-time (JIT) compiler to compile an application's Java bytecode into native hardware instructions when said code was executed (such as when an app was opened). This form of compiler was necessary in older Android editions due to the hardware limitations of the devices it was running on, specifically in the storage and RAM departments.
ART shifts to an ahead-of-time (AOT) compiler, which compiles the entire application's bytecode into native code only once, rather than each time the application is opened. As these native instructions typically use more space, apps themselves have a larger footprint on Android 5.0 and devices running ART; something that has only really been possible since RAM and NAND capacities of Android smartphones have increased.
By compiling applications into native code ahead of time - typically when the app is opened for the first time - a lot of system overhead is removed for any subsequent launch and use of the same app. Although this does mean the first launch of an app will be slower under ART than Davlik, after the first launch, performance should be improved.
Google also claims that by compiling the entire application at once and only once, it can achieve greater optimization of the code, which again should improve performance. As overhead is removed at the same time, battery life should be improved thanks to fewer CPU cycles going to compilation each time an app is opened and used.
ART also features an improved garbage collection (GC) mechanism, which works behind the scenes to allocate and reallocate memory. Previously, the GC system would have to pause code execution to clean up memory use, which would cause what Google describes as "jank", or general stutter while using an app. With ART, the GC system has been improved to reduce pause times, in turn reducing jank. Combined with better memory allocation systems, and again performance increases.
As for Project Volta, Google's umbrella term for range of improvements, new features and APIs focused on extending battery life. On the feature side we see a new Battery Saver mode, and a Battery Historian app designed to give users and developers a better picture of what's draining the device. But it's the APIs that will do most to improve general battery life.
The Job Scheduler API is new to Android 5.0 and allows developers to bundle tasks together and execute them at ideal times. When used for background tasks, this could significantly reduce the amount of time the modem and CPU is active for. For example, tasks could be bundled together and executed only when the device is charging, or for non-critical internet-active tasks, when the device is connected to Wi-Fi.
These new features won't necessarily improve battery life just from an upgrade to Android 5.0, though it's possible for Android OEMs to integrate the APIs into their stock applications and other elements of their skins.
About the Test, Impressions and General Performance
The four devices used for testing in this article are the Motorola Moto X (2014) and Moto G (2014) Dual SIM, the Samsung Galaxy S5 SM-G900I, and the LG G3. All were updated to Android 5.0 from Android 4.4, with various skins and OEM adjustments applied.
This is a purely official software comparison, so all Android 5.0 updates were official ROMs provided by the OEM, though not every update was performed over the air. I could have installed custom software such as CyanogenMod on other devices I had, but I decided to keep this to official and readily available updates only.
On the Moto X and Moto G, the update to Android 5.0 provides you with an unskinned and essentially pure version of Lollipop, save for a few customizations that add extra features. Apart from getting a Nexus or Google Play Edition device, this is the closest to official Android you can get. The Moto X also had the fastest software update to Android 5.0 out of any non-Nexus device.
Material Design, complete with cards and refreshed animations, is seen throughout, and the new notification system (including proper lockscreen notifications) feels more mature than previous editions of stock Android. Other features like guest logins I didn't use all that much.
The Samsung Galaxy S5's update to Android 5.0 includes a mildly refreshed version of TouchWiz. The general style of Samsung's software skin is largely identical to the previous version, with minor changes that reflect Google's Material Design... to an extent. The carded notification dropdown, notifications on the lockscreen, and the task switcher have all been included, and there's a splash of Material in stock apps. However the general feel of the OS is still decidedly Samsung.
Samsung also didn't take the time to remove a lot of junk from their software iteration, which isn't that surprising. The settings screen is still a ridiculous mess, and several stock applications still feel like they were designed by committee.
LG's Android 5.0 update for the G3 includes the least amount of changes. You get a slightly modified notification pane that features Google's carded style, as well as lockscreen notifications (already a feature of LG's Android 4.4 edition) and the task switcher, but most other aspects of the skin remain visually identical to the previous version.
In general, if you were hoping that Lollipop updates to major smartphones with heavy skins would bring the software closer to stock Android, I think you'll be disappointed. OEMs seem pretty keen on keeping the style of their skins intact, despite how far many of them are from Material Design.
One thing I did notice is that the Android 5.0 experience across all four devices felt smoother and faster than Android 4.4. Browsing around the operating system, moving in and out of different screens and stock applications, felt smoother and more seamless despite a healthy dose of animations across the board. The task switcher, for example, loads notably quicker on all handsets, especially on the LG G3 which had a particularly slow implementation in KitKat.
As I expected, loading applications for the first time after I installed them from the Google Play Store was slightly slower on Lollipop than KitKat, for reasons I just mentioned. After the first load, reloading and switching to these apps felt slightly faster, especially on the Moto G with its limited resources. On powerful Snapdragon 801 devices, the difference was less noticeable as app loading was often instantaneous previously.
These observations were purely subjective, and your mileage may vary, especially if you are applying an OTA to a device already loaded with apps. For this article I tested phones that were factory reset either side of the Android 5.0 update, to ensure a clean slate and fair testing ground across all devices.