Android Automotive Kernel End-of-Life: How to Find the Date That Applies to Your Build

Teams building an infotainment head unit or a cockpit domain controller on Android Automotive OS are often asked the same question by a programme manager, a customer or a type-approval engineer. Until when will the Android Automotive kernel in this vehicle receive security fixes? The usual answer is read from the kernel.org longterm table, and for a certified GKI build it is the wrong date.

This post sets out the dates that apply to an Android Automotive kernel and where each is published. It then explains how Google’s dates are derived, which head units they bind, and gives a short procedure for establishing the date that applies to a shipped build.

The scope is the Android common kernel branches from android12-5.10 to android17-6.18, as listed on source.android.com and read on 2 October 2026.

The published dates behind an Android Automotive kernel

The first date is the upstream one. Kernel.org’s releases page, read on 2 October 2026, lists six longterm series. Their projected end-of-life dates are December 2028 for 6.18 and 6.12, December 2027 for 6.6 and 6.1, and December 2026 for 5.15 and 5.10.

The same page states that “each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large”.

The second date is Google’s branch end of life. The Android common kernels page on source.android.com, last updated on 17 June 2026, carries a support-lifetime table for every Android common kernel branch (ACK) that Google maintains.

It states that ACKs “might be supported for longer than the corresponding upstream stable kernel”, in which case Google provides extended support until the date in the table. It also states that “when kernels are EOLed, they are no longer supported by Google and devices running them are considered to be vulnerable”.

The first four columns below are Google’s table; the last column is added from kernel.org for comparison.

Every Google date in that table equals the upstream launch date plus the stated lifetime, moved forward to the following 1 July. Google does not state this as a rule, but every row fits it. The gap between Google’s date and kernel.org’s therefore varies from about six months to about eighteen months, and the variation comes from kernel.org’s projections rather than from Google’s.

The third date belongs to the build itself. Google does not ship one build per ACK branch. It publishes certified releases from it, each on its own git branch with its own deprecation date.

The android16-6.12 release-builds page, last updated on 2 October 2026, lists the September 2026 release as branch android16-6.12-2026-09 at version 6.12.92. That release is “no longer respin eligible from 2027-04-01”, except for security patches on explicit partner request, and is “deprecated from 2028-01-01. No respins allowed after this date.”

How releases are cut from an Android common kernel branch

Google’s Android common kernels are downstream of kernel.org. When an upstream LTS is declared, a new ACK branch is branched from android-mainline and named for the Android platform release and the kernel version, such as android16-6.12. That branch then receives a merge from each upstream stable release, “normally done immediately after the LTS release is posted”, in the words of the Android common kernels page.

Each ACK branch passes through a development phase, a stabilisation phase and a frozen phase. Once the Kernel Module Interface (KMI) is frozen, it can be extended with new exported symbols but not broken, except where a serious security issue cannot be fixed any other way.

This is the property that makes GKI a practical basis for an Android Automotive kernel. SoC and board support live in loadable vendor modules, and the core kernel can be replaced by a later release on the same branch without rebuilding them, provided the KMI generation number, the digit after -androidNN- in uname -r, is unchanged.

The page states that if the KMI generation changes, “the modules must be rebuilt and updated synchronously with the kernel”.

The page also states the limit: “KMI compatibility isn’t maintained between different GKI kernels”, so moving from android15-6.6 to android16-6.12 means rebuilding every vendor module.

From each ACK branch, Google publishes certified releases. The GKI release process page states that “GKI is released on a quarterly cadence post KMI freeze”.

Each quarterly release contains “a tested boot.img that includes a Google inserted certificate to attest that the binaries were built from a known source code baseline”. The page also publishes a calendar of check-in cut-off and preload-ready dates per branch, currently running to December 2026. The release tag carries the release branch name, in the form android16-6.12-2025-12_r1.

