Android 8.0 Oreo is the 26th version of the world's most popular operating system. This year, Google's mobile-and-everything-else OS hit two billion monthly active users—and that's just counting phones and tablets. What can all those users expect from the new version? In an interview with Ars earlier this year, Android's VP of engineering Dave Burke said that the 8.0 release would be about "foundation and fundamentals." His team was guided by a single question: "What are we doing to Android to make sure Android is in a great place in the next 5 to 10 years?"

Take a closer look at Oreo and you really can see the focus on fundamentals. Google is revamping the notification system with a new layout, new controls, and a new color scheme. It's taking responsibility for Android security with a Google-branded security solution. App background processing has been reined in, hopefully providing better battery life and more consistent performance. There's even been some work done on Android's perpetual update problem, with Project Treble allowing for easier update development and streaming updates allowing for easier installation by users. And, as with every release, more parts of Android get more modularized, with emojis and GPU driver updates now available without an OS update.

View more

Like its partnership with Nestlé for Android 4.4 "KitKat," Google is taking its alphabetical snack-themed codenames to the extreme with 8.0. This time Nabisco is sharing its "Oreo" brand with Google. (We've yet to hear about any kind of monetary arrangement for this sort of thing). Google's Eclipse-themed launch party was complete with custom Oreo cookies featuring an Android robot design and green filling.

Two billion users is a huge number, but with Android 8.0, Google shows that it still isn't satisfied. A new initiative called "Android Go" targets the developing world, where cheap devices and limited access to data and power require taking a different look at how some parts of Android function.

Oreo will also serve as the base for three new Android form factors. It will be built into cars as "Android Automotive," where Google works with car OEMs to integrate Android. Android 8.0 will also be the base OS for "Android Things," an "Internet of things" (IoT) version of the OS designed to easily manage on embedded devices. Finally, Google's virtual reality "Daydream" group will also launch a new form factor with Oreo: standalone VR headsets.


So, coming soon to your phone, your tablet, your watch, your TV, your car, your "things," and your VR headset—it's Android 8.0 Oreo. Let's dive in.

Table of Contents

Project Treble—Finally, real progress on the fragmentation problem

While Android's scale is impressive, the vast majority of Android users won't get to use new versions of the OS quickly—or at all. Google's own Pixel phones get updates immediately, third-party flagships get updates in six months to a year, and everyone else gets updates when they throw out their existing handsets and buy new ones. Android's biggest problem is easily the ecosystem's inability to ship updates quickly and efficiently to every device.

Google's past "solutions" to the Android update problem have involved little action and lots of talk. In 2011, Google asked OEMs to do better and announced the "Android Update Alliance"—a group of Android OEMs that totally-pinky-sweared to ship updates quicker. After the big announcement, exactly nothing changed; the group was never mentioned again. In 2016, Google reportedly ranked OEMs by update speed and showed the list around the ecosystem in an attempt to "shame" OEMs into doing a better job. Little happened.


Asking OEMs nicely has not improved things, so in Android Oreo, Google is finally implementing a technical change to Android that should help. The effort—called "Project Treble"—modularizes the Android OS away from the drivers and other hardware-specific code. As Android's Head of Engineering, Dave Burke, put it in an interview with Ars, "Today, it just costs too much to do an upgrade of Android. The amount of work and dependencies are too high." The goal with Treble is to make it easier, faster, and—most importantly for OEMs—cheaper to pump out an Android update.

Once Google releases an Android update, getting it running on a specific device usually involves three major steps. First, SoC vendors like Qualcomm or Samsung's Exynos division take the update and modify the release for that specific piece of hardware. Then OEMs like Samsung and LG theme the OS, rebranding Android with new icons, colors, and layouts, often changing core parts of the OS to add extra features and functionality. Finally, carriers test the new release, certify it for their networks, and send it out to users. (If you buy an unlocked device, you can skip the "carrier" step and get your update directly from the OEM.) Each step creates not only a delay but also the opportunity for a company to end update support, leaving users with an abandoned piece of hardware.

Project Treble will help with that first step: relying on SoC vendors to get the release running on specific SoC hardware. Project Treble introduces a "Vendor Interface"—a standardized interface that sits between the OS and the hardware. As long as the SoC vendor plugs into the Vendor Interface and the OS plugs into the Vendor Interface, an upgrade to a new version of Android should "just work." OEMs and carriers will still need to be involved in customizing the OS and rolling it out to users, but now the parties involved in an update can "parallelize" the work needed to get an update running. SoC code is no longer the "first" step that everyone else needs to wait on.


Google has a new set of tests, called the Vendor Test Suite (VTS), which ensures the Vendor Interface on a device is properly implemented and future proof. This is a hardware-focused analog to the Compatibility Test Suite (CTS), which ensures the Android app APIs are properly implemented on a device.

HAL versioning and deprecation

On the Android Developer's Backstage Podcast (which is more-or-less Google's "official" Android podcast), Iliyan Malchev, the head of Project Treble, dished out a good amount of detail about his pet project. "We haven't been very formal about defining the boundary between the top [Android Open Source Project] and the bottom [Silicon Vendor] pieces of the OS," he said. With Treble, Malchev said that Google is "defining a set of interfaces, formally, in a structured and versioned manner, and committing to maintaining them."

Treble isn't just a single interface. HALs (Hardware Abstraction Layers) are broken down into "major subsystems" like the camera, audio, location, Wi-Fi, telephony, and other components. Malchev revealed there are "about 60" of these HALs in Oreo, with more to come in future releases. To allow for each subsystem to grow and evolve over time, each one gets a major and a minor version number, and each release of Android will support a range of versions for each subsystem. For device types Google doesn't officially support, there's a "Vendor NDK" that allows vendors to make their own custom modular HALs.


The versioned subsystems mean that future device support will be partially dependent on Google and what subsystem versions it chooses to support or deprecate with each Android release. If your phone SoC only supports "Camera HAL version 1.3" and "Android 9.0" requires Camera HAL v1.4 and up, you'll need to have your camera HAL upgraded before Android 9.0 will fully work on your device.

To help make HAL deprecation decisions like this, Google will have some sort of database containing all the HAL information for all the Treble Android devices out there. As Malchev put it on the podcast, "We will have a way to know, for every given device, exactly which HAL interface it implements at which version, and we're going to have a way to look at the universe and see 'Ok, what will happen if we drop support for this old version of this interface? How many devices will not be eligible to get a new upgrade?' We'll be able to make a data-driven decision for this sort of thing, and that's great because previously we didn't have that kind of data."

Working with SoC vendors

Treble is about making lives easier for the thousands of Android OEMs out there, but nearly all the work was done with the SoC vendor community. "There are ten [silicon vendors] in the world or so," Malchev said on the ADB Podcast, "companies like Qualcomm, Mediatek, LSI, Spreadtrum, Intel. It is these companies that manufacture systems on a chip that underpin the actual Android devices. The fanout from these few companies to the thousands upon thousands of phones and tablets out there is massive... By working directly with these companies, we essentially solve the problem to a very, very large degree at the source, prior to that fanout."

SoC vendors represent a much more focused group than OEMs. "We cannot possibly go to the hundreds upon hundreds of OEMs and say, 'Hey, we're doing this, can you change those things?'" Malchev explained. "We instead go to the silicon vendors of the world and work with them, so that, as the fanout happens, everyone benefits from the work we do."


Malchev said that getting SoC vendors on board with Project Treble "took as much time as the engineering work." The work started in late 2015, and today, as part of Treble, Google has a dedicated SoC vendor outreach team. Malchev said that Google now has "teams in Taiwan, Seoul, [and] San Diego dedicated to working with our major partners, with the silicon vendors in their own time zone and in their own back yard." Malchev did not specify which silicon vendors Google had embedded teams with, but a quick comparison of SoC company headquarters against that list suggests that Google is in Taiwan for MediaTek, Seoul for Samsung, and San Diego for Qualcomm.

A ROM revolution

While Treble is focused on official Android OEMs, Project Treble should also be revolutionary for aftermarket Android ROM projects like Lineage OS (formerly CyanogenMod) and individual developers on places like the XDA Developers Forum. These groups take code from Google's open source Android repository and make Android-based OSes themselves, usually offering upgrades to abandoned devices or conversions from skinned Android to a more stock look.

In the past, the bane of third-party ROM developers has been that AOSP (Android Open Source Project) has never been a complete, bootable software package for real life hardware. You've never been able to compile AOSP, slap it on a device, and have it run—you need all sorts of "binary blobs" from chip vendors to make things work. Usually, the ROM developers end up compiling AOSP and combining it with the official software, resulting in a janky mix of new AOSP code and old proprietary bits. Because Android never had a standardized interface between the hardware and software, updates would break all sorts of things, leading to issues with the camera, networking, and other components, or to general performance problems.


Treble promises to change everything. Malchev says that Treble standardizes Android hardware support to such a degree that generic Android builds compiled from AOSP can boot and run on every Treble device. In fact, these "raw AOSP" builds are what will be used for some of the CTS testing Google requires all Android OEMs to pass in order to license the Google apps—it's not just that things should work, they are required to work.

