Work-in-progress snapshot of the source.android.com (formerly PDK) site
refresh.
diff --git a/pdk/docs/compatibility/overview.jd b/pdk/docs/compatibility/overview.jd
new file mode 100644
index 0000000..039e2c2
--- /dev/null
+++ b/pdk/docs/compatibility/overview.jd
@@ -0,0 +1,88 @@
+page.title=Compatibility Program Overview
+doc.type=compatibility
+@jd:body
+<p>The Android compatibility program makes it easy for mobile device
+manufacturers to develop compatible Android devices.</p>
+<h3>Program goals</h3>
+<p>The Android compatibility program works for the benefit of the entire
+Android community, including users, developers, and device manufacturers.</p>
+<p>Each group depends on the others. Users want a wide selection of devices
+and great apps; great apps come from developers motivated by a large market
+for their apps with many devices in users' hands; device manufacturers rely
+on a wide variety of great apps to increase their products' value for
+consumers.</p>
+<p>Our goals were designed to benefit each of these groups:</p>
+<ul>
+<li><b>Provide a consistent application and hardware environment to application
+developers.</b><p>Without a strong compatibility standard, devices can vary so
+greatly that developers must design different versions of their applications
+for different devices. The compatibility program provides a precise definition
+of what developers can expect from a compatible device in terms of APIs and
+capabilities. Developers can use this information to make good design
+decisions, and be confident that their apps will run well on any compatible
+device.</p></li>
+<li><b>Enable a consistent application experience for consumers.</b><p>If an
+application runs well on one compatible Android device, it should run well on
+any other device that is compatible with the same Android platform version.
+Android devices will differ in hardware and software capabilities, so the
+compatibility program also provides the tools needed for distribution systems
+such as Android Market to implement appropriate filtering. This means that
+users can only see applications which they can actually run.</p></li>
+<li><b>Enable device manufacturers to differentiate while being
+compatible.</b><p>The Android compatibility program focuses on the aspects of
+Android relevant to running third-party applications, which allows device
+manufacturers the flexibility to create unique devices that are nonetheless
+compatible.</p></li>
+<li><b>Minimize costs and overhead associated with
+compatibility.</b><p>Ensuring compatibility should be easy and inexpensive to
+device manufacturers. The testing tool (CTS) is free and will soon be available
+in open source. CTS is designed to be used for continuous self-testing during
+the device development process to eliminate the cost of changing your workflow
+or sending your device to a third party for testing. Meanwhile, there are no
+required certifications, and thus no corresponding costs and fees.</p></li>
+</ul>
+<p>The Android compatibility program consists of three key components:</p>
+<ul>
+<li>The source code to the Android software stack</li>
+<li>The Compatilbility Definition Document, representing the "policy"
+aspect of compatibility</li>
+<li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li>
+</ul>
+<p>Just as each version of the Android platform exists in a separate branch in
+the source code tree, there is a separate CTS and CDD for each version as
+well. The CDD, CTS, and source code are -- along with your hardware and your
+software customizations -- everything you need to create a compatible device.</p>
+
+<h3>Compatibility Definition Document (CDD)</h3>
+<p>For each release of the Android platform, a detailed Compatibility
+Definition Document (CDD) will be provided. The CDD represents the "policy"
+aspect of Android compatibility.</p>
+<p>No test suite, including CTS, can truly be comprehensive. For instance, the
+CTS includes a test that checks for the presence and correct behavior of
+OpenGL graphics APIs, but no software test can verify that the graphics
+actually appear correctly on the screen. More generally, it's impossible to
+test the presence of hardware features such as keyboards, display density,
+WiFi, and Bluetooth.</p>
+<p>The CDD's role is to codify and clarify specific requirements, and
+eliminate ambiguity. The CDD does not attempt to be comprehensive. Since
+Android is a single corpus of open-source code, the code itself is the
+comprehensive "specification" of the platform and its APIs. The CDD acts as a
+"hub", referencing other content (such as SDK API documentation) that provides
+a framework in which the Android source code may be used so that the end
+result is a compatible system.</p>
+<p>If you want to build a device compatible with a given Android version,
+start by checking out the source code for that version, and then read the
+corresponding CDD and stay within its guidelines. For additional details,
+simply examine <a href="">the latest CDD</a>.</p>
+
+<h3>Compatibility Test Suite (CTS)</h3>
+<p>The CTS is a free, commercial-grade test suite, available along with the
+Android source code. The CTS represents the "mechanism" of compatibility.</p>
+<p>The CTS runs on a desktop machine and executes test cases directly on
+attached devices or an emulator. The CTS is a set of unit tests designed to be
+integrated into the daily workflow (such as via a continuous build system) of
+the engineers building a device. Its intent is to reveal incompatibilities
+early on, and ensure that the software remains compatible throughout the
+development process.</p>
+<p>For details on the CTS, consult the <a
+href="{@docRoot}compatibility/cts-intro.html">CTS introduction</a>.</p>