How Google reconfigured the Nexus 4 to optimize KitKat for the world

A new report courtesy of the folks at ReadWrite is shining light on the steps and process Google’s engineers undertook to optimize Android 4.4 KitKat before its introduction to the world.

As Google’s engineers believed they reached a “feature parity” point, they turned their attention to performance and optimization, something that began with Android 4.1 Jelly Bean and “Project Butter.” The hope was that Android would be faster, more reliable and devoid of the crashes that plagued many Android users.

Through this came “Project Svelte,” and the goal of making the Android footprint smaller while continuing with top-end functionality.

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

So how did Google optimize KitKat and its ability to run on devices that had as little as 512MB of RAM? They took a Nexus 4 and configured it to run at 512MB of RAM according to Burke. The following steps were to have KitKat running at a lower screen resolution and one two processors instead of four. Android engineers began dogfooding their very own re-configured Nexus 4 units to make sure they were experiencing what consumers would see as the final result.

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

Ultimately, Google had four objectives with Android 4.4:

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

In the end Google achieved the first two results by placing those Android features onto their reconfigured versions of the Nexus 4. The final two objectives came to life by better monitoring how apps performed in Android and how they were handled by the system. Now, if the Android OS detects an app is using too much memory, it will get shut down.

In the end, Google’s Android team was able to cut some of the fat off the OS without compromising any user functionality or experience. For all the negativity that people may pass around with Google these days – spying on our emails or forcing Google+ on the world – there’s still a hugely creative and devoted team behind the products that are capable of doing things that never fail to surprise us.

via ReadWrite