The release-builds page lists each release at a single LTS version. After publication, a release changes only through respins, which the release process page describes as builds containing “only the patches that are on top of the quarterly certified kernels that have been chosen”.

The release-builds page defines three stages. For its first six months a release is in the launch stage and accepts partner-requested respins. After that it enters the maintenance stage, in which it is “eligible for respin only by an explicit request from a partner for security patches cited in Android Security Bulletin (ASB)”. Finally it is deprecated.

The deprecated-builds page states the consequence: “These branches don’t get security updates and aren’t supported for deployment.”

The length of each release’s life is visible in the dates. Each of the September 2026, June 2026, March 2026, December 2025 and September 2025 releases is deprecated on the first day of the sixteenth month after its release month, about fifteen months after the release is published.

Google’s kernel lifetime file, kernel-lifetimes.xml in the kernel/configs project, records the change: “when transitioning from monthly GKI releases to quarterly, the GKI lifetimes transitioned from 12-months to 15-months.”

The same file states that it is “used for enforcement of EOL by various tests”, and that its dates “may indicate later dates than the official EOLs” by as much as one quarter, where enforcement was relaxed, for example during that transition.

The release dates also follow the minimum kernel version that Google sets in the Android Security Bulletin. The release-builds page states: “When the LTS requirements cause the branch to be non-compliant, the branch is deprecated.”

The bulletin publishes the minimum in a section headed “Kernel LTS”, as a table of Android launch version, kernel launch version and minimum update version. That section appears only in some bulletins. The December 2025 bulletin carries one row, a device launched on Android 12 with kernel 5.4 and a minimum update version of 5.4.292. The September 2026 bulletin has no such section.

For a GKI release, the practical effect of the minimum is already published in advance as the release’s deprecation date.

What changed: four-year branch lifetimes and fifteen-month releases

The Android common kernels page states: “Beginning with kernel 6.6, the support lifetime for the stable kernels is 4 years.”

Before the change, android14-6.1, launched upstream on 11 December 2022, carries a six-year lifetime and an end of life of 1 July 2029. After it, android15-6.6, launched upstream on 29 October 2023, carries four years and an end of life of 1 July 2028.

The result is an ordering that does not follow kernel age. The newer branch reaches Google’s end of life one year before the older one, and on the same day as android13-5.15.

The second change concerns the releases. In 2025 the android16-6.12 branch had monthly releases.

A copy of its release-builds page archived on 7 April 2026 lists the June, July and August 2025 releases at 6.12.23, 6.12.30 and 6.12.38, deprecated from 1 July, 1 August and 1 September 2026. Each of those lived twelve to thirteen months. The September 2025 release, also at 6.12.38, is deprecated from 1 January 2027, about fifteen months after publication.

Two releases at the same LTS version therefore carry deprecation dates four months apart, because they fall on either side of the change from monthly to quarterly releases. On 2 October 2026 all three monthly releases appear only on the separate deprecated-builds page.

The third change concerns the platform. The compatibility matrix on the Android common kernels page lists the kernels each Android release supports. Android 17 (2026) still lists android12-5.10 and android13-5.10, but marks both “not supported in Android 17 QPR1 or higher”.

The current Android Automotive release notes list Android Automotive 26Q2 at API level 37, which is the Android 17 API level. A programme planning a platform upgrade through 2027 on a 5.10 kernel therefore has a platform end date as well as a kernel end date.

For comparison with the Yocto side of the vehicle, NXP’s S32 automotive BSP release bsp48.0, tagged on 30 July 2026, uses a 6.12.92 kernel branch. That is the same LTS version as the September 2026 GKI release.

The Yocto BSP has no published per-build deprecation date. Its maintenance period is limited by the kernel.org projection and by how often the vendor publishes a new branch. The GKI release at the same version has an explicit deprecation date, 1 January 2028. One model states the obligation and enforces it. The other requires the integrator to determine it.

Which head units Google’s dates bind

