On March 27, 2025, Google announced a major shift in how Android will be developed: the public branch of the Android Open Source Project (AOSP) will no longer be maintained, and future Android work will move to Google’s internal private branch. Related infrastructure, including Android Gerrit and parts of the CI/CD workflow, is also set to be phased out.
That does not mean Android source code disappears entirely. Google has said it will continue to comply with open-source obligations such as the GPL and will still release source code for new Android versions. But the practical change is significant: outside developers will lose real-time visibility into Android’s development process and will no longer be able to follow, test, or contribute to core platform changes as they happen.
For years, AOSP served as the foundation for third-party ROM projects such as LineageOS and Pixel Experience. Those projects could build on a relatively current Android base, customize it, and keep pace with platform evolution. Once development happens only inside Google, that dynamic changes. External developers will be limited to whatever code Google publishes at the end of a release cycle, without access to features, fixes, or security work still in progress.
In practical terms, that could leave many community projects maintaining branches based on older public versions for longer periods. As Google’s internal branch continues to move ahead, those outside projects may fall further behind in both functionality and security. Over time, that gap could make them less attractive to users and harder to sustain technically.
Another consequence is the loss of a direct contribution path. AOSP previously allowed outside developers to submit patches. With the core branch no longer open to public participation, only Google’s internal teams will be able to modify the main Android codebase directly. That weakens one of the most valuable qualities of an open platform: the ability of independent developers and small teams to help shape its future through technical contributions.
The effect will likely be felt well beyond ROM communities. Developers have long relied on AOSP’s public branch for debugging, compatibility checks, and understanding platform behavior before final releases landed. With that visibility gone, diagnosing problems may become slower and less precise. If a new Android version introduces compatibility issues or vulnerabilities, external developers may have to wait for Google’s delayed public release or patch publication before responding, stretching app adaptation and device support timelines.
This matters especially for manufacturers building non-certified devices. Some lower-cost phones, automotive systems, and other specialized products have historically used AOSP without paying for Google Mobile Services licensing. If the public branch becomes less useful and the private branch becomes the real center of Android development, Google may gain new leverage to push such vendors toward formal agreements or stricter technical requirements. That could raise costs for smaller manufacturers, costs that may ultimately be passed to buyers—or force some products out of the market altogether.
For large mainstream brands that already operate within Google’s commercial ecosystem, the immediate disruption may be limited. Companies such as Samsung and Xiaomi, which already have GMS agreements in place, are more likely to retain access to the support and coordination needed to stay current. The pressure will fall more heavily on smaller manufacturers, which may have less bargaining power and fewer engineering resources. Over time, Android could move further toward a semi-closed model: still partially open in legal terms, but increasingly centralized in practice, with less room for independent variation and less diversity across the market.
That broader shift has strategic implications beyond Android itself. As Google tightens control over the platform, alternative operating systems may become more appealing. HarmonyOS has already positioned itself as a credible candidate, built on its own architecture and backed by an ecosystem that had reached 1 billion devices as of March 2025. That scale gives it a stronger chance of attracting partners looking for an option outside Google’s orbit. At the same time, companies such as China Software International are accelerating work on domestic operating system ecosystems, aiming to fill any gaps left by AOSP’s retreat from public development.
The open-source community may also try to respond directly. One possible path is to fork the last fully public AOSP release and maintain it as an independent branch. In theory, that could preserve a more open Android-like platform. In reality, it would be difficult. Sustaining such a fork would require major long-term investment, deep engineering capacity, and the ability to keep up with a codebase that would increasingly diverge from Google’s private branch. A new alliance could emerge around that effort, but in the near term it would be hard to challenge Google’s dominant position.
Security is another area of concern. When development becomes less transparent, it becomes harder for outsiders to track how vulnerabilities are handled and when fixes are introduced. Non-certified devices may be particularly exposed, because their security update quality will depend heavily on the technical ability of each manufacturer. Vendors with weak software teams could struggle to respond quickly, leaving users with greater risk.
Google’s decision can be read in two ways at once. On one level, it is a technical consolidation move that reduces the cost and complexity of maintaining parallel development branches. On another, it is a business decision that strengthens control over the Android ecosystem. For developers, that likely means a narrower space for experimentation inside Android’s core. For emerging operating systems and domestically built software stacks, it may open a rare window to gain ground.
The next phase of operating system competition is unlikely to be defined simply by the old open-versus-closed argument. The more decisive factors may be ecosystem integration, technological self-reliance, and the quality of the user experience delivered across devices. Developers will need to adjust accordingly—whether by expanding into cross-platform development or by exploring newer ecosystems such as HarmonyOS and RISC-V—as the mobile software landscape becomes more fragmented and more strategically contested.