Android O team talks Project Treble, blob emoji, themes, and more

As you may know, the engineering team behind Android O held an AMA on Reddit today, and here are some of the things we learned from it.

The most frequently brought up topic was probably Project Treble, and with good reason. After all, it’s expected to accelerate the speed of OS updates, something that has been a fundamental problem among Android devices. Full theming is another theme (sorry) that came up a lot throughout this session as well as questions regarding adaptive refresh rates and the future of Android tablets and Android Wear. We’ve gathered some of the most interesting conversations from the AMA below. If you’d like to see the full AMA, you can head on over here.

I really want to believe Project Treble will (mostly) fix fragmentation. Am I too optimistic?

• Devices launching with Android O will come Treble-enabled out of the box. Project Treble will make it easier, faster and less costly for device maker partners when these devices are updated in the future. In addition to the engineering changes, which enable Project Treble on all new devices launched with Android O and beyond, we’re working closely with device makers and silicon manufacturers to both get required Android customizations (such as carrier-specific requirements) into AOSP, and reduce their cost and complexity when updating to the new version of Android. For example, Sony and Qualcomm have already contributed dozens of features and hundreds of bug fixes into AOSP so they no longer need to rework these patches with each new release of Android. We’ll publish more information about Project Treble on source.android.com soon.

When do you think we will get the first results from Project Treble? 

• It depends on how much the partner wants to take advantage of some of the benefits of Treble. Device maker partners can choose to utilize the same stable vendor implementation with the newest version of Android or they can choose to work with silicon manufacturers to update both the Android OS framework and the vendor implementation.

Is there a programming obstacle to full theming (à la TouchWiz or MIUI) or is it something the Android team doesn’t think is right yet?

• TL;DR: Theming is not hard. Reliable and consistent theming is hard.

There are technical and logistical issues with theming. The technical side is largely solved in O with RRO support (thanks Sony!); however, we still don’t have stable APIs for describing what can be themed or adequate ways to verify that existing applications properly support theming. You might remember a dark theme making brief appearances in previous releases – since we already had a dark Material theme, we didn’t have to worry about APIs to describe the themeable properties; however, we were unable to convert every existing app (ex. Calendar, Photos, other bundled and core apps – even Settings was a challenge) to support dark Material theme and verify that it was properly supported.

If you had, say, a bright pink “Hello Kitty” theme that’s not a simple brightness inversion, you run into even more complicated cases of ensuring minimum contrast levels for accessibility, picking reasonable secondary and tertiary colors, etc.

Is there any push to support adaptive refresh rates within Android? 

• Sharp has been shipping Android phones with adaptive refresh rates since 2016 (at least in Japan). I’ve been disappointed with my 60 Hz phones since I’ve played with one of those Sharp phones :) Adaptive refresh rates and 120 Hz rendering is something we’ve been thinking about for years (it’s great for 24fps video playback!).

Why did you kill the blob emoji? (*insert sad blob emoji here*)

• Over the last few years Unicode has expanded the range of emoji considerably and created new categories of emoji. In parallel new messaging use cases have emerged (i.e.: larger emoji used as stickers). The current design system did not lend itself well to supporting the expanding emoji set and these new use cases, so we needed a significant visual refresh.

Will Android O do anything for Android Wear? 

• Android O will mostly be a technical upgrade for Android Wear. For example, Wear will get background limits which will help preserve battery with O and users can expect more controls over notifications via notification channels. In addition, we have added new tools for developers to help implement complications and build watch friendly UIs.

How far along are you from completion on the return of Tablet UI?

• Honestly, I don’t think tablets is a space where we can meaningfully talk about “completion.” It’s more about figuring out what the next driver of innovation will be for this form factor. We are continuing to invest in productivity use cases (keyboard-driven UI, multiwindow, etc) but also – along with lots of other folks in the industry – working on what the next evolution of tablets should be. For Android, there are some interesting overlaps with tablets given the increasing success of Chromebooks and the recent addition of the ability to run Android apps on Chrome OS. We are working to make the Android developer stories for both form factors (tablets, Chromebooks) identical.

What is being done to shore up the Bluetooth audio solution?

• The Android Bluetooth, audio, and performance teams actually did a lot of work to improve BT audio in O. We flipped the switch internally since the most recent developer preview because we needed a little more time to make sure that things were stable, so you haven’t seen the fruits of that labor quite yet. (To find out more on this, click here)

While the team didn’t reveal the official name of Android O – as expected – we now have a more complete picture of what Android O will bring to the table later this year. What questions do you have regarding Android O? Do you think Project Treble will be enough to fix fragmentation? Let us know in the comments below!