Google’s release dates bind an Android Automotive kernel only when the device ships a certified GKI image. Whether an automotive device must do so is enforced by Google’s own compliance test, vts_gki_compliance_test.cpp in the VTS security test project.

The test skips every device whose kernel is not arm64, with the message “Exempt from GKI test on non-arm64 kernel devices”.

For a device that declares itself automotive, it also skips the GKI check when the kernel version is below 5.15 or the device launched before Android 13. The comment in the source reads: “Skip for automotive devices if the kernel version is not >= 5.15 or the device is launched before Android T.”

The consequence for vehicle programmes is direct. An arm64 head unit that launched on Android 13 or later with a 5.15 or newer kernel is held to a certified GKI image or, from Android 14, an approved OEM-built GKI, and the release dates above apply to a certified GKI.

A head unit on 5.10, on an x86_64 processor, or launched before Android 13 may ship a vendor-built kernel. For that kernel the per-release dates have no direct force. The governing date is whatever the vendor or Tier 1 supplier commits to. If the kernel was built from an ACK, Google’s own fixes for it stop at the ACK end of life.

The test also shows how certification is proven. It reads the boot partition, extracts the boot signature and fails with “The GKI image descriptor is not signed by an official key” if the signature does not verify against Google’s keys.

A kernel release string that contains -android16- shows that the kernel came from an ACK. It does not show that the image is a certified GKI.

The test further recognises an OEM-built GKI on Android 14 and later, identified by a release-string component matching -abogki followed by a number, which it checks against a list of approved builds instead.

Finding the date for a shipped Android Automotive kernel

The procedure follows from the dates and conditions above. Establish whether the Android Automotive kernel is held to GKI, identify the release it ships, and then read the release date and the branch date. These checks run from the host over adb:

raghu@techveda.org:~$ adb shell uname -rm
raghu@techveda.org:~$ adb shell getprop ro.product.first_api_level
raghu@techveda.org:~$ adb shell pm has-feature android.hardware.type.automotive

The machine field from uname -m shows whether the kernel is arm64; the VTS test accepts aarch64 or armv8l. The first API level shows the Android release the device launched with, and 33 is Android 13. The feature query prints true when the device declares itself automotive.

Together these three answers tell you whether the compliance rule above applies to the Android Automotive kernel on the device under test.

The release string from uname -r begins with the upstream version, the Android release, the KMI generation and the commit, as in Google’s documented example 6.6.30-android15-6-g86d10b30f51f, and may carry further suffixes. The upstream version gives the LTS version, and the Android release with the kernel version gives the ACK branch, android15-6.6 in that example.

Look that branch up in the support-lifetime table for the branch end of life.

Next, identify the release the Android Automotive kernel was built from. Map the LTS version to a release on the matching release-builds page, and check the deprecated-builds page as well.

Because two releases can share an LTS version, as the two 6.12.38 releases show, ask the supplier for the GKI release tag the build was taken from, such as android16-6.12-2025-12_r1. The tag names the release branch, and the release branch carries the deprecation date.

Finally, read the patch level recorded in the boot image. For Android 16 GKI images, the release-builds page explains that the os_version field in the boot image header is set to zero. Partners can instead put the operating system version and security patch level into the AVB footer, as the properties com.android.build.boot.os_version and com.android.build.boot.security_patch. On the host, with the boot image from the build:

raghu@techveda.org:~$ avbtool info_image --image boot.img

Google shows these properties in the form Prop: com.android.build.boot.security_patch -> '2025-07-05', and avbtool info_image prints property descriptors as Prop: lines. The value is the patch level the integrator declared for the boot image. Check that it matches the build that is actually flashed, but do not treat it as evidence of which kernel fixes are present. That comes from the release tag.

The answer to the programme manager’s question then has two parts. If the programme ships one GKI release and never updates it, the governing date is that release’s deprecation date.

If the programme always moves to a newer certified release on the same branch before the release it ships is deprecated, the governing date is the branch end of life, and each release date becomes the latest date for the next vehicle software update.