Treble's modularity is enforced in Android's partition layout, too. AOSP code lives in the "System," "Recovery," and "Boot" partitions. The SoC vendor (usually Qualcomm) gets the "Vendor" and "Radio" partitions. The ODM/OEM (Samsung, LG, HTC, etc) gets the "Bootloader," "ODM," and "OEM" partitions for their code. These partitions all existed before as options, but now things like a dedicated Vendor partition are mandatory for 8.0. Google's documentation spells out the implications of this, saying, "It ​should ​be ​possible ​to upgrade ​a ​device system.img ​from ​Android ​8.0 ​to ​Android ​P ​while ​other ​images ​(such ​as vendor.img, odm.img, ​etc.) ​remain ​at ​Android ​8.0. ​This ​modularity ​enables ​timely Android ​platform ​upgrades ​(such ​as monthly ​security ​updates) ​without ​requiring ​SoC/ODM partners ​to ​update ​SoC- ​and ​device-specific ​code." In the ROM world, this means you should be able to flash a new system partition built from AOSP, while leaving everything else alone, and have a working system.

We'll have to see how things exactly work in practice, but I'm expecting the ROM community to explode in popularity once Treble devices become more widespread. Custom ROMs shouldn't need to be painstakingly hand-crafted for individual devices anymore—a single build should cover multiple Treble devices from multiple manufacturers. Imagine the next time a major new version of Android is released. On Day One of the AOSP code drop, a single build (or a small handful of builds) could cover every Treble device with an unlocked bootloader, with a "download Android 9.0 here" link on XDA or some other technical website.


Users should also have more control over their devices, like being able to buy a skinned Android phone and immediately apply a fully-functional AOSP build, stripping away bloat and most of the annoying "customizations" that OEMs make. You can sort of do this today, but, again, the lack of a standard interface and the need to include binary blobs from the SoC vendor makes this a very iffy proposition. The standardization of Treble should ensure that everything will work.

Being able to compile AOSP, slap it on a device, and have it work will be a boon to home tinkerers, and on the official retail build side of things, could help to prolong the life of Android devices. If security is your goal, though, there's still a need for involvement for the SoC vendors. There will inevitably be bugs and security flaws in the vendor code, and since that code doesn't live in AOSP, vendor support will be required to fix those.

All of this ROM stuff depends on buying a phone with an unlocked bootloader, which lets users tinker with the software. Usually this just means buying an "unlocked" phone directly from an OEM, rather than a carrier.

Isolating the media stack

Another benefit of Project Treble: security! The separation of vendor code from the OS means the vendor code can run in a separate process. This also helps harden the media stack in Oreo. The media framework is a particularly important area after 2015's "Stagefright" vulnerability, which exploited Android's media player engine (which is actually called "Stagefright") to remotely execute code.

On a Treble-enabled phone, the audio, camera, and DRM parts of the media stack have also been isolated in separate processes and sandboxes. Each part gets a new hardware abstraction layer (HAL) between the framework and kernel, too, so it should now be harder for a framework exploit in these areas to access the kernel.

Android's biggest re-architecture, ever

Project Treble will make Android work more like the PC market, where a single version of an OS can run on multiple devices. It's been obvious that Android needed to make a change like this for some time, but Treble was a massive project and counts for a lot of what makes Android 8.0 a full "1.0" update.

As Burke puts it, Treble "used up a huge amount of the engineering budget [for Android 8.0]. It was a lot of work and super deep surgery across every single interface of Android." At the I/O Android Fireside Chat, Burke called Treble "probably the biggest re-architecture of Android since it started." On the ADB Podcast, Romain Guy, Android's Graphics lead and an Android engineer for the last 10 years, said, "I don't think there's ever been something remotely even close to the complexity of Treble in terms of infrastructure change to the platform." Malchev revealed Treble involved "upwards of 300 developers within Android engineering itself contributing to this, across 30 teams."


As far as device support for Treble, the feature is a requirement for any new device that ships with Android 8.0. For upgrading devices, Treble is optional. So far the one and only upgrading device we know about is the Google Pixel, but Malchev said that "we are working with some companies to upgrade their flagship devices to O while Treble-izing them fully."



Notifications—Android's best feature gets better

Since Android 1.0, notifications have been a killer app for the platform. In Oreo, they're improved even further. There's a new layout, a new color scheme, and new animations. You can snooze notifications, app icons show notification badges, users are better informed about what's happening in the background, and apps can have multiple notification channels.

The first thing you'll notice is the new top section of the notification panel. It's now light grey with black icons, and a new strip below the power toggles shows the date (or alarm, if you have one set), settings gear, and the expand caret. The status bar icons like cellular connectivity, battery, and time are preserved on this screen now, whereas in Android 7.x they were hidden. Pull down again to expand the Quick Settings, and you'll see even more light grey. Again, the status bar icons mostly survive at the top of the screen, while the new bottom strip shows the date, profile picture, edit button, settings button, and expand button.


The Quick Settings tiles act differently in Android 8.0, too. We're now back to two touch targets for certain tiles, which are again denoted with dropdown arrows next to the text description. This is something Google introduced in Android 5.1, removed in 7.0, and has now restored. It seems like Google finally nailed Quick Settings tiles in 8.0, though. The panel is now actually consistent: every icon is always a toggle switch, every description with an arrow will open a panel, long-pressing anything will open the most relevant system settings page. (Before you had no idea whether a tile would open a panel or toggle the feature, and it really didn't help that Google changed what the buttons did in nearly every new version.)

Most of the old tricks still work. You can still hold down the settings gear to unlock the System Tuner, and tapping on the profile picture still opens the profile panel for switching users. The battery panel seems to be dead, though. The old "Battery" tile has been replaced with a "Battery Saver" tile, which kicks the phone into low power mode, rather than showing a power usage graph.

The new layout—and its awesome “By the Way” section

The panel and notification ordering logic has been refined into a tiered top-to-bottom system. First, there's "Major Ongoing" notifications for things like currently playing music, phone calls, timers, Google Maps navigation, and other running, foreground services. Below that are "People-to-People" notifications, which are incoming text messages and missed calls from various apps. After that are "General" notifications for e-mails, reminders, calendar appointments, and all other apps.

Google's UX studies have identified People-to-People notifications as the most important incoming notifications, so these get top billing after the ongoing notifications. P2P notifications also get to be bigger in Oreo: the smallest size now shows three lines of text, up from a single line in Nougat. You can still expand these and to get a "reply" button and even more text.


The new bottom section, which Google has given the perfectly fitting name of "By the Way," houses single-line, minimized-by-default notifications that don't create a status bar icon. One of the Google I/O slides described this section as a catch-all for less important notifications like "weather, traffic info, suggestions, and promotions." The idea is that this section can house notifications that you don't need to deal with right now but might be useful information for you to have—a bit like having a mini Google Now section at the bottom of your notification panel. With the Oreo background processing lockdown, apps running in the background are forced to generate a notification letting the user know something is sucking up resources, and those notifications will show up here.

The "By the Way" section is one of my favorite parts of Android 8.0. It feels like a whole new class of notification: not important enough to be a full-size notification that shows up in the main list but not unimportant enough to totally turn off. The tiny size and bottom positioning makes these easy to ignore when you're dealing with more important notifications, which really makes the panel feel less cluttered. Killing status bar icons for these notifications is a great idea, too. Again, it really cuts down on the clutter.

The best part is that, if an app supports Oreo's notification channels, you can manually demote apps to the "By the way" section. Just long press on a notification and press "more settings" (or dive into Settings-> Apps & notifications -> App Info -> [app_name] -> App Notifications) and you should see an "importance" setting. Setting something to "low" will move it into this tiny new section, block it from making noise, and not let it create a status bar icon.


In Android 7.1, if you had an abundance of notifications and they couldn't all fit on the screen, notifications would stack up and cover each other, just like Recent Apps. In Oreo, instead of stacking up a long list, the icons shift to a tiny, one-line "shelf" at the bottom of the screen. The shelf only displays icons, making it look like a status bar that just happens to be at the bottom of the notification panel.

Google has an incredibly slick animation for the shelf. When you pull down the notification panel, the shelf is the first thing you see, and all the icons are listed there. As you expand the panel, the icons slide out of the shelf and up to the notification panel. That's where they take their usual spot in their respective notification cards. Scrolling works this way, too, by pulling items out of the shelf and into the scrolling list.

The new colors and media notifications

The new notification layout is visually distinguished, too. Google is encouraging the top-tier of notifications, "Major Ongoing" notifications, to have brightly colored backgrounds that make them stand out from the usual white notification card. Google has experimented with this in the past with Google Maps' bright-green navigation notification, but now this is an official design recommendation.

The standout addition here is the new "currently playing media" notifications, which all get automatically colored based on the album art. Of course this works with Google Play Music, but since this is a system-level change to the Notification.MediaStyle component, any app notification with media controls will automatically be colorized based on the album art, unless the developer specifically opts out. This means it also works with YouTube, SoundCloud, Pandora, Spotify, Pocket Casts, and even Chrome, which will grab colors from the favicon of a site.


