Google has released new AndroidX Security State libraries that give Android developers and enterprise management tools a more granular way to determine whether a device is protected against known vulnerabilities and whether security updates are waiting to be installed.
The stable release includes AndroidX Security State 1.1.0 and Security State Provider 1.0.0, introducing standardized APIs for assessing security at the individual component level instead of relying primarily on Android’s traditional device-wide Security Patch Level.
The change reflects how Android security updates have evolved. Security fixes can now reach devices through several channels, including manufacturer OTA updates and modular Google Play system updates, meaning a single patch date does not necessarily describe the security state of every component on a device.
Google’s new libraries address that by exposing three separate security patch levels: Device SPL (DSPL), Published SPL (PSPL) and Available SPL (ASPL).
DSPL represents the security patch level currently installed and running on a device. Apps can retrieve this information from device properties and configurations without making a network request.
PSPL represents the latest officially published security patch level for a component based on the Android Security Bulletin.
ASPL provides a third piece of information: the security update currently available to download and install on that specific device. It is retrieved asynchronously from on-device update clients using inter-process communication.
Together, the three measurements allow an app to determine not only whether a device is behind the latest published security level, but also whether an applicable update is already available to resolve the difference.
Google is applying the model across three areas of Android: the core system, system modules and kernel.
System security state covers the main Android operating system and updates delivered through conventional manufacturer OTA mechanisms. System modules cover modular parts of Android that can receive updates through Google Play system updates under Project Mainline.
Kernel security is handled differently. Rather than using monthly security patch dates, the library evaluates Android kernel security using Long-Term Support release versions, such as 5.15.159 or 6.1.91.
The additional visibility is intended particularly for apps handling sensitive workflows, including banking, fintech and healthcare services, as well as Mobile Device Management platforms.
For example, a banking app could check a device’s installed security state before allowing a high-value transaction. If the device is behind but ASPL indicates that a relevant update is already available, the app could direct the user to install the update before continuing.
Enterprise apps could apply a similar approach to credential enrollment, access to corporate resources or biometric authentication.
The framework is designed to enable more contextual decisions instead of simply treating every device below a particular patch date as equally insecure.
Apps can perform synchronous DSPL checks when they launch and compare installed component versions against published security information. Enterprise administrators could use those results to determine whether a device meets an organization’s security baseline before providing access to sensitive resources.
ASPL can then provide information about pending remediation. Rather than immediately blocking a user whose device is behind, an app can determine whether a system or Google Play system update is already staged or available and provide instructions for completing it.
The libraries also extend security checks to individual vulnerabilities.
Developers can obtain device-specific vulnerability information using data from the Open Source Vulnerabilities database, allowing applications to determine whether particular Common Vulnerabilities and Exposures, or CVEs, have been addressed.
Google gives NFC and Bluetooth vulnerabilities as examples. An app handling a sensitive proximity-based workflow could verify whether specific high-risk fixes have been applied before enabling functionality such as tap-to-pay or nearby data sharing.
The companion Security State Provider library addresses the other side of the system: Android manufacturers and update clients.
It creates a standardized Android IPC mechanism through which update clients can report available security updates. Previously, proprietary OTA applications could know that an update was available without making that information accessible in a consistent way to third-party apps.
With the new framework, apps can retrieve ASPL information through a unified API regardless of whether an update is being delivered through Google Play or an OEM update system, provided the relevant update client supports the framework.
Google says Google Play system updates already expose ASPL on Android devices with Google Mobile Services, while Google Over-The-Air has also been integrated. The company is working with Android manufacturers to bring additional OTA clients into the system.
The libraries also account for cases where a device is effectively protected even though its visible patch level may suggest otherwise.
If a monthly security update does not contain any new vulnerabilities affecting a particular component, the framework can automatically advance that component’s effective security level. This is intended to prevent devices from appearing outdated when there are no additional relevant fixes for that component.
Android 17 adds another mechanism for manufacturers through Supplemental Patches XML.
Manufacturers can use the file to declare individual security fixes that have been backported to a device above its stated Security Patch Level. The Security State libraries can expose those fixes to apps and services without requiring manufacturers to wait for a broader patch-level update.
That could be particularly relevant for manufacturers that backport critical vulnerability fixes independently of their normal monthly or quarterly update cycle.
For developers, the result is a shift from asking whether an Android device has a sufficiently recent patch date to evaluating which components are actually protected, what vulnerabilities have been fixed and whether additional updates are currently available.
The distinction becomes increasingly important as Android security updates are distributed through multiple independent mechanisms.
Rather than replacing Android’s existing security update infrastructure, the AndroidX Security State libraries provide a standardized layer through which apps, enterprise tools, OEMs and update clients can interpret that infrastructure.
For security-sensitive Android apps, that could enable access and authentication policies based on the device’s actual component-level patch state instead of a single system-wide date.
Comments
Loading…