GrapheneOS: Google Stops Using Git Tags in Certain AOSP Repos

⏱️ Lectura: 10 min

Google has stopped publishing Git tags in several Android source repositories, according to a report from GrapheneOS on its official Mastodon account. The change, silent and without prior notice, directly affects the mechanism that GrapheneOS, CalyxOS, LineageOS, and other AOSP-based projects use to verify that their source code exactly matches what Google compiles and distributes.

📑 En este artículo

1. TL;DR
2. What Happened
3. How Git Tags Work in AOSP
4. Technical Details: What Changes Without the Git Tag
5. Getting Started: Check the Status of an AOSP Repository Yourself
6. How This Connects to the Rest of the AOSP Pipeline
7. Impact and Analysis
8. What’s Next
9. Frequently Asked Questions
   1. What is a Git tag in the context of AOSP?
   2. Did Google stop publishing Android’s source code?
   3. Why does this matter to GrapheneOS and not to a regular user?
   4. How can I check if an AOSP repository has up-to-date tags?
   5. Is there a reliable alternative if there’s no Git tag?
   6. Does this affect LineageOS and CalyxOS the same way?
10. References

Git tags in AOSP are not a minor detail: they are the public reference that lets any developer clone the exact code of an official Android build, compare security patches across versions, and audit changes commit by commit. Without them, verification work becomes more manual and depends on reading the build manifest directly.

TL;DR

• GrapheneOS reported on Mastodon that Google replaced pushing Git tags in certain AOSP source repositories.
• Git tags are the traditional mechanism for syncing exact code with repo sync -c <tag>.
• Without per-repository tags, the source of truth shifts to depending on the AOSP manifest (platform/manifest).
• The manifest pins a commit SHA per project for each build, instead of a human-readable tag name.
• GrapheneOS, CalyxOS, and LineageOS use these tags to audit security patches commit by commit.
• AOSP source code remains public: what changes is build-to-build traceability, not availability.

What Happened

On August 20, 2026, GrapheneOS’s official Mastodon account posted a message that begins: “Google replaced pushing Git tags for certain source…”. The visible fragment of the post, hosted on grapheneos.social, describes how Google replaced the practice of pushing Git tags to certain AOSP source repositories with another mechanism.

GrapheneOS is one of the AOSP-based operating systems with the strictest verification process in the Android ecosystem. Its team compares, build after build, the source code published by Google against the binaries distributed on supported Pixel devices. That process depends on having a stable, public reference to the exact commit Google used to compile a given version, and that stable reference has historically been the Git tag.

⚠️ Heads up: without a public Git tag, there’s no immutable, easily discoverable reference to know which exact commit corresponds to an official build. It has to be reconstructed by hand from the manifest.

How Git Tags Work in AOSP

AOSP doesn’t live in a single repository. It’s made up of more than a thousand independent repositories (frameworks/base, system/core, packages/apps/Settings, and so on) that are downloaded together with the repo tool, created by Google to sync the entire source tree at once. Each official Android version references a specific revision of each of those repositories through an XML file called the manifest, published at platform/manifest.

For years, when Google prepared an official build (for example, a factory image for a Pixel), the process included pushing a Git tag like android-14.0.0_r30 to each of the repositories involved. That tag pointed to the exact commit used in that build. Any developer could run repo init with that tag and get, repository by repository, the same source code Google used to compile the official image.

<!-- fragment of an AOSP manifest -->
<project name="platform/frameworks/base" path="frameworks/base"
  revision="refs/tags/android-14.0.0_r30" />
<project name="platform/system/core" path="system/core"
  revision="refs/tags/android-14.0.0_r30" />

This Git tag system is what makes it possible for projects like GrapheneOS to diff between two Android versions and know exactly what changed in each monthly security patch, without depending on Google publishing a detailed changelog.

Technical Details: What Changes Without the Git Tag

When a repository stops receiving its corresponding Git tag, the AOSP manifest still works because it can point directly to a commit hash (SHA) instead of a tag name. Technically, repo sync doesn’t need a tag: any valid reference is enough, including a pinned revision like revision="a1b2c3d4...".

The problem isn’t that the code stops being available: it’s still public at android.googlesource.com. The problem is traceability. A tag like android-14.0.0_r30 is human-readable, shows up when running git tag -l in any clone of the repository, and doesn’t depend on anyone keeping a copy of that build’s exact manifest. A commit hash without a tag only makes sense if you already know which manifest to look it up in.

Reference Method	How the Exact Commit Is Located	Visible Without the Manifest	Risk If the Manifest Is Lost
Git tag per repository	git tag -l in the repo	Yes	Low: the tag survives independently
Commit SHA only in the manifest	Read the manifest for that specific build	No	High: without the manifest, the SHA is hard to locate

Getting Started: Check the Status of an AOSP Repository Yourself

