1 files changed, 328 insertions, 0 deletions
diff --git a/en/setup/faqs.html b/en/setup/faqs.html
new file mode 100644
index 00000000..938f07c5
--- /dev/null
+++ b/en/setup/faqs.html
@@ -0,0 +1,328 @@
+<html devsite>
+  <head>
+    <title>Frequently Asked Questions</title>
+    <meta name="project_path" value="/_project.yaml" />
+    <meta name="book_path" value="/_book.yaml" />
+  </head>
+  <body>
+  <!--
+      Copyright 2017 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.
+  -->
+
+
+
+<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="/setup/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="/setup/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="/setup/community.html">
+Android Community</a> page prior to beginning any work. You can find more
+information on this topic from the <a href="/setup/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="/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 complete the contact form included in <a
+href="/compatibility/contact-us#for-business-inquiries">licensing Google Mobile
+Services</a> to seek access to Google Play. 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>
+
+  </body>
+</html>