Android at I/O 2019: The Project Mainline update system and other highlights

Google I/O 2019 wrapped up on May 9th, but we’re still picking through the incredible flood of information that came out of the show. In addition to the slew of announcements on keynote day, there are dozens of hours of sessions and documentation, plus a whole new Android release to pick though. Here are a few highlights from the show.

Android’s gesture navigation is actually good now

Every Google I/O presents a new release of Android, and paired with Google I/O 2019 is Android Q Beta 3. There really aren’t a ton of changes in this beta release, but there is a new navigation system. There are three versions of system navigation in Android Q Beta 3, actually. The traditional three-button navigation is an option, even on devices like the Pixel 3, which originally did not ship with it. Apparently, the three-button mode will be returning to all phones for accessibility considerations, since the gesture system requires a significant amount of fine motor control. The existing Android Pie gesture system has been renamed “two-button navigation.” The third option, called “Fully gestural navigation, “is new for Android Q Beta 3, and it’s the best version of Android gesture navigation yet.

In Android P, the “two-button” gesture navigation was a bit of a mess. Google only replaced the Recent Apps button with a gesture, and Home and Back were still buttons. The bar didn’t save any space, so there wasn’t a huge benefit to using it. Beta three solves a lot of these problems. Every button is now a gesture. The navigation bar has been minimized to a slim strip about a third of the height of the usual bar. Some apps will even give you a fully transparent gesture navigation area. The new setup is very reminiscent of iOS, and that’s what everyone has been asking for since the launch of gesture navigation with Android P.

Let’s talk gestures. For “Home,” just swipe up from the bottom of the display. For “Recent Apps,” swipe up and hold. For “Back,” swipe in from either edge of the display. You can also switch between your last two apps by swiping up from the bottom and moving the app in an arc to the right. Again, it’s very iPhone-like, and a big improvement from the gesture system in Android P. The one non-iPhone gesture is really weird: a swipe up, diagonally, from the corner of the display, will open the Google Assistant. This one is completely undiscoverable.

There are a few strange edge-cases with the gesture system currently. First, trying to open Recent Apps from the Home Screen is a bit clunky. The swipe-and-hold gesture is strange to begin with (even on an iPhone), but on the home screen a swipe up also opens the app drawer. Trying to open Recent apps on the home screen means you will actually start raising the app drawer up from the bottom of the screen and bring the Recent Apps carousel in from the side of the screen at the same time. I think the home screen design needs to change if we’re going with this swipe-up system gesture.

Developers can override the gesture area in the left and right side.

Credit: Google

The new gesture system means the system UI now captures touch input from the sides and bottom of the display, taking it away from apps. This will cause problems with some apps that have side-mounted controls, and to help with that, Google will introduce a new API allowing developers to reclaim touch input from the system. Developers can basically draw rectangles on the display to reclaim touch input, and Google recommends blocking out system-gesture input around things like seek bars.

The side navigation panel has been a common UI style for Android apps, and since many implementations open with a swipe in from the side of the screen, this will be the most common action that is disrupted by the new system gestures.

The word from Google I/O is that Google plans to fix this issue by changing the side navigation widget it provides to developers. With the new version, the first side swipe will open the navigation panel, and the second swipe will go back. The one app that implements this right now is the Google I/O app, and it’s pretty weird in practice. The first swipe back gets eaten by the app drawer, and only the second switch back will actually go back. The good news is that this only happens on the main page of the I/O app. If you do something like open an I/O session and swipe, you will immediately go back. I think the best solution is to try to not use a navigation drawer, which has been derided in the past as being a dumping ground for navigation with poor discoverability.

The other oddity is that this new behavior will only apply to apps with the updated navigation panel, so you’ll have inconsistent behavior depending on if the app is running the new side panel widget or not.

The fully gestural navigation system covers “Home,” “Recent Apps,” and “Back,” but the Android system bar contained more than just these three buttons at times. When you opened a keyboard, the back button would change to point down, indicating that instead of going back, the button would just close the keyboard. This icon doesn’t fit in the slimmer gesture bar, so now when a keyboard is open, the gesture bar actually grows to the old size, and then it has room to display the old button. The other missing button from the new bar is Android 9 Pie’s smart rotation switch, which just never shows up anymore.

Visually, there are a few compatibility quirks, too. First, let’s look at the best case scenario and open something like the Google I/O app on Android Q Beta 3. This is the Android gesture system at its full capabilities, with a fully transparent system bar that the current app can draw behind. In the IO app, you only see the thin gesture line and nothing else, just like an iPhone X. Android will even continuously sample the background as you scroll. It will smoothly fade between a dark and light themed gesture bar to maintain contrast.

Most apps don’t look like the Google IO app, though, and instead of a beautiful, transparent gesture area, you get a regular black or white Android system bar that is segmented away from the rest of the app. Apps that don’t request a transparent system bar get this older-looking, uglier gesture bar, so uh, please update your apps, everyone on Earth.

