The Android operating system has matured. The engineers that build Android at Google believe that they have achieved “feature parity” with the other top mobile operating systems (chiefly, Apple’s iOS), so that Android can compete against anybody.
With parity achieved, Google turned its efforts in Android to other aspects of the operating system in the last couple of years to make it better. First, Google focused on the performance of Android for the Jelly Bean 4.1 release of the OS in an operation it called “Project Butter.” The effort was to make Android faster and more reliable, while being less prone to crashes.
Having finished this goal, Google turned its attention to making the memory footprint of Android smaller while retaining that top-end functionality. This was called “Project Svelte” and the results were released in the latest version of Android, version 4.4 KitKat.
“We were kind of joking that, when I started, the first thing that I was working on was Project Butter to make the system smoother. The thing is, butter puts on weight. So then I did Project Svelte to lose weight. So now my contribution to Android is basically zero,” Dave Burke, the head of engineering for Android at Google, joked in an interview with ReadWrite.
Project Svelte was Google’s effort to make the newest hardware features and design of Android work on just about any phone built by manufacturers. Android KitKat can run on devices with as little as 512 MB of RAM, and it represents Google’s latest shot reducing Android fragmentation by ensuring that even new low-end Android smartphones won't use older versions of the OS—especially version 2.3 Gingerbread.
How did the Android team slim down Android KitKat to fit a much broader device profile? Well, it started with a Nexus 4.
“The goal of Project Svelte was basically to reduce the memory footprint to fit into 512 megs. The way we did it, by the way ... was to take a Nexus 4 and adapt it to run at 512 megs,” Burke said.
The next step was to get KitKat running at a lower resolution and on two processors instead of four. The clock frequency was lowered. To make sure Android engineers were eating their own dog food, they all started using these slimmed down Nexus 4s to get a closer experience of what they were making.
“We adapted the resolution to qHD that is 960-by-540 because that is kind of the sweet spot for entry level smartphones,” Burke said. “We reduced it from four CPUs to two CPUs. We reduced the clock frequency and whatnot. And literally a bunch of us just used that as our default phone. It was painful and it was broken to start with.”
After configuring the Nexus 4, Google’s four objectives were to slim down Android were to:
- Reduce the footprint of the system.
- Reduce the footprint (memory usage) of the apps that run on a Google Experience (Nexus) device.
- Fix how apps react and crash during bad memory situations.
- Provide better measurement and instrumentation of how apps are running in Android so developers can see how memory-conscious their apps are.
That last point is what is called “ProcStats”—process stats—in the developer mode of KitKat devices. Burke described how process stats work for developers.
We haven’t made a user feature of it but if you go into developer options on an Android KitKat device and made this thing called ProcStats. It’s process stats ... It is basically watching different apps and services in the system and it looks at how often they are running and tells how much RAM they are using in the background. It kind of computes a weight score, like how heavy it is and then ranks it so you can actually see which apps are consuming a lot of memory for a lot of time in the background. We found that very useful from a Google apps perspective. Often we found that some of our apps were not being memory efficient. They were running services in the background, 24 hours a day. So, it is a very useful tool to analyze that and clean it up.
The first two objectives were achieved by shoehorning Android features into the tweaked version of the Nexus 4 that the Google team had configured. The footprint of Google apps was partially achieved when the Android team decoupled Google apps from the operating system with services like location and the Google Play store acting as separate apps and not part of Android itself.
The next two objectives were realized by better monitoring how apps performed in Android and how the system handled them. For instance, if an app is using too much memory over a period of time, Android will shut it down.
The end result is Android KitKat users of Android 4.4 will hardly notice the difference between pre-Jelly Bean Android and the new memory profile and functionality found in KitKat. Google’s Android team was able to cut the fat off of Android without compromising user experience or functionality.
In the end that was the biggest trick the Android team pulled off.