Random Musings on the Android 16 Developer Preview 1

Wow, it’s February again already?

*checks calendar*

No, Google is just changing the timeframe for major Android releases.

As is outlined in the Android 16 DP1 blog post, Google is moving to having a major and a minor release each calendar year. The major release has been moved earlier in the year to better align with device manufacturer timetables. The minor release, planned for late 2025, “will include new developer APIs” but should not “include planned behavior changes that could affect apps”.

So, What’s In the API Differences Report?

Fans of these “random musings” posts know that I pore through the API differences report to help provide detail beyond what the release notes state and to identify other changes that Google is not talking about yet.

That is not working out so well this time around.

Simply put, the API differences report is largely broken. Links lead to 404s or call out API additions that do not show up in the actual documentation. It could be that they changed the scope of DP1 and failed to regenerate the API differences report. Or, it could be that the API differences report is correct and they failed to publish the documentation updates. My guess is that it is the former, given the mix of what is working and what is not.

I may publish a follow-on post with more if the API differences report starts behaving more normally.

OK, What Can You Tell Us?

The biggest area of change surrounds the photo picker. As is noted in the release notes:

The developer preview includes new APIs that enable apps to embed the photo picker into their view hierarchy. This allows it to feel like a more integrated part of the app while still leveraging the process isolation that allows users to select media without the app needing overly broad permissions.

What is interesting to me is that they are using SurfaceControlViewHost for this. The actual UI will be rendered by a separate process, but you can control where that UI gets rendered on your screen, wrap it in your own UI, etc. Google debuted this system four years ago, and I have been waiting for it to get put to use — it might be applied elsewhere, but this is the first that I recall seeing.

The other big area of possible change is something called “app functions”. This is a bit of a “negative space” analysis, as this is the biggest area that is missing from the API differences report. For example, there is a new android.app.appfunctions package… and there is no documentation for it, despite a link to that page from the API differences report. But, what I can infer is:

• It is tied to app search. There is a similar “new with missing docs” android.app.appsearch.functions package, and AppSearchManager will have a new getAppFunctionManager() method.

• There is a new system service, probably AppFunctionManager, tied to another system service name.

• It probably involves developers creating a custom bound service, as there will be a new BIND_APP_FUNCTION_SERVICE permission. Those BIND_ permissions allow developers to defend a service, ensuring that only core OS processes can bind to them, not arbitrary other clients.

Given those two, I’ll guess that the app search functionality will gain some sort of “quick actions” UI, where developers can publish operations (“app functions”) that can be performed on search results for their app. What would be even more interesting is if developers could offer actions on any search results.

Is There Much Else of Note?

The release notes and blog post mention changes to Health Connect and Privacy Sandbox. If you use either of those, you may want to investigate further.

Beyond that:

• The BatteryManager broadcasts may be getting a new EXTRA_CAPACITY_LEVEL extra, perhaps tied to battery health

• A bunch of FingerprintManager constants are supposedly deprecated, but, then again, that whole class is deprecated, so 🤷🏻

Little else seems like it has changed in areas that might be commonly used. Ad Services might qualify, but I have never used it, so I cannot really cover it here.

That’s It?

Even if we assume that the broken documentation points to changes, this is a surprisingly small major release. Since there is only one more developer preview, and API changes should start fading out after a Beta 1 release, Android 16 might be a bit sparse in terms of developer-facing changes. Since they had ~3 months chopped off the development schedule, this seems reasonable. It may be that DP2 will turn out to be much larger.

For user-facing changes, as always, pay attention to Mishaal Rahman, who does excellent work covering those!