Android Release History: Security Features From Android 10 to 16

Android shipped seven platform releases from Android 10 (API level 29, September 2019) to Android 16 (API level 36, June 2025), plus 12L and the Android 16 QPR2 minor SDK release, and each one tightened a default. Android 10 brought scoped storage and Project Mainline. Android 11 added one-time permissions. Android 12 added Private Compute Core and a privacy dashboard. Android 13 added the photo picker. Android 14 added Credential Manager and blocked very old apps. Android 15 added Private Space and theft protection. Android 16 added Advanced Protection Mode.

As of 23 October 2026, the October 2026 Android Security Bulletin lists fixes for Android 14, 15, 16, 16 QPR2 and 17 only. Android 13 and older no longer appear in the bulletin's AOSP version columns, and Google's Mainline documentation says Mainline support for Android 11 and lower ended in the fourth quarter of 2025. A phone on Android 13 or earlier is no longer receiving platform fixes through the public bulletin, whatever its settings screen says.

Key takeaways

• Two clocks run on every Android phone. The Android security patch level (set by the device maker's firmware) and the Google Play system update date (Mainline modules from Google). They move independently, and you need both to know where a device stands.
• Each bulletin has two patch levels. The -01 level covers fixes common to all Android devices; the -05 level adds kernel and chipset fixes. A device reporting -05 must include everything in -01 plus all earlier bulletins.
• Bulletin coverage is roughly three and a half years per version in practice. Android 10 last appears in the February 2023 bulletin, Android 11 in February 2024, Android 12 and 12L in March 2025, and Android 13 in December 2025. That is an observed pattern from the bulletins, not a published guarantee.
• Mainline moved key security components out of the OS release cycle. Conscrypt (TLS), the DNS resolver, media codecs, Bluetooth, Wi-Fi, ART and more can be patched through Google Play system updates on Android 10 and later, without waiting for the device maker.
• Most privacy changes bite through target API levels. Exported components, pending intent mutability, foreground service types, TLS 1.0 and 1.1 removal and stricter intent matching only apply when an app targets the new API level. Google Play's target API rule is what forces the move.
• Android 16 changed the calendar. The major release moved to the second quarter, a fourth quarter minor SDK release (API 36.1) added APIs without behavior changes, and from 2026 Google publishes AOSP source only in Q2 and Q4.
• The EU now sets a floor. Smartphones placed on the EU market from 20 June 2025 must keep getting any operating system updates the maker provides for at least five years after the last unit of that model is sold.
• You can verify all of this in two minutes with adb shell getprop and the Settings app, as shown in the walkthrough below.

This post goes one level deeper than our earlier Android posts. For the boot chain that protects the system partition these releases ship in, see Android Verified Boot and the chain of trust. For how Android's update model compares with the other big phone platform, see iPhone vs Samsung Galaxy security compared. For what the cellular network itself protects, see the 5G security architecture explained.

Android versions from 10 to 16: API levels, dates and bulletin coverage

The authoritative list of Android version numbers and API levels is the AOSP page Codenames, tags, and build numbers. It also lists a "quarterly release name" for the newest releases: 24Q3 for Android 15, 25Q2 for Android 16, 25Q4 for Android 16 QPR2 (API level 36.1) and 26Q2 for Android 17 (API level 37).

Release dates come from Google's announcements on the Android Developers Blog where we could fetch them: Android 12 was pushed to AOSP on 4 October 2021, Android 13 on 15 August 2022, Android 14 on 4 October 2023, Android 15 on 3 September 2024 and Android 16 started rolling out to Pixel on 10 June 2025. For Android 10 and 11 we use the month of the first AOSP release tag (android-10.0.0_r1 and android-11.0.0_r1), whose security patch levels are 2019-09-05 and 2020-09-05.

The last column is not a published support policy. Google does not state an end date per version in the bulletin. Instead, each bulletin's vulnerability tables have an "Updated AOSP versions" column, and a version that stops appearing there has stopped receiving AOSP platform patches through the public bulletin. We read the column in each bulletin to find the last month each version appeared.

Timeline table

Three details in that table are easy to miss:

• 12L shared Android 12's lifetime. It was listed alongside 12 in every bulletin we checked and dropped out at the same time, after the March 2025 bulletin.
• The gap between "released" and "dropped" has been close to three and a half years for 10, 11, 12 and 13. Android 10 ran from September 2019 to February 2023 in the bulletin; Android 13 ran from August 2022 to December 2025. Device makers can and do ship patches longer than that for their own devices, but those patches are their own backports, not AOSP bulletin fixes.
• Not every month has platform fixes. The February 2026 bulletin states plainly that there are no security vulnerabilities in it, and the January 2026 bulletin lists a single partner component issue. You cannot infer a version's support status from a single quiet month. Look across several bulletins.

What 12L, QPR and quarterly release names mean

12L (API level 32) was a feature drop for large screens and foldables. It carried its own API level because it added APIs, but security fixes were shipped in lockstep with Android 12.

QPR stands for quarterly platform release. Google has shipped QPRs to Pixel for years, but Android 16 QPR2 was the first one with its own API level (36.1) published to developers as a "minor SDK release". The Android 16 features page explains the plan: the Q2 major release is the only release in the year with planned behavior changes that could affect apps; the Q4 minor release adds APIs, features, optimizations and fixes but "will not include any app-impacting behavior changes"; Q1 and Q3 updates are incremental quality releases. In the bulletin, that shows up as a separate "16-qpr2" entry in the version column, which means the QPR2 branch is patched in parallel with the original Android 16 branch.

How Project Mainline and APEX changed how fixes reach phones

Before Android 10, a fix to almost any platform component had to travel through the device maker. Google published the patch, the chipset vendor and the device maker integrated it, the carrier certified it in some markets, and the user received a full over the air (OTA) system update. Every hop added weeks or months, and many devices never got the update at all.

Mainline, introduced in Android 10, changed that for a defined set of components. Google's documentation describes it as modularizing "some Android system components" so they can be updated outside the normal release cycle. End user devices receive Mainline updates through the Google Play system update feature, which runs on Play Store infrastructure, or through a partner's own OTA mechanism.

What is inside Mainline

The AOSP module table lists each module, its format and the release that introduced it. The security relevant ones include:

Two rules in the documentation explain why Mainline updates are safe to push broadly. Module updates "don't introduce new APIs" and use only CTS guaranteed SDK and system APIs or stable C and AIDL interfaces, so they cannot break apps that rely on documented behavior. And a module package "installs and rolls back atomically": either every module in the train updates or none does.

What APEX is

Some modules are plain APKs. Most are APEX files, a container format introduced in Android 10 for components that load before the framework starts, such as native libraries and the runtime. An APEX file is a signed zip that contains apex_payload.img, an ext4 file system image backed by dm-verity. It is signed twice: the payload's vbmeta descriptor is signed with one key, and the whole file is signed with the APK signature scheme. The APEX manager verifies both before activating an update, and at boot the payload is mounted with dm-verity checking every block, the same mechanism that protects the system partition under Verified Boot.

On devices with Google Mobile Services, Mainline packages are signed by Google and named com.google.android.*; on devices signed with AOSP keys they are named com.android.*.

What Mainline does not cover

Mainline is not a full patch channel. The kernel, vendor drivers, chipset firmware, the bootloader, the modem and most of the framework still arrive through the device maker's OTA. Every bulletin has a short "Google Play system updates" section that lists which of its CVEs ship through Mainline. In the October 2026 bulletin that section lists a Telephony core issue and two Wi-Fi issues; every other fix in the bulletin needs a firmware update.

And Mainline has its own end date. The Mainline page now carries a note: "Mainline support for Android 11 and lower is concluded as of Q4 of 2025." A device frozen on Android 11 lost both its AOSP bulletin coverage (February 2024) and its Mainline updates (end of 2025).

How Android Security Bulletins and patch levels work

The Android Security Bulletins overview is the index. Bulletins are published on the first Monday of each month, or the next working day if that Monday is a holiday. Each one lists CVEs, the Android bug ID, the vulnerability type (RCE, EoP, ID, DoS), severity and the AOSP versions that received the fix. Google states in each bulletin that it notifies Android partners of all issues "at least a month before" publication.

The two patch level dates

Every recent bulletin answers the question "Why does this bulletin have two security patch levels?" in its FAQ. The answer: two levels give Android partners the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. In practice:

A device maker that ships the fixes sets the system property ro.build.version.security_patch to the matching string, for example [ro.build.version.security_patch]:[2026-10-01]. The bulletin also notes that for some devices on Android 10 or later, the Google Play system update "will have a date string that matches" the -01 level. That is why a phone can show a Google Play system update of September 2026 while its Android security update still reads June 2026: the two clocks are independent.

Where the fixes come from

The overview splits fixes into three sources:

1. Android platform fixes, from AOSP.
2. Upstream Linux kernel fixes, linked directly from the bulletin.
3. Fixes from SoC manufacturers, available from those manufacturers, often marked with an asterisk when the fix is not public.

The FAQ also explains why some issues appear only in device or partner bulletins (such as the Pixel Update Bulletin): issues in the Android Security Bulletin are required to declare the latest security patch level, while issues in partner bulletins are not.

The 2025 to 2026 change in how source lands in AOSP

Older bulletins promised that source patches would be released to AOSP within 48 hours of publication, and you can still see that wording in the October 2025 to February 2026 bulletins. The current overview says something different: Android platform security fixes are merged into AOSP 24 to 48 hours after the quarterly security bulletin is released, in March, June, September and December. The AOSP documentation banner adds that from 2026, Google publishes full source code to AOSP in Q2 and Q4 only, and that builders should use the android-latest-release manifest, which always references the most recent release (currently android17-release).

For device makers inside the partner program, nothing changes: they receive fixes ahead of publication. For anyone building from public AOSP (custom ROMs, research, some embedded products), the practical lag between a bulletin and public source can now be up to a quarter for platform fixes. We cover one example in detail in the October 2026 Android bulletin and AOSP's quarterly source cadence.

Security and privacy features in each Android version

The features below are taken from Google's own developer documentation and Android Help pages for each release. "All apps" means the change applies regardless of an app's target API level. "Targeting" means it applies only when an app's targetSdkVersion is at least that level.

Android 10 (API 29): scoped storage and Mainline

Android 10 is where the modern privacy model starts. From the Android 10 privacy changes:

• Scoped storage. Apps targeting Android 10 get scoped access to external storage by default: they see their own app specific directories and media they created, without broad storage permissions.
• Background location is a separate permission. Location access in the background requires its own grant.
• Background activity launch restrictions. Apps can no longer start activities while in the background, which removed a common way to hijack the screen.
• MAC address randomization on by default. The system transmits randomized MAC addresses by default when it connects to Wi-Fi.
• Non-resettable identifiers locked away. Reading IMEI and serial number needs READ_PRIVILEGED_PHONE_STATE, which Play installed apps cannot hold.
• Clipboard limited to the foreground app and the default input method, restricted access to /proc/net, and USB serial numbers protected.
• Project Mainline and APEX arrive, as covered above.

Android 11 (API 30): one-time permissions and enforced scoped storage

From the Android 11 permissions updates, storage updates and behavior changes for all apps:

• One-time permissions. Location, microphone and camera prompts gain an "Only this time" option.
• Auto-reset permissions. If an app targeting Android 11 is not used for a few months, the system resets its sensitive runtime permissions, as if the user had set each to Deny.
• Scoped storage enforced. The requestLegacyExternalStorage opt-out only works for apps that still target Android 10.
• Conscrypt is the default SSL engine for SSL sockets, and Scudo hardened allocator services heap allocations in native code to detect and mitigate some memory safety bugs.
• Heap pointer tagging on supported ARM64 devices (targeting).
• APK Signature Scheme v2 required for apps targeting Android 11: an app signed only with v1 cannot be installed or updated.

Android 12 (API 31): Private Compute Core, indicators and exported components

From the Android 12 features, behavior changes for all apps and behavior changes for apps targeting 12:

• Privacy Dashboard in Settings shows which apps used location, camera and microphone, with a timeline.
• Microphone and camera indicators and toggles. Supported devices show an indicator when an app uses either sensor, and Quick Settings toggles cut access for all apps.
• Approximate location. Users can grant approximate rather than precise location.
• Clipboard access notifications show a toast when an app reads clipboard data another app placed there.
• Untrusted touch events are blocked, which closes off a class of overlay "tapjacking" attacks.
• Safer component exporting (targeting): any activity, service or receiver with an intent filter must declare android:exported explicitly.
• Pending intent mutability (targeting): every PendingIntent must declare FLAG_MUTABLE or FLAG_IMMUTABLE.
• Private Compute Core. Google's security blog introduced it as an open source, isolated environment for on-device machine learning features such as Live Caption and Smart Reply. Features inside it have no direct network access; they reach the cloud only through Private Compute Services, whose source Google said it would publish for outside audit.
• ART becomes a Mainline module, so the runtime itself can now be patched through Google Play system updates.

Android 13 (API 33): the photo picker and notification consent

From the Android 13 features and behavior changes for all apps and apps targeting 13:

• Photo picker. Users choose specific photos and videos to share instead of granting access to the whole library. The photo picker documentation says it is available on Android 11 and later through Mainline updates, and that Google Play services can install a backported version on Android 4.4 through 10.
• Notification permission. POST_NOTIFICATIONS becomes a runtime permission for all apps.
• Granular media permissions (targeting): READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and READ_MEDIA_AUDIO replace broad storage reads.
• Nearby Wi-Fi devices permission (NEARBY_WIFI_DEVICES) separates Wi-Fi scanning from location.
• Safer context-registered receivers. Apps can mark runtime receivers as exported or not.
• Clipboard hides sensitive content in the preview, and shared user ID is deprecated for new apps.
• APK Signature Scheme v3.1 supports key rotation targeted to specific SDK versions.
• Bluetooth becomes a Mainline module.

Android 14 (API 34): Credential Manager and the minimum target floor

From the Android 14 features and behavior changes for all apps and apps targeting 14:

• Credential Manager becomes a platform API for passwords, passkeys and federated sign-in in one interface, with support back to Android 4.4 through a Jetpack library using Google Play services. See the Credential Manager guide.
• Minimum installable target API level. Apps with targetSdkVersion lower than 23 cannot be installed. Google's stated reason: malware often targets API 22 to avoid the runtime permission model introduced in Android 6.0.
• Selected Photos Access (targeting): users can grant access to specific photos instead of all media of a type.
• Foreground service types required (targeting): every foreground service must declare at least one type.
• Implicit intents only reach exported components (targeting), and creating a mutable pending intent without a component or package throws.
• Runtime receivers must declare export behavior with RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED (targeting).
• Safer dynamic code loading (targeting): dynamically loaded DEX and JAR files must be marked read only.
• Zip path traversal protection, per session consent for screen capture, tighter background activity launches, and exact alarms denied by default.
• Remote Key Provisioning becomes a Mainline module, so attestation key provisioning can be updated separately.

Android 15 (API 35): Private Space and theft protection

From the Android 15 features and behavior changes for all apps and apps targeting 15:

• Private Space. A separate user profile, under the device lock or a separate lock, whose apps are hidden from the launcher, recents, notifications and other apps while locked. Content and accounts are separated from the main space.
• TLS 1.0 and 1.1 disallowed for apps targeting Android 15.
• Secured background activity launches (targeting): pending intent creators block background activity launches by default, among other changes.
• Safer intents (targeting): first phase, focused on the sending app.
• OTP redaction. Untrusted notification listeners can no longer read unredacted content from notifications where a one-time password has been detected.
• Screenshare protection. Notification content is hidden during screen sharing sessions, and the public version of a notification is shown instead when the app provides one.
• Credential Manager integrates with autofill and biometric prompts for single tap sign-in and sign-up.
• Content URI permission checks and a key management API for end to end encryption.
• Theft protection. Android Help's theft protection page describes Theft Detection Lock (motion sensors and on-device signals lock the screen if the phone is snatched), Offline Device Lock, Failed Authentication Lock and Remote Lock. The page notes that some steps only work on Android 15 and up while others work on Android 10 and up, and the same page describes Identity Check, available on certain devices, which requires biometrics for sensitive actions such as changing biometrics or turning Identity Check off when the phone is outside designated trusted places, with no PIN fallback.
• 16 KB page size support for performance on new devices; our post on whether your app needs 16 KB page support covers the build side.

Android 16 (API 36): Advanced Protection and stricter intents

From the Android 16 features and behavior changes for all apps and apps targeting 16:

• Advanced Protection Mode (AAPM). The developer guide says AAPM "is a new feature launched in Android 16" for at-risk users such as journalists and activists. One setting turns on a fixed set of protections. The guide lists disabled 2G and WEP connections, blocked sideloading, active forensic logging, blocked calls from unknown numbers and spam protection for links in messaging apps. Apps can check the mode with the AdvancedProtectionManager service and harden themselves.
• Intent redirection hardening for all apps, plus strict intent matching as a receiving app opt-in through android:intentMatchingFlags="enforceIntentFilter".
• Local network permission (phased): access to devices on the LAN moves behind a runtime permission, rolled out between 25Q2 and 26Q2.
• MediaStore version lockdown (targeting): MediaStore#getVersion() becomes unique per app to stop fingerprinting.
• Certificate Transparency becomes available to apps through the network security configuration, off by default on Android 16. The network security config documentation shows the opt-in element.
• Key sharing API. KeyStoreManager lets apps grant and revoke access to Android Keystore keys by app UID.
• GPU syscall filtering on affected Pixel devices blocks deprecated and development-only GPU ioctls in production builds.

After 16: what Android 17 added

Android 17 (API level 37) shipped in the second quarter of 2026, and the October 2026 bulletin already patches it. Its features and behavior changes for apps targeting 17 continue the same direction: Certificate Transparency and Encrypted Client Hello on by default for apps targeting API 37, read only enforcement extended from DEX files to native libraries loaded with System.load(), local network permission enforced for apps targeting 17, OTP protection for standard SMS, a hybrid post-quantum APK signature scheme pairing a classical key with ML-DSA, and AAPM features exposed to developers. Android 17 also lists a plan to deprecate usesCleartextTraffic in favor of the network security configuration.

Feature by version comparison

"Introduced" marks the first release; later columns mean the feature remains. Backports through Google Play services or Mainline are why a few features appear on versions older than the one that introduced them in the platform.

What changed for app developers at each target API level

Most of the security value in the list above only applies once an app targets the new API level. That is deliberate: Google ships behavior changes behind targetSdkVersion so that old apps keep working, then uses Google Play's target API policy to move the ecosystem forward.

The developer checklist by target API

Our deeper posts cover two of these in detail: network security config defaults by API level and exported Android components (CWE-926).

Google Play's target API rule

The target API level requirements are what turn optional hardening into mandatory hardening. From 31 August 2026, new apps and app updates submitted to Google Play must target Android 16 (API level 36) or higher, with exceptions for Wear OS and Android Automotive OS (API 35) and Android TV and Android XR (API 34). Existing apps must target Android 15 (API 35) or higher to remain available to new users on devices running a newer Android version than the app targets. Developers can request an extension to 1 November 2026.

That means every app that ships an update to Play this autumn picks up all of the targeting changes through Android 16 at once, including strict intent rules, foreground service types and the TLS 1.0 and 1.1 removal. If your release train has been holding target API at 34, expect a cluster of behavior changes in a single upgrade.

How OEM update commitments differ, and what the EU now requires

Google's bulletin publishes fixes; device makers decide how long they ship them. Commitments vary by maker, by model tier and sometimes by region, so the only reliable source is the maker's own support page for the exact model.

Google's Pixel update page is a useful reference point because it is precise. Pixel 8 and later phones get seven years of OS and security updates, counted from when the device first became available on the Google Store in the US. Pixel 6, 6a, 7, 7a, 7 Pro, 6 Pro and Pixel Fold get five years from the same starting point. Other makers publish their own pages with their own terms, and some commit to a number of major OS upgrades separately from a number of years of security updates.

EU Regulation 2023/1670

The EU's ecodesign rules for smartphones and tablets, Commission Regulation (EU) 2023/1670, apply to smartphones, feature phones, cordless phones and slate tablets placed on the EU market from 20 June 2025. The European Commission's product page summarizes the update requirement as operating system upgrades "for at least 5 years from the date of the end of placement on the market of the last unit of a product model", next to spare parts availability for seven years after the end of sales.

The Commission's FAQ on Android updates adds the important nuance: if economic operators provide security, corrective or functionality updates to an operating system, they must make them available at no cost for all units of a product model with the same operating system, from the end of placement on the market to at least five years after that date. The FAQ also says an update does not need to go to a model whose different hardware makes a specific feature incompatible, for those features only.

Two practical consequences for anyone buying or managing Android fleets:

• The clock starts at the end of sales, not at launch. A model sold for two years in the EU will be covered for at least seven years from its launch.
• The rule is conditional on the maker providing updates for that OS. It guarantees that updates the maker produces reach every unit for free, which is different from guaranteeing a particular Android version. Read the maker's own commitment alongside the regulation.

The regulation also excludes some categories, such as devices with flexible roll-up displays and smartphones for high security communication.

How to check patch level, Mainline modules and Play system updates

The Settings path is the fastest check on a single phone. Android Help's check and update your Android version page lists three fields under Settings, About phone, Android version: Android version, Android security update and Google Play system update. On most devices you can tap the last two to check for updates.

For more than one device, or for anything you want to record, use adb. Nothing below changes the device; every command only reads properties or package metadata.

Step 1: connect with adb

Enable Developer options and USB debugging, connect the phone and confirm it is listed. Turn USB debugging off again when you finish; an Advanced Protection enabled phone restricts USB data signaling.

adb devices -l

Step 2: read the version, API level and patch levels

adb shell getprop ro.build.version.release        # Android version, for example 16
adb shell getprop ro.build.version.sdk            # API level, for example 36
adb shell getprop ro.build.version.security_patch # Platform patch level, for example 2026-10-01
adb shell getprop ro.vendor.build.security_patch  # Vendor partition patch level, if set
adb shell getprop ro.build.fingerprint            # Exact build, useful for tickets

Compare ro.build.version.security_patch with the current bulletin. If it reads 2026-10-01, the device has the October platform fixes but not necessarily the -05 kernel and chipset fixes. A vendor patch level well behind the platform level means the chipset and driver side is lagging.

Step 3: list Mainline APEX modules and their versions

adb shell pm list packages --apex-only --show-versioncode

Each line is a module package and its version code. On devices with Google Mobile Services, names begin with com.google.android.. To see the date of the last Google Play system update train, read the version name of the module metadata package:

adb shell dumpsys package com.google.android.modulemetadata | grep versionName

On devices built with AOSP keys the package is com.android.modulemetadata. If neither package is present, the device does not take Mainline updates through Google Play.

Step 4: check a specific module against a bulletin

When a bulletin lists a fix under "Google Play system updates" (for example a Wi-Fi or Telephony issue), check that the module is present and that the Play system update date is at or after the bulletin month:

adb shell pm list packages --apex-only --show-versioncode | grep -E "wifi|conscrypt|resolv|media"

Step 5: record the result across a fleet

for s in $(adb devices | awk 'NR>1 && $2=="device"{print $1}'); do
  printf "%s,%s,%s,%s\n" "$s" \
    "$(adb -s "$s" shell getprop ro.build.version.release | tr -d '\r')" \
    "$(adb -s "$s" shell getprop ro.build.version.security_patch | tr -d '\r')" \
    "$(adb -s "$s" shell getprop ro.product.model | tr -d '\r')"
done

That prints a CSV line per connected device: serial, Android version, patch level and model. For managed fleets the same fields are available from your device management console; see Android Enterprise modes for which mode reports what.

Step 6: check user facing protections

These are settings rather than properties, so check them on the device:

• Theft protection: Settings, Google, All services, Theft protection. Confirm Theft Detection Lock, Offline Device Lock and Identity Check where offered. Greyed out entries mean the device does not support the feature.
• Advanced Protection: on Android 16 and later devices that offer it, check the Advanced Protection entry in security settings.
• Private Space: on Android 15 and later, check whether a private space exists and whether it uses a separate lock.

What Android 16's release model and the AOSP cadence change

Android 16 changed three schedules at once, and each affects security work differently.

The major release moved to Q2. Google said it planned the major release a quarter earlier to align with device launch schedules, so more new devices ship with the latest major version. For developers it moves annual compatibility testing earlier: behavior changes now land in June rather than September.

A Q4 minor SDK release adds APIs without behavior changes. Android 16 QPR2 (API 36.1) is the first. Code can check for it with the full SDK version rather than the major API level. For security teams it means a second set of new APIs in a year, but no new target-gated restrictions; the restrictions still arrive with the Q2 major release.

AOSP source arrives twice a year. From 2026, full source drops to AOSP happen in Q2 and Q4, and platform security fixes are merged into AOSP 24 to 48 hours after the quarterly bulletins in March, June, September and December. Monthly bulletins still publish CVE details every month, and device makers in the partner program still get patches a month early. The groups most affected are those who build from public source and those who audit fixes by reading the AOSP change: they may see a CVE described weeks before the code is public.

One more change sits beside these: the bulletin is getting quieter in some months. February 2026 listed no vulnerabilities at all. A quiet month is not a reason to skip the monthly update, because the device maker's OTA usually also carries Pixel or partner bulletin fixes and Mainline updates.

Common mistakes

• Reading only the Android version. "Android 14" says nothing about patch state. Read ro.build.version.security_patch and the Google Play system update date.
• Treating the Google Play system update date as the patch level. It covers Mainline modules only. Kernel, driver and most framework fixes still need the maker's OTA.
• Assuming -01 means fully patched. The -05 level is the one that includes kernel and chipset fixes.
• Assuming an old version is supported because the phone still gets updates. A maker may ship its own backports after AOSP coverage ends, but Android 13 and older are no longer in the AOSP bulletin's version columns, and Android 11 and older no longer get Mainline updates.
• Judging support by one quiet bulletin. Months with no platform fixes exist. Check several bulletins.
• Holding target API back to avoid behavior changes. Play's August 2026 rule forces API 36 for updates; deferring makes the jump bigger.
• Turning on cleartext globally to fix one endpoint. Scope it to the one domain in the network security config, and plan for the usesCleartextTraffic deprecation Android 17 announced.
• Leaving android:exported="true" on internal components because it fixed a build error. Export only what other apps must reach, and protect it with a permission.
• Ignoring the EU rule's starting point. Five years runs from the end of sales of the model, not from the purchase date of your unit.
• Leaving USB debugging on after running the checks above.

Where Safeguard fits, honestly

Most of this post is outside what Safeguard does. Safeguard does not manage Android devices, push OTA or Google Play system updates, check patch levels on phones, enforce Advanced Protection or theft settings, scan firmware or provide endpoint or mobile threat protection. Those jobs belong to the device maker, Google and your device management tools.

The honest link is the software you build for Android. Every target API bump in the tables above lands in a Gradle project that also pulls dozens of open source libraries, and those libraries change far more often than the platform does. Safeguard's CLI can scan a repository, a container image or an SBOM file (safeguard scan --dir ., --image <name>, --sbom <file>), match components against vulnerability databases, apply reachability analysis, and the platform shows which projects contain a given component and version. Policies and gates can stop a known vulnerable dependency from shipping. None of that patches a phone.

FAQ

What is the latest version of Android?

As of October 2026 the newest major release is Android 17 (API level 37), released in the second quarter of 2026. Android 16 (API 36) shipped in June 2025, and Android 16 QPR2 (API 36.1) followed in the fourth quarter of 2025 as a minor SDK release.

Which Android versions still get security updates?

The October 2026 Android Security Bulletin lists fixes for Android 14, 15, 16, 16 QPR2 and 17. Android 13 last appeared in the December 2025 bulletin. Individual device makers may ship their own patches longer, so check the maker's page for your model.

How long does Google support each Android version?

Google does not publish a fixed end date per version in the bulletin. Looking at the bulletins, Android 10, 11, 12 and 13 each received AOSP bulletin fixes for about three and a half years after release. Pixel phones have their own commitment: seven years for Pixel 8 and later.

What is the difference between the 01 and 05 security patch levels?

The -01 level covers platform fixes common to all Android devices. The -05 level includes everything in -01 plus kernel and chipset component fixes. Either level also requires all fixes from previous bulletins.

What is a Google Play system update?

It is how Project Mainline modules, such as Conscrypt, the DNS resolver, media codecs, Wi-Fi, Bluetooth and ART, are updated outside a full OS update on Android 10 and later. Its date is separate from the Android security patch level.

How do I check my Android security patch level?

Open Settings, About phone, Android version and read "Android security update". With adb, run adb shell getprop ro.build.version.security_patch.

What is Android Advanced Protection Mode?

A single setting introduced in Android 16 for at-risk users. It applies a fixed set of protections, including blocking sideloading, disabling 2G and WEP connections, enabling forensic logging and restricting USB data signaling, and lets apps detect the mode and harden themselves.

Does Android 11 still get Mainline updates?

No. Google's Mainline documentation states that Mainline support for Android 11 and lower concluded in the fourth quarter of 2025.

What does the EU require for Android phone updates?

Regulation (EU) 2023/1670 applies to smartphones placed on the EU market from 20 June 2025. If the maker provides OS updates, they must be available free for all units of that model for at least five years after the last unit of the model is placed on the market.

What changed in Android 16's release schedule?

The major release moved from Q3 to Q2, a Q4 minor SDK release adds APIs without app-impacting behavior changes, and from 2026 Google publishes full AOSP source in Q2 and Q4, with platform security fixes merged after the quarterly bulletins.

Every Android release changes how the platform protects users, but the apps that run on it are mostly built from open source libraries that need their own fixes. A target API upgrade, a new Android Studio install or a rebuilt CI runner pulls those dependencies again, and the networking, image and serialization libraries inside an APK are patched on their own schedules, not Google's.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos update a phone, change Android settings or read a device's patch level. They show how Safeguard handles the software you build for Android and the machines you build it on.

The first demo is a real Android session with the Safeguard mobile app: you send work to a computer running the Safeguard CLI, then approve the command on the phone with Allow once, Allow for turn or Deny. For an Android team, that is how a fix for a vulnerable library in your app's build can be started and approved from the phone you are testing on, while the computer does the work.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the JavaScript and tooling dependencies around an Android project, such as a React Native app or a build script, when a fixed version exists.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. That is the route for scanning an Android repository on the workstation where you build it, for example right after a target API upgrade has pulled new library versions.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• AOSP: Codenames, tags, and build numbers
• AOSP: Android Security Bulletins overview
• AOSP: Android Security and Update Bulletins index
• Android Security Bulletin, October 2026
• Android Security Bulletin, June 2026
• Android Security Bulletin, March 2026
• Android Security Bulletin, February 2026
• Android Security Bulletin, January 2026
• Android Security Bulletin, December 2025
• Android Security Bulletin, November 2025
• Android Security Bulletin, October 2025
• Android Security Bulletin, September 2025
• Android Security Bulletin, April 2025
• Android Security Bulletin, March 2025
• Android Security Bulletin, March 2024
• Android Security Bulletin, February 2024
• Android Security Bulletin, March 2023
• Android Security Bulletin, February 2023
• AOSP: Mainline
• AOSP: APEX file format
• AOSP: Android security features
• AOSP: Site updates and changes to AOSP
• Android Developers: SDK Platform release notes
• Android Developers: Android 10 privacy changes
• Android Developers: Android 11 permissions updates
• Android Developers: Android 11 storage updates
• Android Developers: Android 11 behavior changes, all apps
• Android Developers: Android 11 behavior changes, apps targeting 11
• Android Developers: Android 12 features
• Android Developers: Android 12 behavior changes, all apps
• Android Developers: Android 12 behavior changes, apps targeting 12
• Android Developers: Android 13 features
• Android Developers: Android 13 behavior changes, all apps
• Android Developers: Android 13 behavior changes, apps targeting 13
• Android Developers: Android 14 features
• Android Developers: Android 14 behavior changes, all apps
• Android Developers: Android 14 behavior changes, apps targeting 14
• Android Developers: Android 15 features
• Android Developers: Android 15 behavior changes, all apps
• Android Developers: Android 15 behavior changes, apps targeting 15
• Android Developers: Android 16 features
• Android Developers: Android 16 behavior changes, all apps
• Android Developers: Android 16 behavior changes, apps targeting 16
• Android Developers: Android 17 features
• Android Developers: Android 17 behavior changes, all apps
• Android Developers: Android 17 behavior changes, apps targeting 17
• Android Developers: Advanced Protection Mode
• Android Developers: Network security configuration
• Android Developers: Photo picker
• Android Developers: Credential Manager
• Android Developers: Foreground service types
• Android Developers: Target API level requirements for Google Play
• Android Developers Blog: Android 12 is live in AOSP (4 October 2021)
• Android Developers Blog: Android 13 is in AOSP (15 August 2022)
• Android Developers Blog: Android 14 is live in AOSP (4 October 2023)
• Android Developers Blog: Android 15 is released to AOSP (3 September 2024)
• Android Developers Blog: Android 16 is here (10 June 2025)
• Google Security Blog: Introducing Android's Private Compute Services (September 2021)
• Android Help: Protect your personal data against theft
• Android Help: Check and update your Android version
• Pixel Phone Help: Learn when you'll get software updates on Google Pixel phones
• European Commission: Smartphones and tablets, ecodesign and energy labelling
• European Commission FAQ: Do Android update requirements cover only minor versions?

Last reviewed: 23 October 2026. Android support coverage changes with every monthly bulletin; check the current Android Security Bulletin and your device maker's update page before planning around these dates.