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:
-
We can find out if bubbles are enabled
-
We can find out if our activity was launched from a bubble.
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.