本文档列出了与 Android 2.1 兼容的手机必须满足的要求。
在本文档中，“设备实现者”或“实现者”指的是开发搭载 Android 2.1 的硬件/软件解决方案的个人或组织。“设备实现”或“实现”指的是所开发的硬件/软件解决方案。
设备实现必须满足以下要求，才会被视为与 Android 2.1 兼容：
以上很多资源都是直接或间接源自 Android 2.1 SDK，并且其功能与该 SDK 的文档中所述的功能相同。如果本兼容性定义或兼容性测试套件与 SDK 文档有任何不一致的情况，均以 SDK 文档为准。上面包含的参考资料内提供的所有技术详细信息都被视为本兼容性定义的一部分。
Android 平台包含一组受管理 API、一组原生 API 和一系列所谓的“软”API，例如 intent 系统和 Web 应用 API。本节详细介绍了对兼容性至关重要的硬 API 和软 API，以及某些其他相关的技术和界面行为。设备实现必须遵守本节中的所有要求。
除非本兼容性定义文档中明确许可，否则设备实现不得省略任何受管理 API，不得更改 API 接口或签名，不得违背所载述的行为，也不得包含空操作。
除了第 3.1 节中的受管理 API 之外，Android 还包含一个非常重要的运行时专用“软”API，该 API 采用 intent、权限，以及 Android 应用中在应用编译期间无法被强制执行的其他类似方面等形式。本节详细介绍了与 Android 2.1 兼容所需的“软”API 和系统行为。设备实现必须满足本节中所述的所有要求。
Android 使用 intent 在应用之间实现松散耦合的集成。本节介绍了与设备实现必须支持的 intent 模式相关的要求。“支持”意味着设备实现者必须提供一个 Android activity 或 Service，用于为每个指定的 intent 模式指定匹配的 intent 过滤器，并为这些模式绑定并实现正确的行为。
不过，任何此类替代版本都必须支持上游项目提供的相同 intent 模式。例如，如果设备包含替代音乐播放器，它仍必须支持第三方应用发出的用于挑选歌曲的 intent 模式。
以下应用被视为核心 Android 系统应用：
核心 Android 系统应用包含各种被视为“公开”组件的 activity 或 Service 组件。也就是说，属性“android:exported”可以不存在，也可以具有“true”值。
对于在一个核心 Android 系统应用中定义的每个 activity 或 Service，如果未通过将属性“android:exported”的值设为“false”来将该应用标记为“非公开”，则设备实现必须包含一个相同类型的组件，来实现与该核心 Android 系统应用相同的 intent 过滤器模式。
换言之，设备实现可以更换核心 Android 系统应用；不过，如果进行此类更换，设备实现必须支持由被更换的每个核心 Android 系统应用所定义的所有 intent 模式。
由于 Android 是一个可扩展的平台，因此设备实现者必须允许使用第三方应用替换核心系统应用中定义的每种 intent 模式。上游 Android 开源项目默认允许这么做；设备实现者不得为系统应用使用这些 intent 模式的情况附加特殊特权，也不得阻止第三方应用绑定到这些模式并取得对这些模式的控制权。具体而言，此项规定包括但不限于停用“选择器”界面（用户可通过该界面在多个均可处理相同 intent 模式的应用之间进行选择）。
设备实现者不得添加任何符合以下条件的 Android 组件：支持任何使用 ACTION、CATEGORY 或使用 android.* 命名空间中的其他键字符串的新 intent 模式或广播 intent 模式。设备实现者不得添加任何符合以下条件的 Android 组件：遵从任何使用 ACTION、使用 CATEGORY 或使用属于其他组织的软件包空间中的其他键字符串的新 intent 模式或广播 intent 模式。设备实现者不得更改或扩展第 3.2.3.1 节列出的核心应用使用的任何 intent 模式。
此项规定类似于第 3.6 节中针对 Java 语言类的规定。
第三方应用依赖平台广播某些 intent 来获悉硬件或软件环境中发生的变化。与 Android 兼容的设备必须广播公共广播 intent 来响应相应的系统事件。如需关于广播 intent 的介绍，请参阅 SDK 文档。
在 Dalvik 中运行的受管理代码可以调用应用 .apk 文件中提供的原生代码，作为针对相应设备硬件架构编译的 ELF .so 文件。设备实现必须支持在受管理环境中运行的代码，以使用标准 Java 原生接口 (JNI) 语义调用原生代码。以下 API 必须可供原生代码使用：
设备实现必须支持 OpenGL ES 1.0。没有硬件加速的设备必须使用软件渲染程序实现 OpenGL ES 1.0。设备实现应尽可能多地实现设备硬件所支持的 OpenGL ES 1.1 功能。设备实现应提供 OpenGL ES 2.0 实现（但前提是硬件要能够在这些 API 上实现合理的性能）。
这些库必须与 Android 开源项目在 Bionic 中提供的版本保持源代码兼容（即标头兼容）和二进制文件兼容（针对给定的处理器架构）。由于 Bionic 实现与其他实现（例如 GNU C 库）并不完全兼容，因此设备实现者应使用 Android 实现。如果设备实现者使用这些库的其他实现，则必须确保标头、二进制文件和行为兼容性。
实现原生代码兼容性是一项颇具挑战性的任务。因此，应重申一下，强烈建议设备实现者使用上面列出的库的上游实现，以帮助确保兼容性。
由于无法为网络浏览器开发综合测试套件，因此设备实现者必须在 WebView 实现中使用 WebKit 的特定上游 build。具体而言：
实现可以在独立的浏览器应用中附带自定义用户代理字符串。此外，独立的浏览器可以基于替代浏览器技术（例如 Firefox、Opera 等）。不过，即使交付的是替代浏览器应用，向第三方应用提供的 WebView 组件也必须基于 WebKit（如上文所述）。
上述列表并不详尽，设备实现者需负责确保行为兼容性。为此，设备实现者应尽可能使用通过 Android 开源项目获得的源代码，而不是重新实现系统的重要部分。
兼容性测试套件 (CTS) 用于测试平台重要部分的行为兼容性，而不是测试整个平台的行为兼容性。实现者需负责确保与 Android 开源项目保持行为兼容。
Android 遵循 Java 编程语言定义的软件包和类命名空间惯例。为了确保与第三方应用兼容，设备实现者不得对以下软件包命名空间进行任何禁止执行的修改（见下文）：
禁止执行的修改包括：
“公开提供的元素”是指上游 Android 源代码中不带“@hide”标记的任何构造。换言之，设备实现者不得在上述命名空间中提供新的 API 或更改现有的 API。设备实现者可以执行仅限于内部的修改，但不得向开发者通告或以其他方式公开这些修改。
请注意，上述限制对应于 Java 编程语言中命名 API 的标准惯例；本节只是为了强调这些惯例，并通过将其纳入本兼容性定义来使其具有约束力。
设备实现必须配置 Dalvik，以便向屏幕被归类为中密度或低密度的设备上的每个应用分配至少 16MB 的内存。设备实现必须配置 Dalvik，以便向屏幕被归类为高密度的设备上的每个应用分配至少 24MB 的内存。请注意，设备实现可以分配比这些数字更多的内存，但并非必须如此。
Android 平台包含一些开发者 API，允许开发者接入系统界面。设备实现必须将这些标准界面 API 整合到他们开发的自定义界面中，具体如下文所述。
设备实现者可以用替代启动器替换参考启动器（即主屏幕）。替代启动器应包含对 AppWidget 的内置支持，并提供用于直接在启动器中添加、配置、查看和移除 AppWidget 的界面元素。替代启动器可以省略这些界面元素；不过，如果省略这些界面元素，设备实现者必须提供可从启动器访问的单独应用，以便用户添加、配置、查看和移除 AppWidget。
设备实现必须包含单个共享的系统级搜索界面，并且该界面能够在用户输入内容时实时提供建议。设备实现必须实现一些 API，以供开发者重复使用此界面，从而在其应用内提供搜索功能。设备实现必须实现一些 API，以便在搜索框以全局搜索模式运行时，可让第三方应用向搜索框中添加建议。如果没有安装任何可利用此功能的第三方应用，则默认行为应为显示 Web 搜索引擎的搜索结果和建议。
设备实现可以附带替代搜索界面，但应包含专用的硬或软搜索按钮（可以随时使用该按钮在任何应用中调用搜索框架），其行为在 API 文档中提供。
如果硬件能够在不限制功能且不会对其他应用造成负面影响的情况下，以合理的帧速率运行所有动态壁纸，则会被视为能够可靠地运行动态壁纸。如果硬件中的限制会导致壁纸和/或应用崩溃、无法正常运行、占用过多 CPU/消耗过多电池电量，或者运行时的帧速率低得令人无法接受，相应硬件会被视为无法运行动态壁纸。例如，有些动态壁纸可能会利用 Open GL 1.0 或 2.0 上下文来渲染其内容。动态壁纸将无法在不支持多个 OpenGL 上下文的硬件上可靠地运行，因为使用 OpenGL 上下文的动态壁纸可能会与其他同样使用 OpenGL 上下文的应用发生冲突。
如果设备实现能够可靠地运行动态壁纸（如上所述），则应实现动态壁纸。如果设备实现被判定为无法可靠地运行动态壁纸（如上所述），则不得实现动态壁纸。
设备实现者必须使用以下开源应用测试实现兼容性：
实现必须能够正确启动并运行上述每个应用，才会被视为兼容实现。
此外，设备实现必须测试以下每个冒烟测试应用的每个菜单项（包括所有子菜单）：
上述应用中的每个测试用例必须在设备实现中正常运行。
设备实现必须支持以下多媒体编解码器。在 Android 开源项目的首选 Android 实现中，所有这些编解码器都是作为软件实现提供的。
请注意，Google 和开放手机联盟 (Open Handset Alliance) 均未做过任何关于这些编解码器中没有使用第三方专利的声明。打算在硬件或软件产品中使用此源代码的用户请注意，实现此代码（包括在开源软件或共享软件中实现）可能需要获得相关专利持有者的专利许可。
请注意，上表并未列出大多数视频编解码器的特定比特率要求。这是因为，在实践中，当前的设备硬件支持的比特率未必正好就是相关标准指定的所需比特率。设备实现应支持硬件上可行的最高比特率，但不超过规范规定的上限。
设备实现必须支持 Android SDK 中提供的 Android 开发者工具。具体而言，与 Android 兼容的设备必须与以下各项兼容：
Android 旨在为设备实现者打造创新的设备规格和配置提供支持。同时，Android 开发者希望某些硬件、传感器和 API 能在所有 Android 设备上使用。本节列出了所有 Android 2.1 兼容设备都必须支持的硬件功能。
如果设备包含特定的硬件组件，而该组件具有针对第三方开发者的相应 API，该设备实现必须实现该 API（如 Android SDK 文档中所定义）。如果 SDK 中的某个 API 需要与某个被规定为可选组件的硬件组件互动，但设备实现不具备该组件，则：
对于 Android 2.1，以下是最常见的屏幕配置：
某些 .apk 软件包的清单没有将它们标识为支持特定的密度范围。运行此类应用时，应遵循以下限制条件：
与第 8.1.1 节中列出的任一标准配置不匹配的屏幕配置需要额外考虑，并具有兼容性。设备实现者必须与第 12 节中提供的 Android 兼容性团队联系，以获取关于屏幕尺寸范围、密度和缩放比例的分类。获得这些信息后，设备实现必须按指定方式实现它们。
请注意，某些屏幕配置（例如超大或超小屏幕以及某些宽高比）从根本上就与 Android 2.1 不兼容；因此，建议设备实现者在开发过程中尽早与 Android 兼容性团队联系。
设备实现：
设备实现：
兼容的设备必须支持按应用动态设置屏幕方向（纵向或横向）。也就是说，如果应用请求使用特定屏幕方向，设备必须遵从该请求。设备实现可以选择纵向或横向作为默认方向。
设备实现：
设备实现：
主屏幕、菜单和返回功能对于 Android 导航范式至关重要。无论应用处于何种状态，设备实现都必须随时为用户提供这些功能。应通过专用按钮实现这些功能，也可以使用专用软件按键、手势、触摸板等来实现。但如果是这样，这些功能必须始终可以访问，并且不得遮住或影响可用的应用显示区域。
设备实现者还应提供专用的搜索键。设备实现者还可以为通话提供发送键和结束键。
设备实现必须支持无线高速数据网络。具体而言，设备实现必须支持至少一种能够达到 200 Kbit/sec 或更高传输速率的无线数据标准。满足此要求的技术包括 EDGE、HSPA、EV-DO、802.11g 等。
如果设备实现包含一种特定模态，而 Android SDK 包含一个用于该模态的 API（即 Wi-Fi、GSM 或 CDMA），那么该实现必须支持此 API。
设备可以实现多种形式的无线数据连接。设备可以实现有线数据连接（例如以太网），但必须至少包含上述一种形式的无线连接。
设备实现必须包含相机。随附的相机：
Android 2.1 可以在不包含电话硬件的设备上使用。也就是说，Android 2.1 可与非电话设备兼容。不过，如果设备实现包含 GSM 或 CDMA 电话，则必须全面支持针对该技术的 API。如果设备实现不包含电话硬件，则必须将所有相关 API 实现为空操作。
另请参阅第 8.8 节“无线数据网络”。
设备实现必须有至少 92MB 的内存供内核和用户空间使用。这 92 MB 不包括不在内核控制范围之内的任何专供硬件组件（例如无线装置、存储器等）使用的内存。
设备实现必须有至少 150MB 的非易失性存储空间可用于存储用户数据。也就是说，/data 分区必须至少为 150MB。
设备实现必须为应用提供共享存储空间。提供的共享存储空间不得小于 2GB。
设备实现必须配有默认装载且可直接使用的共享存储空间。如果共享存储空间未装载在 Linux 路径 /sdcard 下，则设备必须包含从 /sdcard 指向实际装载点的 Linux 符号链接。
设备实现可以具有相应的硬件来安装可供用户使用的可移动存储设备，例如安全数字卡。或者，设备实现可以将内部（不可移动的）存储空间分配为应用的共享存储空间。
无论使用何种形式的共享存储空间，共享存储空间都必须实现 USB 大容量存储，如第 8.6 节所述。共享存储空间是出厂时随附的，必须装载 FAT 文件系统。
下面列举了两个常见示例。如果设备实现包含 SD 卡插槽以满足共享存储空间要求，则设备在出售给用户时就必须包含容量不低于 2 GB 的 FAT 格式的 SD 卡，并且必须默认装载该卡。或者，如果设备实现使用内部固定存储空间来满足此要求，则该存储空间必须至少为 2 GB，并且必须装载在 /sdcard 上（如果装载在其他位置，则 /sdcard 必须是指向实际位置的符号链接）。
Android 兼容性计划的其中一个目标就是为消费者提供一致的应用体验。兼容的实现不仅必须确保应用能够在设备上运行正常，还必须保证应用以合理的性能正常运行，并提供良好的整体用户体验。设备实现必须满足下表中定义的 Android 2.1 兼容设备关键性能指标：
CTS 能够在实际设备上运行。与所有软件一样，CTS 自身也可能包含 bug。CTS 的版本发布独立于本兼容性定义，我们可能会针对 Android 2.1 发布多个 CTS 修订版本。设备实现必须通过设备软件发布时可用的最新 CTS 版本的测试。
设备实现必须包含可用于替换整个系统软件的机制。该机制不需要执行“实时”升级 - 也就是说，可能需要重启设备。
可以使用任何方法，但前提是相应方法可以替换设备上的整个预安装软件。例如，以下任何方法都可以满足此要求：
使用的更新机制必须支持在不擦除用户数据的情况下进行更新。请注意，上游 Android 软件包含满足此项要求的更新机制。
在设备实现发布后，如果在其合理的产品生命周期内发现其中存在错误，并且经与 Android 兼容性团队磋商后确定该错误会影响第三方应用的兼容性，设备实现者必须通过可按上述机制应用的可用软件更新来更正该错误。