Google’s Next-Gen Assistant in action. That navigation bar isn’t going to stick around.

Another major navigation change Google showed off at I/O had to do with the “Next Generation Google Assistant.” This was a turbocharged assistant with offline functionality and lots of natural language processing. The next-gen Assistant demo used the old two-button gesture navigation system, and in the blank spot where “Recent Apps” used to be, the next-gen Assistant would transcribe your voice input.

The demoed next-gen assistant UI is totally incompatible with the future of where Android is going. The full gesture system in Android Q doesn’t have a blank spot to use for voice transcription—the slimmer bar isn’t even tall enough to fit a single line of text. This is just not going to work as shown at Google I/O. Did the Google Assistant team not talk to the Android Team or something?

Project Treble is making a difference

Starting with Android 8.0 Oreo and finishing up in Android 9 Pie, Google introduced “Project Treble” a modularization of Android that separated the OS from the hardware support. Treble was a scheme to make Android updates less work to build and easier to update, and there were signs all over Google I/O 2019 that Treble is actually making a difference.

Just like last year, later Android betas are now available on non-Google phones, but this year the list is bigger than ever. Android Q Beta 3 is coming to 23 devices, with 15 from third-party OEMs.

This list shows that most important Android manufacturers are now taking part in the Android Q Beta. The only heavy hitters missing are Samsung—which is pretty much always hostile to consistency and cooperation within the Android ecosystem—and Lenovorola, another company that doesn’t care about Android updates.

It’s not just that these devices were announced as compatible for the Android Q beta—some of them were on display at I/O, and they were shockingly far along. Huawei had the Mate 20 Pro on display and it was actually skinned. Huawei’s Android skin, EMUI, is a heavy, full-conversion of Android, and to see that it was already working on a beta was a real shock. Unfortunately, Huawei won’t be able to finish its Android Q development, as a US executive order has banned companies from doing business with the Chinese company. The Mate 20 Pro used to be on the Android Beta page, but after the order, it was quietly removed.

Project Treble is making a difference on the retail side of things, too. In a post on the Android Developer Blog, Google said Project Treble “accelerated Android 9 Pie OS adoption by 2.5x compared to Android Oreo.” Faster is always better, but with 2.5 billion active devices (another new stat just announced by Google) getting anything to change is like turning the Titanic. The Android Platform Dashboard is back after about a six-month hiatus, and we can see that Pie currently makes up just 10 percent of the current Android active user base. Still, there are 250 million Android 9 Pie devices out there.

Dual-booting Android will be a thing in the future

At one of the Google I/O demo areas, Google was quietly showing off a new Android Q feature that allows you to dual boot between two different versions of Android. This feature has gone through a few name changes. In our I/O preview article, we called it “Dynamic Android”; at the show, it was called “Dynamic System Updates,” and before that it was apparently called “Live images.”

No matter what you call it, the feature seems pretty cool. The idea is that you’ll be able to load a second version of Android onto your devices, allowing you to do things like test a beta build of Android without messing with the underlying, stable build of Android that came with the phone. Android Q supports dynamic partitions and can scrape together free space to make a new logical partition for your test built of Android. You can flash to this reserved area of space, and with a quick reboot, can swap between your two versions of Android. The feature kind of works like a virtual machine, but you can boot into it.

At I/O, Google showed a phone that could switch between the retail, “Google Android” build of Android Q and an all-AOSP build of Android, and it happened about as quickly as a normal reboot. Booting from Android Q to Android Q isn’t compelling today, but that’s currently all that is compatible. This time next year, imagine booting between the final Android 10 Q release and the Android R Beta.

Since these Dynamic System Updates don’t touch the underlying Android OS, the feature will work even on devices with a locked bootloader. Developer-centric devices like the Google Pixel come with an unlocked bootloader, which allows you to load any (compatible) version of Android on the device. The vast majority of devices are locked down, though, so they don’t get to do things like run the Android beta or roll back to an earlier version. For testing, being able to move forward and backward in the Android release timeline is invaluable, and this will open that up to more devices and more people.

For developers (and journalists) that need to test things in the beta version of Android, this sounds amazing. It will probably help lower the bar a bit for Android development, as not everyone can afford a second device to ruin with an Android beta, and hobbling your primary smartphone might not be an option for most. This will also open up beta testing to devices without an unlocked bootloader, which can be rare and/or expensive depending on what is available in your region. There’s always the Android emulator, of course, but nothing beats testing on actual hardware.

I said before that Google had flip-flopped between several names for this feature, and I don’t really know why “Dynamic System Updates” is the one that stuck. The feature explicitly does not update your phone or mess with your phone software in any way; instead, it just allows you to load a second (possibly newer) version of Android on your device as a temporary image. Couldn’t they have just used existing computer terminology and called it “Dual Booting?” Is that not sufficiently cool enough? Maybe “Live Dual Booting?” “Virtual Android?” “Android VM?” Anything other than “Dynamic System Update,” which doesn’t do a great job of describing the feature.

Project Mainline is the next big update scheme

