Random Musings on the Android 12 Developer Preview 3

By Pro Web Design

2021-04-23 15:44:12

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

What Does Not Shock Me

Adding the SCHEDULE_EXACT_ALARM permission
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
is unsurprising.

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 getRedactedUri()
method on MediaStore. Given the Uri of some piece of content, getRedactedUri()
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.

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
( element?). The one supported value is neverForLocation,
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?
See also generateDisplayHash() on View.

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 RemoteViews improvements.
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 ListView,
using RemoteCollectionItems.

Also, the deprecated AnalogClock class continues getting new capabilities.

What Is Going Away

If you were using system-supplied playlist tracking via MediaStore.Audio.Playlists,
do something else.

The “network slicing” APIs added to DevicePolicyManager in an earlier developer
preview are now gone.

And our ripples no longer have style.

What Is Back

Deprecated is no longer deprecated.

What Relieves Me Tremendously

We made it to DP3 without any obvious changes to scoped storage.

What Makes Me Go “Hmmmmm…”

There is a new LightsManager
that “allows control over device lights”. It is unclear whether or not
there are four lights.

Theoretically, there is a new DomainVerificationManager system service,
except the documentation leads to a 404.

There is a new MANAGE_MEDIA
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.

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
that means.

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 android:launchMode.

compileSdkVersion is now reported for installed apps.
This includes a separate compileVersionSdkCodename value
apparently for things like android-S.

AudioManager now lets you control “the audio device that should be used for communication use cases”
via setCommunicationDevice().

The scrolling-screenshot capability being added to Android 12 may be being powered
by ScrollCaptureCallback.

Interested in Jetpack Compose? jetc.dev has a weekly newsletter of the latest articles, samples, and other details of Compose development!