Q&A: We talk details with Android execs Dave Burke and Stephanie Saad Cuthbertson.

Google I/O doesn't need skydivers or LCD Soundsystem to keep us interested year to year—we'll happily settle for what is becoming an annual chat with members of the Android team. Heading into this year's conference, the group was fresh off the release of the second Android O Developer Preview and the announcement of Project Treble, a massive modularization of Android's hardware dependencies that should make updates a little easier on everyone involved with the OS. So as usual, there was plenty to talk about.

Dave Burke, VP of engineering for Android, has made time for us at several recent conferences, but this year we also had Stephanie Saad Cuthbertson, PM director for Android, in on the conversation. Given the opportunity, we tried to keep these questions pretty technical. What follows is a transcript with some of the interview lightly edited for clarity. For a fuller perspective, we've also included some topical background comments in italics.

Project Treble

The second Android O developer preview was a big departure from past developer preview releases. Other than a bunch of new emoji, there weren't any new major features or additions. Compare this to the Android N Developer Preview, which added features like Vulkan, a new VR platform, and a new update installation process in the second and third preview releases. What's the deal?

Ars: It doesn't seem like there's a huge amount of new features in the Android O Beta. Is it all under the hood stuff?

Burke: The way I think about it is, every year we have an engineering budget to spend on stuff, and this year we decided to focus very much on foundation and fundamentals. Part of it is that we can see the scale, we kind of knew we were going to hit 2 billion users this year. Conveniently, we hit it before I/O. You start thinking about the scale of it, the impact of the product, and—it sounds grandiose, but—the responsibility you have to make sure it's good. For the release this year, rather than, "What are we releasing to make a phone good in 2017?," it was more like "What are we doing to Android to make sure Android is in a great place in the next 5 to 10 years?" We started investing in foundational stuff. The two categories we looked at were vitals, which is really system health, and then Project Treble, which is about what we can do to reduce the cost of doing updates so we can get updates quicker. So that's where we spend the budget. Project Treble is a good example; we used up a huge amount of engineering budget. It was a lot of work and super deep surgery across every single interface of Android.

Project Treble brought a new "vendor interface" to Android O. The idea is to separate the Android OS from the hardware, giving silicon vendors (Qualcomm, Samsung Exynos, etc.) a standardized hardware interface to write to and a new set of tests, the Vendor Test Suite (VTS), to ensure their implementation will be forward-compatible with new versions of Android. The "write a standard and provide a test suite" strategy is a copy of Android's Compatibility Test Suite (CTS) which ensures OEMs implement all the Android APIs correctly and don't break anything.

Treble should make OEMs less dependent on SoC vendors for updates, cutting out one of the three major steps in shipping an Android update to consumers (the blue squares in the above diagram). It also means that OEMs should have much more control over how long their phones get updates. Google is also an OEM now, with the Pixel line, and clearly it is targeting Apple with this premium device. Despite the similar prices, currently the Pixel update program can't hold a candle to Apple's iPhone support: Google offers two years of major updates, while Apple offers five years of OS updates for iPhones. So can Google improve now?

Google has always had this promise of two years of major updates on its phones. Is that something that's driven by the SoC manufacturers? With Project Treble, now that you don't have to worry about SoC vendor support, could you offer Pixel phone updates for more than two years?

Burke: It definitely makes it easier for device makers, because the vendor code should be more robust and stable, and because we have this formal VTS test. I think you still need some level of support from the silicon vendor, because you never know where your bug will appear. It certainly makes the economics of it much more feasible. At the end of the day, it's all economics in a sense, right? Today, it just costs too much to do an upgrade of Android. The amount of work and dependencies are too high. The device maker has to depend on the silicon vendor and has to wait until the silicon vendor releases code. We're just trying to like parallelize these things a little bit, so we can release Android and it will still work. And your previous vendor implementation, there's a separation of concerns. That's the goal, basically.
Burke's comment on "parallelization" is really interesting. With a standardized hardware interface, the silicon vendors and OEMs can both immediately start work on porting an Android update at the same time. Google, Samsung, and other OEMs will no longer have to wait for up-to-date code from Qualcomm or other SoC vendors. Everyone should be able to mash their code together at ship time, and as long as everyone sticks to the agreed upon vendor interface, it should just work.

