Random Musings on the Android 12 Developer Preview 1

Each time Google releases a new developer preview, I rummage through the API differences report the high-level overviews, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize mainstream features that any developer might reasonably use, along with things that may not get quite as much attention, because they are buried in the JavaDocs.

As with the previous four releases, Android 12 seems to be lacking a prominent user-facing feature. I have no idea what I will tell my mother that she’ll gain if her phone gets the update at some point. Admittedly, Google appears to be sandbagging a bit, holding out some changes for later releases, so perhaps something compelling to ordinary people will appear later.

But, as has been common in a similar timeframe, the interesting bits for developers are not covered in the DP1 release notes.

What Will Irritate Developers

In principle, I am a fan of requiring positive declaration of exported components. However, this desperately needs a Lint warning, though hopefully one is forthcoming, perhaps in the current canary release of Android Studio 2020.3.1 Arctic Fox My Goodness This Name Is Long. I am hopeful that the error message will improve, though, as tens of thousands of developers next year are going to encounter this change, and approximately zero of those developers will be reading the documentation. Helen of Troy had “the face that launched a thousand ships”; this sort of inscrutable error message for an all-but-guaranteed failure is “the error that launched a thousand Stack Overflow questions”.

I had no idea that nested Intents were much of a thing, making me wonder if this was a technique used by certain libraries (e.g., ad networks). That, and requiring mutability flags on PendingIntent, worry me less for apps directly and more for libraries that might not be receiving updates. Of course, depending on where those libraries were published, the libraries may be gone, anyway.

I foresee a blog post in my future on writing activity trampolines.

Perhaps the one that worries me most is the limit on starting foreground services from the background. In theory, this is fine. In practice, foreground services are already unreliable, with timing-related OS bugs yielding Context.startForegroundService() did not then call Service.startForeground() or similar sorts of errors. My concern is that, just as Google seems unconcerned about those errors, Google will not care about follow-on errors related to timing of when you can and cannot start a foreground service. Hopefully, my fears are unfounded.

Fortunately, all of the preceding changes in this section only take effect once your targetSdkVersion hits 31(?) or higher. That means it probably will affect those of us experimenting with DP1 for a few months, and then the bulk of developers sometime next year.

One change that might take effect more quickly — though I have not yet tested it — is that there are new permissions for using the camera and using the microphone in the background. These are dangerous permissions, ones that we have to request at runtime. It is also unclear how future camera and microphone toggles might behave and how apps will find out about the state changes.

And the new VERSION_CODES value is messed up, as usual.

What Is Neat But Confusing

The unified content API, for accepting media from paste, drag-and-drop, and other sources, is nice. However, it is unclear why this is a new framework API, since the documentation depicts it as being a wrapper around existing APIs with a backport already in AndroidX. If the backport is complete, why did we need a framework API? And if we needed a framework API, what is the gap between what Android 12 offers and what the backport offers?

PackageManager has gained some interesting, if under-documented, features:

  • You can request checksums of installed apps.

  • There is a new form of “property” that you can declare on a component or elsewhere in the manifest. It is unclear how this relates to the long-standing <meta-data> option in the manifest.

  • A package can have attributions in the <manifest>, defined in <attribution> elements. It is unclear if this ties into data access auditing, though, or what role these “attributions” otherwise play.

What Is Subtly Nice

The postponed foreground service notifications feature should help with user distraction. Often, we need a foreground service because we cannot be certain that a background service will complete in time… but if the work is completed quickly, we hassle the users with a short-lived notification. This change should help eliminate that.

Apps have improved options for blocking touch input passed through other windows, including a permission to be able to enable such a block and a window option to implement the block. Frankly, this is long overdue, as is banning apps from closing system dialogs.

Since the beginning, we have built up some heuristics for which types of Context are safe for UI operations and which ones are not. Finally, Google is formalizing the concept, with a dedicated API to tell you if this Context is OK for UI work. There is a corresponding option in StrictMode to warn you about incorrect Context usage.

PowerManager can now give us real-world estimates of remaining battery life, which might be useful for some apps to better scale back work in low-battery states.

And, as Romain Guy tweeted about, we have a new API to apply a RenderEffect to a View, which should give us an easy blur option.

What Needs Third-Party Love

ImageDecoder now supports decoding the full animations of GIF and WebP images. It will be interesting if image-loading libraries start adopting it on Android 12 and newer devices — my guess is that they will only if if provides obvious benefits over their existing code for handling these animations.

What’s Dead (Or Seriously Morphed)

At least in DP1, there are relatively few massive deprecations, like the deprecation of AsyncTask in Android 10.

However:

What Is the Human Resources Department Doing In My Developer Preview?

There is a new PeopleManager system service. Google added a lightweight concept of “conversations” to the Notification API over the past few releases. This appears to try extend that further.

This might tie into the conversation app widgets described in some Android 12 document leaks. There also is a new way to tie a NotificationChannel to conversations.

What Is the Insect Resources Department Doing In My Developer Preview?

There is a BugreportManager in Android 12, though it is unclear exactly how useful it will turn out to be.

What Makes Me Go “Hmmmmm”

And now, we get to a list of other things that caught my eye in the API differences report that did not get included in Google’s DP1 overview:

  • There is a new AppSearchManager that appears to be an on-device search engine. It will be interesting if this gets covered more in future developer previews.

  • The fused location provider has appeared in the SDK for the first time. It will be interesting to see if this means that you can start using this on non-Play devices.

  • We now have a new facet of a Configuration: fontWeightAdjustment. I do not see an option for this in the Settings app. It also remains to be seen if this triggers a new type of configuration change.

  • We can now control whether we get click events for a disabled View.

  • It appears as though an <intent-filter> can now filter Uri values based on a suffix and some sort of “advanced pattern”. It is unclear what is so advanced about that pattern, though.

  • There are two new Notification categories. CATEGORY_WORKOUT suggests that Google is going to have more explicit support for fitness-related apps, perhaps stemming from their acquisition of Fitbit. And I do not know what CATEGORY_LOCATION_SHARING means, such as “sharing with who?”.

  • If you played with Android 10’s device controls, there is new control type: the thumbnail. I am uncertain what the use case is, though security cameras might be one.

  • There is a new requireDeviceScreenOn attribute on… something. It is described as “Whether the device must be screen on before routing data to this service. The default is true.”. That default seems odd; otherwise, I would have thought that perhaps this attribute goes on <service> in the manifest. It is possible that this ties into a new option to require unlocking the device before processing a notification action.

  • There is a new AppUriAuthenticationPolicy, though it is unclear how it will be used.

  • We can have more sophisticated haptics, with multiple blended vibration patterns. Alas, the name of the class for this will spawn yet another round of off-color jokes.

What Happens Now?

While I do plan on writing an Elements of Android S along the lines of its Q and R predecessors, I plan on waiting to release something. I waste too much time chasing changes that eventually themselves change or outright vanish. So, my current plan is to wait to ship a Version 0.1 of the book until the last developer preview or first beta release. If you feel that this is a mistake, and I should publish something more rapidly, let me know!.

 

Meta


Creative Commons License