BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Google's Android Security State Libraries Enable Component-Level Security Verification

Google's Android Security State Libraries Enable Component-Level Security Verification

Listen to this article -  0:00

Google's AndroidX Security State libraries enables apps to verify security patch status at the individual component level, rather than relying on a single, device-wide security patch date.

With the introduction of the AndroidX Security State and Security State Provider libraries, Google provides a centralized mechanism for assessing Android device security, enabling more granular verification and greater flexibility.

Whether you develop security-critical, consumer-facing apps (such as banking, fintech, or healthcare) or Mobile Device Management (MDM) solutions, these libraries enable you to programmatically verify the security state of the device per component.

The Security Patch Level (SPL) is a monolithic patch number that encompasses the entire system software stack running on an Android device. The new mechanism enables component-level security verification and provides more precise visibility into available remediations.

The Security State library defines three distinct patch levels: Device SPL, Published SPL, and Available SPL. The Device SPL is queried directly from the running system without requiring network access and indicated the security patch level currently installed. The Published SPL represents the latest patch level officially published by Google for a given component. The Available SPL identifies the patch level that is available for download and installation on the specific device.

At the component level, the Security State library distinguishes among the core Android OS (system), OS subsystems updated via Google Play (system modules), and kernel.

By surfacing these three distinct patch levels at the component level, developers and enterprises can now understand exactly how secure a device is, identify missing patches, and take proactive remediation steps.

For example, banking and enterprise apps can use Device and Available SPLs to ensure a device is secure before allowing sensitive actions. Rather than simply rejecting a request, they can require users to install specific OS component updates first. Developers can also check for the patch status of specific CVEs before allowing security-sensitive operations using a certain hardware o software component (.e.g. NFC or Bluetooth).

The library provides a queryAllAvailableUpdates() function as well as a fetchAvailableSecurityPatchLevel() which aggregates data retrieved from current device to discover pending security updates across system components.

The areCvesPatched() functions checks whether specific CVEs have been patched on the device, while isDeviceFullyUpdated() helps determine whether a device has installed all available security patches.

Finally, the createVulnerabilityReportUrl() generates standardized URLs for security bulletins and CVE details.

The Security State Provider library is a companion library specifically for OEMs that standardizes how update clients tell Android apps that an update is available. This means that an app doesn't have to know whether an update comes from Google Play, Google's OTA client, or an OEM's proprietary OEM client.

The Understanding device security state guide provides all required information for developers to start using real-time, component-level patch information to better protect their users.

About the Author

Rate this Article

Adoption
Style

BT