Burke: One of the subtle things we're doing—it's hard to explain this—you know we have CTS, a test for the developer API, and we have VTS for testing this vendor interface. The goal of VTS is to make sure the vendor interface is forward-compatible. So if you're a device maker, you can take the next version of Android—P—and put it on top and it will just run, and that gives you a huge head start. As a device maker, maybe there's some changes you want to do in Android, but out of the box things will just work. Another subtle thing we do is, we require you as a device maker to pass VTS, but also to pass CTS using the open source Android. You literally have to take that open source code, put it on top of your vendor interface, run the CTS test, and make sure it passes. What that does is it creates a sort of subtle incentive so you as a device maker to make sure your code is upstream.

So vendors don't have to do as much work.

Burke: Yeah, so you do less. You have to make this thing work anyway, so you might as well have your stuff in there. We think this will help over time—quite a lot actually—but it will take time to play out. This is a long-term view, but it's kind of one of those things you just have to do. We felt now is the time, so, like, “let's do it.”

Project Treble addresses the chipset-vendor side of the Android update situation, but the other big deal is theming—for instance, when Samsung wants to change every single icon and piece of UI. There's a button on the Pixel in the developer preview that says "themes,” and you can switch between some styles...

Burke: Yeah! So part of Treble was, "OK, let's make a better architecture" and part of it is, "Let's spend more time with device makers and silicon makers and see where the pain points are and see what we can do to help them." So we're trying to upstream a lot of bugfixes for one, but also features, so we reduce the effort for device makers to have to rework stuff every time they update a device. Theming is something that they all want, and also we want our own theme, so we're like "OK, that seems like a good feature." What you see now is our version 1.0 of theming. It's a basic theming set—something we want to do more of over time. But it's a good example of a feature that makes device makers' lives easier, and so hopefully it'll help over time. The other thing I was saying, I don't know if you tried the Galaxy S8, but it's a lot more restrained now. To me, it looks familiar, like, "Oh, this feels like Android!" Because I have a very warped view of Android, a more purist view, so I think the industry is getting more restrained. I think the innovation should happen in the apps and services. That's the more interesting place.
Our original Android O hands-on had a section titled "Things that don’t work yet (and things that mystify us).” With the second developer preview, every question was answered except one—what does that mysterious "Binderized HAL" button do in the Android Developer Settings? Who better to ask than a pair of Android engineers?

What does the binderized HAL button do in developer settings? Is that a Project Treble thing?

Burke: (Laughs) Yeah, so... The vendor interface—that's a very high-level term for it. We call it the HIDL interface; HIDL is a Hardware IDL (Interface Definition Language)—and so you specify your interface with this IDL language, and then on top of that it's binderized, so all the vendor code runs in a separate process, which does two things for us. One is it promotes security because it's a separate process base. The second thing it does is it actually enforces dependencies so the code is hermetic. It turns out—this is a great question—if you're updating a device from N to O, that’s a huge step. So you don't want to enforce that. We don't even want to enforce binderized HALs for new devices from O forward. What happens is when you go from N to O, HIDL still specifies an interface, but it's in the same process, so you don't have to worry about it. But if you flip that button on a Pixel, you will actually put all of the vendor implementation into a separate process. It's on by default, and the reason it's on by default is we want to force the Pixel to be like a new device. We want to prove out all of Treble, so all of Pixel's vendor implementation code is running on a separate process, actually separate processes, and that's just a switch. So it's a debug switch, and if something went wrong you could turn it off and make sure it wasn't because of treble. Is it in DP2, like is it in Beta? I'll get it removed from the next beta.

So it's going to be on by default when you ship final?

Burke: Yeah... but I thought it was on by default in developer preview 1. That was the intent anyway. Basically, if we hadn't run Pixel in this full binderized mode, the new devices coming this year would be testing it for the first time. We just wanted to get ahead of it and prove it all out. So I'm glad we did it, but it was a lot of work.

Android Extensions

Android 7.0 surprised us with a totally new addition to the Compatibility Definition Document (CDD) for OEMs. It mentioned "Android Extensions" as a way to "extended the managed APIs while keeping the same API level version," and it included two new APK files in Android: "GoogleExtShared.apk" and "GoogleExtServices.apk." No one outside of Google had any idea what these were. My theory was that, like Google Play Services, they were a package of API shims that Google would ship in future versions. In Android N they were blank, but how about Android O?

