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
InputEventthat 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.
