The Community

Mr. Cowell made me aware of a Medium article by Bastien Bobe, field CTO at Lookout, this week. His article gave me a good overview of a vulnerability discovered by Alan Zaccardelle that I'd previously not heard about. I'd encourage reading the linked article above for the overview and demo video of the vulnerability, but in a nutshell the issue is as follows: During work profile setup, there's a temporary state as the profile initialises where no policies are applied. It's too early for organisational policy to enforce (in which sideloading is always prevented by default) and there's no default policy in place on Android's side. The work profile is wide open. This means if a user has developer settings enabled, USB debugging turned on, and the device connected up to a computer, applications can be sideloaded via ADB. For those more advanced, a script can be written to check for the presence of the work profile, and immediately adb install package.apk as many apps as desired until continuing on to the point of registration/enrolment and corporate policy application. Here's a video of my own tinkering (I don't pause the process, so policy can be seen blocking further installs), and I'll continue the article below:

Mr. Cowell made me aware of a Medium article by Bastien Bobe, field CTO at Lookout, this week. His article gave me a good overview of a vulnerability discovered by Alan Zaccardelle that I'd previously not heard about. I'd encourage reading the linked article above for the overview and demo video of the vulnerability, but in a nutshell the issue is as follows: During work profile setup, there's a temporary state as the profile initialises where no policies are applied. It's too early for organisational policy to enforce (in which sideloading is always prevented by default) and there's no default policy in place on Android's side. The work profile is wide open. This means if a user has developer settings enabled, USB debugging turned on, and the device connected up to a computer, applications can be sideloaded via ADB. For those more advanced, a script can be written to check for the presence of the work profile, and immediately adb install package.apk as many apps as desired until continuing on to the point of registration/enrolment and corporate policy application. Here's a video of my own tinkering (I don't pause the process, so policy can be seen blocking further installs), and I'll continue the article below:

