Why Google Stopped Git Tags for Android Code

If you’ve pulled Android source code recently, you might have noticed something missing. Git tags for certain repositories stopped updating. This isn’t a bug, it’s a deliberate change from Google. The shift affects how developers track releases, sync code, and manage dependencies. Here’s what’s happening under the hood.

What changed with Android Git tags

Google historically used Git tags to mark stable points in the Android Open Source Project. These tags, like android-14.0.0_r1, let developers fetch exact release versions. Now, some repositories, especially newer ones, no longer receive these tags. Instead, Google is pushing updates directly to branches like android14-release without tagging them.

The move aligns with how Google manages internal development. Tags were always a convenience for external contributors, not a core part of their workflow. By dropping them, Google reduces maintenance overhead while still providing access to the latest code. The trade-off is less clarity for those relying on tagged releases.

Which repositories are affected

• Newer platform repositories added after Android 12.

• Vendor-specific codebases like Pixel device trees.

• Kernel and driver repos that sync with upstream Linux.

• Experimental or preview branches that never had tags.

Core AOSP repositories, such as frameworks/base or system/core, still receive tags. But if you’re working with device-specific code or newer modules, you’ll need to adjust. The change is most noticeable in projects where Google doesn’t prioritize external compatibility.

How this impacts your workflow

Without tags, syncing to a known stable version becomes harder. You can no longer run repo init -b android-14.0.0_r1 and expect a predictable snapshot. Instead, you’re left with two options: track a moving branch or manually pin commits.

• Use repo sync -c to fetch only the current branch, reducing bandwidth.

• Check out specific commits using git checkout <hash> if you need stability.

• Monitor Google’s release notes for commit hashes tied to specific builds.

Why Google made this change

Tags add friction to Google’s internal development. Every tag requires a signed commit, which slows down rapid iteration. Since most AOSP contributors are Google engineers, the company optimized for their workflow. External developers are now expected to adapt.

There’s also a security angle. Tags can be spoofed or misused to distribute unofficial builds. By relying on branches, Google maintains tighter control over what gets labeled as a release. This reduces the risk of malicious forks masquerading as official versions.

What to do instead of relying on tags

If you need reproducible builds, start tracking commit hashes. Google’s release documentation often includes the exact commit for a given version. For example, the Android 14 QPR1 release notes list the top-of-tree commit for each repository.

For CI/CD pipelines, replace tag-based syncs with branch-based ones. Use repo init -b android14-release and repo sync -c to stay on the latest. If you need a specific point in time, check out the commit hash from Google’s release notes.

The future of Android versioning

This change isn’t temporary. Google is moving toward a model where branches are the primary way to track releases. Tags will likely remain only for major platform releases, like android-15.0.0_r1. Everything else will rely on branches or commit hashes.

For developers, this means more manual work. You’ll need to document commit hashes for your builds and update them as new releases roll out. The upside is that you’re no longer tied to Google’s tagging schedule, you can pull the latest code whenever you need it.

If you’re building for production, always pin to a commit hash. Branches move fast, and you don’t want your app to break because of an unexpected update.

Final takeaways

Google’s shift away from Git tags is a reality for Android developers. While it complicates version tracking, it also reflects how the company actually develops the OS. The key is to adapt: use branches for flexibility, commit hashes for stability, and Google’s release notes as your guide. The days of simple tag-based syncs are over, time to embrace the new workflow.