Other Android Q-uestions

Now for the "why is this here?" portion of the interview. The first oddity that we addressed is the status of the "Snooze notification" feature in Android Q. This feature arrived with Android 8.0 Oreo, and it survived all the way up to Android Q Beta 3, where it disappeared. It returned in Android Q Beta 4. So, why?

Ars: Android Q stuff: Why was snooze removed from the notifications panel—bug or feature?

Burke: It may or may not be gone in the future. So, we added this new "gentle" and "priority" setting for notifications. We're trying to simplify all the concepts. The problem with notifications, I think, is that they have gotten a little too complicated. You have this concept of channels, you've got snoozing. We wanted to simplify and just have this gentle and priority setting. So one part of our team is arguing to remove snooze—I'm on that part of the team—to simplify things for general users. Obviously, we always worry that there's going to be some users who really liked snoozing, but what's the right thing for the majority of users? Is simple better? And, so, that's why it's sort of coming and going. I think it was in one beta, it's not in another. It may end up back there. It has very low usage.

Ars: It's hard to find, yeah.

Burke: This is kind of one of the advantages or disadvantages of doing betas. You can see us debating.

Next oddity: This strange "Adaptive Sleep" setting was showing up for some people in one of the Android Q betas. It described itself as a feature that kept the screen away when it detected you were looking at it, but it didn't work and it was unclear how it would work. Some devices, like Samsung Galaxy phones, already had a feature like this that was powered by the front camera. It would turn on when the screen was on, and if it detected a face, it would stay on.

Ars: What is this adaptive sleep thing in the settings? Did everybody see the picture?

Burke: That's kind of an experimental thing that isn't ready. I think we had a bug where it showed up in certain builds.

Ars: Yep.

Burke: So a couple of people have asked us for this, and basically the idea is to keep the phone awake when you're looking at it. This is just a skeleton framework right now, so it could be anything. I don't think it's actually implemented in AOSP. It's just like, "Here is where you would put it in the OS, and then, a device maker would provide a back end to it." I don't think it's going to make it out to Q. It wasn't ready, so I was surprised to see it, too.

Google does this a lot. OEMs come to it with a feature they want implemented that isn't in Android, and often they either implement it themselves or add API hooks for OEMs to plug into. In the case of something like split screen support in Android 7.0 Nougat, OEMs build a feature first and Google arrives with its own implementation and standard rules for the entire ecosystem later. In the case of "Adaptive Sleep," Samsung will have a clean, tidy place to plug its front camera implementation into. Either option is a good thing as it reduces the amount of custom code OEMs have to keep track of, even if it doesn't show up in the next Pixel device.

The next weird item on my list was Android Q's desktop mode. With a carefully crafted ADB command—you can read all about it on XDA Developers—you can enable a desktop OS interface for Android. The desktop interface looks, well, like Chrome OS, with a desktop, floating windows, and an app drawer button that could double as a "start" button. Why would Google build such a thing? Is Chrome OS being replaced? Is Android going to take on Windows? Will there be Pixel computers sold with a keyboard and mouse?!

Ars: Speaking of weird features, why is there a desktop mode?

Burke: Where's the "desktop mode?"

Ars: With some ADB commands you can enable a desktop mode with floating windows and stuff.

Burke: Oh, right.

Ghuloum: I can give the history on that. This is a part of the work we do with the Foldables team and teams at various OEMs. We build better support for simultaneous multi-window and multiple displays. One of the interesting use cases here, that we don't officially support on Pixel but our partners support, is Samsung's DEX mode and other OEM's desktop mode. Everything we did there works great for the Android Runtime on Chrome and works great for desktop mode. So, the team was just using that as a way to sort of demo and experiment with stuff before we actually had physical form factor devices.

Let's talk Linux!

Malchev is also the Google representative that shows up at some of the Linux conferences. Malchev was a speaker at Linaro Connect 2017, where he made the announcement that LTS (Long Term Support) Linux kernels would be supported for triple the previous lifespan, or six years. This was a big deal for Android device development, which took so long that it was typical for a device support window to outlast the Linux kernel support window.

Kernel.org lists two kernel versions on the six-year LTS plan: Linux kernel 4.4 and 4.9. Newer releases of the Linux kernel have gone back to a two-year support window, though, so it seems not every release will be a six-year LTS. Since Malchev kicked off the announcement of this plan, I figured he would know what the selection process is like.

Ars: You announced six-year LTS kernel and now it seems not every release is getting a six year LTS. How does that work?

Malchev: Six-year LTS kernels are a thing, and we will keep announcing six-year LTS kernels. Not every two-year LTS kernel becomes a six-year LTS one because not every LTS kernel is what ends up on Android devices.

Ars: So basically this is driven by Qualcomm?

