Random Musings on the Android 16 QPR2 Beta 1

Apparently, the mid-cycle update will be under the “QPR” brand, so we got a beta for it. We did not get a developer preview AFAIK, and it is unclear if there will be any follow-on betas, despite the “1” nomenclature. 🤷🏻

So, given the announcement blog post and the API differences report, let’s see what we are in store for.

What Might Get Google Sued

According to the blog post:

Android 16 QPR2 can automatically generate a themed icon for your app if you don’t provide a dedicated one. The system applies a color filtering algorithm to your existing launcher icon to render it in a monochrome style, allowing it to integrate with the user’s chosen theme.

Given that some firms have a lot invested in particular colors, one imagines that there will be some disputes over Google’s unilateral decision to replace those colors because Googlers feel like it.

What Else is Scary

The new CAPTURE_KEYBOARD permission “Allows an application to be able to capture keys before Android system get chance to process system keys and shortcuts.” However, this is a normal permission, which means apps can request it and users are not involved. Depending on the scope of this “capture” of keyboard events, a permission like this should be dangerous at minimum.

What Might Break Your App

The system-generated dark theme outlined in the blog post might work some of the time but feels like it is unlikely to work all of the time. If you do not already implement a dark theme — one recognized by the system — you might wish to test this behavior.

The changes to MediaRouter outlined in the blog post might cause you to need to request more permissions, such as BLUETOOTH_SCAN, that you have not needed previously.

There is a “camera compatibility treatment for fixed-orientation apps” that you can opt out of. If you use the camera, pay attention to this.

What Requires Research

Launcher implementations should look into startVisibilityTracking() and stopVisibilityTracking() on AppWidgetHostView. These will help trigger AppWidgetEvents for when the app widget can and cannot be seen by the user, for metrics and whatnot. App widget developers can use queryAppWidgetEvents() on AppWidgetManager to find out about those events.

Launcher implementations ought to consider also researching the new ACCESS_LAUNCHER_DATA permission.

Notification now offers isRequestPromotedOngoing() and Notification.Builder has setRequestPromotedOngoing(), for whatever “promoted ongoing notifications” are.

What Points Towards “Android on the Desktop”

The blog post describes “Display Topology API”, “Device-aware ViewConfiguration”, “Controlled Mouse Scrolling”, “Files Desktop UX”, and a variety of printer API updates. While not completely irrelevant for phones or tablets, this all points to a bigger push for Android on the desktop, perhaps as part of the Chrome OS changes.

What’s Next?

The timeline in the blog post suggests two more betas, but it is unclear to what extent they will introduce more changes, revert some of this release’s changes, or otherwise affect us.