Additional content massaging based on feedback received.
diff --git a/pdk/docs/faqs.jd b/pdk/docs/faqs.jd
new file mode 100644
index 0000000..a55d380
--- /dev/null
+++ b/pdk/docs/faqs.jd
@@ -0,0 +1,325 @@
+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>