How Google is quietly building Android 13 for smart displays

When Google released the second developer preview of Android 13 last week, they addressed something that I know many users have been wondering: will it include all the large screen improvements of Android 12L? The answer, of course, is yes. Android 13 builds upon the large screen features introduced in 12L, with tweaks to the taskbar and multi-user experience among other changes. These large screen changes improve the experience of using a tablet, Chromebook, or foldable, which are the main three form factors that Google says are “key surface[s] for the future of Android.”

Android Device Management

There are other types of devices that run Android and have large screens, however. As I mentioned on the Android Bytes podcast, there’s also the emerging Android-on-Windows ecosystem and the oft neglected desktop mode experience available on many phones. In addition, there’s the smart display, which you may be surprised to hear since their operating systems typically don’t resemble Android in any way. Take a peek under the hood of the most popular smart displays on the market, however, and you’ll find they often do run Android in some form. Both the Facebook Portal and Amazon Echo Show run heavily customized forks of AOSP, for example. Google’s own Nest Hub also runs Android, at least the second generation model does since the first generation model was flipped to Fuchsia OS post-release.

Every smart display that currently runs Android does so with an incredibly outdated version of the OS. None of these devices have access to Google Play and its enormous catalog of applications. None of them are really intended to be used as a general purpose computer. A smart display is basically just a tablet that’s stationary, so if you were to dock a tablet, it would essentially become a smart display given the right software. That’s what companies like Samsung and Lenovo have already realized, and it’s an area that Google is exploring heavily in Android 13. In fact, I’m willing to say that many new features in Android 13 are purposely built around this smart display/tablet convergence.

Android 13's many hidden improvements for smart displays

If you’ve been following my coverage of Android 13, then you’ll know that a lot of the features I documented haven’t been announced yet. Google hides many user-facing features until the public beta program, and they also leave some new APIs with little to no documentation. Because of this, I can’t be 100% certain what Google intends to do with these new features and APIs, and I don’t have privileged insight into Google’s development plans. I’m making an educated guess about what these features and APIs were introduced for, but I’m quite confident that my big picture analysis is correct, especially because it lines up almost perfectly with the rumor from 9to5Google that Google is making a new Nest Hub smart display with a “dockable tablet form factor.”

With that out of the way, here are the new Android 13 features that I believe are intended for smart displays. I’m going to start off by expanding on features you may have already heard of (from reading my deep dive), and then I’ll share some changes that haven’t been documented before! These sections will be light on details because I’ll be linking out to my deep dive to go over the technical aspects.

Screen saver complications

Android 13 is finally updating a feature first introduced all the way back in Android 4.2. Screen savers are being revamped to support “complications”, which are basically overlays of useful information shown on top of a screen saver. The complications I spotted in Android 13’s code will show the time, date, weather, air quality, and cast info.

‍

The cast info complication is particularly interesting to me because I believe you’ll be able to see information about cast sessions that have been sent to the device. Most Android phones and tablets can’t act as Google Cast receivers like Android TV devices can. Another interesting bit of information about the cast info complication is its code-name: mediashell. Mediashell is the code-name of the Chromecast built-in app that enables receiving cast sessions on Android TV. Smart displays can also be cast to, which is partly why I think Android 13’s screen saver complications were designed for them.

That’s not the only reason I think the screen saver revamp is meant for smart displays, though. While I was digging into the SystemUI app to figure out how to enable complications, I discovered code for a special variant of SystemUI called “SystemUITitan”. I spotted a new “SystemUITitanFactory” class that extends SystemUIGoogle (which itself extends the AOSP SystemUI) to show a custom view and enable the new screen saver and communal mode bits (the latter of which I’ll get into soon). “Factory” classes, by the way, are what Google uses to customize SystemUI for different devices. It informs SystemUI what components should be shown in the UI, and by changing the Factory class that’s loaded, the default setup can be overridden.

I attempted to load the SystemUITitanFactory to no avail (it just kept crashing), so I don’t have any images to show what the SystemUI would look like. However, I think this “Titan” SystemUI is intended for smart displays rather than another device type. Class factories already exist for automotive and television, so the only other option would be the foldable. Screen savers and communal mode make a lot more sense to me on a smart display than they do on a foldable, which is why I’m leaning towards “Titan” referring to smart displays.

Communal mode

One of the features that I think will significantly improve the experience of sharing a device is “communal mode”, also referred to as “hub mode.” Smart displays and docked tablets are often used by multiple users in a household, so there needs to be a way to set up multiple profiles. Android has had multi-user support for years, wherein each user can have their own apps and data. Some apps even have multi-user support built-in, like Netflix, so you don’t need to switch Android profiles to access another Netflix profile. For all other apps, though, you need to do exactly that, which is what communal mode is designed to solve.

Communal mode will let you pick apps to share between profiles, which will be accessible on a “common surface” that I think will be the screen saver. Code within the Pixel’s SystemUIGoogle app connects communal mode with docking and screen savers. While most of the code related to communal mode and screen savers will presumably end up in AOSP, there are some additional features implemented in classes that are under com.google.android.systemui.communal rather than com.android.systemui, suggesting that this code is Google’s proprietary work. The aforementioned cast info complication falls under com.google.android.systemui, as does the handler for a new feature called “switch to admin user when docked.” The latter feature, as its name implies, enables automatically switching to the primary user after the device has been docked and a set amount of time has passed.

This feature seems particularly suited for stationary devices like docked tablets and smart displays, but there’s still a lot I don’t know about it. Current builds of Android 13 are missing a lot of the pieces needed to get this feature working, but I’m sure that Google has working versions of this feature internally.

