Android Go—Scaling Android for the next billion users

While Android has 2 billion monthly active users, if your plan is world domination that means there's still 5 billion more people to go. Only about half the world's population have access to the internet, and as this number rises, Google wants to capture these new Internet users when they first step onto the web.

These new users will be from developing countries, where a smartphone—the smallest, cheapest internet-capable device available—will be their primary computing device. These will be ultra-low-end, sub-$100 devices, and since there's no such thing as a low-end iPhone, Android is the OS for choice in the developing world.

Google shared a fun statistic at I/O 2017: The company expects one-third of Android devices shipped in 2017 to cost under $100. While the long term goal is to tackle the 5 billion users without internet access, immediately this helps the US market too. Google says the US will be the second most popular market for these sub-$100 phones.

With such a large portion of Android devices shipping on low-end hardware, it's no surprise that Google goes out of its way to support these devices. In Android 4.4, "Project Svelte" added a "low RAM configuration" which would change the way memory was managed, shut off power-hungry features like live wallpapers, and disable memory intensive features like JIT. Google also started the "Android One" program, a low-end Android device program with the goal of making a device "cheap, but also good." In the Android One program, Google offers guidance on specs and often supports the devices in-house, just like Nexus and Pixel devices.

With Android 8.0, Google is making its biggest push into the low-end ever, with a wide-ranging ecosystem solution called "Android Go." Like past efforts, Android Go offers a "low end" configuration for the OS, shutting off memory-hogging features that would hurt performance on low-end devices. "Go" is also extending this kind of thinking to apps, too: Google is slowly amassing a collection of "Go" apps designed for the developing world. These stripped down apps reimagine Google services in a way that works for the developing world, sometimes sacrificing Google's sacred cows (offline YouTube?!) to do it.

Android 8.0 will be the first OS to support a "Go" configuration, but a finished consumer phone with a Go config won't be out until 2018. So while I haven't actually used an Android Go device, I can still talk about Google's announcements, some of my personal research, and the "Go" apps that have come out so far.

The OS in "Go" mode

For the OS, a "Go" config will very much be the same core Android 8.0 operating system, but with a few flags changed that won't just tone down memory intensive behavior, but also turn on some interface options that will be beneficial for the developing world. Go will automatically be enabled on any Android device with 1GB of RAM or less, with a minimum spec of 512MB of RAM. Going forward, Google says that every new version of Android will have a "Go" config, as the company plans to continually develop new features for low-end devices.

Thanks to an "Android Go" session at I/O, we know that the OS portion of Android Go will come with some UI changes. Google's user studies found that 95 percent of "Entry-level users" only switch between the four most recent applications, so for the Go config, Android's Recent apps screen has been redesigned. It's no longer a cascading, overlapping card design, but instead a flat, vertically-scrolling list of thumbnails. Patrik Torstensson, the engineering Manager for Android Go, described these thumbnails as "memory-intensive bitmaps," so capping these at four—as opposed to the 20-ish thumbnails that are possible on a normal config of Android—saves a lot of memory.

The "Go" config also gets a nice new section above the quick settings panel showing live information about remaining data, battery life, and available storage. The idea is that data is extremely expensive in developing countries, power can be hard to come by, and storage on these cheap phones is often a concern. So Go tries to address these concerns with a special UI right in the notification panel. I bet there are a few non-developing world users that would like these features too, though.

Android has data usage tracking today, but it's designed more for the "unlimited" or "limited with overage charges" use case, and is just a running total. The new "Go" data controls treat data like a "balance"—Android will know what your hard data limit is, and will track how close you are to using it up. A new API for carriers can track the data usage and limit for this interface, along with a new "top up" button that can allow users to purchase more data right on the phone. In the mockups there's also a general-purpose "Use less background data for all apps" checkbox, but we're not sure what exactly this does.

Torstensson gave a vague description about the under-the-hood OS changes at an I/O talk. There's been some work done to tune Linux for low end smartphones by changing the swap and threading behavior. Go mode will more aggressively reclaim memory from "low priority" background processes, leaving more memory free for the main activity. The compiled executable files that are pumped out by the Android Runtime (ART) have been optimized too, with smaller dex files leading to less memory used per app.