You can check today whether a specific AOSP repository is still receiving Git tags. With Git installed (on Linux, macOS, or Windows with Git Bash), run the following against any AOSP project:

# Linux / macOS / Windows (Git Bash)
git ls-remote --tags https://android.googlesource.com/platform/frameworks/base \
  | tail -n 10

If the tag list doesn’t include the Android version you’re looking for, that’s a direct signal that Google didn’t push the corresponding tag to that repository. The next step is to sync the full manifest with the repo tool and read the pinned revision project by project:

# install repo (one time only)
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH="${HOME}/bin:${PATH}"

# sync the manifest for an AOSP branch/tag
repo init -u https://android.googlesource.com/platform/manifest -b android-14.0.0_r30
repo sync -c -j8

With the tree synced, you can confirm whether the commit that a specific repository brought in was marked with a public tag by running git tag --contains HEAD inside that repository. If the output is empty, that commit has no associated tag and is only identifiable through the manifest you just synced.

💡 Tip: keep a local copy of the manifest for every build you care about as soon as you sync it. It’s the only way to reconstruct the reference if the tag never gets published.

How This Connects to the Rest of the AOSP Pipeline

The following diagram summarizes where the Git tag (or its absence) fits into the path from an internal Google build to the verification done by AOSP forks:

flowchart TD
    A["Google compiles an official build"] --> B["Updates the manifest at platform/manifest"]
    B --> C{"Pushes Git tag to the repo?"}
    C -->|"Yes"| D["Public tag: android-14.0.0_r30"]
    C -->|"No"| E["Only the SHA pinned in the manifest remains"]
    D --> F["GrapheneOS, CalyxOS, and LineageOS sync and verify"]
    E --> F

Impact and Analysis

For an end user, this change is invisible: Pixel phones keep receiving updates and GrapheneOS keeps publishing its builds normally. The real impact is in the engineering work behind the scenes. Teams like GrapheneOS’s maintain internal scripts that assume a tag exists for every new Android version to automate security patch comparisons. If Google removes that tag from some repositories without notice, those scripts start failing or producing incomplete results until someone updates them by hand.

This kind of friction isn’t new in the AOSP ecosystem. Google controls the pace and format of source code publication, and derivative projects depend on that format staying stable so they don’t have to rebuild their tooling every time something changes. When the format changes without public documentation, fork maintainers absorb the cost, not Google.

💭 Key point: AOSP’s code remains open and public. What’s at stake is how easily that code can be automatically verified to match an official build exactly.

What’s Next

GrapheneOS didn’t publicly detail, in the available fragment of its post, whether it plans to adapt its patch-tracking tools or ask Google to restore Git tags in the affected repositories. Judging by how the project responded to similar changes in the past, it will most likely adjust its internal scripts to read the commits pinned in the manifest directly, instead of assuming a tag will be available.

For the rest of the AOSP ecosystem (CalyxOS, LineageOS, /e/OS, and manufacturers maintaining their own forks) the practical recommendation is the same: stop assuming every official build will have a readable Git tag, and treat the commit-pinned manifest as the primary source of truth.

📖 Summary on Telegram: View summary

Try it yourself: run git ls-remote --tags https://android.googlesource.com/platform/frameworks/base right now and check whether your favorite AOSP repository is still receiving tags.

Frequently Asked Questions

What is a Git tag in the context of AOSP?

It’s a fixed, human-readable reference (like android-14.0.0_r30) that Google historically applied to a specific commit in each Android repository, to mark exactly which code was used in an official build.

Did Google stop publishing Android’s source code?

No. AOSP’s code remains public at android.googlesource.com. What changed, according to GrapheneOS, is the tagging mechanism (Git tags) in certain repositories, not the code’s availability.

Why does this matter to GrapheneOS and not to a regular user?

Because GrapheneOS needs to compare, commit by commit, the code it compiles against the code Google officially used, to audit every security patch and guarantee reproducible builds. An end user just needs the update to reach their phone.

How can I check if an AOSP repository has up-to-date tags?

Run git ls-remote --tags against the repository’s URL on android.googlesource.com and check whether the tag for the Android version you’re interested in shows up.

Is there a reliable alternative if there’s no Git tag?

Yes: the AOSP manifest (platform/manifest) pins an exact commit SHA per repository for each build. Syncing it with the repo tool gives you the same result, though it requires an extra manual step.

Does this affect LineageOS and CalyxOS the same way?

Any project that depends on AOSP and uses Git tags for its verification or sync process faces the same challenge, though each team may have its own way of mitigating it.

References

• GrapheneOS on Mastodon: original post about the change in pushing Git tags to AOSP source repositories.
• android.googlesource.com/platform/manifest: official manifest repository defining the revisions for each AOSP project.
• source.android.com: official documentation for the Android Open Source Project.
• grapheneos.org: official site of the GrapheneOS project.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Yancy Min en Unsplash