page.title=Frequently Asked Questions
@jd:body

<!--
    Copyright 2013 The Android Open Source Project

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
-->
<div id="qv-wrapper">
  <div id="qv">
    <h2>In this document</h2>
    <ol id="auto-toc">
    </ol>
  </div>
</div>

<a name="top"></a>
<p>Please see the <a
href="http://developer.android.com/guide/faq/index.html">Android FAQs</a> on
developer.android.com for answers to other common questions.

<h2 id="open-source">Open Source</h2>
<h3 id="what-is-the-android-open-source-project">What is the Android Open Source Project?</h3>
<p>We use the phrase "Android Open Source Project" or "AOSP" to refer to the
people, the processes, and the source code that make up Android.</p>
<p>The people oversee the project and develop the actual source code. The
processes refer to the tools and procedures we use to manage the development
of the software. The net result is the source code you can use to build
mobile phones and other devices.</p>
<h3 id="why-did-we-open-the-android-source-code">Why did we open the Android source code?</h3>
<p>Google started the Android project 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 make sure there was no
central point of failure, so no single industry player could restrict or control
the innovations of any other.  The single most important goal of the Android
Open Source Project (AOSP) is to make sure that the open-source Android
software is implemented as widely and compatibly as possible, to everyone's
benefit.</p>
<h3 id="what-kind-of-open-source-project-is-android">What kind of open-source project is Android?</h3>
<p>Google oversees the development of the core Android open-source platform
and works to create robust developer and user communities. For the most part,
the Android source code is licensed under the permissive Apache Software
License 2.0, rather than a "copyleft" license. The main reason for this is
because our most important goal is widespread adoption of the software, and
we believe that the ASL2.0 license best achieves that goal.</p>
<p>You can find more information on this topic on our <a href="{@docRoot}source/licenses.html">Licenses</a> page.</p>
<h3 id="why-is-google-in-charge-of-android">Why is Google in charge of Android?</h3>
<p>Launching a software platform is complex. Openness is vital to the
long-term success of a platform, since openness is required to attract
investment from developers and ensure a level playing field. However, the
platform itself must also be a compelling product to users.</p>
<p>That's why 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 actually make it to market.</p>
<p>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?</p>
<p>Google's goal is to ensure a successful ecosystem around Android. Of course, no
one is required to participate. We opened the Android source code
so anyone can modify and distribute the software to meet their own needs.</p>
<h3 id="what-is-googles-overall-strategy-for-android-product-development">What is Google's overall strategy for Android product development?</h3>
<p>We aim to release great devices into a competitive marketplace. We
then incorporate the innovations and enhancements we made into the core
platform as the next version.</p>
<p>In practice, this means the Android engineering team typically focuses
on a small number of "flagship" devices and develops the next version of
the 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 many more devices that take advantage of the
new features. In this way, we make sure the Android platform evolves
according to the actual needs of real-world devices.</p>
<h3 id="how-is-the-android-software-developed">How is the Android software developed?</h3>
<p>Each platform version of Android (such as 1.5, 1.6, and so on) has a
corresponding branch in the open-source tree. At any given moment, the most
recent such branch will be considered the "current stable" branch version.
This current stable branch is the one that manufacturers port to their
devices. This branch is kept suitable for release at all times.</p>
<p>Simultaneously, there is also 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.</p>
<p>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.</p>
<p>You can find more information on this topic at our <a href="{@docRoot}source/code-lines.html">Codelines,
Branches and Releases</a> page.</p>
<h3 id="why-are-parts-of-android-developed-in-private">Why are parts of Android developed in private?</h3>
<p>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. Developers,
meanwhile, 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.</p>
<p>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 application compatibility are developed in the open, however.
It's our intention to move more of these parts to open development over
time.</p>
<h3 id="when-are-source-code-releases-made">When are source code releases made?</h3>
<p>When they are ready. Releasing the source code is a fairly complex process.
Some parts of Android are developed in the open,
so 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.</p>
<p>In some releases, core platform APIs will be ready far enough in advance
that we can push the source code out for an early look prior to the
device's release; however in other releases, this isn't possible. In all cases, we
release the platform source when we feel the version has stabilized enough,
and when the development process permits.</p>
<h3 id="what-is-involved-in-releasing-the-source-code-for-a-new-android-version">What is involved in releasing the source code for a new Android version?</h3>
<p>Releasing the source code for a new version of the Android platform is a
significant process. First, the software gets 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. It also goes through operator testing. This is an important phase
of the process, since it helps shake out a lot of software bugs.</p></p>
<p>Once the release is approved by the regulators and operators, the
manufacturer begins mass producing devices, and we turn to releasing the
source code.</p>
<p>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.</p>
<p>Also included is a final legal 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 too must verify it is clear to make contributions.</p>
<p>From the time mass production begins, the software release process
usually takes around a month. This often places source code releases
around the same time the devices reach users.</p>
<h3 id="how-does-the-aosp-relate-to-the-android-compatibility-program">How does the AOSP relate to the Android Compatibility Program?</h3>
<p>The Android Open Source Project maintains the Android software, and
develops new versions. Since it's open-source, this software can be used for
any purpose, including to develop devices that are not compatible with other
devices based on the same source.</p>
<p>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" may participate in the
Android ecosystem, including Google Play; devices that don't meet the
compatibility requirements exist outside that ecosystem.</p>
<p>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 only
Android-compatible devices -- as defined and tested by the Android
Compatibility Program -- may participate in the Android ecosystem.</p>
<h3 id="how-can-i-contribute-to-android">How can I contribute to Android?</h3>
<p>There are a number of ways you can contribute to Android. You can report
bugs, write apps for Android, or contribute source code to the Android
Open Source Project.</p>
<p>There are some limits to the kinds of code contributions we are willing or
able to accept. For instance, someone might want to contribute an
alternative application API, such as a full C++-based environment. We would
decline that contribution, since Android encourages applications 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.</p>
<p>We encourage those interested in contributing source code to contact us
via the channels listed on the <a href="{@docRoot}source/community/index.html">
Android Community</a> page prior to beginning any work. You can find more
information on this topic from the <a href="{@docRoot}source/contributing.html">
Contributing</a> page.</p>
<h3 id="how-do-i-become-an-android-committer">How do I become an Android committer?</h3>
<p>The Android Open Source Project 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.</p>
<p>Once submitted, changes need to be accepted by a designated Approver.
Approvers are typically Google employees, but the same approvers are
responsible for all submissions, regardless of origin.</p>
<p>You can find more information on this topic at the <a href="submit-patches.html">Submitting Patches</a> page.</p>
<a href="#top">Back to top</a>  
<h2 id="compatibility">Compatibility</h2>
<h3 id="what-does-compatibility-mean">What does "compatibility" mean?</h3>
<p>We define an "Android-compatible device" as one that can run any
application 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 cannot. Devices that are properly
compatible can seek approval to use the Android trademark. Devices that are
not compatible are merely derived from the Android source code and may not
use the Android trademark.</p>
<p>In other words, compatibility is a prerequisite to participate in the
Android apps ecosystem. Anyone is welcome to use the Android source code.
But if the device isn't compatible, it's not considered part of the Android
ecosystem.</p>
<h3 id="what-is-the-role-of-google-play-in-compatibility">What is the role of Google Play in compatibility?</h3>
<p>Devices that are Android compatible may seek to license the Google Play
client software. This allows them to become part of the Android app
ecosystem, enabling their users to download developers' apps from a catalog
shared by all compatible devices. This option isn't available to devices
that aren't compatible.</p>
<h3 id="what-kinds-of-devices-can-be-android-compatible">What kinds of devices can be Android compatible?</h3>
<p>The Android software can be ported to many different kinds of devices,
including some on which third-party apps won't run properly. The
<a href="{@docRoot}compatibility/index.html">Android Compatibility Definition
Document</a> (CDD) spells out the specific device configurations that will be
considered compatible.</p>
<p>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.</p>
<p>The CDD will evolve over time to reflect market realities. For instance,
version 1.6 of the CDD supports only cell phones. But the 2.1 CDD 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 will 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 would not be useful on a media player, so Google
Play allows the developer to restrict that app exclusively to phone
devices.</p>
<h3 id="if-my-device-is-compatible-does-it-automatically-have-access-to-google-play-and-branding">If my device is compatible, does it automatically have access to Google Play and branding?</h3>
<p>Google Play is a service operated by Google. Achieving compatibility is
a prerequisite for obtaining access to the Google Play software and branding.
Device manufacturers should contact <a
href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>
to obtain access to Google Play. While we read every email that is received at
this alias, we cannot respond to each of them. Please note, we will be in
contact if we can help you.</p>
<h3 id="if-i-am-not-a-manufacturer-how-can-i-get-google-play">If I am not a manufacturer, how can I get Google Play?</h3>
<p>Google Play is only licensed to handset manufacturers shipping devices.
For questions about specific cases, contact <a
href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>.</p>
<h3 id="how-can-i-get-access-to-the-google-apps-for-android-such-as-maps">How can I get access to the Google apps for Android, such as Maps?</h3>
<p>The Google apps for Android, such as YouTube, Google Maps,
Gmail, and more, are Google properties that are not part of Android and
are licensed separately.  Contact <a
href="mailto:android-partnerships@google.com">android-partnerships@google.com</a>
for inquiries related to those apps.</p>
<h3 id="is-compatibility-mandatory">Is compatibility mandatory?</h3>
<p>No. The Android Compatibility Program is optional. Since the Android source
code is open, 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 their devices are compatible.</p>
<h3 id="how-much-does-compatibility-certification-cost">How much does compatibility certification cost?</h3>
<p>There is no cost to obtain Android compatibility for a device. The
Compatibility Test Suite is open-source and available to anyone for device testing.</p>
<h3 id="how-long-does-compatibility-take">How long does compatibility take?</h3>
<p>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.</p>
<h3 id="who-determines-what-will-be-part-of-the-compatibility-definition">Who determines what will be part of the compatibility definition?</h3>
<p>Since Google is responsible for the overall direction of Android as a
platform and product, Google maintains the Compatibility Definition Document
for each release. We draft the CDD for a new Android version in consultation
with various OEMs who provide input on its contents.</p>
<h3 id="how-long-will-each-android-version-be-supported-for-new-devices">How long will each Android version be supported for new devices?</h3>
<p>Since Android's code is open-source, 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 will exist outside the
Android apps ecosystem, just as if they were non-compatible.</p>
<h3 id="can-a-device-have-a-different-user-interface-and-still-be-compatible">Can a device have a different user interface and still be compatible?</h3>
<p>The Android Compatibility Program determines whether a device can run
third-party applications. The user interface components shipped with a
device (such as home screen, dialer, color scheme, and so on) do not
generally have much effect on third-party apps. As such, device builders are
free to customize the user interface as much as they like. The Compatibility
Definition Document does restrict the degree to which OEMs may alter the
system user interface for areas that do impact third-party apps.</p>
<h3 id="when-are-compatibility-definitions-released-for-new-android-versions">When are compatibility definitions released for new Android versions?</h3>
<p>Our goal is to release new versions of Android Compatibility Definition
Documents (CDDs) once 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 will always be released after the first device.
However, wherever practical we will make draft versions of CDDs available.</p>
<h3 id="how-are-device-manufacturers-compatibility-claims-validated">How are device manufacturers' compatibility claims validated?</h3>
<p>There is no validation process for Android device compatibility. However,
if the device is to include Google Play, Google will typically validate
the device for compatibility before agreeing to license the Google Play client
software.</p>
<h3 id="what-happens-if-a-device-that-claims-compatibility-is-later-found-to-have-compatibility-problems">What happens if a device that claims compatibility is later found to have compatibility problems?</h3>
<p>Typically, Google's relationships with Google Play licensees allow us to
ask them to release updated system images that fix the problems.</p>
<a href="#top">Back to top</a>
<h2 id="compatibility-test-suite">Compatibility Test Suite</h2>
<h3 id="what-is-the-purpose-of-the-cts">What is the purpose of the CTS?</h3>
<p>The Compatibility Test Suite is a tool used by device manufacturers to help
ensure 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.</p>
<h3 id="what-kinds-of-things-does-the-cts-test">What kinds of things does the CTS test?</h3>
<p>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 application lifecycle and performance. We plan to add
support in future CTS versions to test "soft" APIs such as Intents as
well.</p>
<h3 id="will-the-cts-reports-be-made-public">Will the CTS reports be made public?</h3>
<p>Yes. While not currently implemented, Google intends to provide web-based
self-service tools for OEMs to publish CTS reports so that they can be
viewed by anyone. CTS reports can be shared as widely as manufacturers
prefer.</p>
<h3 id="how-is-the-cts-licensed">How is the CTS licensed?</h3>
<p>The CTS is licensed under the same Apache Software License 2.0 that the
bulk of Android uses.</p>
<h3 id="does-the-cts-accept-contributions">Does the CTS accept contributions?</h3>
<p>Yes please! The Android Open Source Project accepts contributions to
improve the CTS in the same way 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 out Android.</p>
<h3 id="can-anyone-use-the-cts-on-existing-devices">Can anyone use the CTS on existing devices?</h3>
<p>The Compatibility Definition Document requires that compatible devices
implement the 'adb' debugging utility. This means that any compatible device
-- including ones available at retail -- must be able to run the CTS
tests.</p>
<h3 id="are-codecs-verified">Are codecs verified by CTS?</h3>
<p>Yes. All mandatory codecs are verified by CTS.</p>

<a href="#top">Back to top</a>