Google Play Services gets chopped up

The functionality of a consumer Android device can be split up into three big buckets. The first is AOSP (Android Open Source Project), which is a collection of files that make up the base OS. While primarily written by Google, AOSP doesn't need to rely on Google servers or services, and it can easily be "forked" into a non-Google version. Google Play Services is the second big bucket, and traditionally this has been a single, monolithic APK file that is a catch-all for any Google developer API or OS feature that relies on a Google server. The third is everything on the Google Play Store, which is a collection of individual Google apps (many of which come pre installed).

Did you catch the one outlier in that description? If you're concerned about memory usage and only loading what you need into memory, that monolithic Google Play Services APK poses a problem.

For Android Go, Play Services is being re-architected from one giant APK into a bunch of dynamic modules that each contain a set of APIs. The idea is that by only having the system load what it needs, it can save memory.

As far as what this looks like practically, after some digging I believe this project is whimsically codenamed "Chimera," after a mythical creature from Geek Mythology composed from parts of multiple animals. If you dig through a phone's root directory and head to "/system/priv-app/PrebuiltGmsCore/app_chimera/m/," you'll find some files named "DynamiteLoader.apk" and "DynamiteModuleA.apk," "DynamiteModuleB.apk," etc. with the letter incrementing for each "module" file. Currently this goes up to "D."

From what I can tell right now, "DynamiteModuleA.apk" is AdSense and in-app purchases, "B" is the Google Maps API, and "C" is the Google Cast framework, and "D" is Cronet, the Chromium networking stack. If you haven't guessed by now, these are the most-commonly used parts of Google Play Services, and if you're an app developer, there's a chance your app only needs one of these modules instead of the full Play Services APK.

The file sizes here tell a great story. Android APK files go through a compile step before they are loaded into memory, so this isn't a 1:1 mapping, but the "DynamiteLoader" APK weighs in at basically nothing at only 21KB. Modules A, B, and C average out to about 800K each, while D is about 8MB. Meanwhile, the monolithic Play Services APK was a whopping 50MB in 2016, while the current (also monolithic) version in Android 8.0 is about 35MB. The progress made on a smaller Play Services file is great, but many apps will be able to get away with only using a dynamic module or two, which will save a lot of memory over the monolithic version. These numbers are all from the files on a non-Go device, but there's already a potential for big memory savings here.

Apps get special "Go" versions and features









To meet the requirements of the developing world, Google is also reworking its suite of apps to better suit the "limited data, limited battery, limited cpu power" use case. The poster child for this project is the "YouTube Go" app, a from-scratch reimagining of the YouTube app for the developing world.

YouTube Go is ridiculously simple: There are no subscriptions, no comments, no channel pages, and no liking or disliking. There's only about four pages to the interface: the home screen, search, downloads, and playing a video. Videos can be downloaded (!) or streamed, and users can even share downloaded videos locally over Wi-Fi rather than re-downloading them from the Internet. To make sure users really want to spend their data on this video, the video download page also comes with a rapid-fire gif preview of the video, giving users an idea of what the content is like. While YouTube Go supports Google Accounts, you can also log in with a phone number.

With no subscriptions or channel pages, video selection is entirely based off the home page recommendation algorithm or by running a search. For me, the home page recommendations were unbelievably bad, continually showing videos that were several months old—and mostly ones I had already watched. As someone that lives on the YouTube subscription page, I am not sure how users are supposed to live and die by the terrible recommendation algorithm.

Update: Google tells me that since YouTube Go isn't meant to work in the US (the supported countries are India, Nigeria and Indonesia), the recommendation system here isn't "optimized." To be fair, it is still in beta.

