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