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.

There are new BLUETOOTH_CONNECT and BLUETOOTH_SCAN 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 group, NEARBY_DEVICES.

Possibly related, there is a new android:usesPermissionFlags that goes somewhere (<uses-permission> 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.

What Continues Its Remarkable Turnaround

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, obtained using DOMAIN_VERIFICATION_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.

There is a new wordy START_FOREGROUND_SERVICES_FROM_BACKGROUND 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 android:requestOptimizedExternalStorageAccess="true". 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. Sometimes.

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.