Android Go is Google’s stripped down version of Android based on Android 8.1 Oreo, and it aims to be an optimized version of Android for low-end devices with 1GBs of RAM or lower. It was announced last May at the Google I/O Developer conference, and eventually more details were revealed in December later that year. It was said to be made for the next generation of entry-level devices, to ensure that those in developing countries can still make use of functioning smartphones in order to access the internet and use apps.
Go has a wide variety of performance optimizations and improvements, including taking up 50 percent less storage space than an average Android Oreo installation. Thanks to Android Runtime (ART) and kernel optimizations too, a device running Android Go will, on average, run 15 percent faster than on a regular Android Oreo install on the same device. These optimizations are made through a number of specialized build configurations made by Google, which we’ll get to explaining later.
Android Go also benefits from special “Go” applications, such as Files Go, YouTube Go and Google Maps Go. These are lightweight versions of applications made by Google, which have reduced requirements to run more efficiently. This means that those with Android Go devices can enjoy most of the same benefits that regular Android Oreo users can too, making use of Google’s suite of applications without having to spend a lot of money on a flagship or even mildly more expensive budget device.
It’s all about Google expanding their market. Yet it begs the question that if Android Go consists mostly of a build configuration and a suite of optimized Google apps, can developers make their own builds of Android Go? In short, yes we can.
A Few LineageOS Developers are already building Android Go-optimized custom ROMs
We are already seeing somewhat of an uptake in Android Go from some custom ROM developers, such as by XDA Recognized Developer AdrianDC, with his work on LineageOS 15.1 with Android Go build configurations for several old Sony phones. The devices in question are the Sony Xperia SP, Sony Xperia T, Sony Xperia V and the Sony Xperia TX. These devices all date back to the years 2012 and 2013, yet they will be receiving LineageOS 15.1 based on Android 8.1 Oreo using an Android Go build configuration, which may allow the devices to run Google ‘Go’ apps fluidly, should an Android Go set of Gapps eventually be released.
Any individual LOS maintainer should be able to introduce an Android Go configured build, with it being a set of build configurations and other optimizations. What this means is that those who may have purchased the Sony Xperia T for example, a device running Android 4.0.4 Ice Cream Sandwich at launch, will be able to use a better-optimized build of Android 8.1 Oreo on the device, making use of applications such as YouTube Go and Google Maps Go. It’s not going to run at flagship levels of performance, but it should be usable—especially for a device which dates back to 2012.
How Android Go Can Help Older Android Phones Run Android Oreo
Build configurations on Android are a set of parameters which pertain to various aspects of the Android system that are applied when compiling the system image for flashing onto a device. Typically these change how the system behaves, and Android Go’s main optimizations come from these build configurations.
The build configurations used for compiling Android Go.
I spoke with XDA Recognised Developer joshuous, who helped me greatly to understand the changes that were taking place—what really makes Android Go work. Some of these build configurations cannot be changed without recompiling, and are part of the blueprint of the ROM itself. These are the fully capitalized flags.
All of these flags, however, pertain to many different aspects of Android relating to storage and memory usage. These include automatic storage management, Android’s low memory killer, the dex (dalvik executable files) optimizer and RAM limits for running apps. APK files consist of these DEX files, so in a way, it’s possible to think of an APK file as simply a ZIP file containing lots of .dex files, which is actually what Android runs when it executes an application. Automatic storage management will instead be controlled by the Files Go application, not the Android system.
Android Go Utilities Android’s Low RAM Mode
In Android 4.4 KitKat, Google introduced a new flag called “low-ram“, which was aimed at supporting devices with 512MBs of RAM. It makes a number of optimizations to the system. These changes are hugely beneficial to lower RAM devices.
Improved memory management
- Validated memory-saving kernel configurations: Swap to ZRAM.
- Kill cached processes if about to be uncached and too large.
- Don’t allow large services to put themselves back into A Services (so they can’t cause the launcher to be killed).
- Kill processes (even ordinarily unkillable ones such as the current IME) that get too large in idle maintenance.
- Serialize the launch of background services.
- Tuned memory use of low-RAM devices: tighter out-of-memory (OOM) adjustment levels, smaller graphics caches, etc.
These changes above basically ensure that the system makes sure to use compressed RAM where possible, through the use of ZRAM. ZRAM is basically a RAMdisk (a storage medium which uses RAM, much faster than using regular storage on the device) as a swap file. A swap file is used when RAM usage is high and applications still require memory. This is much, much slower than RAM and should be avoided where possible. In essence, it simply compresses the contents of memory.
Reduced system memory
- Trimmed system_server and SystemUI processes (saved several MBs).
- Preload dex caches in Dalvik (saved several MBs).
- Validated JIT-off option (saves up to 1.5MB per process).
- Reduced per-process font cache overhead.
- Introduced ArrayMap/ArraySet and used extensively in framework as a lighter-footprint replacement for HashMap/HashSet.
What’s mostly happening here is just reduced memory consumption from various processes running on the device, to be as conservative as possible. Essential system services have been stripped to use as little memory as possible in the background, as every megabyte of RAM is important.
Android Go Uses a Modified Low Memory Killer and dex Optimizations
Given that Android Go is mainly for devices with 1GB of RAM or less, there will need to be more aggressive memory management. Android Go modifies the Low Memory Killer (LMK) in a few different ways. First, when a high amount of the RAM is used up, the low memory killer goes to a “critical pressure” state. This is because when memory usage is high, the system will become sluggish due to constantly trying to access a swap file on the device’s storage. Keeping the RAM clear will prevent the system needing to use this swap file and prevent memory thrashing. Memory thrashing occurs when the device’s memory is full, and constantly has to page the swap file on the device’s storage, degrading performance heavily.
Services and WiFi services are set to “speed-profile,” which means that select methods in these services are Ahead-of-Time (AOT) compiled. (A method refers to a set of code which can be called at any point by name.) This reduces RAM usage and storage, as the Android system will not need to continuously recompile essential services that run on the device. Meanwhile, shared APKs are set to “quicken,” which is designed to give extra battery life and extra CPU cycles by optimizing dex instructions to get better performance.
In terms of dex optimizations, Android Go does quite a lot. For starters, after 10 days it will downgrade an application if it isn’t used to save space. Downgrading here does not refer to the actual version number of the application decreasing, but rather it means that the dalvik_cache for the app will be wiped. The Dalvik cache is used so that the device does not need to recompile apps, instead, it is compiling only the most necessary parts of it and caching that. The rest is compiled using the Just in Time (JIT) compiler when the application is run. If the application is not used for 10 days, however, then the essential parts of the application which are pre-compiled are also removed. This is done to free up as much space as possible. Another simple change is not allowing an app’s RAM usage to exceed 256MB so that an app cannot use all of the RAM on the device.
Is Android Go the Future of Custom ROM Development on Low-end Devices?
Currently, we don’t know the answer to this, but the future looks bright for custom ROM development on older devices. There may be other problems in getting a newer version of Android running on a device, but in theory, an upgrade to a more optimized Android Go based on Android Oreo should make an older, low-end device run better.