With the color-changing media notifications, Google is finally making use of Android's "Palette API," introduced all the way back in Android 5.0 Lollipop. The Palette API can automatically extract colors from a source image and serve it up to an app for UI coloring. The colors get tossed into buckets like "Vibrant," "Muted," "Light," and "Dark," which preserve text contrast.

When this feature went live in the third Android O Developer Preview, it instantly became one of my favorite new features. Every song brings a new and interesting color combination, and I ended up just quickly scrolling through my music collection for a bit, just to see what wild color combos the Palette API would come up with. Grungy album art gets a dark color scheme, happy neon album art gets an eyeball-searing notification, and subdued mellow album art gets a matching, muted color scheme. And because the API automatically detects light and dark colors, I never ran into a single readability problem. This is probably also helped by the small size of the media notification—Apple tried a full-screen auto-coloring feature in iTunes that did not go over well.

When Google introduced Material Design with Android L (in 2014!), it showed off a concept of a Palette API-powered music app. But such a design didn't survive to Google Music. Years later, we finally get to see the color-changing feature in the media notifications. Hopefully, the whole Google Music app gets a redesign soon to match this new notification style because, right now, the two interfaces don't match at all. The media notification is a beautiful chameleon, while Google Music is always a boring orange and white.


If I can go off on a rant for a minute—there's also the issue of the music app being a bloated, cluttered, impossible-to-navigate mess, thanks to Google's attempt to integrate a music locker, Internet radio, curated playlists, music store, and podcasts into a single app. Hey Google, remember how you broke Google Drive into separate apps: Drive, Docs, Sheets, and Slides? A Google Music redesign in the same style (with separate music locker, Internet radio, and podcasts apps) would be swell.

Media apps aren't the only things getting fancy colored notification backgrounds. A new API allows developers to colorize foreground service notifications. Google recommends that app developers "should only use this feature in notifications for ongoing tasks which are critical for a user to see at a glance." But the only thing stopping developers from colorizing everything seems to be the honor system. After announcing the new API at Google I/O, Saleem Cinek, a Senior Software Engineer on the System UI Team, pleaded with the audience: "Please, please, please don't abuse these styles. We're putting a lot of trust in the developer ecosystem, and if we see this being abused too much, we will have to change it in the future." Sounds pretty scary!

The move reminds me of the addition of pop-over "Heads-up" notifications in Android 5.0. Google gave developers control over this setting, and developers abused the feature in order to "increase user engagement." After a whole version of complaints from users, Google finally reined in the feature with Android 6.0. The company gave users control over notification importance.


At I/O, Cinek continued by saying, "I really want to stress that 'colorized' isn't the new 'white.' By default a notification shouldn't be colorized. We don't want to create a shade of rainbow colors. We want to put focus on the one notification that matters."

The problem is that developers often think their notification is the only one that matters. Here, again, they're the ones in control. Hopefully, we won't have to revisit notification coloring permissions for Android P, or whatever the next version is.

Snoozing notifications

Android 8.0 adds the long-suggested ability to "snooze" notifications, removing them from the notification panel to have them return at a later time. To snooze a notification, just horizontally nudge a notification, which will reveal a gear and clock icon. Tapping the clock icon will snooze a notification, removing it and replacing the clock with temporary snooze controls in its place. The snooze controls give you options to "undo" the notification snooze along with the ability to adjust the snooze time.

The ability to snooze notifications has frequently been suggested as an Android feature, and I always thought it was a great idea. I love the way Google Inbox handles snoozing e-mails, allowing you to clear your inbox while having mail return when you want to deal with it. An exact copy of Inbox's snooze system for all of Android's notifications would be great. Oreo's implementation of notification snoozing is far less useful than Inbox, though, and after a week or two with the feature I just found myself never using it.


The problem is that you only have extremely limited snooze options: 15 minutes, 30 minutes, or 1 hour. Compare this to Inbox, which offers canned settings for "tomorrow," "two days from now," "this weekend," "next week," and, critically, the ability to just enter an arbitrary date and time. Personally, if I need to remember a notification 15 minutes to an hour from now, I just won't swipe it away. I'm fine with leaving the notification there as a constant reminder for such a short period of time. What makes Inbox's snoozing notification useful are options like "I'll worry about this tomorrow" or the ability to send messages that say "do this by x day" to the exact "x day" mentioned.

Inbox has gotten so good at snoozing e-mails that it will automatically populate the snooze options with intelligently picked dates that are mentioned in the e-mail. It will automagically pick out snooze options like "the day of delivery" for a package or offer to snooze a reservation e-mail to the day of that reservation. You can even geofence an e-mail, snoozing it until you arrive at a particular place. In comparison, Oreo's notification snoozing is extremely lacking. I want options for days, not minutes.

Notification Channels: Great for apps that have it, terrible for apps that don't

User notification controls in Oreo are where things start to get poorly implemented and confusing. Apps that are freshly updated with the latest Android 8.0 features get a great set of notification controls, while apps that are not updated to target 8.0 arbitrarily get a more limited feature set.

'Targeting' Android 8.0, Defined There will be many times when I mention that an app needs to target Android 8.0 to use a new feature or be affected by a change. This does not mean the app will only run on Android 8.0. There will be many times when I mention that an app needs to target Android 8.0 to use a new feature or be affected by a change. This does not mean the app will only run on Android 8.0. Internally, an Android app must set two "SDK level" flags. First, there's "Min SDK Version" which is the oldest version of Android an app will run on. Then there's the "Target SDK Version" (the one we care about), which is the highest version of Android that the app is aware of. From time to time, Google changes the way Android works, and the "Target SDK" allows developers to opt-in to those new changes while keeping things the same (and not breaking anything) for old apps. Many Android 8.0 app changes come with the stipulation that the app must target Android 8.0. App developers usually don't target the latest release of Android at launch. When I last did a survey of the top 200 apps, only five percent were targeting the latest Android version at launch—78 percent targeted an SDK level that was a year old. Just as new Android OS versions take forever to be adopted by OEMs, Android app changes take forever to be adopted by developers.

If an app targets Android 8.0, it must support the new "Notification Channels" API to deliver notifications. This allows an app to break down its notifications into multiple categories. From a UI perspective, this lets the user control each type of notification from an app individually instead of as a single block. For the System UI, for example, you'll see four categories: "Alerts," "Storage," "General Messages," and "Screenshots." You can control the notification options for these separately.

The notification channel settings live in Settings -> Apps & Notifications -> App Info -> [App Name] -> App Notifications. Alternatively, like notification snoozing, you can pull an active notification over a bit to expose a gear icon, tap the gear, then tap "All Categories." This will bring up the "App Notification" page and, if an app supports Notification Channels, you'll see them listed here under the "category" heading. On the first page of a Notification Channel compatible app, you can turn the new notification badge feature on and off for each app or toggle each notification category on and off. Tapping into each category will bring up individual notifications controls. Here, you will see the usual toggles for vibration and ignoring your do-not-disturb settings along with a notification sound selector. There's also a new item called "importance."


The important controls are great. These are basically the "Power notification controls" from the experimental Android 7.1 System Tuner, but they're now an official feature in the notification channel settings. "Low" shrinks a notification down to the new single-height "by the way" notification. "Medium" and "high" are full size notifications (just with and without sound, respectively), and "Urgent" will let the notification pop in overtop of the screen. All of these settings affect the sorting weight on the notification panel—"Low" goes on the bottom, "Urgent" goes on the top.

These four settings levels might not seem as detailed as the 7.1 System Tuner's seven levels, but most of the options are still here, only spread out more. The highest level of the 7.1 controls ignored the "do not disturb" settings, which you can still do through a separate checkbox. The lowest level was just "off," which again exists through a checkbox on each notification channel. The one missing option is "automatic," which just worked as a "reset to defaults" button. There's actually no way to reset the notification of an app to default, which seems a bit like an oversight.

The problem with the new importance controls comes when an app doesn't support Notification Channels. These apps get a single page of notification controls—instead of the multi-page UI enabled by channels. While many of the controls get moved into this single page, like "Allow badge icon," "Allow sound," and "Override Do Not Disturb," the "importance" UI critically does not get moved over. There's nothing about Notification Channels that allows the importance controls to work—they worked fine in Android 7.1, remember—but the arbitrary location of the button means you can't get to the controls unless the app supports channels.


Again, many apps don't target the latest version of Android at launch, so most won't support notification channels. This means Oreo introduces a major regression by removing fine-grained notification controls for the vast majority of apps. To Google's credit, the power notification controls were located in the hidden System Tuner UI, which does warn that "these experimental features my change, break, or disappear in future release." Still, it really hurts to see them removed. It doesn't make any sense to lock importance controls behind the Channel UI. Lots of other controls move to the single page for non-Channel apps—and importance controls should too.

Users who know what they're doing (likely you if you're reading this) will find some solace in the "Allow sound" checkbox. The label isn't quite right; it will actually set the notification to "medium" priority, which blocks sound but also blocks the "peek" pop-up notifications, blocks full-screen interruptions, and lowers the sorting on the notification list. It's not as nice as just being able to block Facebook from using a peek notification for everything, but it's better than nothing.

