pdk/docs/faqs.jd - platform/development - Git at Google

 page.title=Frequently Asked Questions
 doc.hidenav=true
 @jd:body
 <a name="aosp"></a><h2>Open Source</h2>
 <h3>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 that you can use to build
   cell phone and other devices.</p>

 <h3>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 that 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 that there was no
 central point of failure, so that 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>
 <p>You can find more information on this topic at our Project Philosophy page.</p>

 <h3>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 at our Project Philosophy and
   Licensing pages. </p>

 <h3>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 end 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 that great
   devices running Android actually make it to market.</p>
 <p>By making sure that Android is a success with end 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, but no
   one is required to participate, of course. We opened the Android source code
   so anyone can modify and distribute the software to meet their own needs.</p>

 <h3>What is Google's overall strategy for Android product development?</h3>
 <p>We focus on releasing great devices into a competitive marketplace, and
   then incorporate the innovations and enhancements we made into the core
   platform, as the next version.</p>
 <p>In practice, this means that 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 that the Android platform evolves
   according to the actual needs of real-world devices.</p>

 <h3>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 Branches Releases
   page.</p>

 <h3>Why are parts of Android developed in private?</h3>
 <p>It typically takes over a year to bring a device to market, but of course
   device manufacturers want to ship the latest software they can. Developers,
   meanwhile, don't want to have 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 refine the next version
   of the platform using the flagship Android devices. This allows developers
   and OEMs to focus on a single version without having to track 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>When are source code releases made?</h3>
 <p>When they are ready. Some parts of Android are developed in the open, and
   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 in advance of the
   device's release; however in others, 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. Releasing the source code is a
   fairly complex process.</p>

 <h3>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>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 final API changes
   and documentation (to reflect any changes 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 IP ownership of their contribution,
   Google too must verify that it is clear to make contributions.</p>
 <p>Starting at the time mass production begins, the software release process
   usually takes around a month, which often roughly places source code
   releases around the same time that the devices reach users.</p>

 <h3>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 ship 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 Android Market; 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 call themselves "Android" and participate in
   the Android ecosystem.</p>

 <h3>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 on 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 is focused on applications that run
   in the Dalvik VM. Alternatively, 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 AOSP Community page prior to beginning any work. You can find more
   information on this topic at the Getting Involved page.</p>

 <h3>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 Submitting Patches
   page.</p>

 <a name="compatibility"></a><h2>Compatibility</h2>
 <h3>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, and irrelevant to developers.</p>

 <h3>What is the role of Android Market in compatibility?</h3>
 <p>Devices that are Android compatible may seek to license the Android Market
   client software. This allows them to become part of the Android app
   ecosystem, by allowing 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>What kinds of devices can be Android compatible?</h3>
 <p>The Android software can be ported to a lot of different kinds of 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 will be considered compatible.</p>
 <p>For example, though the Android source code could be ported to run on a
   device that doesn't have a camera, the CDD requires that in order to be
   compatible, all devices must have a camera. This allows developers to rely
   on a consistent set of device capabilities when writing their apps.</p>
 <p>The CDD will evolve over time to reflect market realities. For instance,
   the 1.6 CDD only allows cell phones, but the 2.x CDD allows devices to omit
   telephony hardware, allowing for non-phone devices such as tablet-style
   music players to be compatible. As we make these changes, we will also
   augment Android Market 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 Android
   Market allows the developer to restrict that app exclusively to phone
   devices.</p>

 <h3>If my device is compatible, does it automatically have access to Android Market and branding?</h3>
 <p>Android Market is a service operated by Google. For legal and business
   reasons, Google isn't able to make that service available in all parts of
   the world. Similarly, Google is unable to license the Android trademark for
   use in all cases.</p>
 <p>As a result, achieving compatibility does not automatically entitle a
   device to include Android Market or use the Android name. Device
   manufacturers should contact Google to obtain access to those tools.</p>

 <h3>If I am not a manufacturer, how can I get Android Market?</h3>
 <p>Android Market is only licensed to handset manufacturers shipping devices.
   For questions about specific cases, contact
   android-partnerships@google.com.</p>

 <h3>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 and Navigation,
   Gmail, and so on are not part of Android, and are licensed separately.
   Contact android-partnerships@google.com for inquiries related to those
   apps.</p>

 <h3>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 a
   manufacturer wishes to use the Android name with their product, or wants
   access to Android Market, they must first demonstrate that the device is
   compatible.</p>

 <h3>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 to use to
   test a device.</p>

 <h3>How long does compatibility take?</h3>
 <p>The process is automatic. 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>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 a number of OEMs, who provide input on its contents.</p>

 <h3>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
   Android Market 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>Can a device have a different user interface and still be compatible?</h3>
 <p>The Android Compatibility Program focuses on 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) does 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 the few areas that do impact third-party apps.</p>

 <h3>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. Since the CDDs</p>

 <h3>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 Android Market, Google will typically validate
   the device for compatibility before agreeing to license the Market client
   software.</p>

 <h3>What happens if a device that claims compatibility is later found to have compatibility problems?</h3>
 <p>Typically, Google's relationships with Android Market licensees allow us to
   ask them to release updated system images that fix the problems.</p>

 <a name="cts"></a><h2>Compatibility Test Suite</h2>
 <h3>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>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>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>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>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>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>
	page.title=Frequently Asked Questions
	doc.hidenav=true
	@jd:body
	<a name="aosp"></a><h2>Open Source</h2>
	<h3>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 that you can use to build
	cell phone and other devices.</p>

	<h3>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 that 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 that there was no
	central point of failure, so that 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>
	<p>You can find more information on this topic at our Project Philosophy page.</p>

	<h3>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 at our Project Philosophy and
	Licensing pages. </p>

	<h3>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 end 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 that great
	devices running Android actually make it to market.</p>
	<p>By making sure that Android is a success with end 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, but no
	one is required to participate, of course. We opened the Android source code
	so anyone can modify and distribute the software to meet their own needs.</p>

	<h3>What is Google's overall strategy for Android product development?</h3>
	<p>We focus on releasing great devices into a competitive marketplace, and
	then incorporate the innovations and enhancements we made into the core
	platform, as the next version.</p>
	<p>In practice, this means that 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 that the Android platform evolves
	according to the actual needs of real-world devices.</p>

	<h3>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 Branches Releases
	page.</p>

	<h3>Why are parts of Android developed in private?</h3>
	<p>It typically takes over a year to bring a device to market, but of course
	device manufacturers want to ship the latest software they can. Developers,
	meanwhile, don't want to have 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 refine the next version
	of the platform using the flagship Android devices. This allows developers
	and OEMs to focus on a single version without having to track 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>When are source code releases made?</h3>
	<p>When they are ready. Some parts of Android are developed in the open, and
	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 in advance of the
	device's release; however in others, 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. Releasing the source code is a
	fairly complex process.</p>

	<h3>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>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 final API changes
	and documentation (to reflect any changes 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 IP ownership of their contribution,
	Google too must verify that it is clear to make contributions.</p>
	<p>Starting at the time mass production begins, the software release process
	usually takes around a month, which often roughly places source code
	releases around the same time that the devices reach users.</p>

	<h3>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 ship 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 Android Market; 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 call themselves "Android" and participate in
	the Android ecosystem.</p>

	<h3>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 on 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 is focused on applications that run
	in the Dalvik VM. Alternatively, 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 AOSP Community page prior to beginning any work. You can find more
	information on this topic at the Getting Involved page.</p>

	<h3>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 Submitting Patches
	page.</p>

	<a name="compatibility"></a><h2>Compatibility</h2>
	<h3>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, and irrelevant to developers.</p>

	<h3>What is the role of Android Market in compatibility?</h3>
	<p>Devices that are Android compatible may seek to license the Android Market
	client software. This allows them to become part of the Android app
	ecosystem, by allowing 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>What kinds of devices can be Android compatible?</h3>
	<p>The Android software can be ported to a lot of different kinds of 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 will be considered compatible.</p>
	<p>For example, though the Android source code could be ported to run on a
	device that doesn't have a camera, the CDD requires that in order to be
	compatible, all devices must have a camera. This allows developers to rely
	on a consistent set of device capabilities when writing their apps.</p>
	<p>The CDD will evolve over time to reflect market realities. For instance,
	the 1.6 CDD only allows cell phones, but the 2.x CDD allows devices to omit
	telephony hardware, allowing for non-phone devices such as tablet-style
	music players to be compatible. As we make these changes, we will also
	augment Android Market 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 Android
	Market allows the developer to restrict that app exclusively to phone
	devices.</p>

	<h3>If my device is compatible, does it automatically have access to Android Market and branding?</h3>
	<p>Android Market is a service operated by Google. For legal and business
	reasons, Google isn't able to make that service available in all parts of
	the world. Similarly, Google is unable to license the Android trademark for
	use in all cases.</p>
	<p>As a result, achieving compatibility does not automatically entitle a
	device to include Android Market or use the Android name. Device
	manufacturers should contact Google to obtain access to those tools.</p>

	<h3>If I am not a manufacturer, how can I get Android Market?</h3>
	<p>Android Market is only licensed to handset manufacturers shipping devices.
	For questions about specific cases, contact
	android-partnerships@google.com.</p>

	<h3>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 and Navigation,
	Gmail, and so on are not part of Android, and are licensed separately.
	Contact android-partnerships@google.com for inquiries related to those
	apps.</p>

	<h3>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 a
	manufacturer wishes to use the Android name with their product, or wants
	access to Android Market, they must first demonstrate that the device is
	compatible.</p>

	<h3>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 to use to
	test a device.</p>

	<h3>How long does compatibility take?</h3>
	<p>The process is automatic. 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>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 a number of OEMs, who provide input on its contents.</p>

	<h3>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
	Android Market 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>Can a device have a different user interface and still be compatible?</h3>
	<p>The Android Compatibility Program focuses on 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) does 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 the few areas that do impact third-party apps.</p>

	<h3>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. Since the CDDs</p>

	<h3>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 Android Market, Google will typically validate
	the device for compatibility before agreeing to license the Market client
	software.</p>

	<h3>What happens if a device that claims compatibility is later found to have compatibility problems?</h3>
	<p>Typically, Google's relationships with Android Market licensees allow us to
	ask them to release updated system images that fix the problems.</p>

	<a name="cts"></a><h2>Compatibility Test Suite</h2>
	<h3>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>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>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>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>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>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>