After the branch end of life, the only routes are a move to a newer ACK branch, with every vendor module rebuilt, or a maintenance arrangement with the silicon vendor or Tier 1 supplier.

Common mistakes when reading Android Automotive kernel support

The first mistake is to take the Android Automotive kernel’s end of life from kernel.org alone. Kernel.org is the authoritative source for upstream longterm maintenance, and on a Yocto-built Linux system it often is the governing date.

For a certified GKI build it is neither of Google’s dates. The branch end of life is later on every row, and the release deprecation date is usually earlier.

The second mistake is to assume that a newer Android Automotive kernel lasts longer. Under the six-year rule it did. Under the four-year rule, a supplier choosing between android14-6.1 and android15-6.6 for a 2026 start of production, on the assumption that newer means longer, would choose the branch that ends a year earlier.

The third mistake is to treat the branch end of life as the date for an unmaintained build. The Android Automotive kernel in a shipped head unit is built from one release frozen at one LTS version.

If no later release is ever taken, that release’s deprecation date applies, and it is eighteen months before the branch date for the September 2026 android16-6.12 release.

The reverse mistake also occurs. The release date is not always earlier: the July 2026 android12-5.10 release at 5.10.257 is deprecated from 1 November 2027, four months after its branch end of life of 1 July 2027. The page does not explain this, and this post does not offer an explanation. Read both dates.

The fourth mistake is to read -androidNN- in the release string as proof of a certified GKI, or to read the platform security patch level from ro.build.version.security_patch as proof that the kernel is current. The first shows the kernel came from an ACK. The second describes the system image, not the kernel.

The fifth mistake is to look for the kernel in the Android Automotive release notes.

The Android Automotive 26Q2 notes, last updated on 27 September 2026, list eight new features and 180 addressed issues, covering the framework, car services, display safety and system UI. They do not mention a kernel version. Kernel support for Android Automotive is documented in the platform-wide kernel pages and in the VTS source, not in the automotive section.

What this does not cover, and what was not verified

Five limits apply. First, the compliance rule is read from the main branch of the VTS source on 2 October 2026. The version of VTS that a particular programme was certified against may differ, and the post does not trace the rule back through earlier releases.

Second, the Android Automotive kernel may not be the only kernel in the vehicle. Where Android Automotive OS runs as a guest under a hypervisor, the host or hypervisor and any safety domain beside it have their own maintenance positions, which these Android tables do not describe.

Third, Google’s dates describe Google’s support. A silicon vendor or Tier 1 supplier may contract to maintain a kernel beyond them. Such contracts are not public, no supplier arrangement is named here, and no vehicle or manufacturer is attached to any kernel version in this post.

Fourth, the two places Google publishes release dates do not always agree. The release-builds pages give dates per release; kernel-lifetimes.xml gives dates per LTS version and states that its enforcement dates can be up to one quarter later.

On the android16-qpr2-release branch it lists 6.12.23 with an end of life of 1 October 2026, against 1 July 2026 in the archived release page.

Because it lists one date per LTS version, it cannot tell the two 6.12.38 releases apart; its 6.12.38 entry, 1 December 2026, is earlier than the September 2025 release’s 1 January 2027. Record both and plan against the earlier one.

Fifth, the minimum update version for any particular launch version was not established for this post. The “Kernel LTS” section was read in the December 2025 bulletin, and the September 2026 bulletin was confirmed to have none.

For kernels that do not come from Google, the counterpart to this procedure is the three-clock check in how to tell whether SoC kernel support has already lapsed. It compares the upstream end-of-life date, the vendor branch head date and the silicon longevity commitment.

Key takeaways