The real downside to the lack of notification controls is that they would have been so much more powerful with the new, smaller "By the Way" notification section. I would have loved to aggressively "clean up" my notification panel and demote a bunch of apps to the "By the Way" section. There are so many apps that I don't want to outright block from generating a notification but aren't very important to me. For example, I would love to shrink my personal Gmail account notifications, all my smart home notifications, Google Fit's "You've reached your goal" notifications, Android's screenshot notification, Android Pay's "You just bought something" notification, every notification from Google Photos, and a million other things. Unfortunately, I'll have to wait for these apps to update in order to demote them.

Icon badges and shortcuts

In Oreo, icons on the home screen are better tied to the notifications they generate. First up, there's new "Notification Badges." These are little circular dots that appear on icons on the home screen, app drawer, and folders, and these signify that an app is generating a notification. The notification badges are very iOS-like, with the main difference being that Android doesn't show a number in the badge (Google says that causes too much anxiety). By default, they work in the Pixel Launcher, but the badges use an open API that other launchers are free to support.

Users get all the controls they could want for this feature. If you dive into the app settings, you can disable badges on a per-app basis or a per-channel basis if the app supports notification channels. The Pixel launcher also has an "Allow icon badges" toggle, so if you hate them, you can turn them off entirely. Badges don't seem to show up on apps generating an ongoing notification, like playing music or navigating to a place; they're more for messages and other more "temporary" notifications.


One other notification feature attached to icons is the new long press icon menu. Long press on an icon and you'll get a new popup menu. Here, you'll see the usual shortcut introduced in Android 7.1, but you'll also see any notifications the app is generating directly in this menu. If you want to clear the notification, you can just swipe it away. It's like a tiny, one-item notification panel.

The new ambient notification display

Ambient notifications—a feature which debuted on the Nexus 6 with Android 6.0—are a dark, low power notification display that occasionally pops up on the phone while the display is "off." Usually the screen will activate when a notification comes in, as a "here's why your phone just beeped" display. That happens again every time you move the phone or double tap the screen.

For Android 8.0, a lot has changed for this feature. Android 7.x took a very simple approach: it always displayed the normal lockscreen notification panel UI, just rendered in white-on-black style that was power saving and unobtrusive. Android 8.0 replaces that with a custom UI. There are two different styles in 8.0: one "incoming notification" style that pops up only once as the notification arrives and another "here's what you missed" style that pops up every time thereafter.


The "incoming notification" style doesn't show the entire notification panel, just the new notification rendered in a custom style. There are some improvements here. The notification is bigger, allowing you to read it from further away. The display uses a small splash of color related to the app icon—Gmail is in red, Hangouts is in green, etc. This style also surfaces the notification action buttons, allowing you to reply to a message or archive/delete an e-mail with a single tap. The downside is less information overall. In Gmail's case, you lose the contact picture and the account name, while the rest of the UI shows any previous notifications and the date.

The "old notification" style, which pops up whenever you trigger Ambient Display by moving the phone or tapping on it, is vastly simplified. The only bits of notification information are tiny "status bar" icons that sit below the time—there's no text at all. This change is a big downgrade and kind of baffling.

One thing that might justify such a minimal UI is if this UI were made to be "always on" on the Pixel 2—code for such a feature has been spotted in AOSP, but so far it has not appeared in a production build. This interface uses such a small amount of pixels that an AMOLED display—which features individually-backlit pixels and therefore doesn't use power to display pure black pixels—might be able to display it all the time with minimal battery drain. Samsung phones do a similar thing today, as the screen never really turns off but the battery is fine. Still, it would be possible to have an "always on" interface like this while still keeping the user-activated UI (triggered by movement or a double-tap) full of information. As an always-on display this is fine; as a user-triggered interface it sucks.

The Great Background Processing Lockdown

In the world of smartphones, Android has always been, uh, generous when it comes to allowing apps to do stuff in the background. This leads to some really powerful apps, but Android's background free-for-all also leads to some apps accidentally (or greedily) sucking down background resources. In the run-up to Android 7.0, Google warned everyone that The Great Background Processing Lockdown was coming, and in Android 8.0, serious background restrictions for apps targeting Android 8.0 (remember, that's a big qualifier) have finally arrived.

Ben Poiesz, a project manager on the Android Framework, laid out the team's rationale for scaling back background processing in a Google I/O 2017 talk. The goal of locking down background processing is not only improve battery life but also to better manage memory so the device runs more smoothly. He said the team wants Android to have "consistent device performance" over time, which was definitely not the case in the past. At the talk, Poiesz showed a few slides of a pre-O device's typical performance deterioration over the first few months. The first chart wasn't surprising, with the takeaway being "more apps = less battery life" thanks to apps doing processing work in the background. The second was a little shocking; Google found that UI performance was also affected by the number of apps installed. As apps on their own schedule randomly start up in the background, they slow down the phone and cause UI animation skips. Even things like uptime would slow the UI performance, presumably from apps claiming system resources and never returning them.


At his talk at I/O, Poiesz said Google's eventual goal is for "multi-day battery life" in Android, which he said would require a "6-8x efficiency improvement" from where Android is today. He described the switch to JobScheduler (see below) as "setting the stage for the future," so in addition to what we're seeing in Oreo, I'd expect more background changes to come to Android eventually.

Mandatory JobScheduler

The change from free-for-all background processing to something more managed has been a steady march. In Android 5.0, Google introduced the JobScheduler API, a "traffic cop" for background tasks in Android. Instead of having an app wake up the phone on its own timeline to perform a background task, apps would put in a request to the JobScheduler. JobScheduler would batch up requests from multiple apps into a coordinated burst of background activity. Batching up background tasks lets the phone stay idle for longer periods of time, which is key to saving battery power. JobScheduler also encourages delaying noncritical background work until the phone is idle, plugged-in, and on Wi-Fi, when the device has unlimited power and data. To save on RAM, JobScheduler runs these jobs one at a time, or a few at a time, so the system doesn't run out of memory. The feature also enabled the "Doze" mode in Android 6.0 and up, and this put an idle phone into a deep sleep to save power.

When JobScheduler was introduced in Android 5.0, it was an optional thing that apps could coordinate with if they wanted to be good citizens. The old system was still around, so apps could also ignore JobScheduler if they chose to do so. In Android 8.0, Job Scheduler has been promoted from optional to the main method of running background tasks for apps that target Android 8.0.