Media Tap To Transfer

Android 13 is preparing a “media tap to transfer” feature that will seemingly let you “transfer” music playback from one device to another simply by getting each device close together and then having them touch. While the feature doesn’t work, its command line interface used for prototyping shows how the sender and receiver flow works.

The media tap to transfer “chip” that’s shown in the screenshots are intended to show up when a user is playing media on a local “media cast sender” device (like a smartphone) and they move their device close enough to a “media cast receiver” device (like a tablet) that they own. The chip’s text encourages users to “transfer” the media from the sender to the receiver.

While I’m still trying to figure out how the media actually gets transferred, I think I now understand why this feature exists. Assuming Google actually intends to build Android 13 for a smart display/docked tablet device like the rumored 2022 Nest Hub, then this media tap to transfer feature will let users start music playback on their phone and then transfer playback to their Nest Hub (and presumably any speaker groups it’s part of). This feature only makes sense to me in this context. Transferring music playback from a portable device like a phone to a stationary device like a docked tablet or smart display is a feature we’ve seen on other platforms, so I wouldn’t be surprised if that’s the angle Google is going for here.

Ambient Context events

Android 13 has added a new API called AmbientContext that provides a framework for “client” apps to get notified of sleep-related events like coughing and snoring. These events are detected by a service implemented in a privileged “provider” app so the “client” app never needs to have access to raw sensor data. Google is working on implementing this API into their Android System Intelligence app, though I don’t know which (if any) of their fitness apps will act as a “client”.

One of the features that Google introduced in the 2nd generation Nest Hub is “Sleep Sensing”, which uses a Soli radar to detect your movement and breathing while you’re sleeping. It also uses other sensors (presumably a microphone) to detect sounds like snoring and coughing while you’re asleep. Google may be trying to replicate existing functionality on the new Nest Hub with the Ambient Context API, or they could just be trying to bring some “Sleep Sensing” features to Pixel phones.

Cross-device calling

While it’s possible to make a phone call with a Google Nest smart display, the feature isn’t available for everyone. Google may be working on a solution to this problem that may utilize new APIs in Android 13. Within Google’s Android 13 preview builds for Pixels is a system app called “Cross-Device Communication Service.” Earlier versions of the app had a setup page for a feature called “nearby calling” that would let you “quickly move calls between your phone & Nest Hub” among other things. This feature hasn’t launched yet, but if it does, I think it’ll make use of the new cross-device calling API in Android 13.

Cross device calling was added to support transferring phone calls to remote “endpoints”, which refer to devices that may or may not be able to carry out a call on their own. Calls that are routed to devices that can’t carry out calls on their own are considered “tethered” external calls. Since these “tethered” devices can’t make phone calls on their own, the call audio is routed to the device using the new external call audio routing API.

This is yet another feature in my list that’ll also benefit tablets, but seeing as Google has already shown hints that they’re implementing a feature to transfer calls between a phone and a Nest Hub, I think this feature was likely designed with that in mind.

Hardware camera and microphone toggle support

Android 12 added software toggles to block apps from accessing the camera and microphone. App developers can call the SensorPrivacyManager API to check which of these toggles is supported on the device. Android 13 is extending this API so developers can check if a device supports a hardware toggle for the camera and microphone as well.

Most devices don’t have hardware toggles for camera and microphone access, but some TVs and many smart displays do. Android 13 will propagate the state of the hardware switch to the framework, so the status of Android’s built-in camera and microphone toggle will match the position of the hardware switch.

This is one change that makes sense to introduce because there’s no reason the status of a hardware camera or microphone switch shouldn’t sync with the software toggle. If you’re familiar with Android feature development, however, then you’ll know that you have to filter every feature addition through the lens of “hmm, how might this end up in a Google product?” For that reason, I’m leaning towards this change being introduced for the sake of smart displays with hardware sensor switches, which are present in all Nest Hub devices.

Low light clock

If you own a Nest Hub, go turn off the lights in the room it’s in and take a look at the screen. See the clock that appears? That’s basically being added to Android 13.

Android 13’s new “low light clock” is a barebones text clock that’s shown when the device is docked and the ambient brightness is low. When I first discovered this last week, I didn’t know why this was being added considering Android already has a screen saver and an ambient/always on display. If I consider that Google is building Android 13 for a future smart display like the rumored 2022 Nest Hub, however, suddenly this feature makes a lot more sense — it’s just replicating what existing Nest Hub devices already have.

Thread support?

This last one is a bit murky because I’m not really sure if it’s coming to Android 13 or not. Searching for code with the word “thread” in it is a nightmare, and the only reference to Thread support in Android is this lone AOSP code change.

Thread, for those of you who don’t know, is a wireless networking technology that’s based on the IEEE 802.15.4 standard. It offers numerous benefits for IoT devices, and it’s used by a couple of Nest products during setup (which, I must add, can lead to problems).

Android 13 may or may not add Thread support, but if it does, then this would be yet another example of Google bringing a feature to Android 13 that already existed in Nest products.

Will Google's new Nest Hub really run Android 13?

I’m not privy to Google’s hardware plans, and even if I were, I would not be sharing that information publicly. Therefore, this post should not be taken as confirmation that Google’s rumored Nest Hub will run Android 13. Instead, this post is intended to show the efforts that Google has quietly undertaken to improve Android for docked tablets and smart displays. I leave any speculation up to you, the reader. I'll leave you to consider the implications of this question by a Googler that once threw me for a loop (but makes a whole lot more sense to me now): “Is it still easy to cherry-pick [a code change] to sc-v2 (API level 32)? That could benefit us as some of our Nest devices might not be migrated to T."

Android Device Management