Random Musings on the Android 12 Developer Preview 3
Each time Google releases a follow-on developer preview, I rummage through
the incremental API differences report,
the release notes,
and even the release blog post,
to see if there are things that warrant more attention from
developers. I try to emphasize things that mainstream developers might use but may not
get quite as much attention, because they are buried in the JavaDocs.
Today, let’s take a look at the (presumed) last of the developer previews, DP3, as
we race towards betas. As usual, things start to slow down the deeper into the
release process we get, but there are still some DP3 changes to consider.
What Makes Me Very Angry
Splash screens. Specifically, Google-mandated-and-designed splash screens.
Even more specifically, Google-mandated-and-designed splash screens that affect
every app regardless of
What Does Not Shock Me
is unsurprising. If anything, I am surprised it took this long.
Similarly, continuing The War on Background Processing by adding an even more restrictive
“restricted” app standby bucket
Adding additional blocks on what apps can handle
ACTION_VIEW for Web URLs
also is unsurprising. Unfortunately, this has some anti-competitive aspects, as it
puts additional burdens on third-party clients for existing Web properties, as well
as for alternative Web browsers.
The fact that RenderScript is dead is unsurprising… other than the fact
that zombies are remarkably tough to kill sometimes.
What Security-Conscious Developers Should Ponder
android:allowBackup no longer affects device-to-device data transfers.
There is a separate configuration mechanism that you can use to try to put some
limits on that.
There is a new
MediaStore. Given the
Uri of some piece of content,
will return a
Uri that serves up the same content with some form of redaction
in place. The cited example is removing location/GPS-related EXIF headers from images.
It is unclear if there are other forms of redaction that are offered.
There are new
permissions. My hope is that these will mean that we will no longer have to request
location permission to work with Bluetooth devices. OTOH, it seems like this should be
documented more by now, particularly since they are
dangerous permissions and
presumably require runtime requests. These appear to be in a new permission
Possibly related, there is a new
android:usesPermissionFlags that goes somewhere
<uses-permission> element?). The one supported value is
which basically says “we pinky-swear that we are not going to use your location
despite asking for location permissions”.
There is a new
DisplayHashManager system service,
which is “used to validate information about what was present on screen”.
This begs the question: under what circumstances would this hash fail?
RemoteViews, particularly for use with app widgets, is getting more love here
in Android 12. I mentioned a bunch of improvements in my DP2 post.
In DP3, we get a whole bunch of additional
It looks like we can adjust
android:layout_* attributes now, for height, width,
and margins. And, it appears that we have a simpler option for populating a
Also, the deprecated
AnalogClock class continues getting new capabilities.
What Is Going Away
If you were using system-supplied playlist tracking via
do something else.
The “network slicing” APIs added to
DevicePolicyManager in an earlier developer
preview are now gone.
What Is Back
What Relieves Me Tremendously
We made it to DP3 without any obvious changes to scoped storage.
What Makes Me Go “Hmmmmm…”
Theoretically, there is a new
DomainVerificationManager system service,
except the documentation leads to a 404.
There is a new
permission. If I understand it correctly, apps that hold it can have a somewhat
streamlined user experience with media management, with fewer confirmation popups
to grant access to the managing app.
There is a new wordy
permission. Right now, we cannot start foreground services from the background,
but with this permission, you can. However, ordinary apps cannot have it,
only privileged apps and those in certain roles. Why a gallery app deserves
to have the right to start foreground services from the background is beyond me.
Somewhere, perhaps in the manifest, we can specify
That can only be granted to apps with
MANAGE_EXTERNAL_STORAGE or, once again,
gallery apps. If granted, “bulk file path operations will be optimized”, whatever
Bubble can suppress their bubbles.
The app search APIs expanded massively
yet remain unannounced. In completely unrelated news, Google I|O 2021 will
be held May 18-20.
We can now find why our
JobScheduler job was stopped,
which is a rather nice addition.
There is a new
singleInstancePerTask value for
AudioManager now lets you control “the audio device that should be used for communication use cases”
The scrolling-screenshot capability being added to Android 12 may be being powered
Interested in Jetpack Compose?
jetc.dev has a weekly newsletter of the latest articles, samples, and other details of Compose development!