Google's also working on an experimental "Search Lite" app, which offers a stripped-down, search-as-you-type Google app with a custom interface. There's not much to it beyond a simple search app, but that's the point. Today's "normal" Google app is massive, containing the search interface, voice search and the Google Assistant, a home screen for Pixel phones, the Google Feed with predictive cards, and third-party app indexing. With the Lite app, you get a search box, search results, and buttons limiting your search to certain data types, like Maps or Images.

Chrome gets in on the developing world fun, too, by turning its "Data Saver" feature on by default. This features sends all your Web pages to Google's servers first for transcoding into a smaller format. The "Go" version will apparently include a new item at the bottom of the Chrome menu telling users how much data this transcoding feature has saved.

The Play Store will also start highlighting apps that are optimized for lower end devices, and soon, it will support "secure peer-to-peer" downloading and installation of apps. In other words, just like YouTube Go, you'll be able to locally copy an app from a friend's phone instead of from the Internet. Downloads from the Internet will also be able to be delayed until nighttime, when data is often cheaper, or when you're connected to Wi-Fi.

Color management

Android 8.0 finally supports color management. "Color management," if you don't know, aims to "standardize" the display of colors across devices. In addition to respecting the specific color profile embedded in an image, color management also takes into account the specific display the software is running on. This means having a calibration profile for any given display—measuring what a display's color output looks like, so colors can be changed to look "correct" on that specific display. Do everything correctly, and the same picture displayed on two different phones should have identical colors.

Previously, Android did nothing when it came to managing colors, and this was very obvious when you looked at any two Android phones side-by-side. A picture on a phone with an OLED display looked way more saturated than the same picture on an LCD. Android didn't respect color profiles either, and it simply mapped an image's 0-255 color ranges to whatever the display color range was. This made the same color on two different displays look wildly different.

For now, color management won't be a system-wide thing—apps will have to enable a flag that says "I want color management," which will allow them to properly convert colors across color spaces. Google seems to only be targeting apps that display pictures, like Gallery apps. So for now, it looks like we'll mostly still have to deal with the UI on an OLED display being more saturated than the UI on an LCD.

Color management will also require some work from OEMs to start. They'll have to measure their displays to create a color profile and embed that information in the OS. Thanks to variations in manufacturing, no two displays—even displays that are the same model—display identical colors, and if an OEM really wants accurate color, it could measure every display individually as part of the manufacturing process.

Physics-based animation and the new Easter Egg

What would a major Android release be without a silly new easter egg? For 8.0, we have the "Octoquarium," which shows a creepy black octopus (It starts with "O" for "Android" and "octa" for "8.0," get it?) swimming around a watery background. You can grab the octopus and move it around, at which point the octopus will reveal that it's super stretchy. Fling it around the screen, and its black tentacles will stretch out into a creepy Slender Man-like monster.

It's tradition for most new versions of Android to have their own little Easter Egg, which you can access by tapping repeatedly on the "Android version" field in About Phone (that's Settings -> System -> About Phone on Android 8.0), then tapping and long pressing on the logo that pops up. The Easter Egg is different with every version, and usually these are built to test out a new API. The "Neko" cat game in Android 7.0 was created to test out custom Quick Settings tiles. The "Flappy Bird" clone in Android 6.0 was designed to test out the new real-time shadow APIs. In Android 8.0, the "Octoquarium" is designed to use Android's new physics-base animation system.

Just like in video game development, a physics engine can automatically animate an object in response to a force, saving the developer from the impossible task of hand-animating every possible interaction between objects. In this demo, the springiness of the octopus is computed automatically by Android's new physics library. Of course, Android games have had third-party physics engines forever, but this is a physics engine for 2D apps. It can help with things like scrolling animations (fling, bounce back, etc), transitions, and gestures like pull-to-refresh. For a spring animation, developers just give an object a start velocity, damping ratio (aka "bounciness"), and a stiffness, and the animation system can handle the rest. For scrolling, you just set a pane's "friction" property and the system handles the animation.

The "Dynamic Animation" library that enables the new physics system is part of the support library, so it should work on older versions of Android.

The new "SDCardFS" file system wrapper

