More Random Musings on R DP2!

Rich Hong pointed me to the DP1 -> DP2 API differences report. Which is really good, because, as it turns out, all the cool stuff isn’t in the actual R DP2 docs.

So, here are some more random musings, based on that API differences report, and building upon yesterday’s original set of R DP2 musings.

Things That Show How Android Is In Control

As XDA-Developers mentioned a few hours ago, there is a new API for adding “quick controls” to the menu we get on a long-press of the POWER button. Apps can implement a ControlsProviderService to advertise options for this “quick controls” area. This appears to work a bit like TileService does for adding tiles to the notification shade. The available types of controls are defined as constants on a DeviceTypes class, and the candidates are mostly appliances and similar sorts of household items… and, apparently, a pergola. However, I feel quite confident that enterprising developers will find ways to use this for ‘device types’ that are somewhat broader in nature.

Things That Share

In Android 10, we got SurfaceControl. I blew past it, in part because I couldn’t figure out what it was for our how we would really use it.

In R DP2, we now have SurfaceControlViewHost. Its JavaDocs have a very interesting sentence:

The primary usage of this class is to embed a View hierarchy from one process in to another.

The implication is that we might now have something that developers have been asking for since the very early days of Android: the ability to embed the UI of one app in another. Whether that is the intended purpose or not remains to be seen, as all of this is still rather under-documented.

Things That Affect Security

There is a new VpnManager API for developers of VPN clients.

We also now have VerifiedKeyEvent and VerifiedMotionEvent. We seem to get these from verifyInputEvent() on InputManager, whose JavaDocs state:

Verify the details of an InputEvent that came from the system. If the event did not come from the system, or its details could not be verified, then this will return null.

It is unclear what the scenarios are where the InputEvent would not come from “the system”, in part because there is no real definition here of “the system”. However, if you have a highly-secure input scenario (e.g., passcode for a banking app), this may be worth investigating further.

Things That Are Getting Massaged

If you have been using various ways of implementing full-screen UIs, such as setSystemUiVisibility(), your current API calls may now be deprecated. That is moving to WindowInsetsController and WindowMetrics.

The ChooserTarget and ChooserTargetService that were the original approach for direct-share targets are now deprecated in favor of Android 10’s Sharing Shortcuts API.

What Happens Next?

The collapse of Google I/O does start to raise questions about Android R’s rollout. It would not surprise me if things get delayed, both at the level of the developer previews and betas and at the level of a final release. After all, Google has to do what everyone else is doing: try to get stuff done in the face of a pandemic.

However, eventually, the sun will shine again, SARS-CoV-2 will have reduced impact, and Android R will ship. Between now and then, I will write and blog what I can on what Android R means for us developers.