The Android App Bundle (AAB) is a modern application packaging format introduced by Google to streamline and optimise Android app distribution. Unlike the traditional APK, an AAB contains all the necessary compiled code, resources, and assets for an app only for the purpose of permitting dynamic packaging; it cannot be directly installed through Android's package manager on-device (3rd party options exist though!). Instead, it is uploaded to Google Play, which dynamically processes & bundles the respective code into highly-optimised APKs specific to the device(s) downloading the app. The AAB format has been available to Android developers since 2018, and mandatory for new app uploads from the Google Play console since 2021. The Google Play iFrame, used by enterprises for private app distribution, has however historically mandated APK uploads. Based on a recently-updated help doc, support for AAB in enterprise scenarios appears to be now possible, although it doesn't seem fully rolled out yet. It's live! Not a day or so after this article went up, Google announced general availability, including answering some questions and touching on scenarios raised below. I'll dot additional thoughts in callouts like this one where relevant with updated data. All the same, I spent some time figuring out what's possible so you don't have to! How AAB and APKs differ # First thing's first, is this a pitch to organisations to immediately push all private applications over to AAB? No. There are valid use cases for both, which presumably (in addition to understanding the effort it may take organisations to convert over) is why Google will continue supporting APKs in the iFrame. That said, here's a brief overview of each. APKs # An APK is a single package file containing all the resources, assets, and compiled code for all supported device configurations. While this offers the greatest compatibility across a device estate, it means APK files are often larger than necessary as they include resources irrelevant to the downloading device. APKs offer simplicity and convenience for developers who want a quick, straightforward way to package and share their applications. They ensure broad compatibility across all Android devices without additional processing or conversion. Additionally, APKs support offline installation, making them ideal for environments with limited or no connectivity. Their self-contained nature enables immediate deployment and rapid testing, which accelerates development and iteration cycles. Furthermore, APKs provide flexibility by allowing distribution through various channels beyond Google Play, including alternative app stores or direct downloads. Finally, because APKs don't rely on Google Play explicitly, they're suitable for devices lacking Google Play access, or regions where it isn't available. That covers everything from deployment to devices in restricted countries such as China, to closed-network environments without direct access to Google Play. AOSP is a consideration also, but there's a lot more to managing AOSP that I won't dive into here. Android App Bundles (AAB) # Like an APK, an AAB is a publishing format containing all the necessary components in a single file, the difference is in the processes that occur after uploading to Google Play, as I opened with above. As well as significantly reducing app sizes through dynamically generated, optimised APKs tailored to each user's device, AABs also support dynamic delivery of features and resources, enabling efficient feature rollouts and resource management. Release management is also simplified, as developers maintain only a single upload file, eliminating the need to manually handle multiple APK variants for different architectures or feature sets. Additionally, AAB leverages App Signing by Google Play, centralising key management, potentially increasing security, and simplifying key recovery - particularly sometimes beneficial in organisations who have struggled with key storage and management in the past. Finally, AABs allow for larger uploads to Google Play, exceeding the 100MB APK limit that appears to be a blocker for the organisations I've worked with quite often. Leveraging AABs with Android Enterprise # In enterprise scenarios, Android App Bundles enable organisations to deliver tailored application experiences by dynamically serving device-specific features, languages, and resources as needed. This customisation simplifies version management, reduces deployment overhead, and leads to streamlined app lifecycle management, significantly improving end-user experiences. For organisations operating under tight data budgets, the optimised app sizes alone can justify migrating to the AAB format due to significantly reduced download sizes and improved efficiency. Enough talk, AABs in action # For the context of this article, I opted to take an existing APK and convert it to AAB. There are two reasons for this: It seemed like the more complex approach, so makes for more interesting reading. Google hadn't yet turned on AAB uploads for new private apps from the iFrame for my enterprises. General availability update I have added the experience for new AAB uploads towards the end. Here's where we start; I have a private application uploaded as an APK: Clicking into the application, I can select Advanced editing options to head to the Google Play Console: I can then head into the application, click Test and release > Production and create a new release. All so far, so normal. Other tracks are available if Production isn't desired. On any other day, if I were to manage an app update from within the Play Console - which is a perfectly valid approach for organisations with advanced knowledge of developing and distributing applications - I would upload an APK via the upload link. We're not here for APKs though. To go further, I need to enrol into Play app signing. Enrol into Play app signing # Play app signing is a requirement for AABs, as Google needs to be able to sign generated APKs on behalf of the organisation when distributing them to devices. I'm clicking Use Play app signing to continue: For organisations/developers using a Java KeyStore to facilitate application signing, either via Android Studio or otherwise, this next step offers a guide for extracting the private key from it to allow Google to manage it. I'm using Android Studio and want to upload the key I used to originally sign the APKs, so that's what I'm configuring here: Give Google our keys!? This is down to the organisation and/or the personal views of the developer. I can appreciate this isn't a desirable choice for some, and that's OK. Google offers alternatives for setup, including dual-releases, but you can stop here and return to APK management if desired. If you're on the fence, pros and cons: Pros: Simplified key management: Google securely stores and manages your app signing keys, reducing the complexity and risk of losing keys. They're stored securely: Google uses strong cryptographic security standards to store keys securely, minimising potential breaches or key leaks. Easy key recovery: In case of compromised or lost upload keys, Google provides a straightforward and secure method for recovery without losing your app’s listing and user base. General availability update According to App bundle FAQs, key recovery is not supported for iFrame-uploaded applications at this time, which is a significant omission to the benefits of AAB. Instead, for this feature, a full developer account is required. Optimised distribution: Google Play can leverage advanced features like dynamic feature modules and optimised delivery because they control the final signing process. Cons: Loss of direct control: You relinquish direct control over your signing keys to Google, leaving your app's distribution and security dependent on Google's practices and infrastructure (via Play). Dependence on Google: You'll require careful planning if you choose to distribute your app via alternative channels (non-Play) to ensure friction points are minimised. Security concerns: Organisations with strict security or compliance policies might find Google's key management approach incompatible with their internal security practices. Ultimately, whether Google Play App Signing is suitable depends on your organisation’s requirements for security, flexibility, compliance, and control. That isn't a finite list, and I'm also not an expert, so feel free to read more into this through other sources. Still here? Let's continue! The script in the above image is: java -jar pepk.jar --keystore=foo.keystore --alias=foo --output=encrypted_private_key_path --rsa-aes-encryption --encryption-key-path=/path/to/encryption_public_key.pem Note: The KeyStore and alias - if you're unfamiliar - should match what's shown in Android Studio when prompted during the building of a signed application. If you know what you're doing, do your thing. Once the private key .PEM file is output, it can be uploaded to Google via Upload private key: After which I'm then prompted to agree to Play app signing terms. I glanced at it for a good 15 seconds. And we're enrolled: Upload the AAB # There are two ways to now get the AAB up, via console and via iFrame. To ensure it works as I'd expect it to, I opted first to test it in the console where I am confident AAB uploads would be supported. Not least because there's a draft release still pending. I headed back to Test and release > Production, and clicked the Releases tab, allowing me to Edit release: As now pictured, Releases signed by Google Play is showing, so I'm good to select and upload an AAB in the upload area below: If you scroll up, you'll note the version in the managed Play iFrame was on version 1.0, and the console here is now showing version 2 (1.1). I carried on through the process, paying attention to any damning errors, warnings, and messages (the Play Console is missing an Oxford comma, there). I chose to ignore two warnings about obfuscation and a government declaration, because I haven't needed to worry about them in the iFrame. I'll update here if that becomes a problem later: Send the change(s) for review.. ..and voilà! 8 nail-biting minutes later, the iFrame also updated to the latest build. And finally, it pushed to my test device nice and quickly, no fuss at all. Note the size difference between versions below. All I did was bump the version in build.gradle and build an AAB rather than an APK for the newer version! Note: I'm aware this is not the same device, their version sizes matched on 1.0, though. Updating from the iFrame # While in the iFrame, I'd be remiss if I didn't test it here also. It's literally a case of editing the app as normal, and just selecting the AAB instead: Done. Upload a new AAB from the iFrame # With AAB support fully rolled-out, testing AAB uploads via the iFrame directly turned out to be a lot simpler. First, I add a new app: Then, I upload my AAB and accept the terms. I definitely read these again. Create! And as quickly as that, my AAB is uploaded: What needs work? # General availability update The first two of the following issues are resolved, as noted by the demonstration of uploading a new AAB added above. Feel free to skip to key management. While in the iFrame, I'd be remiss if I didn't test it here also. Here's one of a few snags with the process currently, which I'll state after the image: Did you see it? It still references APK file, but it does in fact allow the upload of an AAB. Luckily the file extension is conveniently left in place (thanks, Google!) so you can see it is, indeed, an AAB. Based on Google's help doc, what we can expect to see, at some point, is a more generic label replacing APK file: One of the other snags that currently exists is the inability to upload an AAB as a new application from the iFrame, even having followed Google's guidance in enabling Play app signing. The upload allows the selection of an AAB, but the submit button remains greyed out. I went into browser tools and manually enabled the button, only to be met with another error: Key management # It's worth pointing out when doing AAB uploads from the iFrame, Google will generate the key: Note: Private apps that are created for the first time by uploading an AAB to the iframe will use a Google-generated app signing key. Use one of the options below to use your own signing key: Use the Play Console to create the private app with an AAB Use the iframe to create the private app with an APK then switch to AAB. Tying back to the callout above, if you have desires to use your own key with all uploaded apps, follow their advice and use the console with a full developer account to upload a new application. Finally, and hopefully another symptom of this not yet being fully rolled out, is the lack of permissions for key management: General availability update Unfortunately this won't change. Google have, as above, limited the options admins have for key management with iFrame-uploaded AABs. It's too bad, as it looks like the below concern has been further validated once again. It's an ongoing frustration generally, actually; permissions are overly restrictive across the portal due to the unique way Android Enterprise app management is set up. I'd like to be able to have my delegated accounts (i.e. [email protected], not the Google service account) act like an admin when it is granted admin permissions: create apps here, rotate keys in this instance, and so on. I haven't been able to get that working as yet. In summary # Google's move toward supporting Android App Bundles for private app distribution in the managed Google Play iFrame is well overdue, but great to see. While clearly still in the rollout phase, early exploration shows what's already possible and highlights some areas needing further refinement. For organisations ready to embrace smaller app sizes, streamlined deployments, and more flexible/redundant key management, the transition from APK to AAB is worth considering, at least when it becomes fully available; full support within the iFrame will undoubtedly make this process smoother and more broadly accessible in the near future. As always, plan your strategy carefully - particularly around key management and app distribution - to align with your organisation's security, compliance, and operational requirements.

