Robert Ly | 35f2fda | 2013-01-29 16:27:05 -0800 | [diff] [blame^] | 1 | page.title=Compatibility Program Overview |
| 2 | @jd:body |
| 3 | |
| 4 | <!-- |
| 5 | Copyright 2010 The Android Open Source Project |
| 6 | |
| 7 | Licensed under the Apache License, Version 2.0 (the "License"); |
| 8 | you may not use this file except in compliance with the License. |
| 9 | You may obtain a copy of the License at |
| 10 | |
| 11 | http://www.apache.org/licenses/LICENSE-2.0 |
| 12 | |
| 13 | Unless required by applicable law or agreed to in writing, software |
| 14 | distributed under the License is distributed on an "AS IS" BASIS, |
| 15 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 16 | See the License for the specific language governing permissions and |
| 17 | limitations under the License. |
| 18 | --> |
| 19 | |
| 20 | <p>The Android compatibility program makes it easy for mobile device |
| 21 | manufacturers to develop compatible Android devices.</p> |
| 22 | <h1 id="program-goals">Program goals</h1> |
| 23 | <p>The Android compatibility program works for the benefit of the entire |
| 24 | Android community, including users, developers, and device manufacturers.</p> |
| 25 | <p>Each group depends on the others. Users want a wide selection of devices |
| 26 | and great apps; great apps come from developers motivated by a large market |
| 27 | for their apps with many devices in users' hands; device manufacturers rely |
| 28 | on a wide variety of great apps to increase their products' value for |
| 29 | consumers.</p> |
| 30 | <p>Our goals were designed to benefit each of these groups:</p> |
| 31 | <ul> |
| 32 | <li> |
| 33 | <p><em>Provide a consistent application and hardware environment to application |
| 34 | developers.</em> |
| 35 | Without a strong compatibility standard, devices can vary so |
| 36 | greatly that developers must design different versions of their applications |
| 37 | for different devices. The compatibility program provides a precise definition |
| 38 | of what developers can expect from a compatible device in terms of APIs and |
| 39 | capabilities. Developers can use this information to make good design |
| 40 | decisions, and be confident that their apps will run well on any compatible |
| 41 | device.</p> |
| 42 | </li> |
| 43 | <li> |
| 44 | <p><em>Enable a consistent application experience for consumers.</em> |
| 45 | If an application runs well on one compatible Android device, it should run well on |
| 46 | any other device that is compatible with the same Android platform version. |
| 47 | Android devices will differ in hardware and software capabilities, so the |
| 48 | compatibility program also provides the tools needed for distribution systems |
| 49 | such as Google Play to implement appropriate filtering. This means that |
| 50 | users can only see applications which they can actually run.</p> |
| 51 | </li> |
| 52 | <li> |
| 53 | <p><em>Enable device manufacturers to differentiate while being |
| 54 | compatible.</em> |
| 55 | The Android compatibility program focuses on the aspects of |
| 56 | Android relevant to running third-party applications, which allows device |
| 57 | manufacturers the flexibility to create unique devices that are nonetheless |
| 58 | compatible.</p> |
| 59 | </li> |
| 60 | <li> |
| 61 | <p><em>Minimize costs and overhead associated with compatibility.</em> |
| 62 | Ensuring compatibility should be easy and inexpensive to |
| 63 | device manufacturers. The testing tool (CTS) is free, open source, and |
| 64 | available for <a href="downloads.html">download</a>. |
| 65 | CTS is designed to be used for continuous self-testing |
| 66 | during the device development process to eliminate the cost of changing your |
| 67 | workflow or sending your device to a third party for testing. Meanwhile, there |
| 68 | are no required certifications, and thus no corresponding costs and |
| 69 | fees.</p> |
| 70 | </li> |
| 71 | </ul> |
| 72 | <p>The Android compatibility program consists of three key components:</p> |
| 73 | <ul> |
| 74 | <li>The source code to the Android software stack</li> |
| 75 | <li>The Compatilbility Definition Document, representing the "policy" aspect of compatibility</li> |
| 76 | <li>The Compatilbility Test Suite, representing the "mechanism" of compatibility</li> |
| 77 | </ul> |
| 78 | <p>Just as each version of the Android platform exists in a separate branch in |
| 79 | the source code tree, there is a separate CTS and CDD for each version as |
| 80 | well. The CDD, CTS, and source code are -- along with your hardware and your |
| 81 | software customizations -- everything you need to create a compatible device.</p> |
| 82 | <h1 id="compatibility-definition-document-cdd">Compatibility Definition Document (CDD)</h1> |
| 83 | <p>For each release of the Android platform, a detailed Compatibility |
| 84 | Definition Document (CDD) will be provided. The CDD represents the "policy" |
| 85 | aspect of Android compatibility.</p> |
| 86 | <p>No test suite, including CTS, can truly be comprehensive. For instance, the |
| 87 | CTS includes a test that checks for the presence and correct behavior of |
| 88 | OpenGL graphics APIs, but no software test can verify that the graphics |
| 89 | actually appear correctly on the screen. More generally, it's impossible to |
| 90 | test the presence of hardware features such as keyboards, display density, |
| 91 | WiFi, and Bluetooth.</p> |
| 92 | <p>The CDD's role is to codify and clarify specific requirements, and |
| 93 | eliminate ambiguity. The CDD does not attempt to be comprehensive. Since |
| 94 | Android is a single corpus of open-source code, the code itself is the |
| 95 | comprehensive "specification" of the platform and its APIs. The CDD acts as a |
| 96 | "hub", referencing other content (such as SDK API documentation) that provides |
| 97 | a framework in which the Android source code may be used so that the end |
| 98 | result is a compatible system.</p> |
| 99 | <p>If you want to build a device compatible with a given Android version, |
| 100 | start by checking out the source code for that version, and then read the |
| 101 | corresponding CDD and stay within its guidelines. For additional details, |
| 102 | simply examine <a href="4.2/android-4.2-cdd.pdf">the latest CDD</a>.</p> |
| 103 | <h1 id="compatibility-test-suite-cts">Compatibility Test Suite (CTS)</h1> |
| 104 | <p>The CTS is a free, commercial-grade test suite, available for |
| 105 | <a href="downloads.html">download</a>. |
| 106 | The CTS represents the "mechanism" of compatibility.</p> |
| 107 | <p>The CTS runs on a desktop machine and executes test cases directly on |
| 108 | attached devices or an emulator. The CTS is a set of unit tests designed to be |
| 109 | integrated into the daily workflow (such as via a continuous build system) of |
| 110 | the engineers building a device. Its intent is to reveal incompatibilities |
| 111 | early on, and ensure that the software remains compatible throughout the |
| 112 | development process.</p> |
| 113 | <h1 id="compatibility-test-suite-verifier-cts-verifier">Compatibility Test Suite Verifier (CTS Verifier)</h1> |
| 114 | <p>The Compatibility Test Suite Verifier (CTS Verifier) is a supplement to the |
| 115 | Compatibility Test Suite (CTS), available for <a href="downloads.html">download</a>. |
| 116 | CTS Verifier provides tests for APIs and functions that cannot be tested on a |
| 117 | stationary device without manual input (e.g. audio quality, accelerometer, etc).</p> |
| 118 | <p>For details on the CTS, consult the <a href="cts-intro.html">CTS introduction</a>.</p> |
| 119 | |
| 120 | |