I've got more update stuff. In the Compatibility Definition Document...

Burke: Here we go...

…there is a new section, called "Android Extensions." It sounds like a Google Play Services kind of thing where you ship platform code in a APK...? What is it?

Burke: Remind me what it says? I probably reviewed an early version of it but...

It says, "Android includes support of extending the managed APIs while keeping the same API level version." And there's 2 new APKs: "GoogleExtShared.apk" and "GoogleExtServices.apk."

Burke: I think this is for the shared support library. Today, if you look at how people build Android apps, they use our support library. It makes it easier to build an app, but the problem is every app has its own static copy of different versions, so we want to get to a world where apps say, "Hey, I need version 14 of the support library of above," and then we can have a sharable copy of it. I think that APK is the delivery mechanism for the shared library. Basically, the APK support the library, then the class downloaded can load it.

I mentioned the possibility of one APK being a shared support library file in my theory article, so it's great to get confirmation from Burke. Right now, basically every app on an Android device uses the support library, so there are easily 50-100 copies of it on any given device.

Android Extensions still don't work yet, and officially Google has nothing to announce. The second file is still a bit of a mystery; even Burke wasn't quite sure what it did. I asked around at the show and got a few vague confirmations that my article was correct, and the second APK will be used for some kind of platform code. We probably won't have a total confirmation of what it is until Google actually uses it for something.

Android's Linux Kernel hits end of life

Android is the largest Linux-based OS on Earth, but Android and Linux have been diverging lately. Today, the Google Pixel ships with Linux 3.18, which first launched in 2014. 3.18 was a Long Term Support (LTS) release, but it hit end of life in January 2017, meaning that Google is now using an unsupported version of Linux. With Google's promised three years of security updates, it is now stuck maintaining 3.18 on the Pixel until October 2019.

Given the billions of devices 3.18 runs on, mostly thanks to Android, Linux maintainer Greg Kroah-Hartman was nice enough to post one more 3.18 bug fix in February, but he called 3.18 a "sinking ship" and advised people to start "yelling very loudly at your hardware vendor." Does Google consider this a problem?

What is your thinking about the Linux Kernel? You ship a super-old one right now—it's 3.18, from 2014.

Burke: We have 4.4 working [internally].

OK, great, because 3.18 is end of life now.

Burke: We don't do much work on 3.18 anymore. I think the key question is why is it end of life; what does "end of life" really mean? This all has to do with LTS, like the long-term support version of Android. Project Treble has some broad ramifications. One of the things we want to do is make sure the LTS outlasts the multiple years of security updates we're requiring. Right now it doesn't quite line up; so right now we're working with the Linux community to extend LTS to be longer, so that it says “supported.” The other thing is, generally, we don't change the kernel with an update. No one really does that in the industry, except maybe Chromebooks, because it's just too sketchy. Maybe it's not "sketchy," it's just a lot of risky work. What ends up happening is you back port all the security fixes, as you know, and we start a new device. You uprev the kernel. The big thing we're focused on now is longer LTS.

Burke is correct that the Linux support and Android support windows don't really line up. Linux LTS releases are good for two years, while Google wants to offer three years of security updates. This doesn't even include the time it takes to integrate all of the Android-specific changes into a new Linux Kernel. Suppose Google shipped Linux 4.4 today. It's maintained until February 2018. Google wants to provide three years of security updates, so it would still have to update 4.4 on its own from 2018 to 2020.

OK, because you used to track a lot closer to Linux releases in the 4.x days, where you would ship kernels that were about a few months old.

Burke: Yeah, a lot of it is up to silicon vendor support. In this case, [the Pixel] is a Qualcomm device, so what does Qualcomm support. But we are going to be more prescribed about which kernel version you have to ship with for new a device, and then we're going to work with the Linaro community to extend the LTS as well. We're getting more involved in that.

Android Vitals and JobScheduler

What is all this "Vitals" stuff?

Cuthbertson: We kind of walked through vitals already. There's Google Play Protect, which is a lot of exposing what we were doing already.