The Android App Bundle (AAB) is a modern application packaging format introduced by Google to streamline and optimise Android app distribution. Unlike the traditional APK, an AAB contains all the necessary compiled code, resources, and assets for an app only for the purpose of permitting dynamic packaging; it cannot be directly installed through Android's package manager on-device (3rd party options exist though!). Instead, it is uploaded to Google Play, which dynamically processes & bundles the respective code into highly-optimised APKs specific to the device(s) downloading the app. The AAB format has been available to Android developers since 2018, and mandatory for new app uploads from the Google Play console since 2021. The Google Play iFrame, used by enterprises for private app distribution, has however historically mandated APK uploads. Based on a recently-updated help doc, support for AAB in enterprise scenarios appears to be now possible, although it doesn't seem fully rolled out yet. It's live! Not a day or so after this article went up, Google announced general availability, including answering some questions and touching on scenarios raised below. I'll dot additional thoughts in callouts like this one where relevant with updated data. All the same, I spent some time figuring out what's possible so you don't have to! How AAB and APKs differ # First thing's first, is this a pitch to organisations to immediately push all private applications over to AAB? No. There are valid use cases for both, which presumably (in addition to understanding the effort it may take organisations to convert over) is why Google will continue supporting APKs in the iFrame. That said, here's a brief overview of each. APKs # An APK is a single package file containing all the resources, assets, and compiled code for all supported device configurations. While this offers the greatest compatibility across a device estate, it means APK files are often larger than necessary as they include resources irrelevant to the downloading device. APKs offer simplicity and convenience for developers who want a quick, straightforward way to package and share their applications. They ensure broad compatibility across all Android devices without additional processing or conversion. Additionally, APKs support offline installation, making them ideal for environments with limited or no connectivity. Their self-contained nature enables immediate deployment and rapid testing, which accelerates development and iteration cycles. Furthermore, APKs provide flexibility by allowing distribution through various channels beyond Google Play, including alternative app stores or direct downloads. Finally, because APKs don't rely on Google Play explicitly, they're suitable for devices lacking Google Play access, or regions where it isn't available. That covers everything from deployment to devices in restricted countries such as China, to closed-network environments without direct access to Google Play. AOSP is a consideration also, but there's a lot more to managing AOSP that I won't dive into here. Android App Bundles (AAB) # Like an APK, an AAB is a publishing format containing all the necessary components in a single file, the difference is in the processes that occur after uploading to Google Play, as I opened with above. As well as significantly reducing app sizes through dynamically generated, optimised APKs tailored to each user's device, AABs also support dynamic delivery of features and resources, enabling efficient feature rollouts and resource management. Release management is also simplified, as developers maintain only a single upload file, eliminating the need to manually handle multiple APK variants for different architectures or feature sets. Additionally, AAB leverages App Signing by Google Play, centralising key management, potentially increasing security, and simplifying key recovery - particularly sometimes beneficial in organisations who have struggled with key storage and management in the past. Finally, AABs allow for larger uploads to Google Play, exceeding the 100MB APK limit that appears to be a blocker for the organisations I've worked with quite often. Leveraging AABs with Android Enterprise # In enterprise scenarios, Android App Bundles enable organisations to deliver tailored application experiences by dynamically serving device-specific features, languages, and resources as needed. This customisation simplifies version management, reduces deployment overhead, and leads to streamlined app lifecycle management, significantly improving end-user experiences. For organisations operating under tight data budgets, the optimised app sizes alone can justify migrating to the AAB format due to significantly reduced download sizes and improved efficiency. Enough talk, AABs in action # For the context of this article, I opted to take an existing APK and convert it to AAB. There are two reasons for this: It seemed like the more complex approach, so makes for more interesting reading. Google hadn't yet turned on AAB uploads for new private apps from the iFrame for my enterprises. General availability update I have added the experience for new AAB uploads towards the end. Here's where we start; I have a private application uploaded as an APK: Clicking into the application, I can select Advanced editing options to head to the Google Play Console: I can then head into the application, click Test and release > Production and create a new release. All so far, so normal. Other tracks are available if Production isn't desired. On any other day, if I were to manage an app update from within the Play Console - which is a perfectly valid approach for organisations with advanced knowledge of developing and distributing applications - I would upload an APK via the upload link. We're not here for APKs though. To go further, I need to enrol into Play app signing. Enrol into Play app signing # Play app signing is a requirement for AABs, as Google needs to be able to sign generated APKs on behalf of the organisation when distributing them to devices. I'm clicking Use Play app signing to continue: For organisations/developers using a Java KeyStore to facilitate application signing, either via Android Studio or otherwise, this next step offers a guide for extracting the private key from it to allow Google to manage it. I'm using Android Studio and want to upload the key I used to originally sign the APKs, so that's what I'm configuring here: Give Google our keys!? This is down to the organisation and/or the personal views of the developer. I can appreciate this isn't a desirable choice for some, and that's OK. Google offers alternatives for setup, including dual-releases, but you can stop here and return to APK management if desired. If you're on the fence, pros and cons: Pros: Simplified key management: Google securely stores and manages your app signing keys, reducing the complexity and risk of losing keys. They're stored securely: Google uses strong cryptographic security standards to store keys securely, minimising potential breaches or key leaks. Easy key recovery: In case of compromised or lost upload keys, Google provides a straightforward and secure method for recovery without losing your app’s listing and user base. General availability update According to App bundle FAQs, key recovery is not supported for iFrame-uploaded applications at this time, which is a significant omission to the benefits of AAB. Instead, for this feature, a full developer account is required. Optimised distribution: Google Play can leverage advanced features like dynamic feature modules and optimised delivery because they control the final signing process. Cons: Loss of direct control: You relinquish direct control over your signing keys to Google, leaving your app's distribution and security dependent on Google's practices and infrastructure (via Play). Dependence on Google: You'll require careful planning if you choose to distribute your app via alternative channels (non-Play) to ensure friction points are minimised. Security concerns: Organisations with strict security or compliance policies might find Google's key management approach incompatible with their internal security practices. Ultimately, whether Google Play App Signing is suitable depends on your organisation’s requirements for security, flexibility, compliance, and control. That isn't a finite list, and I'm also not an expert, so feel free to read more into this through other sources. Still here? Let's continue! The script in the above image is: java -jar pepk.jar --keystore=foo.keystore --alias=foo --output=encrypted_private_key_path --rsa-aes-encryption --encryption-key-path=/path/to/encryption_public_key.pem Note: The KeyStore and alias - if you're unfamiliar - should match what's shown in Android Studio when prompted during the building of a signed application. If you know what you're doing, do your thing. Once the private key .PEM file is output, it can be uploaded to Google via Upload private key: After which I'm then prompted to agree to Play app signing terms. I glanced at it for a good 15 seconds. And we're enrolled: Upload the AAB # There are two ways to now get the AAB up, via console and via iFrame. To ensure it works as I'd expect it to, I opted first to test it in the console where I am confident AAB uploads would be supported. Not least because there's a draft release still pending. I headed back to Test and release > Production, and clicked the Releases tab, allowing me to Edit release: As now pictured, Releases signed by Google Play is showing, so I'm good to select and upload an AAB in the upload area below: If you scroll up, you'll note the version in the managed Play iFrame was on version 1.0, and the console here is now showing version 2 (1.1). I carried on through the process, paying attention to any damning errors, warnings, and messages (the Play Console is missing an Oxford comma, there). I chose to ignore two warnings about obfuscation and a government declaration, because I haven't needed to worry about them in the iFrame. I'll update here if that becomes a problem later: Send the change(s) for review.. ..and voilà! 8 nail-biting minutes later, the iFrame also updated to the latest build. And finally, it pushed to my test device nice and quickly, no fuss at all. Note the size difference between versions below. All I did was bump the version in build.gradle and build an AAB rather than an APK for the newer version! Note: I'm aware this is not the same device, their version sizes matched on 1.0, though. Updating from the iFrame # While in the iFrame, I'd be remiss if I didn't test it here also. It's literally a case of editing the app as normal, and just selecting the AAB instead: Done. Upload a new AAB from the iFrame # With AAB support fully rolled-out, testing AAB uploads via the iFrame directly turned out to be a lot simpler. First, I add a new app: Then, I upload my AAB and accept the terms. I definitely read these again. Create! And as quickly as that, my AAB is uploaded: What needs work? # General availability update The first two of the following issues are resolved, as noted by the demonstration of uploading a new AAB added above. Feel free to skip to key management. While in the iFrame, I'd be remiss if I didn't test it here also. Here's one of a few snags with the process currently, which I'll state after the image: Did you see it? It still references APK file, but it does in fact allow the upload of an AAB. Luckily the file extension is conveniently left in place (thanks, Google!) so you can see it is, indeed, an AAB. Based on Google's help doc, what we can expect to see, at some point, is a more generic label replacing APK file: One of the other snags that currently exists is the inability to upload an AAB as a new application from the iFrame, even having followed Google's guidance in enabling Play app signing. The upload allows the selection of an AAB, but the submit button remains greyed out. I went into browser tools and manually enabled the button, only to be met with another error: Key management # It's worth pointing out when doing AAB uploads from the iFrame, Google will generate the key: Note: Private apps that are created for the first time by uploading an AAB to the iframe will use a Google-generated app signing key. Use one of the options below to use your own signing key: Use the Play Console to create the private app with an AAB Use the iframe to create the private app with an APK then switch to AAB. Tying back to the callout above, if you have desires to use your own key with all uploaded apps, follow their advice and use the console with a full developer account to upload a new application. Finally, and hopefully another symptom of this not yet being fully rolled out, is the lack of permissions for key management: General availability update Unfortunately this won't change. Google have, as above, limited the options admins have for key management with iFrame-uploaded AABs. It's too bad, as it looks like the below concern has been further validated once again. It's an ongoing frustration generally, actually; permissions are overly restrictive across the portal due to the unique way Android Enterprise app management is set up. I'd like to be able to have my delegated accounts (i.e. [email protected], not the Google service account) act like an admin when it is granted admin permissions: create apps here, rotate keys in this instance, and so on. I haven't been able to get that working as yet. In summary # Google's move toward supporting Android App Bundles for private app distribution in the managed Google Play iFrame is well overdue, but great to see. While clearly still in the rollout phase, early exploration shows what's already possible and highlights some areas needing further refinement. For organisations ready to embrace smaller app sizes, streamlined deployments, and more flexible/redundant key management, the transition from APK to AAB is worth considering, at least when it becomes fully available; full support within the iFrame will undoubtedly make this process smoother and more broadly accessible in the near future. As always, plan your strategy carefully - particularly around key management and app distribution - to align with your organisation's security, compliance, and operational requirements.

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! No bump to minimum SDK version for installation of apps # 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" 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 an older 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. App functions control # Not too much research has been done 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 currently be disabled outright, and disabled cross-profile. I'm hopeful we'll see this ecpand to follow Credential Manager and Widget APIs that allow a block with package exclusions for greater control. We'll see. Disallow NFC radio # 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. As of this release it's now officially showing up as a Baklava feature. Disallow Thread Network # Here's another previously-referenced feature to show up confirmed for Baklava. 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. Automatic time & automatic time zone policies # New in 16 as of (around) beta 3 are two new policies, automatic time and automatic time zone. Both of these APIs have existed since Android 11 with setAutoTimeEnabled and setAutoTimeZoneEnabled respectively, and even prior to 11 there were APIs that influenced time and time zone settings. There's currently no justification documented for revamping these again, and I don't want to speculate, but as and when more information is shared I will update here. That's not all folks! # 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!