This document contains answers to general questions about the Android Open Source Platform (AOSP).
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. This is the branch that manufacturers port to their devices. This branch is kept suitable for release at all times.
Simultaneously, there's a current experimental branch, which is where speculative contributions, such as large next-generation features, are developed. Bug fixes and other contributions can be included in the current stable branch from the experimental branch as appropriate.
Finally, Google works on the next version of the Android platform in tandem with developing a flagship device. This branch pulls in changes from the experimental and stable branches as appropriate.
For details about codelines, branches, and releases, see Android software management.
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. Other parts of the Android system that aren't related to app compatibility are developed in the open. We intend to move more of these parts to open development over time.
When are source code releases made?
When they're ready. Releasing the source code is a fairly complex process. Some parts of Android 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.
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 need to accept all submitted changes. Approvers are typically Google employees, but the same approvers are responsible for all submissions, regardless of origin.
For details, see Submitting patches.
What is Android compatibility?
We define an Android-compatible device as a device that can run any apps written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem and those that can't. For devices that are properly compatible, device manufacturers can seek approval to use the Android trademark. Devices that aren't compatible are derived from the Android source code and aren't permitted to use the Android trademark.
In other words, compatibility is a prerequisite for participation in the Android apps ecosystem. Anyone is welcome to use the Android source code. But if the device isn't compatible, it isn't considered part of the Android ecosystem.
What's the role of Google Play in compatibility?
Device manufacturers with Android-compatible devices can seek to license the Google Play client software. Licensed devices become part of the Android app ecosystem, enabling their users to download developers' apps from a catalog shared by all compatible devices. Licensing isn't available to incompatible devices.
What types of devices can be Android compatible?
Android software can be ported to many different devices, including some on which third-party apps won't run properly. The Android Compatibility Definition Document (CDD) spells out the specific device configurations that are considered compatible.
For example, though the Android source code could be ported to run on a phone that doesn't have a camera, the CDD requires all phones to have a camera. This allows developers to rely on a consistent set of capabilities when writing their apps.
The CDD continues to evolve to reflect market realities. For instance, version 1.6 of the CDD supports only cell phones. But version 2.1 allows devices to omit telephony hardware, enabling non-phone devices such as tablet-style music players to be compatible. As we make these changes, we'll also augment Google Play to allow developers to retain control over where their apps are available. To continue the telephony example, an app that manages SMS text messages isn't useful on a media player, so Google Play allows the developer to restrict that app exclusively to phone devices.
If my device is compatible, does it automatically have access to Google Play and branding?
No. Access isn't automatic. Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. After a device is qualified as an Android-compatible device, the device manufacturer should complete the contact form included in licensing Google Mobile Services to seek access to Google Play. We'll be in contact if we can help you.
If I'm not a manufacturer, how can I get Google Play?
Google Play is licensed only to handset manufacturers shipping devices. For questions about specific cases, contact firstname.lastname@example.org.
How can I get access to Google apps for Android, such as Maps?
Google apps for Android such as, for example, YouTube, Google Maps, and Gmail are Google properties that aren't part of Android and are licensed separately. For inquiries related to these apps, contact email@example.com.
Is compatibility mandatory?
No. The Android Compatibility Program is optional. The Android source code is open, so anyone can use it to build any kind of device. However, if manufacturers wish to use the Android name with their products, or want access to Google Play, they must first demonstrate that their devices are compatible.
How much does compatibility certification cost?
There's no cost to obtain Android compatibility for a device. The Compatibility Test Suite is open-source and available to anyone for device testing.
How long does compatibility take?
The process is automated. The Compatibility Test Suite generates a report that can be provided to Google to verify compatibility. Eventually we intend to provide self-service tools to upload these reports to a public database.
Who determines the compatibility definition?
Google is responsible for the overall direction of Android as a platform and product, so Google maintains the Compatibility Definition Document (CDD) for each release. We draft the CDD for a new Android version in consultation with various OEMs who provide input.
How long will each Android version be supported for new devices?
Android's code is open source, so we can't prevent someone from using an old version to launch a device. Instead, Google chooses not to license the Google Play client software for use on versions that are considered obsolete. This allows anyone to continue to ship old versions of Android, but those devices won't use the Android name and exist outside of the Android apps ecosystem, just as if they weren't compatible.
Can a device have a different user interface and still be compatible?
The Android Compatibility Program determines whether a device can run third-party apps. The user interface components shipped with a device (such as home screen, dialer, and color scheme) don't generally have much effect on third-party apps. As such, device builders are free to customize the user interface. The Compatibility Definition Document restricts the degree to which OEMs are permitted to alter the system user interface for areas that impact third-party apps.
When are compatibility definitions released for new Android versions?
Our goal is to release a new version of the Android Compatibility Definition Document (CDD) when the corresponding Android platform version has converged enough to permit it. While we can't release a final draft of a CDD for an Android software version before the first flagship device ships with that software, final CDDs are always released after the first device. However, wherever practical we release draft versions of CDDs.
How are device manufacturers' compatibility claims validated?
There is no validation process for Android device compatibility. However, if the device is to include Google Play, Google typically validates the device for compatibility before agreeing to license the Google Play client software.
What happens if a device that claims compatibility is later found to have compatibility problems?
Typically, Google's relationships with Google Play licensees allow us to ask the device manufacturer to release updated system images that fix the problems.
Compatibility Test Suite (CTS)
What's the purpose of the CTS?
The Compatibility Test Suite is a tool used by device manufacturers to help ensure that their devices are compatible, and to report test results for validations. The CTS is intended to be run frequently by OEMs throughout the engineering process to catch compatibility issues early.
What kinds of things does the CTS test?
The CTS currently tests that all of the supported Android strong-typed APIs are present and behave correctly. It also tests other non-API system behaviors such as app lifecycle and performance. We plan to add support in future CTS versions to test soft APIs such as intents.
Will the CTS reports be made public?
Yes. While not currently implemented, Google intends to provide web-based self-service tools for OEMs to publish CTS reports so that anyone can view them. Manufacturers can share CTS reports with as wide an audience as they like.
How is the CTS licensed?
The CTS is licensed under the same Apache Software License 2.0 that the bulk of Android uses.
Does the CTS accept contributions?
Yes, please! The AOSP accepts contributions to improve the CTS just as for any other component. In fact, improving the coverage and quality of the CTS test cases is one of the best ways to help Android.
Can anyone use the CTS on existing devices?
The Compatibility Definition Document requires that compatible devices
adb debugging utility. This means that any compatible
device (including those available at retail) must be able to run the CTS
Are codecs verified by CTS?
Yes. All mandatory codecs are verified by CTS.