The scourge of Android is a Gingerbread man—and Google is finally ready to kill it.

Gingerbread is an older version of Android that’s still running on an alarming number of smartphones, which means that their users aren’t getting the latest Google software and developers must keep their apps compatible with the older operating system, or address the smaller, upgraded slice of the Android market.

The biggest aspect of Android 4.4 KitKat is not the new dialer or Caller ID or translucent navigation bars. Nor is it “the Google experience” that is baked heavily into the operating system. The most important aspect of Android 4.4 is Project Svelte.

Project Svelte is an effort by Google to make Android and all of Google’s apps smaller and more efficient so they can run on a wider variety of mobile hardware. That means that Android 4.4 will be able to run on devices with as little as 512MB of RAM, a number that includes many of the low-end devices that currently ship with Android 2.3 Gingerbread, which was released in December 2010. 

Gingerbread still runs on 28.5% of the Android devices that touch Google’s servers as of October 2013. Many Android manufacturers ship low-end smartphones that have Gingerbread as a default because the later versions of the operating system (Ice Cream Sandwich, Jelly Bean) are too big and inefficient to run on devices with limited memory capabilities. 

To fix that, Google has shrunk Android in a variety of ways while also keeping a high-end user experience and feature set. Android KitKat 4.4 will allow manufacturers and cellular operators to update consumers’ devices from Gingerbread if they so choose. If those manufacturers don’t choose to upgrade their users smartphones, at least Google is not the one to blame. 

“We have briefed all of our manufacturing partners on this and they are all very excited about it," said Hiroshi Lockheimer, vice president of engineering for Android at Google. "They all want to ship the latest thing. It is not like they wanted to ship Gingerbread but they had to because that is what fit.”

Contrast that to Apple, which has the ability to upgrade users to the latest version of its mobile software, iOS—even though that hasn't turned out to be the best experience for users of older phones.

The Android developer site has the wonky details:

OEMs building the next generation of Android devices can take advantage of targeted recommendations and options to run Android 4.4 efficiently, even on low-memory devices. Dalvik JIT code cache tuning, kernel samepage merging (KSM), swap to zRAM, and other optimizations help manage memory. New configuration options let OEMs tune out-of-memory levels for processes, set graphics cache sizes, control memory reclaim, and more.
In Android itself, changes across the system improve memory management and reduce memory footprint. Core system processes are trimmed to use less heap, and they now more aggressively protect system memory from apps consuming large amounts of RAM. When multiple services start at once — such as when network connectivity changes — Android now launches the services serially, in small groups, to avoid peak memory demands.

Dave Burke, the engineering director for Android at Google, showed me an app on his developer-edition Nexus 5 which tracks the memory status of each individual app currently running on the operating system and the memory status of the device as a whole. Developers will be able to know if their apps is running well within Android if the memory status of Android is green. If it is yellow or red, developers will need to retool their app or risk Android automatically shutting it down.

What these capabilities in Project Svelte do is essentially kill the need for a third-party app-tasking manager for Android. The operating system now does it automatically—which is a godsend for older Android phones.

New Tools To Manage Device Memory

Google has created two new tools to manage app memory for developers: procstats and meminfo. The procstats tool lets developers check the memory size of apps and services over time while meminfo shows the detailed memory use of an app. So, if your GPS tracker in your fitness app is running too hot, meminfo will be able to show you at the granular level why that is happening. Procstats is available through the Android Software Developer Kit.

On his brand-new Nexus 5, Burke showed me a related app that runs on the device itself, Process Stats, that shows memory usage. It can be reached in the settings tab under “Developer Options.” Process Stats shows developers a variety of metrics on the memory use of an app. Essentially, it is the visual, on-device version of the procstats developer tool. The Process Stats app will show the relative health of memory use of the device (green is good, red is bad) and how much each individual app is contributing to that memory use. The app can be configured to show both backend and frontend memory use—when an app runs in the background versus when a user is actively engaging with it.

Killing The Gingerbread Man

In addition to making Android and Google apps leaner and meaner to ease the memory use of operating system, Google has also performed some housecleaning on the operating system. In the past, Google apps like Calendar, the Google Play app store, location services and Maps were tied directly to the operating system. That is no longer the case.

Google has created a feature within Android that handles the updating and functionality of those apps outside of the hardware integration with the operating system. Google Play Services is a function that controls most of Google’s apps and can update itself and its processes automatically in the background without user notification or consent. 

By decoupling its core Google apps from the OS level of Android, Google allows itself to have more control over the apps and frees the Android kernel of functions it needs to perform on its own. Essentially, the only functions that Android now performs are those that are tied directly to the hardware, like using sensors, Bluetooth, Wi-Fi, the camera, and so on.

Will all of this add up to the final death of Gingerbread? It is up to phone makers to decide if they want to crunch through the KitKat update. No doubt many older phones will never get KitKat. Yet what Google has done is effectively make sure that Android smartphone makers are far less likely to build devices in the future that ship with Gingerbread as the default operating system, now that they don’t have to. That will allow Android 2.3 to die a natural death, like 2.2 FroYo and earlier versions did.

App developers will rejoice. But Google has not ended Android fragmentation quite yet. For one thing, manufacturers’ desire to “skin” their phones with different versions of Android that purportedly highlight their distinguishing features ensures that there will always be a semblance of fragmentation in the ecosystem.

The Gingerbread man, in other words, takes a long time to crumble.