Random Musings on the Android 12 Beta 2

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.

Beta 2 has a bit more change in the API surface than I would expect… and yet still does not have everything that might yet show up in Android 12.

What Google Thinks Is Important

Of the things that Google highlighted in Beta 2, few require developers to do anything. That is nice, considering that this is Beta 2. For example, apps do not have to change for the microphone and camera indicators to appear or for users to be notified about apps reading from the clipboard.

There is a new SensorPrivacyManager, which can let you know if the device supports microphone and camera toggles. It cannot tell you what the state of the toggle is — you just use the microphone and camera normally and get silent/blank output if those hardware features are toggled off.

The new Privacy Dashboard is very nice. If you would like your app to be able to provide explanations for why you used certain dangerous permissions, you can export an activity for that, though pay attention to the docs around ACTION_VIEW_PERMISSION_USAGE_FOR_PERIOD.

What Quietly Got Documented

Somewhere along the line, without an announcement that I can remember, AppSearch is now documented.

AppSearch boils down to a full-text search engine, with an API that developers can use to index content and search it later. The docs specifically compare it to SQLite’s full-text search capability.

This is certainly a nice addition. The docs point to an androidx.appsearch artifact, along with androidx.appsearch:appsearch-compiler and androidx.appsearch:appsearch-local-storage, though. It is unclear what the relationship is between these artifacts and the Android 12 API.

What Makes Me Wonder “What Are They Waiting For?”

The view translation APIs still exist and received their own updates. Yet, there is no sign of documentation, the way that stuff crept in for AppSearch. And, there were some strange reversals, such as FEATURE_TRANSLATION being removed.

In particular, there is no sign of how apps can control this translation, including opting out, if the app developers are not in position to support users with Google-supplied translations.

What Is New and (Potentially) Important

There is a new BLUETOOTH_ADVERTISE permission, described as “Required to be able to advertise to nearby Bluetooth devices”. The only thing that I see as requiring it is ACTION_REQUEST_DISCOVERABLE, and that only needs it once your targetSdkVersion reaches 31.

What Continues to Get Sweet, Sweet Love

RemoteViews got more changes. From the lineup of changes, they feel targeted at app widgets, more so than for other uses of RemoteViews (e.g., custom notifications).

Bubbles continue their march towards usefulness:

The new “lights” API got some changes. It is still unclear what this is all about.

What Notable Got Renamed

The “optimized” storage access from before is now “raw” storage access, as seen in requestRawStorageAccess and related changes to ApplicationInfo. It still seems limited to file managers and galleries.

VIBRATOR_SERVICE is deprecated, as they steer you towards the new VibratorManager.

What Met Its Untimely(?) Demise

We can no longer ask if a job is a foreground job.

The whole android.service.dataloader package that was added in Beta 1 got nuked in Beta 2.

getDefaultAdapter() on BluetoothManager is deprecated, in favor of getAdapter(). getAdapter() has been around since API Level 18, though, so this change hopefully will not be a big one.

DATE_FORMAT on Settings.System is deprecated in favor of TIME_12_24.

What Else Caught My Eye

The “attribution tags” added in Beta 1 got a bit easier in Beta 2, as it appears that we may be able to add them in the manifest.

We can find out if our app was granted the ability to schedule exact alarms.

There is a new PerformanceHintManager.

We can get and set the “effect color” for RippleDrawable. It is unclear whether this refers to the sparkle effect that was seen in earlier previews. If it does, and your designers hate the sparkle effect with the fiery passion of a thousand suns, this might lead to an option to disable it within your app.