Right, I was going to ask if this is different from the app scanning that Play Services has been doing forever.

Cuthbertson: Yeah, Play Services has been doing this scanning behind the scenes for some time now. We look at all the apps that are installed and see if anything matches the signature we know that is potentially harmful. If we find ones that are bad then we disable them and take them off. So we are rebranding it as Google Play Protect and making that more clear. We also rebranded the Google Location Services for phones—so "find my phone"—we improved that quite a bit. We made it a lot easier to find and erase lost phones.

...we identified about 30 "known bad behaviors.” We look and see if the app is doing any of that. We instrument that, and we suck that up to the Play Dashboard and show you, "look, you're doing this, stop it."

Yeah, that app was ancient.

Cuthbertson: You think about keeping your phone secure. If you're like me, I lose my phone about once a week. So it's nice to find it.

Burke: It's also peace of mind, too, like people that aren't super technical don't understand that we have their back. We have this very complicated, elaborate, impressively powerful detection system. It's peace of mind. We want people to feel as safe as they are in reality, and then we wrapped up a couple of things like "find my phone."

Cuthbertson: Another big part of it for us is the phone's foundational performance. There are really two parts for that. When we looked at apps, we found they were consuming a lot of resources they really, honestly, should not have been. They'll be running in the background, taking advantage of the background location, and things of that nature. It does affect your memory, but what it was really affecting is your battery. At times, it could take, like, 20 percent of your battery. I'm not even going to name some of the apps we looked at, but you would be surprised. We got this list of them that would do things like pinging location in the background every minute or every two minutes. And when you spin up the whole network stack, that has a huge impact on the battery. One of the things we did was essentially organize that. For instance, background location apps will access that location and make it available on a specified time stamp.

Everyone has to use JobScheduler.

Burke: Or a foreground service if you want to keep the location going in the background.

Cuthbertson: Yeah, you're quite technical. This is cool.

Burke: It's Ron!

Cuthbertson: The other side of it is that developers are just struggling to make performant apps. It's actually surprising how many of them are doing a lot of work to make their apps performant. They didn't have either good guidance on where to look or good tools. That's why introducing the profilers are so important. The reason we did network and CPU is those are the foundation for battery. So if you want to read into it, now you have these foundations. Those are the two things that typically have the biggest battery impact. And along with the Play Dashboard, I'm not going to say I undersold them, but I can't explain the whole thing in a keynote. What we're doing there is at the very base of the operating system. We exposed services so we can look into every app and see what it's doing. And we identified about 30 "known bad behaviors.” We look and see if the app is doing any of that. We instrument that, and we suck that up to the Play Dashboard and show you, like, "look, you're doing this, stop it."

Right, like a “Top Five Bad Things Your App is Doing."

Cuthbertson: Yeah.

This background lockdown is only for apps that target O, right?
Cuthbertson: Well, the background service changes affect apps that target O, but one of the things I can show you is that you can enable it for every app. If you go into the battery settings, I'll just show this to you right now. Let's say, for instance, you were concerned about Gmail's use of background. You can actually turn its background activity off. Even if the app is not targeting O, you can do that for all apps. We knew a lot of users would want to enforce those limits on all apps.

Does that just kill all background activity for all apps, or does that enforce everything to JobScheduler?

Cuthbertson: No, it enforces these intelligent limits. For instance, for background execution you have to use JobScheduler, and for background location, you have to do location on a specified time schedule—not like, for instance, every second.

Oh, I thought that would kill everything.

Cuthbertson: We're actually not doing that because we would be breaking the API contract.

High-quality Bluetooth

So Sony sent in some kind of Bluetooth high-quality codec?

Burke: Yeah, LDAC. So the default codec we had, literally forever, is called SBC. It's a pretty crappy codec, and we wanted a better codec.

It seems weird that Sony would just give a thing to Android and not charge a licensing fee.

Burke: Yeah, it's super cool. I think they're trying to bootstrap an industry, and they'll make their speakers and headsets so they'll make the other side of it. They offer the code under the Apache License, I want to say. A lot of these people will do license-free anyway for the source. But, yeah, LDAC is pretty good, and then there's APTX as well. These are just higher-definition codecs.

Thanks again to Dave Burke and Stephanie Saad Cuthbertson for sitting down with us.