• A certified GKI-based Android Automotive kernel has two Google dates: the release deprecation date and the ACK branch end of life. Kernel.org’s projection is neither.
• Quarterly GKI releases are deprecated about fifteen months after publication. For a build that is never updated, that date usually comes first; for a programme that moves to a newer release on the same branch before each release it ships is deprecated, the branch end of life governs.
• Moving to a newer release on the same branch keeps the vendor modules. Moving to a newer ACK branch requires rebuilding all of them.
• Google’s VTS source holds an automotive device to certified GKI (or an approved OEM-built GKI) only on arm64, with a 5.15 or newer kernel, and a launch on Android 13 or later.
• Since kernel 6.6, Google’s branch lifetimes are four years rather than six, so android15-6.6 ends before android14-6.1.
• Identify an Android Automotive kernel build by its GKI release tag, not its LTS version: two android16-6.12 releases at 6.12.38 carry deprecation dates four months apart.

Verification checklist

1. adb shell uname -rm reports aarch64 (or armv8l) and a release string containing -androidNN-, and you have recorded the ACK branch and its end of life from the support-lifetime table.
2. ro.product.first_api_level and the automotive feature query have been recorded, and you know whether the device is held to certified GKI.
3. The supplier has named the GKI release tag, the tag appears on the release-builds or deprecated-builds page, and you have recorded that release’s deprecation date.
4. avbtool info_image on the boot.img from the build that is flashed shows a com.android.build.boot.security_patch property that matches the build’s documented patch level.
5. For a 5.10-based build, the programme’s target platform version is below Android 17 QPR1, or a kernel branch change is scheduled.
6. The Android Automotive kernel end-of-life date recorded for the programme names its source page and the date that page was read.

Frequently asked questions

Which end-of-life date applies to an Android Automotive kernel built on GKI?
For a build that is never updated, the deprecation date of the GKI release it was taken from, which is usually the earlier of Google’s two dates. For a programme that moves to a newer certified release on the same branch before each release it ships is deprecated, the end of life of the Android common kernel branch.

Why does android15-6.6 reach end of life before android14-6.1?
Google’s table gives android15-6.6 a four-year lifetime and an end of life of 1 July 2028, and android14-6.1 a six-year lifetime and an end of life of 1 July 2029. The change to four years applies from kernel 6.6 onwards.

Must every Android Automotive head unit ship a certified GKI?
No. Google’s VTS GKI compliance test skips non-arm64 devices, and skips automotive devices whose kernel is older than 5.15 or that launched before Android 13. Those devices may ship vendor-built kernels, to which the per-release dates do not directly apply.

Which documents describe Android Automotive kernel support?
Not the Android Automotive release notes, which do not mention a kernel version. Support is documented in the platform-wide Android common kernel and GKI release pages, and the automotive compliance rule is in Google’s VTS source.

Further reading

• Android common kernels, source.android.com, last updated 17 June 2026 (primary; support-lifetime table, KMI rules and compatibility matrix)
• android16-6.12 release builds, source.android.com, last updated 2 October 2026 (primary; releases, stages and deprecation dates)
• android16-6.12 deprecated builds, source.android.com, last updated 2 October 2026 (primary)
• android16-6.12 release builds, archived 7 April 2026 (primary, archived; deprecation dates of the 2025 monthly releases)
• android12-5.10 release builds, source.android.com, last updated 2 October 2026 (primary)
• Generic Kernel Image (GKI) release process, source.android.com, last updated 17 June 2026 (primary; quarterly cadence and respins)
• vts_gki_compliance_test.cpp, AOSP VTS security tests, main branch (primary; automotive GKI compliance rule)
• kernel-lifetimes.xml, AOSP kernel/configs, android16-qpr2-release branch (primary; per-version enforcement dates)
• Android Security Bulletin, December 2025 (primary; “Kernel LTS” minimum update table)
• Android Automotive 26Q2 release notes, last updated 27 September 2026 (primary)
• Set up the Android 17 SDK, developer.android.com (primary; API level 37)
• Active kernel releases, kernel.org, read 2 October 2026 (primary; longterm projected end-of-life dates)