Malchev: Yeah basically, whatever kernel Qualcomm, MediaTech, and the other SOC manufacturers choose to commercialize their SOCs on, this is what we announce as six-year LTS. For example: for Pie, you are required to ship on one of three kernel versions. We provide the minimum version for each one. Of these three, I think 4.4 and 4.9 are six-year LTS ones. The third one, which, I think, is 4.14, is not announced to be six-year LTS yet because we are still waiting to see if there's an uptick in the ecosystem. There's a literal bootstrapping problem, where we need to support a version on the Android common kernel for silicon vendors to consider it, but for us to announce six-year LTS it needs to actually ship. So, we're in this waiting period for 4.14. Going into Q, there's going to be two more, I think, that we'll add to this range of kernels. It's like a sliding window, right?

Ars: OK, so everybody kind of huddles up and decides what the blessed six-year kernel will be.

Malchev: Yeah. The kernel moves fast, so it's a lot of effort to do even two-year LTSs, let alone six. The gap increases, and so cherry picking is no longer trivial after the third year or so. We need to be judicious with what we decide support for six-year LTS.

As Malchev said, Pie's requirement of Linux kernel 4.4-4.14 is for newly shipping devices only. Android devices don't update to new major kernel versions, though, and since Google wants older devices to be able to update to Android 9 Pie, this means Pie must support kernel versions much older than 4.4. Pie support actually goes back to 3.18, which was released in 2014. It's typical for the Android platform to have to support Linux kernels that are around six years old.

It would be nice to not actually have to support a rolling six-year history of the Linux kernel in every single Android release, but getting there would mean getting devices and device vendors to actually upgrade to major new versions of Android. When we talk about Project Treble modularizing Android away from the hardware, the Linux kernel lives on the "hardware" side of that split. So when it comes to major versions, the current implementation of Android is to drop Linux on a phone and forget about it forever. It does not have to be that way, though.

Sandeep Patil, a senior engineer on the Android team, gave a talk last year at the Linux Plumbers Conference and detailed a possible future where the Linux kernel moved forward in time along with the Android Platform. Just as Project Treble has the "Generic System Image"—a raw AOSP build that must boot on all Project Treble devices—Patil detailed the beginnings of the concept of a "GKI"—the Generic Kernel Image—a kernel that could run on any Treble device. Patil said this kernel would be something Google releases, and someday that might even be an upstream, mainline Linux kernel with drivers and other specific hardware support pushed into SoC-specific modules.

Patil mentioned that Treble laid the groundwork for a GKI project logistically, giving Google a blueprint for the interfaces that would need to be built, cross-ecosystem cooperation that would be needed, and the testing that would need to be instituted. It all sounded like a "Project Treble 2: Linux Boogaloo," but I'm not sure if that's overselling it. I was also not very sure of the progress of this. So...

Ars: What is this I hear about a Generic Kernel Image? Will you really start distributing a kernel with GSIs? Does anyone want to give a status update on this?

Malchev: Everything else being equal, we want to unify things in a way that makes sense, right? Subject to our requirements that we want to be open source, we want to let people customize. Be together, not the same, all this awesome stuff. We have been unifying kernel sources in source form for a while. The Generic Kernel Image is an idea that, "Hey, we have the sources there, why don't we build a kernel out of them that we can use to test devices with?" It's in the spirit of the Generic System Images. They don't exist yet, though. They're interesting conceptually, we just need to do a lot of work to figure out if it makes sense in the ecosystem.

Ars: Is the plan really to have a mainline Linux kernel work on a phone?

Malchev: I'll go out on a limb and say that we want that. The work is tremendously wide in space and difficult. It's an ecosystem wide problem. So, we take it one step at a time. We unify sources. But also like, forget a single kernel, let's get people to upgrade their kernels to the latest LTS. That's what we're focusing on now, right? We're making strides there.

Burke: By the way, this is obvious, but doing that just fixes so many security issues.

Ars: But, when you say "upgrade," you're still not upgrading a kernel on a phone, right?

Malchev: Right, implicit here is that, once a device ships, you won't jump from 4.14 to 5.1, right? You won't jump to next kernel versions, but since these are LTS kernels, we would like for them to take the LTS updates that we so painstakingly enable. So, these LTS trains, we want them to land on actual devices. Even that's a struggle, right? [That's] because of everything that makes updatability difficult, as in user space, for the kernel. So, we're focusing on that, actually, with the security team and our partners. Actually, we're making a lot of progress.

It turns out the minor LTS releases do get updated on some phones. The Pixel 3 XL started on 4.9.96 and today (on the Android Q Beta, at least) it runs 4.9.165. And with that, our time wrapped—thanks to Dave, Iliyan, and Anwar for taking the time to answer my questions. Let's do it again next year!