This document contains answers to general questions about the Android Open Source Platform (AOSP).
About android-latest-release
Why can't I submit to aosp-main?
You can't submit to aosp-main because that branch is now read-only.
Where should I propose changes to AOSP?
You should propose new changes to android-latest-release (when using Repo) or
to the latest release branch specified in the android-latest-release manifest
(when using Git directly). Existing proposed changes on other branches (such as
aosp-main) don't need to be moved.
Which branch should I sync to?
When using Repo, sync to
android-latest-releaseusing the following command:repo init --partial-clone --no-use-superproject -b android-latest-release -u https://android.googlesource.com/platform/manifestWhen using Git directly, sync to the default revision branch specified in the
android-latest-releasemanifest.
See Initialize the Repo client for more details on syncing branches.
Will the code from android-latest-release be merged to aosp-main?
No, the code won't be merged to aosp-main, which is a read-only branch as of
March 27, 2025.
Where is the code for the next release pushed?
Google pushes the code for the next release to the latest public release branch
and updates the android-latest-release manifest to point to that branch.
Will my change request be cherrypicked from the android-latest-release branch into the internal Gerrit?
After you upload a proposed change, Google will review it and, if accepted, will cherrypick it into the internal Gerrit.
How will I know if my change request was accepted?
Accepted and cherrypicked changes appear in a future push to a release branch on
the Android host and can be synced with repo using android-latest-release.
There isn't a notification mechanism for when a proposed change is accepted or
rejected.
What is the general workflow from when a change is proposed by an external contributor to when it is merged into the latest release branch?
An external contributor proposes a change to
android-latest-release(when using Repo) or to the latest release branch specified in theandroid-latest-releasemanifest (when using Git directly).Google reviews the change. If the change is:
Accepted, Google cherrypicks that change and merges it into the internal development branch.
Not accepted, Google doesn't cherrypick the change.
The external contributor checks for their change in
android-latest-release.
What if I don't need my proposed change anymore?
If you no longer need your proposed change, don't want the change to be merged, or know that Google has already reviewed the change, abandon the change so it stays in the proposed change history on the Android host.
Open-source questions
Why did Google open the Android source code?
Google started the AOSP in response to our own experiences launching mobile apps. We wanted to make sure there would always be an open platform available for carriers, OEMs, and developers to use to make their innovative ideas a reality. We also wanted to avoid any central point of failure, so no single industry player could restrict or control the innovations of any other. Our single most important goal with the AOSP is to make sure that open-source Android software is implemented as widely and compatibly as possible, to everyone's benefit.
What kind of open-source project is Android?
Google oversees the development of the core AOSP and works to create robust developer and user communities. For the most part, the Android source code is licensed under the permissive Apache License 2.0, rather than a copyleft license. We chose the Apache 2.0 license because we believe that it encourages widespread Android software adoption. For details, see Licenses.
Why is Google in charge of Android?
Launching a software platform is complex. Openness is vital to the long-term success of a platform, because openness attracts investment from developers and ensures a level playing field. The platform must also be a compelling product to users.
Google has committed the professional engineering resources necessary to ensure that Android is a fully competitive software platform. Google treats the Android project as a full-scale product development operation and strikes the business deals necessary to make sure great devices running Android make it to market.
By making sure Android is a success with users, we help ensure the vitality of Android as a platform and as an open-source project. After all, who wants the source code to an unsuccessful product?
Our goal is to ensure a successful ecosystem around Android. We opened the Android source code so that anyone can modify and distribute the software to meet their own needs.
What is Google's overall strategy for Android product development?
We release great devices into a competitive marketplace. We then incorporate the innovations and enhancements we made into the core platform as the next version.
In practice, this means that the Android engineering team focuses on a small number of "flagship" devices and develops the next version of Android software to support those product launches. These flagship devices absorb much of the product risk and blaze a trail for the broad OEM community, who follow up with more devices that take advantage of the new features. In this way, we make sure that the Android platform evolves according to the needs of real-world devices.
How is Android software developed?
Each platform version of Android (such as 1.5 or 8.1) has a corresponding branch
in the open-source tree. The most recent branch is considered the current
stable branch version, which the android-latest-release manifest points to.
This is the branch that manufacturers port to their
devices. This branch is kept suitable for release at all times.
Finally, Google works on the next version of the Android platform in tandem with developing a flagship device.
Why are parts of Android developed in private?
It typically takes more than a year to bring a device to market. And, of course, device manufacturers want to ship the latest software they can. Meanwhile, developers don't want to constantly track new versions of the platform when writing apps. Both groups experience a tension between shipping products and not wanting to fall behind.
To address this, some parts of the next version of Android including the core platform APIs are developed in a private branch. These APIs constitute the next version of Android. Our aim is to focus attention on the current stable version of the Android source code while we create the next version of the platform. This allows developers and OEMs to use a single version without tracking unfinished future work just to keep up.
When are source code releases made?
When they're ready. Releasing the source code is a fairly complex process. Some parts of Android, such as the kernel, are developed in the open, and that source code is always available. Other parts are developed first in a private tree, and that source code is released when the next platform version is ready.
In some releases, core platform APIs are ready far enough in advance so that we can push the source code out for an early look prior to the device's release. In other releases, this isn't possible. In all cases, we release the platform source when we feel that the version is stable, and when the development process permits.
What's involved in releasing the source code for a new Android version?
Releasing the source code for a new version of the Android platform is a significant process. First, the software is built into a system image for a device and put through various forms of certification, including government regulatory certification for the regions the phones will be deployed. The code also goes through operator testing. This is an important phase of the process, because it helps detect software bugs.
When the release is approved by the regulators and operators, the manufacturer begins mass producing devices, and we begin releasing the source code.
Simultaneous to mass production, the Google team kicks off several efforts to prepare the open-source release. These efforts include making final API changes, updating documentation (to reflect any modifications that were made during qualification testing, for example), preparing an SDK for the new version, and launching the platform compatibility information.
Our legal team does a final sign-off to release the code into open source. Just as open-source contributors are required to sign a Contributors License Agreement attesting to their intellectual property ownership of their contribution, Google must verify that the source is cleared to make contributions.
From the time that mass production begins, the software release process usually takes about a month, so source code releases often happen at around the same time the devices reach users.
How does the AOSP relate to the Android Compatibility Program?
The AOSP maintains Android software, and develops new versions. Because it's open-source, this software can be used for any purpose, including developing devices that aren't compatible with other devices based on the same source.
The function of the Android Compatibility Program is to define a baseline implementation of Android that is compatible with third-party apps written by developers. Devices that are Android compatible are eligible to participate in the Android ecosystem, including Google Play; devices that don't meet the compatibility requirements exist outside of that ecosystem.
In other words, the Android Compatibility Program is how we separate Android-compatible devices from devices that merely run derivatives of the source code. We welcome all uses of the Android source code, but to participate in the Android ecosystem, a device must be identified as Android-compatible by the program.
How can I contribute to Android?
You can report bugs, write apps for Android, or contribute source code to the AOSP.
There are limits to the kinds of code contributions we accept. For instance, someone might want to contribute an alternative app API, such as a full C++-based environment. We would decline that contribution, because Android encourages apps to be run in the ART runtime. Similarly, we won't accept contributions such as GPL or LGPL libraries that are incompatible with our licensing goals.
We encourage those interested in contributing source code to contact us through the channels listed in Android Community prior to beginning any work. For details, see Contributing.
How do I become an Android committer?
The AOSP doesn't really have a notion of a committer. All contributions (including those authored by Google employees) go through a web-based system known as Gerrit that's part of the Android engineering process. This system works in tandem with the Git source code management system to cleanly manage source code contributions.
A designated approver needs to review and accept all proposed changes. Approvers are typically Google employees, but the same approvers are responsible for all submissions, regardless of origin.
For details, see Submitting patches.