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?

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.