For Android Q Beta 3, Google is introducing a new update scheme called “Project Mainline.” Google’s blog post calls this a way to “update specific internal components within the OS itself, without requiring a full system update from your device manufacturer.” We wrote a lot about the “APEX” update system in our Google I/O preview, and it sounds like APEX, along with some other updatable components, make up “Project Mainline.”

The initial focus of Project Mainline.

Credit: Google

While Treble set about making it easier for manufacturers to do a full OS update, Mainline modularizes core parts of the OS, allowing Google (and sometimes manufacturers) to update them through the Play Store. Google focused on “Security, Privacy, and Consistency” with this first round of mainline updates, and while we’ll cover the individual components, the big deal is the new APEX file format, which should allow even more parts of the OS to be put into the Play Store in the future.

For a long time now, Google has been working to split up core Android components into easily updatable apps, and today a lot of what ships on a retail-ready Android phone is updatable through the Play Store. Not every component can be packaged as an app, though, since the app format comes with certain restrictions and limitations. The APEX file type is built for updating lower-level system modules that wouldn’t work as apps. Google’s APEX documentation uses the Android RunTime (ART) and hardware abstraction layers (HALs) as examples. These are both essentially root-level components that need to operate outside of the app permission system. The need to start very early in the boot process, and they can’t just close themselves when it’s time for an update, which is how an app would work.

APEX files address all these problems. They get to start up very early in the boot process, and after they are downloaded, they can be applied during the next reboot. APEX files, like regular APKs (Android’s normal app file), are zip files with a special extension and even contain APK definition files like AndroidManifest.xml, so they already work with a lot of Android app utilities and built tools. While an APK would contain app code, APEX files contain ext4 image files that get mounted at runtime. Just like APKs, these are signed with a key, and in the case of APEX files, they will only be valid from Google or your phone manufacturer. Also, like APKs, delivery happens through Google Play, but don’t expect to see an app listing with screenshots; these are installed and updated more discreetly.

Now, about that list of modules. We have a table direct from Google:

First, like every big change in Android, Mainline is going to roll out slowly over the coming versions, with some modules starting as optional and eventually transitioning to mandatory. Also like many Android changes, the “must” here is a requirement of the Android Compatibility Definition for Android Q, so all manufacturers will have to allow the mandatory modules to be updatable directly by Google, if they want access to the Play Store and other Google apps.

Mainline represents Google clawing back some control over Android’s core system components, so the decisions for mandatory versus optional components were done in negotiation with manufacturers. Modules that Google and the manufacturers felt met everyone’s needs were made mandatory, and modules that need a bit more time in the oven were made optional, with the goal of becoming mandatory in future versions. In some cases, manufacturers can actually add extension modules onto the modules from Google, so for instance they could have the AOSP implementation of the media stack and then ship and update their own additions on top of that.

In the table, we can see that half of Project Mainline uses APKs and the other half uses the new APEX files.The two that immediately jump out to me are “Media Codecs” and “Media Framework Components.” Android’s media playback engine is called “Stagefright,” which rose to infamy a few years ago after a series of vulnerabilities were discovered that could be used for remote code execution. Fixing Stagefright vulnerabilities would have meant patching over a billion devices with full OS updates, which the Android ecosystem was (and still is) in no position to actually do. As a pair of APEX modules, a bug in Stagefright is now something Google can fix directly without needing to involve OEMs.

Also in the “Security” category are APEX files for Android’s DNS Resolver and Conscrypt, which provides encryption for Android Java apps using BoringSSL and Transport Layer Security (TLS). Again, this is an area of the OS that rose to infamy during the “Heartbleed” SSL vulnerabilities. Now on Android Q, Google would be free to fix any new SSL bugs that pop up without having to herd all the Android manufacturers into releasing a full OS update.

For “Privacy,” we have three APKs (not APEX files) for Documents UI, Permission Controller, and ExtServices. Android Q (with later changes in Android R) is implementing wide-ranging changes to the way storage access works, and apps will see their storage access restricted to their own isolated storage sandbox. The Documents UI is the system-level file manager that apps can call on and has to interact a lot with the new storage requirements. Naturally then, spinning the Documents UI out into its own, individually updatable app just before all these massive storage changes kick in sounds like a great way to squash any bugs that pop up.

From what I can tell, there is not a specific component formally called a “Permissions Controller” in Android, but it sounds like the entire permissions system is updatable now. Google’s blog post says, “With Project Mainline, we have the ability to make improvements to our permissions systems to safeguard user data.”

ExtServices was a fun one to see on this list. We published an article about it when it debuted all the way back in Android 7.0, puzzling over what the file could do and why it was mandatory for OEMs to include. At I/O, we had a sit-down interview with a few Google engineers, and Anwar Ghuloum, engineering director for Project Mainline, told me it was a “Grab bag” for “very small things that need to run all the time. Things with no UX, no large memory footprint items.” Apparently it contains bits related to privacy, autofill, and even some parts of Mainline itself.