1page.title=Compatibility Program Overview 2doc.type=compatibility 3@jd:body 4<p>The Android compatibility program makes it easy for mobile device 5manufacturers to develop compatible Android devices.</p> 6<h3>Program goals</h3> 7<p>The Android compatibility program works for the benefit of the entire 8Android community, including users, developers, and device manufacturers.</p> 9<p>Each group depends on the others. Users want a wide selection of devices 10and great apps; great apps come from developers motivated by a large market 11for their apps with many devices in users' hands; device manufacturers rely 12on a wide variety of great apps to increase their products' value for 13consumers.</p> 14<p>Our goals were designed to benefit each of these groups:</p> 15<ul> 16<li><b>Provide a consistent application and hardware environment to application 17developers.</b><p>Without a strong compatibility standard, devices can vary so 18greatly that developers must design different versions of their applications 19for different devices. The compatibility program provides a precise definition 20of what developers can expect from a compatible device in terms of APIs and 21capabilities. Developers can use this information to make good design 22decisions, and be confident that their apps will run well on any compatible 23device.</p></li> 24<li><b>Enable a consistent application experience for consumers.</b><p>If an 25application runs well on one compatible Android device, it should run well on 26any other device that is compatible with the same Android platform version. 27Android devices will differ in hardware and software capabilities, so the 28compatibility program also provides the tools needed for distribution systems 29such as Android Market to implement appropriate filtering. This means that 30users can only see applications which they can actually run.</p></li> 31<li><b>Enable device manufacturers to differentiate while being 32compatible.</b><p>The Android compatibility program focuses on the aspects of 33Android relevant to running third-party applications, which allows device 34manufacturers the flexibility to create unique devices that are nonetheless 35compatible.</p></li> 36<li><b>Minimize costs and overhead associated with 37compatibility.</b><p>Ensuring compatibility should be easy and inexpensive to 38device manufacturers. The testing tool (CTS) is free, open source, and 39available for <a href="{@docRoot}compatibility/downloads.html">download</a>. 40CTS is designed to be used for continuous self-testing 41during the device development process to eliminate the cost of changing your 42workflow or sending your device to a third party for testing. Meanwhile, there 43are no required certifications, and thus no corresponding costs and 44fees.</p></li> 45</ul> 46<p>The Android compatibility program consists of three key components:</p> 47<ul> 48<li>The source code to the Android software stack</li> 49<li>The Compatilbility Definition Document, representing the "policy" 50aspect of compatibility</li> 51<li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li> 52</ul> 53<p>Just as each version of the Android platform exists in a separate branch in 54the source code tree, there is a separate CTS and CDD for each version as 55well. The CDD, CTS, and source code are -- along with your hardware and your 56software customizations -- everything you need to create a compatible device.</p> 57 58<h3>Compatibility Definition Document (CDD)</h3> 59<p>For each release of the Android platform, a detailed Compatibility 60Definition Document (CDD) will be provided. The CDD represents the "policy" 61aspect of Android compatibility.</p> 62<p>No test suite, including CTS, can truly be comprehensive. For instance, the 63CTS includes a test that checks for the presence and correct behavior of 64OpenGL graphics APIs, but no software test can verify that the graphics 65actually appear correctly on the screen. More generally, it's impossible to 66test the presence of hardware features such as keyboards, display density, 67WiFi, and Bluetooth.</p> 68<p>The CDD's role is to codify and clarify specific requirements, and 69eliminate ambiguity. The CDD does not attempt to be comprehensive. Since 70Android is a single corpus of open-source code, the code itself is the 71comprehensive "specification" of the platform and its APIs. The CDD acts as a 72"hub", referencing other content (such as SDK API documentation) that provides 73a framework in which the Android source code may be used so that the end 74result is a compatible system.</p> 75<p>If you want to build a device compatible with a given Android version, 76start by checking out the source code for that version, and then read the 77corresponding CDD and stay within its guidelines. For additional details, 78simply examine <a href="">the latest CDD</a>.</p> 79 80<h3>Compatibility Test Suite (CTS)</h3> 81<p>The CTS is a free, commercial-grade test suite, available for 82<a href="{@docRoot}compatibility/downloads.html">download</a>. 83The CTS represents the "mechanism" of compatibility.</p> 84<p>The CTS runs on a desktop machine and executes test cases directly on 85attached devices or an emulator. The CTS is a set of unit tests designed to be 86integrated into the daily workflow (such as via a continuous build system) of 87the engineers building a device. Its intent is to reveal incompatibilities 88early on, and ensure that the software remains compatible throughout the 89development process.</p> 90<p>For details on the CTS, consult the <a 91href="{@docRoot}compatibility/cts-intro.html">CTS introduction</a>.</p> 92