Supplemental security patches

With Android's shift toward continuous release and quarterly bulletins as part of risk-based security updates, OEMs may want to fix vulnerabilities between releases rather than waiting an entire quarter. The supplemental security patch XML feature lets OEMs report CVEs patched beyond the declared security patch level (SPL) by providing a standardized XML file, so OEMs receive credit for continuous patching.

Note: Using these XML files is optional. You need them only if you want to report a patched state for a CVE beyond the declared SPL.

High level flow

Figure 1. Supplemental security patches architecture and data flow.

OEMs can place the XML file across multiple device partitions (/system, /vendor, or /product), ensuring that security patches from both the framework and hardware-specific components are accounted for. The XML file should be installed in /etc/security/supplemental_security_patches.xml for the respective partition.

The platform aggregates CVE data across these device partitions and exposes them in platform APIs and Jetpack libraries. For details, see Platform API Android 17 and higher and Backport to lower Android versions.

The following example shows a sample supplemental security patch XML file installed on an Android-powered device:

<?xml version="1.0" encoding="utf-8"?>
<security-patches xmlns="http://schemas.android.com/security/patches/1.0">
    <patch><id>CVE-2026-12345</id></patch>
</security-patches>

Platform API (Android 17 and higher)

For Android 17 (API level 37) and higher, the platform's SecurityStateManager handles parsing the supplemental patches from all supported partition locations and exposes them in the returned Bundle from getGlobalSecurityState using the keys KEY_SYSTEM_SUPPLEMENTAL_PATCHES and KEY_VENDOR_SUPPLEMENTAL_PATCHES.

The system service SecurityStateManagerService aggregates partition XML files into these two umbrella reporting buckets:

• KEY_SYSTEM_SUPPLEMENTAL_PATCHES: Aggregates patches from /system, /system_ext, and /product partition paths.
• KEY_VENDOR_SUPPLEMENTAL_PATCHES: Aggregates patches from /vendor and /odm partition paths.

Backport to lower Android versions

For Android 16 and lower, there is no platform API support. Instead, the Jetpack androidx.security:security-state library (SecurityStateManagerCompat) manually reads the XML files using XmlPullParser. To allow the untrusted_app domain to read the files on Android 16 and lower, OEMs must implement the following SELinux changes across all partition paths where the XML file is installed:

file_contexts:

/(system|vendor|product|system_ext|odm)/etc/security/supplemental_security_patches\.xml u:object_r:supplemental_security_patches:s0

supplemental_security_patches.te:

allow untrusted_app supplemental_security_patches:file { getattr open read };

Build rules and schema validation

To install the supplemental patch XML file to /vendor/etc/security/, /system/etc/security/, or /product/etc/security/, add a prebuilt_etc rule in Android.bp. Because SecurityStateManagerService expects the file on the device to be named exactly supplemental_security_patches.xml, use the filename property when using partition-specific module names:

// For vendor partition (/vendor/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "vendor_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
    vendor: true,
}
// For system partition (/system/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "system_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
}
// For product partition (/product/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "product_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
    product_specific: true,
}

The Android Open Source Project (AOSP) includes the XSD schema in supplemental_security_patches.xsd and validates the XML file format during the build process using the xsdc build rule in Android.bp:

xsdc {
    name: "supplemental_security_patches_xsd",
    srcs: ["supplemental_security_patches/supplemental_security_patches.xsd"],
    package_name: "android.security.patches", // Java package name for generated code
}

You can also validate your XML file locally against the XSD schema using xmllint:

xmllint --schema frameworks/base/services/core/xsd/supplemental_security_patches/supplemental_security_patches.xsd --noout supplemental_security_patches.xml

Test and suite integration

The Security Test Suite (STS) and Firmware Analysis (BTS) use the data from the supplemental_security_patches.xml file to extend patch analysis for vulnerabilities present in the XML file. So apart from reflecting the device's security state, integrating this file correctly lets OEMs perform proactive patch analysis on vulnerabilities patched above the device's SPL instead of waiting for the quarterly SPL to be officially declared.