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
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
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
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,
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.
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
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
to warn you about incorrect
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.
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
AsyncTask in Android 10.
LocationManageris significantly changing its API for obtaining locations
DevicePolicyManageris overhauling its passphrase quality API, resulting in a bunch of deprecations
You can no longer use
GET_INTENT_FILTERSwhen querying the
If you were using
WindowManger.LayoutParams, those values have been removed from the SDK entirely
What Is the Human Resources Department Doing In My Developer Preview?
There is a new
system service. Google added a lightweight concept of “conversations” to the
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
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
AppSearchManagerthat 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
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
There are two new
CATEGORY_WORKOUTsuggests 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_SHARINGmeans, 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
requireDeviceScreenOnattribute 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!.
Interested in learning Kotlin? Check out the Klassbook for Kotlin language lessons that you can run right in your browser!