Google hasn't officially said a word about this, but apparently Android 8.0 comes with support for a new file system wrapper called "SDCardFS." Maybe that statement is too presumptuous—with the 8.0 upgrade, the Google Pixel and a few Nexus devices magically start using SDCardFS, so presumably that means the new file storage scheme is available for anyone in AOSP. The intrepid hardware hackers over at XDA have been tracking the implementation progress, and apparently SDCardFS should significantly reduce the I/O overhead involved in accessing Android's shared data storage.

Before we dive into SDcardFS, here's a quick primer on the main Android partitions, all of which live on internal storage:

/system stores the Android OS and the packed-in apps. This is usually formatted in EXT4.

stores the Android OS and the packed-in apps. This is usually formatted in EXT4. /data stores app data generated by the user, downloaded apps, and app updates to the packed-in apps. When you perform a "factory reset," you're wiping out this partition and /sdcard. This is usually formatted in EXT4.

stores app data generated by the user, downloaded apps, and app updates to the packed-in apps. When you perform a "factory reset," you're wiping out this partition and /sdcard. This is usually formatted in EXT4. /sdcard stores media, ringtones, camera pictures, and bricks of resource data for large apps like 3D games. This is the block of storage you see when you plug your phone into a computer. The formatting here is, uh, complicated.

Android's partition naming scheme is a confusing mess of legacy terminology that doesn't make much sense anymore. Case-in-point: SDCardFS is named after Android's /sdcard partition, which has nothing to do with physical SD cards. Back in the Android 1.0 days when devices had less than a GB of internal storage, Android required the presence of a physical SD card to store things like camera pictures and videos. This lived under /sdcard. When phones grew to have 8GB+ of storage, SD cards became optional, but to maintain compatibility with older apps, the /sdcard partition was still kept around. Phones were still given a virtual /sdcard partition, which actually lived in /data. Today, the /sdcard partition is always on the internal flash storage, and a more appropriate name would be something like "/media." If a phone has a real, physical SD card, that gets some other name, like /sd-ext or /sdcard1.

Because /sdcard is presented when you plug a phone into a computer, there's a host of issues. First, to work across Windows, Mac, and Linux, it pretty much has to present itself as FAT32. This Microsoft-owned filesystem from 1996 has a bunch of limitations, but the main problem FAT32 causes for Android is its terrible permission support. Google actually used a straight FAT32 filesystem for /sdcard in the pre-Android 4.4 days, and it meant any app that needed access to /sdcard got access to everything on /sdcard, including all your pictures!

For Android 4.4, Google rigged-up a system that presented a PC with FAT32 while still keeping app data separate: it started using a virtual file system driver called "FUSE" (Filesystem in userspace) to create a virtual, private FAT32 file system for each app. As the name implies, FUSE lets apps write to storage without any permissions, and each app was virtually presented with its own chunk of storage when it needed to access the SD card. Mounting an Android phone to a PC still allowed for viewing the entire /sdcard.

FUSE has its own set of problems, though: having a file system that lives in user space incurs a significant I/O penalty. A system call to read or write a file has to go to the kernel, which passes it to user space for FUSE, and when the read write is finished, it calls back to the kernel. Normally, there would be a single call to the kernel where everything would be handled, so FUSE requires a whole extra round trip to user space. I/O calls can happen many times a second, so any extra overhead can add up really quickly.

SDCardFS replaces FUSE and avoids this extra round trip by being an in-kernel FAT32 emulation layer. SDCardFS was originally developed by Samsung, and it's based on WrapFS. Of course, Samsung has employed the wrapper on its phones already, and some other Android OEMs like Huawei and OnePlus have picked up the system. So it's not exactly a new feature in the world of Android, but it is newly integrated into AOSP.

Since Google isn't really talking about it, we don't have a ton of info about SDcardFS, but anything that reads and writes to /sdcard (the camera, large 3D games, PC file transfers) should see a speed boost.

Grab Bag









The "grab bag" is filled with tiny updates that don't fit anywhere else. Alternatively, this list could include things we have very little to say about, too.