Another periodic reminder: we're talking about changes for apps that "target" Android 8.0, and at launch that's going to be a very small group of apps. For the background processing changes, though, users get a bit more control and can manually force the new background limitations on an app. Just head to the App Info screen (That's System Settings -> Apps & Notification -> App Info -> [App Name] ), tap on "Battery," and turn off the ambiguously-titled "Background Activity" switch. This won't necessarily prevent all background activity, but it will opt any app into the new Oreo background rules. Depending on how the app is written, this might break all background activity for the app, so use with caution.

RIP Implicit Broadcasts

Before JobScheduler, the old app background startup method had apps subscribe to "implicit broadcasts"—system-wide, generalized announcements of status changes, like a new picture being taken or a connectivity change. Multiple apps would listen for one of these status changes, and all start up at once, which could cause a low memory situation as every app tried to load itself at once. This caused major performance issues for devices with low memory, and the situation got worse as you installed more apps. Implicit broadcasts would often trigger when the user was in the middle of doing something, like taking a picture. You take the first picture, a million apps start up because they are subscribed to the "new picture" broadcast, and now when the user is trying to immediately take a second picture, the phone has slowed to a crawl because a bunch of apps want to load themselves into memory.

Google took a gradual approach to fixing implicit broadcasts, shutting down three of the biggest troublemakers in Android 7.0 Nougat—the new picture broadcast, new video, and connectivity change. In Android 8.0, most implicit broadcasts are being disabled for background apps targeting O. If an app is in the foreground, it will be able to receive implicit broadcasts, but apps won't be able to "wake up" anymore from a broadcast. This is yet another change only for apps that target Android 8.0, but users can opt apps into the change by turning off the "Background Activity" switch.


It's worth noting that the other kind of broadcast, an explicit broadcast, can still wake up an app. Explicit broadcasts specifically target an individual app, and these are usually called from notifications (like an incoming message) from within the app itself or called when the app is updated through the Play Store.

Since explicit broadcasts are targeted at a specific app, it's unlikely that this would cause a device slowdown or use a ton of RAM, so they are allowed. For that same reason, some rare or more targeted implicit broadcasts are still allowed, too. Examples include plugging in a headset, changing the locale or timezone, and connecting to Bluetooth. Google doesn't feel such activities are detrimental to the user experience.

No more wakelocks, no silent background services

While JobScheduler and receiving broadcasts both serve to wake up an app, the other component of background processing on Android is keeping the phone awake once your app has started up. In Android parlance, this is a "wakelock"—an single app's ability to keep the phone awake to do processing work.

In past versions this was 100 percent up to app developers. Any single app could keep your phone awake for any reason, and if a single app messed up and didn't release its wakelock, you phone would never go into a low-power state. Moving to these low-power states is absolutely critical for battery life on a smartphone—holding a wakelock can cut hours off a device's battery life. In the world of rooted Android devices, apps and Xposed modules that detect and kill wakelocks are a cottage industry, numerous apps and guides out there let advanced users lockdown background processing themselves.


But Android 8.0 is clamping down on wakelocks—an app's wakelocks will be automatically released by the system when the app is "idle." This basically means that if an app isn't running an activity in the foreground (generating UI that is visible to the user) and isn't using a foreground service (generating an "I'm doing stuff" notification that is visible to the user), the app is going to be shut down. App developers are still expected to manage wakelocks themselves, but this is a "protection" against apps keeping the phone awake.

With the death of wakelocks, as Poiesz put it, "free-running background services are no longer 'a thing'" in Android. Apps won't really be able to do anything in the background anymore, which sounds much more limiting than it really is. Apps can still provide ongoing features and services and do everything they used to do in the background, but now the user must be aware of it. Instead of a background service, apps can use a "foreground service." This works just like a background service, but critically, this approach generates a notification, letting the user know that an app is turned on and consuming battery, RAM, and other resources. We see this today with things like Google Maps' bright green navigation notification, a music app's "currently playing" notification, or Uber/Lyft's "your driver is on their way" notification.

Google's mantra of "tell the user about background processing" makes a lot of sense, and it's a standard feature of desktop OSes like Windows (with the system tray) and macOS (with menu bar icons). In Android 8.0, the base OS also has a new system-wide "App is running in the background" notification, which is a single line, collapsed-by-default notification that will list each app running in the background. This notification seems meant to catch the "sneaky" apps that target an old version of Android and can still quietly run in the background, but there is some potential for duplicate entries here, too.


The way the "running in the background" notification works changes from app to app. Media apps that generate an ongoing notification seem to be exempt, as is Google Maps, but if you start an app that will trigger the notification, you'll also see these "exempt" apps listed in the notification. So if you play music, you won't see the "running in the background" notification, but if you run another app, you'll see the new app and the music app listed in the "background" notification. The important thing is that you're always notified when an app is running in the background... and sometimes you're notified twice.

As always, there are a few exceptions to this "no background services" rule. If JobScheduler wakes up your app, either through a scheduled job or from an incoming "high-priority" message for things like chat apps, the app will be whitelisted for a bit and allowed to deal with the job. There are also exceptions for a few special, user-designated apps, like a keyboard app that is installed and activated, an active live wallpaper, any turned-on "Notification Listener" apps like the Android Wear companion app, and some accessibility apps like screen readers. OEMs are also allowed to do whatever they want in the background with their own apps.

(Somewhat) gracefully declining on older OSes

With the death of broadcasts and background services, some developers will have to do a bit of work if they want to target Oreo. Of course, with Android's eternal update problem, a very low percentage of devices will be on O for some time, so it's hard to encourage app developers to make the switch right now. One thing that will help is the new JobIntentService support library, which allows developers to write for the new Oreo way of doing background services while the library ensures compatibility with older versions of Android.

When using the JobIntentService library, developers get methods that will start a job on Android 8.0 and fall back to a service on an older version of Android. On Pre-O devices, the library will kick in and handle wakelocks for developers starting one when they need to do background work and killing the wakelock when the app is done. Given that JobScheduler was introduced in Android 5.0, I'm not really sure why this library seems to ignore the JobScheduler progress made from Android 5.0 to 7.1, but that's what the documentation says.

Limiting scans for location and Wi-Fi

Before Android 8.0, apps had unlimited background location usage. Google frequently cited background apps "polling once every second" in previous versions, which will chew through battery like crazy. Sometimes this was accidental, where apps would request precise location and in the foreground and forget to stop in the background. Other times, this was a developer being far too aggressive with background location requests.

In Android 8.0, Google is putting limits on background requests. For most cases while in the background, apps will be granted location updates about every 30 minutes. Apps are still free to request as often as they'd like, but the system will just continue providing old data and will only fire up the GPS and update the location at most every half hour.


Just like with the JobScheduler/Implicit broadcast change, this is mostly a case of limiting old, power-hungry, free-for-all APIs in an effort to push developers to switch to a newer, organized, more manageable API. There are many ways to request location in Android, and some methods (the older stuff) are being limited more than others.

Location Manager—The fact that this was introduced in Android 1.0 should tell you all you need to know about it. It gives manual access to the GPS, Wi-Fi, and cell location and it is almost always wrong to use this API. Now, it's limited to "a few times each hour."

Fused Location Provider—A second try at location introduced in the Android 4.2 era, but it was built into Google Play Services instead of directly into Android. Combines location information from the cellular signal, Wi-Fi, and GPS, and bundles it into a simple API for more battery-efficient location detection. Now limited to "a few times each hour."

Geofencing—A centralized location service in Google Play Services that lets developers declare a "geofence"—basically draw a shape on a map—and be alerted if the user enters or exits this area. This API is preferred for most background location usage, as the documentation states that "apps can receive geofencing transition events more frequently than updates from the Fused Location Provider" with an "average responsiveness for a geofencing event" of "every couple of minutes or so."

GNSSMeasurements/GnssNavigationMessage—This raw GPS data API was added in Nougat. Apps probably should not be using this unless they are a detailed GPS satellite data app. It's totally blocked in the background in Android 8.0.

Wi-Fi Manager—Not exactly a background location API, but apps could relentlessly pound on the background Wi-Fi scanning API to try and get a rough location. In Android 8.0, this is limited to once every 30 minutes per app.

Nothing is changed for foreground apps and services, so Google Maps Navigation will still work and your Uber driver will still be able to find you. Google's recommendation is that if an app really needs to perfectly know your location, it should start a foreground service, which will generate a notification to let the user know.

With all the background processing limits in Oreo, many people have wondered if they apply just to third-party apps or if Google will actually be limiting its own apps. For location updates, Google spells it out right in the documentation: "This behavior change affects all apps that receive location updates, including Google Play services."

A real API for floating apps

Android 1.0 introduced an API called "System Alert Window." This API was intended for, well, Android's system alert windows like crash notices and "Amber alerts." It was a public API that probably shouldn't have been public, though, and it started being used by apps like Facebook Messenger to draw floating windows on top of the entire device. Since it was never intended to be used by multiple apps at once (or by the public, at all), it has all sorts of problems. It doesn't have a sane way to manage Z order, there's no way to know what app is drawing a floating window, and there's no communication to the user about using system resources.

System Alert Window also breaks the normal Android layering conventions—it's possible to draw over top of the status bar, System UI, and lock screen. This has led to malicious apps picking up the API to do "clickjacking" or full-screen "ransomware" apps. The System Alert Window API allows such apps to lock you out of your device by covering up the system controls; these apps then demand payment to return control of your device.


Google began to rein in this API in Marshmallow by tagging it under a new "Draw over other apps" permission, but for apps that target Oreo, the API is dead. Google has a new API called "Application Overlays" that is purpose-built for Facebook Messenger-style overlay apps. The new API properly supports layering multiple apps, and it is in the correct Z space (above the foreground app but below the System UI). The API spawns an ongoing notification so users can see an app is using system resources, and it automatically identifies the app to the user.

Security

Google Play Protect—Google says "please don't install antivirus apps"

Alongside the launch of Android 8.0, Google is rebranding its suite of Android security features as "Google Play Protect." It's rolling out much of this rebranding through Google Play Services, so Google says you'll see it on "every" (Google Play-enabled) Android Device in the future. "Rebranding" is definitely the operative word here, since Play Protect is mostly a collection of things that already existed inside Android. Now it has a new, more in-your-face presentation.

Google seems to feel that Android has a security perception problem. On the Play Store side of things, Google does a far amount of work to keep users safe from malware, but no one really knows about it. During an I/O talk, Google Director of Android Security Adrian Ludwig lamented the current (low) awareness of Google's malware scanning operations. "The number of times that I've read the statement, 'Google doesn't look at the applications in Google Play' blows my mind," he said. "Every single application that's uploaded to Google Play goes through a very rigorous screening process, both at the time the developer is enrolling to become a member of the Google Play publishing process and at the time the application is published and every single day after that we reanalyze all of those applications."

Ludwig says Google continually uses its machine learning prowess to improve this malware-scanning operation, and the company shared some statistics on the effort. Google runs scans on two billion devices total, with over one billion device scans a day checking 50 billion apps. Of course, this scanning happens in Google's cloud, where 20,000 dedicated processors scan Android apps for potentially harmful behavior.


This scanning isn't just for apps on the Google Play Store. By default, the Play Store will upload "unknown" apps to Google, so even if you sideload an app, Google will still scan the app as long as you are on a device with Google Play. Between sideloads and new Google Play uploads, Google says it scans 500,000 apps a day, and any newly-discovered apps get queued up for deeper analysis.

Google first started scanning for malicious apps with the release of Android 4.2, where the system was called "Verify Apps." It was buried deep in the settings, which meant a lot of users never knew about it. With Play Protect, there's a big emphasis on app scanning, with new bits of UI that get shown in all the relevant places.

Update: An earlier version of this article said, "Google says it discovers 500,000 new apps a day." The number came from this Google I/O talk. At 1:40 the presenter says "500,000 new applications discovered every day," but the slide says "500k+ apps analyzed daily." Half a million new apps seems way too high, so I think he just misspoke.

The "Security" page in the main Android 8.0 system settings has a new "security status" section right at the top of the screen (non-O devices can access this from Google Settings -> Security, thanks to the magic of Play Services). The first item here is for Google Play Protect, which shows the last time Google's malware scanning pinged your app collection. There's also the current "Find My Device" status, another feature which has been pulled into the Google Play Protect umbrella. The feature was formerly called "Android Device Manager," and it did nothing to indicate to users that it was a phone tracker. The updated security status section also shows the date of your last OS security patch.

Tap on the Play Protect item and you'll go to the new "Protect Home" page, which is full of reassuring statistics that show when your last scan was, which apps were scanned, and the current status of the app scanner. The Play Store gets a few green shields, too, with an on-demand scanner in the Play Store's "My apps" section and a "Verified by Google Play Protect" banner on an app download page.


Google's main goal with Play Protect seems to be to dissuade users from installing a third-party antivirus app. Play Protect uses all the typical antivirus branding vocabulary. The logo is a big, green shield, protecting users from the leet hackers of the world. The Play Protect section in the security settings looks just like an antivirus dashboard app, and Google has placed billboards declaring "EVERYTHING IS FINE" all over the OS. There's even a big "Scan for security threats" check box in the Protect dashboard and a feelgood on-demand scan button on the Play Store updates page.

To his credit, Ludwig was very transparent at I/O about Google adding a bit of security theater to its Android security solution. "What [users] want to know is, 'Am I safe?' That's really what the [Play Protect] announcement was," he said. "Putting, really in a brand, that these protections are there and making them more and more visible to users. Also, [we want to say] that Google is standing behind this protection. It's saying that Google is going to protect you on your Android device and make sure that we have the best protections in place."

While Ludwig didn't mention antivirus companies on the I/O stage, in an 2014 interview with the Sydney Morning Herald, he revealed how much room he thinks exists for third-party Android AV solutions. "I don’t think 99 percent plus users even get a benefit from [antivirus]," Ludwig told the paper. "There’s certainly no reason that they need to install something in addition to [the security we provide]... If I were to be in a line of work where I need that type of protection it would make sense for me to do that. [But] do I think the average user on Android needs to install [antivirus]? Absolutely not."


Most antivirus companies have already slithered their way into preload deals with OEMs or carriers. Lookout usually comes preloaded on AT&T, T-Mobile, Sprint, and Samsung phones, while McAfee comes with anything from Verizon, LG, and Sony. If Google really wants to kill Android antivirus, it has a long way to go.

If "security theater" is instead Google's goal here, the only thing really missing from Play Protect is an app icon. That little green shield would make a great placebo that could be placed, by default, on the home screen of every new Android device. An icon would also help customers dump third-party apps when they see two "shield" icons in the app drawer—one from Google and one from some third party.

Also part of the Play Protect re-branding, the "Find my device" feature is a rebrand of the Android Device Manager. As usual, it can display your phone on a map, make it ring, remotely lock it, and remotely erase it. There's a revamped app and a new website at android.com/find. You can also just Google "Where's my phone" on a desktop and get a tiny inline map of your devices. Google is also putting Chrome's "Safe Browsing" feature—a database of potentially malicious websites—under the Play Protect banner.


A new "Verify Apps API" in Google Play Services will let app developers query the current state of your apps. If Google Play Protect says a "harmful" app is installed, the app can refuse to run. This is the app scanning counterpart to Google's SafetyNet API, which makes sure the operating system is in a good, CTS-certified, non-rooted state.

Sideloading changes

Sideloading, the act of installing an app from a source other than the official Google Play Store, has changed a bit in Android 8.0. Android use to have a single "install unknown sources" checkbox—a system-wide box that would allow installing non-Google Play apps from any other source. Now the "install unknown apps" permission works on a per-app basis, so if you head to "Apps & notifications," "Special app access," then "Install unknown apps," you'll see a list of apps that have requested the permission and will be able to manage each one individually.

According to Ludwig, Google has "come to appreciate that there are other safe places [besides Google Play] to install applications from." He said the point of this feature is to let users "install from those other safe places without introducing the risk of installing from anywhere that's out there."


There are some good third-party app stores out there, like the Amazon App Store and F-Droid, a repository of open source apps. There's also APKMirror.com, which lets impatient Android enthusiasts download apps directly, sidestepping the Play Store's complicated and annoying rules for app rollouts, A/B tests, betas, and region locks.

Ludwig wants users to be able to "decide, 'yep, that app store can install,' but that doesn't mean everybody can install." That sounds like a good idea, but the delivery mechanism for all of these app stores and websites is the Chrome browser. Once you've allowed Chrome to install third-party apps, you've essentially put the "everybody can install" scenario back on the table—the entire Internet has permission to install apps again.

If having the "allow unknown sources" permission turned on is actually risky (and I'm not sure that it is, since you still have to download a malicious app, open the APK file, press the "install" button, and probably grant it some nasty permissions), Google needs to work out a system that allows app installs on a per-website basis as well as per app. Right now, anyone downloading a third-party app store will have to grant the "install" permission to Chrome, which basically defeats the purpose of the entire per-app system. Just because I allow something from APKMirror doesn't mean I want to allow FreeViruses.com to install stuff, and I'd guess the majority of Android malware that appears out there arrives from a drive-by Chrome download.

Security grab bag

No more OS downgrades—If an attacker steals your phone, Android has several security features in place that will make it more difficult to access your device. It doesn't help matters much if the attacker can just downgrade the operating system to a version that didn't have those protections in place, so with that in mind Android 8.0 introduces "rollback protection" into the Verified Boot process. With rollback protection, Verified Boot will no longer start up an OS that it detects has been downgraded to an earlier version.

Developers (or Android-obsessed journalists) that need to downgrade their device to an older version for testing or checking something can disable this feature, which will trigger the usual slew of boot-up warning messages. Google also says it has "hardened the bootloader unlocking process," which should make it harder for bugs or malicious apps to unlock the bootloader without user approval.


Device identifiers get locked down—In Android 8.0, Google has locked down a number of ways for apps and other third-parties to identify the device. The Wi-Fi MAC address can now be randomized, provided you have compatible Wi-Fi chipset firmware. Google has this up and running on Oreo on the Pixel and Nexus 5x. The "Android ID" value is now scoped per app and per user. For apps that target Oreo, accessing the serial number is locked behind the "Phone" permission, just like the IMEI number, and Google says in the future that the API will be deprecated entirely. "Net.Hostname" now treats the device as anonymous instead of sharing the device hostname with networks. A number of other identification techniques were limited, too.

Google recommends using its "Advertising ID" for app device identification needs. This has a limited tracking option available to users (Settings -> Google -> Ads -> "Opt out of ads personalization"), and it resets when the device is wiped.

Stagefright gets a traffic cop—As we covered in the "Project Treble" section, Google's modularization of Android also adds HALs for the audio, camera, and DRM servers in Google's "Stagefright" media framework. With the HALs acting as a middle man, the Android Framework pieces no longer have access to the Kernel, making it harder for an exploit in one area to cross the barrier into the other area.


Seccomp filter—In the same vein of "limiting access to the Kernel", Android is now using Linux's seccomp filter. This is a filter that allows Google to whitelist system calls—a feature that lets apps communicate with the Linux kernel directly. Google has locked things down to only the system calls surfaced by the Android framework, calls needed by Android's C runtime, or calls required to boot up. The idea is that shutting down access to typically unused system calls will limit the attack surface of the kernel.

WebViews get isolated—Android's WebView—a way for apps to embed Web content, powered by the Chrome browser—has been upgraded in Android 8.0. The renderer for WebViews will now run in a separate process, allowing the app to be insulated from the web content it's loading. If the render crashes, only the WebView should crash, and malicious content should have more roadblocks between it and the app. The new isolated render is sandboxed with a limited set of permissions—it can't write to the disk or talk to the network on its own. Safebrowsing—Chrome's database of potentially malicious web sites—can also be enabled on WebViews now.

Developer options requires a password—Enabling the Developer Options opens up lots of powerful settings and tools, so to protect the device, you'll now have your lock screen security challenge pop up after enabling the feature.

Emoji: New glyphs and an all-new design

There's major emoji news in Android 8.0: All 2000+ emoji have been redesigned. This is something like the fifth edition of redesigns for Android's emojis. Google's old blob-style emoji are dead, replaced with something a lot more neutral and Apple-y. I think iOS-style emojis are a good thing and will lead to more consistent communication across platforms. Some people are very, very attached to Google's old blob emojis, though, and are unhappy.

Google gave an explanation of the change in a blog post, writing, "With the proliferation of high density screens and new messaging use cases, we decided it was time to give our emoji an overhaul." Google says the old emoji style "wasn’t equipped to to provide standards that unified the look and feel of all the illustrations across the many emoji categories. As a result, our emoji became inconsistent between old and new designs, making it difficult to quickly scan the keyboard to find the right emoji."


To create the new emojis, Google says it created a "design system" that will allow it to pump out consistent emoji now and in the future as new glyphs come out. All the emoji are drawn on a single grid system for consistent sizes and shapes. The eyes, noses, mouths, and other parts are shared across emojis. Poses and angles were standardized for animals, and the colors were standardized with a neutral yellow, sad blue, sick green, and red for angry. The outlines are all in a contrasting brightnesses from the main emoji color, helping with legibility across any background colors.

In its blog post, Google fully admits the iOS influence, saying it "one of our main goals with the redesign was to avoid confusion or miscommunication across platforms" and that it "wanted to assure the user that when they sent an emoji to a friend, the message was clearly communicated regardless of whether they are on iOS, Windows, Samsung, or any other platform."

Besides all the existing emoji redesigns, Google is also rolling out Emoji 5.0 from Unicode 10 in Android 8.0. This means Android is getting 69 new emojis plus all the usual skin tone options. These includes lots of fantasy characters, a few new animals, a few more food options, even more smiley faces, and some inclusiveness emoji like "breast feeding" and "woman with headscarf." Personally, I really like the hedgehog.

EmojiCompat and Downloadable fonts—updating emojis without a system update

It's not part of Oreo, but along with the launch, Google is also introducing a new feature in Support Library 26 called "EmojiCompat." This library—compatible with Android 4.4 and up—will allow app developers to ship new emoji to old versions of Android.

EmojiCompat isn't a single, system-wide emoji update system. Instead, it relies on individual apps to include it. The idea is that an app like Google Hangouts could include EmojiCompat, and then instead of older systems seeing tofu—the little squares (☐) that show up when a device doesn't support a character—they'll see the new emoji. Keyboards are just apps in Android, so keyboards can include EmojiCompat, too, allowing users on old systems to type the new emoji. Keyboards are encouraged to check a few flags in the app to see if they're running EmojiCompat, too, so the keyboard doesn't display a glyph the app can't display.


In the past, Android needed a full system update to get a new batch of emojis. Emojis are just a font, though, so—together with a new "downloadable fonts" feature—apps will be able to get fresh emojis shipped to them as they come out. With downloadable fonts, apps will request fonts from a central trusted font provider rather than bundle them with the app. For Google Play devices, this "font provider" is Google Play Services.

In the future, imagine a world where apps and keyboards are all shipping the EmojiCompat library, and a new set of emojis are released with Unicode 11. Google just has to update the emoji font in Play Services, which can be downloaded to your device and used in every EmojiCompat app. Again, this isn't just Android 8.0—this should happen on Android 4.4 and up.

Downloadable emojis adds an interesting wrinkle to the skinned Android situation, since Samsung, LG, HTC, and other OEMs replace Google's emojis with their own designs (For an example, just look at any Emojipedia entry, which shows each style). When new emojis are available, a device will download them from Play Services, so they'll be the Google emojis. By default, EmojiCompat will only replace missing emoji with glyphs from Play Services, so on a skinned device, you'll get OEM-style glyphs for old emoji, but Google-style glyphs for new emoji. You're going to get a mix of emojis styles. App developers can also configure EmojiCompat with a "replace all" option, which will swap out everything for the Google-style emoji. Should app developers opt to banish skinned emoji for the sake of internal consistency? It's a difficult decision—maybe one that can be a user-configured option in an app?


Play Services is handling font duty not just because that's an easy way to get an authoritative font provider on new and old versions of Android, but also because fonts can execute code on Android, so they need to be controlled. Play Services will be providing a "trusted" pool of fonts from Google Fonts—about 800 options in total.

For developers, there are plenty of security procedures to go through, given that fonts are a security risk. Developers have to specify which exact font authority they want to download from, along with a special signed certificate for that font provider. For now, this is only Google Fonts. But in the future, Google wants to allow third parties to provide fonts for Android.

Any required fonts that aren't already on the system will be downloaded at install time. Developers have the option of sticking to a single version or being automatically updated to the latest font release. Apps will share fonts, so only one copy will be updated at a time. This should reduce APK size and storage needs if you have a bunch of custom font apps.


For Developers, fonts are now a resource type in Android, just like images, text strings, colors, layouts, and animations. Along with the Play Services-powered font provider, developers will have 800 fonts to pick from for their apps.

System UI improvements

Adaptive icons—Shape shifting, animated icons

Today, Android skins—like Samsung's TouchWiz or Xiaomi's MIUI—have trouble blending in with the rest of the Android ecosystem, particularly when it comes to icons. A company like Samsung can change the system theme and reskin all the AOSP apps, but it can't change the Google apps or third-party apps. This is easily seen on the home screen of most skinned devices, where the OEM apps will follow one icon style while Google and third-party apps follow another. If you're an app developer, an icon shape is a tough decision to make. Pixel devices use circular icons, Samsung devices use a squircle, numerous Chinese companies try to emulate Apple's rounded rectangle icons, and apps following the old Google guidelines use uniquely-shaped icons.

To bring a bit more consistency to icons, Google is introducing "Adaptive Icons" in Oreo. Instead of having developers submit a fully-assembled icon with a locked-in shape, the Adaptive Icons system has developers submit a foreground and an oversized background for their icon. The launcher can then assemble these pieces on the fly. The foreground gets centered in the icon, and the launcher crops the background to match whatever icon shape it wants. With this system, developers can match whatever shape the launcher needs with just two pieces of artwork. Samsung can have its squircles, and Google can have circles—whatever shape you need will work.


Like everything new with Android, adopting adaptive icons is an ongoing process that the ecosystem is slowly picking up. For Google in particular, it really seems like the company needs to drastically redesign some of its icons to fit this new icon style. Some apps, like Google Maps, are great: the foreground has a location marker and a white Google "G," while the background is a colorful map that changes shape depending on the icon mask. Other apps, like the Google Play Suite, are awful. They're still using the triangle-shaped "play button" icons, just slapped on top of a white background. It looks lazy and unfinished, and it's in desperate need of a revamp.

Google also plans to animate these icons at some point in the future. At I/O 2017, Android software engineer Hyunyoung Song spoke of using the oversized layers for "parallax effects" and "pulsing," which lets the foreground layer move around inside the icon mask while scrolling or tapping. "We're still vetting how to best place these [animations]," Song said, "but it will come up in future releases."

That's not the only animation feature coming to icons—the clock icon now animates in Oreo. The icon is an analog clock with an hour, minute, and second hand, so they will all move in sync with the time.

A new widget picker

A desktop style, fully-customizable home screen was one of Android's major mobile innovations when it first came out. Finding that customization functionality was always a struggle though. Individual apps never had a way to offer up their widgets to users, which meant, after installing a new widget, the only way to add it was to subject yourself to a clunky process of going to the home screen, log pressing, opening up the widget drawer, and finding the thing you just installed.

In Android 8.0, apps can now offer up an "add to homescreen" dialog box for icons or widgets. From an app, you can now press an "install widget" button, and a popup will appear showing a preview of the new icon or widget. Users are instructed to long press on the item, at which point the home screen pops up and they can place it anywhere by releasing. There's also an "add automatically" button, which will dump the item on your home screen wherever it fits.


The widget picker has the usual "new Android feature" problem: almost nothing supports it at launch. The only thing I've spotted that this is available in is the contacts app, where you can press the overflow menu button and pick "add contact to home screen." Apps like Chrome and Google Hangouts have their own "add to homescreen" button, but it uses a custom-built solution. This will really help third-party apps that are only widgets, which currently show really clunky "dig through the widget drawer and find our widget!" tutorial screens.

Picture-in-Picture for phones and tablets

It's hard to call picture-in-picture (PiP) a "new" feature in Android 8.0, since Android 7.0 introduced the feature to Android TV. In Android 8.0 though, picture-in-picture gets ripped out of the "TV" niche and is available on any Android device.

Opening PiP is a little complicated. You have find a video, full screen it, and, while it is playing, press the home button. It would be a lot more obvious and discoverable if there was a "PiP" button somewhere in the video UI. Once the video is in PiP mode it works about how you would expect. You can drag it around and leave it anywhere on the screen. If you tap on it, the video will get a bit bigger, and show controls for "rewind," "pause," "forward," "full screen," and "close." The one missing feature is that you can't resize the PiP window, even on a tablet (sign #28576 that Google doesn't care about tablets).


It's up to apps to support PiP mode, and right now Google has support in Chrome and YouTube (if you pay for YouTube Red) but not Google Photos or Google Play Movies. Third-party apps like VLC have started to support the API, too. The YouTube Red requirement for PiP is a real bummer, since it's the video site most people will want to use. Along with limiting background playback, it's another case of YouTube's premium "service" charging users to use a basic, core OS feature. YouTube.com even manages to break Chrome's PiP support—YouTube's mobile site manages to detect-and-kill Chrome's PiP for non-Red users.

Google also seems to experimenting with the idea that picture-in-picture can be used for things other than video. A Google Maps beta has early PIP support—so early that we're not quite sure what the end product will look like. I'm not sure this kind of multitasking works for driving, but it would be great to have a small Maps window on the screen for mass transit or walking directions. Then you could have most of the screen free for watching a video or texting someone while still being able to keep an eye on your next turn or stop.

Correction: I originally blamed Chrome for the lack of PiP support for YouTube, but Paul Kinlan, Chrome's head of developer relations, set me straight.

Smart text selection and TensorFlow Lite

Text selection has been powered-up in Android 8.0 with some machine learning goodness. With a long press or double tap, the system will automatically highlight entire times and dates, addresses, phone numbers, and URLs, instead of just simple "word" selection. The standard cut/copy/paste text popup can also include a shortcut to an appropriate app for a selection: Maps for addresses, Chrome for URLs, etc. Some apps, like Gmail, will already try to detect and link-ify things like phone numbers, but since this is part of the standard text view now, it will work on all sorts of apps.

The brains behind this feature is a mobile version of TensorFlow, Google's open source machine learning library, called TensorFlow Lite. This "lite" version does on-device machine learning, without needing to send any data to the cloud. Recognizing addresses is rather underwhelming task for a neural network, but apparently this is just the tip of the iceberg for Android. During the Google I/O 2017 keynote, Dave Burke said the Android team was working on a hardware accelerated compute framework, and that in the future the team expects dedicated machine learning computer hardware to show up in phones. Burke says machine learning DSPs will power "the next generation of on-device speech processing, visual search, augmented reality, and more." For now though, it finds addresses.


In a future version of 8.0, due out later this year, Android will provide a "neural network API" that lets third-parties plug into TensorFlow.

AutoFill

Also on the text input side of things, Android 8.0 now comes with both an Autofill API and a Google-powered autofill service.

The autofill API works with all the fields you would expect it to: Contact information, credit cards, and username and password combos. Any app that uses the standard text input views is compatible with the autofill framework.


Users can grant and revoke autofill permissions to apps in Settings -> System -> Languages & input -> Advanced -> Input assistance -> Autofill service. By default the only option here is "Autofill with Google" but there's also a handy "Add Service" link that will do a custom Play Store search for other autofill apps. Currently the list is blank, but we've already seen experiments from password management apps like 1Password. For apps storing private data like credit cards or passwords, you can lock the data behind some kind of authentication, like a fingerprint.

Google's autofill service uses all the usual Google cloud services. Names and addresses come from your Google account information, credit card information comes from Google Payments, and passwords come from Google's "saved passwords," which is the same system Chrome uses.

Autofill in Android 8.0 really does seem to work everywhere, and it's really nice given how annoying tiny smartphone keyboards are.

Settings—A new theme, a new layout

Generally the Settings in Android 8.0 have been visually polished up, with new margins and icons that didn't exist before. The color scheme has changed from a dark grey header in Android 7.1 to a light grey header for 8.0. The settings have also been totally reorganized, cutting down the main sections considerably from 26 items to 13. Everything is still here though—most sections have just been merged into logical, more general categories.

The first of the big new categories is "Network & Internet," which sucks up top-level Android 7.1 sections like "Wi-Fi," "Data Usage," and the ambiguously-titled "More," which housed things like hotspot settings, Airplane Mode, VPN settings, and APN settings. There's also "Apps & notifications," which—duh—contains the "Apps," and "Notification" pages from 7.1, but also eats the "Tap & Pay" section. The biggest new category is "System," which merges a whopping eight 7.1 sections: "Moves," "Languages & input," "Backup & reset," "Date & time," "About phone," and, if you have them enabled, "Developer Options," "Memory" (which moved to the Developer Options), and "System Tuner."

Not everything is here that was in the Android 7.1 settings. The detailed battery stats have been removed in Oreo. These listed technical items like "CPU Total," "Keep Awake" time, "Mobile Active Radio" time, and others. In their place are three more easily-understandable statistics. There's "Active Use" time, "Background use" time, and a total "Battery Usage" stat, which computes the mAh the app used. One subtle but kind-of-threatening change to this screen is the button arrangement. While looking at the battery stats, users used to have "Force Stop" and "Report" buttons, but now the buttons are "Force Stop" and "Uninstall/Disable." Google is really encouraging users to break up with misbehaving or greedy apps, saying, "Don't like the battery usage? Uninstall that app!"


One huge improvement to the settings design is a willingness to put the same option in multiple locations. If you prefer to browse the settings rather than search for something, this takes a lot of guess work out of finding the option you need. Is the screen timeout on the "Display" page, because it has to do with the screen, or on the "Battery" page, because it greatly effects how long your phone will last? You don't have to guess! It's on both pages. A link to "app permissions" is in multiple pages too, along with some of the fingerprint sensor gestures.

Totally rearranging the settings in a new release is always annoying, but across the Android ecosystem the settings have always been a mess. Manufacturers inexplicably insist on rearranging the settings in their Android skins, which already made learning Android's settings—or trying to follow online instructions—impossible. The Android ecosystem's always-changing system settings means the settings search is your best friend, and thankfully, it works great in Android 8.0. Besides directly linking you to an item, the search results also show a path to the item, so you can attempt to learn the new settings.

There is now finally an "Add Ringtone" UI in the sound settings. You've always been able to add custom ringtone, notification, or alarm sounds to Android if you knew the secret: You needed to use a third-party file manager (or computer) to add an audio file to the appropriate folder in /sdcard. Oreo actually exposes custom ringtones in the "Sound" settings UI: just tap on the ringtone, notification, or alarm sound, and at the bottom of the list you'll see an "add ringtone" button. This will open a file manager and you can pick an MP3 or OGG file! It's amazing what technology can do.

There's a new "Turn on Wi-Fi automatically" feature in the settings. You can find this checkbox in Network and internet -> Wi-Fi -> Wi-Fi Preferences. There is zero documentation on this feature, but it seems the idea is that you can turn Wi-Fi off then you're traveling, and the phone will turn Wi-Fi back on when you are near a saved Wi-Fi spot. Presumably this uses your location, but Android location also uses Wi-Fi as a low-power means of determining location. I think what's happening is that turning Wi-Fi "off" doesn't really turn it "off." The location detecting "Wi-Fi scanning" feature—available in Security & Location- > Location -> Scanning—is always active, and now instead of just using it for your location, if Android happens to see a familiar network, it will turn on Wi-Fi and connect to it. Wi-Fi scanning even tries to communicate this to you in the checkbox, which says it will improve location by "detecting Wi-Fi networks at any time" meaning even when the Wi-Fi is "Off."

Streaming OS Updates—never fail an update due to storage space again

We've probably all had this happen at one point or another: It's time for an OS update, and your phone wants to download a ~1GB brick of an update file. On Android, this normally gets downloaded to the user storage partition and flashed to the system partition, but wait! Your phone is full of pictures, or videos, or apps, and there's not enough space to store the update file. The update fails, and the user is told to "free up some space." According to the latest soure.android.com documentation, Google has cooked up a scheme to make sure that "insufficient space" error will never stop an update again.

Where the heck can Google store the update if your phone is full, though? If you remember in Android 7.0, Google introduced a new feature called " Seamless Updates ." This setup introduced a dual system partition scheme—a "System A" and "System B" partition. The idea is that, when it comes time to install an update, you can normally use your phone on the online "System A" partition while an update is being applied to the offline "System B" partition in the background. Rather than the many minutes of downtime that would normally occur from an update, all that was needed to apply the update was a quick reboot, at which point the device would just switch from partition A to the newly-updated partition B.

When you get that "out of space" error message during an update, you're only "out of space" on the user storage partition, which is just being used as a temporarily download spot before the update is applied to the system partition. Starting with Android 8.0, the A/B system partition setup is being upgraded with a "streaming updates" feature. Update data will arrive from the Internet directly to the offline system partition, written block-by-block, in a ready-to-boot state. Instead of needing ~1GB of free space, Google will be bypassing user storage almost entirely, needing only ~100KB worth of free space for some metadata.

Streaming updates is a new feature built into Android 8.0, but Google is also back-porting the feature to Google Play Services, which will enable it on "Android 7.0 and later" devices with a dual system partition setup. Presumably this is so devices upgrading from Android 7.0 to 8.0 will be able to take advantage of this smoother upgrade system.

Supporting Android A/B partition setup isn't something OEMs really publicize. To the best of my knowledge, only the Google Pixel, Moto Z2 Force, and Essential Phone have this A/B partition setup, and devices are never "upgraded" to an A/B setup via an update (repartitioning is too scary). Since steaming updates is attached to the A/B update system, it's an option system that OEMs can choose to implement or choose to ignore.

Rescue Party

Android 8.0 has a new automatic recovery process that can kick in when it detects your build of Android is non-functional. The feature is called "Rescue Party" and, according to the documentation, it will "escalate through a series of actions to recover the device."

Rescue Party will be triggered if the device restarts more than five times in five minutes, or if a persistent system app crashes more than five times in 30 seconds.


The final stage of Rescue Party's recovery tactics is to automatically boot into recovery mode and prompt the user to perform a factory reset. Before that, Rescue Party "escalates through rescue levels," and "each level is progressively more aggressive in what it clears or resets." The documentation doesn't say what those pre-factory reset levels actually do though.

Rescue Party won't help for hardware defects, but should fix problems caused by malicious or defective apps.

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"