A little earlier in the year, Android 16 beta 1 has just landed! With the first beta available, it's time to take a look at what's new, so far, in Android 16 "Baklava".

This is, as last year, a non-definitive and unconfirmed list of changes. Like the work profile changes in Android 14 things can change at any point and without warning.

Here we go!

The first beta does not include a change to minimum SDK for app installation. Will it come later? We shall see.

For context, every year now since 14 the minimum version an application must target has increased. In Android 15 it was 24, in 14 it was 23..

If you're interested in what "targeting" is, it looks like this within an application's configuration:

defaultConfig {
    applicationId = "org.bayton.example.apptrackdemo"
    minSdk = 24
    targetSdk = 23
    versionCode = 1
    versionName = "1.0"
}

Minimum SDK is the lowest version of Android an application will support, this typically changes when new features introduced could cause compatibility issues. It could also change when a developer no longer wishes to support a very old version of Android. In either case the application will no longer be available for installation from Google Play on an affected device, and will error when sideloaded.

With the shift in timing for this release it's not clear if this'll be mandated so soon after the bump to 24 in 15, or if that'll come in a quarterly release at a later point. Currently 16 follows 15: only apps that target Android 7.0 - API level 24 - or later will be permitted.

jason@MBP adb install app-release.apk
Performing Streamed Install
adb: failed to install app-release.apk: Failure [INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 23]

To reiterate my sentiment from last year on this topic:

As ever, we're talking about applications targeting a version of Android 10+ years old. While some organisations with line-of-business apps that haven't seen an update in half a decade may balk at the idea of getting their applications updated or rewritten, the justification behind this limitation is solid - security. Where apps targeting <6.0 were able to abuse the old permissioning system (pre-runtime!), apps targeting 7.0 are still able to abuse device administrator and similar APIs. This isn't something you want potentially leveraged directly or indirectly on your managed estate.

Not too much is currently known about this feature arriving in 16, but from what I've found, this looks like a new way of allowing applications to interact with one another through the publishing of "functions" an app can perform.

Google's example here suggests an assistant app can search on-device for applications with a known function for creating a note, which replaces a slightly more convoluted approach app developers have to take today:

An assistant app is trying to fulfill the user request "Save XYZ into my note". The assistant app should first list all available app functions as AppFunctionStaticMetadata documents from AppSearch. Then, it should identify an app function that implements the CreateNote schema. Finally, the assistant app can invoke executeAppFunction(ExecuteAppFunctionRequest, Executor, CancellationSignal, OutcomeReceiver) with the functionIdentifier of the chosen function.

This feels, and not just because of the example used, like it'll make the lives of Gemini, ChatGPT, and many other assistant application developers far easier. What I don't get from the example offered is how to target apps. I could have Keep, Obsidian, and several other apps offering a function to create a note. I'm sure this will be explained in due course though (if it isn't already and I just missed it).

For enterprise, Google has added a few restrictions on app functions. They can be disabled outright and disabled cross-profile. Hopefully we'll see similar to Credential Manager and Widget APIs, that allow a block with package exclusions.

Originally found in the Android 15 documentation, this one was referenced in the UserManager APIs, but never ultimately landed in 15.

As it says on the tin. If you're thinking "Don't we already have an API for NFC?" Yes we do, but that's to control the beaming of data between devices. This is a full on radio disable and will probably live under DeviceRadioState in AMAPI at some point later.

This was originally found when Android 15 was in beta, and didn't make it to production. As of this release it's now officially showing up as a Baklava feature.

This is related to comms with thread devices. Again, it's a cut-and-dry, simple restriction. More details on its use will come in time.

This is extremely short and sweet given how early in the process we are for 16. Expect several more betas with several more changes. Check back here again soon!