Android 2.2 兼容性定义

版权所有 © 2010，Google Inc. 保留所有权利。
compatibility@android.com

目录

1. 简介
2. 参考资源
3. 软件
4. 参考软件兼容性
5. 应用打包兼容性
6. 多媒体兼容性
7. 开发者工具兼容性
8. 硬件兼容性
9. 性能兼容性
10. 安全模型兼容性
11. 兼容性测试套件
12. 可更新软件
13. 联系我们
附录 A - 蓝牙测试程序

1. 简介

本文档列举了移动电话与 Android 2.2 兼容必须满足的要求。

“必须 (must)”、“不得 (must not)”、“必需 (required)”、“应 (shall)”、“不应 (shall not)”、“应该 (should)”、“不应该 (should not)”、“建议 (recommended)”、“可以 (may)”和“可选 (optional)”的使用符合 RFC2119 中定义的 IETF 标准 [参考资源，1]。

在本文档中，“设备实现者”或“实现者”是指开发运行 Android 2.2 的硬件/软件解决方案的个人或组织。“设备实现”或“实现”是指如此开发的硬件/软件解决方案。

要被视为与 Android 2.2 兼容，设备实现

  • 必须满足本兼容性定义中提出的要求，包括通过引用并入的任何文档。
  • 必须通过设备实现的软件完成时可用的最新版本 Android 兼容性测试套件 (CTS)。（CTS 作为 Android 开放源代码项目的一部分提供 [参考资源，2]。）CTS 测试了本文档中概述的许多组件，但并非全部。

如果本定义或 CTS 未提及、含义模糊或不完整，设备实现者有责任确保与现有实现的兼容性。因此，Android 开放源代码项目 [参考资源，3] 既是参考实现，也是 Android 的首选实现。强烈建议设备实现者将其实现基于 Android 开放源代码项目提供的“上游”源代码。虽然某些组件在理论上可以用替代实现来替换，但强烈建议不要这样做，因为通过 CTS 测试将变得更加困难。设备实现者有责任确保与标准 Android 实现的完全行为兼容性，包括且不仅限于兼容性测试套件。最后，请注意，本文档明确禁止某些组件替换和修改。

2. 参考资源

  1. IETF RFC2119 要求级别：http://www.ietf.org/rfc/rfc2119.txt
  2. Android 兼容性计划概述：https://aosp.org.cn/docs/compatibility/index.html
  3. Android 开放源代码项目：https://aosp.org.cn/
  4. API 定义和文档：https://developer.android.com.cn/reference/packages.html
  5. Android 权限参考：https://developer.android.com.cn/reference/android/Manifest.permission.html
  6. android.os.Build 参考：https://developer.android.com.cn/reference/android/os/Build.html
  7. Android 2.2 允许的版本字符串：https://aosp.org.cn/docs/compatibility/2.2/versions.html
  8. android.webkit.WebView 类：https://developer.android.com.cn/reference/android/webkit/WebView.html
  9. HTML5：http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Dalvik 虚拟机规范：可在 Android 源代码 dalvik/docs 中找到
  11. AppWidget：https://developer.android.com.cn/guide/practices/ui_guidelines/widget_design.html
  12. 通知：https://developer.android.com.cn/guide/topics/ui/notifiers/notifications.html
  13. 应用资源：http://code.google.com/android/reference/available-resources.html
  14. 状态栏图标样式指南：https://developer.android.com.cn/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. 搜索管理器：https://developer.android.com.cn/reference/android/app/SearchManager.html
  16. Toast 消息：https://developer.android.com.cn/reference/android/widget/Toast.html
  17. 动态壁纸：https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. 适用于 Android 的应用：http://code.google.com/p/apps-for-android
  19. 参考工具文档（适用于 adb、aapt、ddms）：https://developer.android.com.cn/guide/developing/tools/index.html
  20. Android apk 文件描述：https://developer.android.com.cn/guide/topics/fundamentals.html
  21. 清单文件：https://developer.android.com.cn/guide/topics/manifest/manifest-intro.html
  22. Monkey 测试工具：https://developer.android.com.cn/studio/test/other-testing-tools/monkey
  23. Android 硬件功能列表：https://developer.android.com.cn/reference/android/content/pm/PackageManager.html
  24. 支持多种屏幕：https://developer.android.com.cn/guide/practices/screens_support.html
  25. android.content.res.Configuration：https://developer.android.com.cn/reference/android/content/res/Configuration.html
  26. android.util.DisplayMetrics：https://developer.android.com.cn/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera：https://developer.android.com.cn/reference/android/hardware/Camera.html
  28. 传感器坐标空间：https://developer.android.com.cn/reference/android/hardware/SensorEvent.html
  29. Android 安全和权限参考：https://developer.android.com.cn/guide/topics/security/security.html
  30. 蓝牙 API：https://developer.android.com.cn/reference/android/bluetooth/package-summary.html

这些资源中的许多直接或间接地来源于 Android 2.2 SDK，并且在功能上与该 SDK 文档中的信息相同。在本兼容性定义或兼容性测试套件与 SDK 文档不一致的任何情况下，以 SDK 文档为准。上述参考文献中提供的任何技术细节都通过包含被视为本兼容性定义的一部分。

3. 软件

Android 平台包括一组托管 API、一组原生 API 以及一组所谓的“软”API，例如 Intent 系统和 Web 应用程序 API。本节详细介绍了构成兼容性组成部分的硬 API 和软 API，以及某些其他相关的技术和用户界面行为。设备实现必须遵守本节中的所有要求。

3.1. 托管 API 兼容性

托管的（基于 Dalvik）执行环境是 Android 应用程序的主要载体。Android 应用程序编程接口 (API) 是暴露给在托管 VM 环境中运行的应用程序的一组 Android 平台接口。设备实现必须提供 Android 2.2 SDK [参考资源，4] 公开的任何已记录 API 的完整实现，包括所有已记录的行为。

除非本兼容性定义明确允许，否则设备实现不得省略任何托管 API、更改 API 接口或签名、偏离已记录的行为或包含空操作。

3.2. 软 API 兼容性

除了第 3.1 节中的托管 API 之外，Android 还包括一个重要的仅运行时“软”API，其形式包括 Intent、权限以及 Android 应用程序的类似方面，这些方面无法在应用程序编译时强制执行。本节详细介绍了与 Android 2.2 兼容所需的“软”API 和系统行为。设备实现必须满足本节中提出的所有要求。

3.2.1. 权限

设备实现者必须支持并强制执行权限参考页面 [参考资源，5] 记录的所有权限常量。请注意，第 10 节列出了与 Android 安全模型相关的其他要求。

3.2.2. 构建参数

Android API 在 android.os.Build 类 [参考资源，6] 中包含许多常量，旨在描述当前设备。为了在设备实现之间提供一致的、有意义的值，下表包括对设备实现必须符合的这些值的格式的额外限制。

参数 注释
android.os.Build.VERSION.RELEASE 当前正在执行的 Android 系统的版本，以人类可读的格式。此字段必须具有 [参考资源，7] 中定义的字符串值之一。
android.os.Build.VERSION.SDK 当前正在执行的 Android 系统的版本，格式可供第三方应用程序代码访问。对于 Android 2.2，此字段必须具有整数值 8。
android.os.Build.VERSION.INCREMENTAL 设备实现者选择的值，用于指定当前正在执行的 Android 系统的特定构建版本，以人类可读的格式。此值不得重复用于提供给最终用户的不同构建版本。此字段的典型用途是指示用于生成构建版本的构建编号或源代码控制更改标识符。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.BOARD 设备实现者选择的值，用于标识设备使用的特定内部硬件，以人类可读的格式。此字段的可能用途是指示为设备供电的电路板的特定修订版本。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.BRAND 设备实现者选择的值，用于标识生产该设备的公司、组织、个人等的名称，以人类可读的格式。此字段的可能用途是指示销售该设备的 OEM 和/或运营商。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.DEVICE 设备实现者选择的值，用于标识设备机身（有时称为“工业设计”）的特定配置或修订版本。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.FINGERPRINT 唯一标识此构建版本的字符串。它应该具有合理的人类可读性。它必须遵循此模板
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例如
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
指纹不得包含空格字符。如果上面模板中包含的其他字段包含空格字符，则必须在构建指纹中将其替换为另一个字符，例如下划线 ("_") 字符。
android.os.Build.HOST 唯一标识构建版本所在主机的字符串，以人类可读的格式。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.ID 设备实现者选择的标识符，用于指代特定版本，以人类可读的格式。此字段可以与 android.os.Build.VERSION.INCREMENTAL 相同，但应该是对于最终用户而言足够有意义的值，以便区分不同的软件构建版本。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.MODEL 设备实现者选择的值，其中包含最终用户已知的设备名称。这应该是设备向最终用户营销和销售时使用的名称。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.PRODUCT 设备实现者选择的值，其中包含设备的开发名称或代号。必须是人类可读的，但不一定旨在供最终用户查看。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
android.os.Build.TAGS 设备实现者选择的逗号分隔的标签列表，用于进一步区分构建版本。例如，“unsigned,debug”。此字段不得为 null 或空字符串 ("")，但单个标签（例如“release”）也可以。
android.os.Build.TIME 表示构建发生时的时间戳的值。
android.os.Build.TYPE 设备实现者选择的值，用于指定构建版本的运行时配置。此字段应具有与三种典型的 Android 运行时配置之一对应的值：“user”、“userdebug”或“eng”。
android.os.Build.USER 生成构建版本的用户（或自动用户）的名称或用户 ID。对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。

3.2.3. Intent 兼容性

Android 使用 Intent 来实现应用程序之间松耦合的集成。本节介绍与设备实现必须遵守的 Intent 模式相关的要求。“遵守”是指设备实现者必须提供一个 Android Activity 或 Service，该 Activity 或 Service 指定匹配的 Intent 过滤器，并绑定到每个指定的 Intent 模式并为其实现正确的行为。

3.2.3.1. 核心应用 Intent

Android 上游项目定义了许多核心应用程序，例如电话拨号器、日历、联系人簿、音乐播放器等。设备实现者可以使用替代版本替换这些应用程序。

但是，任何此类替代版本都必须遵守上游项目提供的相同 Intent 模式。例如，如果设备包含替代音乐播放器，则它仍然必须遵守第三方应用程序发出的用于选择歌曲的 Intent 模式。

以下应用程序被认为是核心 Android 系统应用程序

  • 桌面时钟
  • 浏览器
  • 日历
  • 计算器
  • 相机
  • 联系人
  • 电子邮件
  • 图库
  • 全局搜索
  • 启动器
  • LivePicker（即动态壁纸选择器应用程序；如果设备不支持动态壁纸，则可以省略，根据第 3.8.5 节。）
  • 消息 (又名 "Mms")
  • 音乐
  • 电话
  • 设置
  • 录音机

核心 Android 系统应用程序包括各种 Activity 或 Service 组件，这些组件被认为是“公共”的。也就是说，属性“android:exported”可能不存在，也可能具有值“true”。

对于在核心 Android 系统应用之一中定义的每个 Activity 或 Service，如果未通过值为“false”的 android:exported 属性标记为非公共，则设备实现必须包含一个相同类型的组件，该组件实现与核心 Android 系统应用相同的 Intent 过滤器模式。

换句话说，设备实现可以使用替代的核心 Android 系统应用程序；但是，如果这样做，则设备实现必须支持每个被替换的核心 Android 系统应用程序定义的所有 Intent 模式。

3.2.3.2. Intent 覆盖

由于 Android 是一个可扩展的平台，设备实现者必须允许第三方应用程序覆盖第 3.2.3.1 节中引用的每个 Intent 模式。默认情况下，上游 Android 开放源代码项目允许这样做；设备实现者不得将特殊权限附加到系统应用程序对这些 Intent 模式的使用，或阻止第三方应用程序绑定到这些模式并取得控制权。此禁令特别包括但不限于禁用“选择器”用户界面，该界面允许用户在处理相同 Intent 模式的多个应用程序之间进行选择。

3.2.3.3. Intent 命名空间

设备实现者不得包含任何 Android 组件，该组件使用 android.* 命名空间中的 ACTION、CATEGORY 或其他键字符串来遵守任何新的 Intent 或广播 Intent 模式。设备实现者不得包含任何 Android 组件，该组件使用属于其他组织的软件包空间中的 ACTION、CATEGORY 或其他键字符串来遵守任何新的 Intent 或广播 Intent 模式。设备实现者不得更改或扩展第 3.2.3.1 节中列出的核心应用程序使用的任何 Intent 模式。

此禁令类似于第 3.6 节中为 Java 语言类指定的禁令。

3.2.3.4. 广播 Intent

第三方应用程序依赖于平台广播某些 Intent 以通知它们硬件或软件环境的变化。与 Android 兼容的设备必须广播公共广播 Intent 以响应适当的系统事件。广播 Intent 在 SDK 文档中进行了描述。

3.3. 原生 API 兼容性

在 Dalvik 中运行的托管代码可以调用应用程序 .apk 文件中提供的原生代码，该原生代码是为适当的设备硬件架构编译的 ELF .so 文件。设备实现必须包含对在托管环境中运行的代码调用原生代码的支持，使用标准 Java 原生接口 (JNI) 语义。以下 API 必须可用于原生代码

  • libc (C 库)
  • libm (数学库)
  • JNI 接口
  • libz (Zlib 压缩)
  • liblog (Android 日志记录)
  • 对 C++ 的最低限度支持
  • 支持 OpenGL，如下所述

设备实现必须支持 OpenGL ES 1.0。缺少硬件加速的设备必须使用软件渲染器实现 OpenGL ES 1.0。设备实现应尽可能多地实现设备硬件支持的 OpenGL ES 1.1。如果硬件能够在这些 API 上实现合理的性能，则设备实现应提供 OpenGL ES 2.0 的实现。

这些库必须与 Android 开放源代码项目在 Bionic 中提供的版本在源代码上兼容（即标头兼容）和二进制兼容（对于给定的处理器架构）。由于 Bionic 实现与其他实现（例如 GNU C 库）不完全兼容，因此设备实现者应使用 Android 实现。如果设备实现者使用这些库的不同实现，则必须确保标头、二进制和行为兼容性。

设备实现必须通过 android.os.Build.CPU_ABI API 准确报告设备支持的原生应用程序二进制接口 (ABI)。ABI 必须是 Android NDK 最新版本中 docs/CPU-ARCH-ABIS.txt 文件中记录的条目之一。请注意，Android NDK 的其他版本可能会引入对其他 ABI 的支持。

原生代码兼容性具有挑战性。因此，应重申，强烈建议设备实现者使用上面列出的库的上游实现，以帮助确保兼容性。

3.4. Web 兼容性

许多开发者和应用程序依赖于 android.webkit.WebView 类的行为来实现其用户界面，因此 WebView 实现必须在不同的 Android 实现之间兼容。同样，完整的 Web 体验对于 Android 用户体验至关重要。设备实现必须包含与上游 Android 软件一致的 android.webkit.WebView 版本，并且必须包含现代的、支持 HTML5 的浏览器，如下所述。

3.4.1. WebView 兼容性

Android 开放源代码实现使用 WebKit 渲染引擎来实现 android.webkit.WebView。由于为 Web 渲染系统开发全面的测试套件不可行，因此设备实现者必须在 WebView 实现中使用 WebKit 的特定上游构建版本。具体而言

  • 设备实现的 android.webkit.WebView 实现必须基于 Android 2.2 的上游 Android 开放源代码树中的 533.1 WebKit 构建版本。此构建版本包括 WebView 的一组特定功能和安全修复。设备实现者可以对 WebKit 实现进行自定义；但是，任何此类自定义都不得更改 WebView 的行为，包括渲染行为。
  • WebView 报告的用户代理字符串必须采用以下格式
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
    • $(VERSION) 字符串的值必须与 android.os.Build.VERSION.RELEASE 的值相同
    • $(LOCALE) 字符串的值应遵循国家/地区代码和语言的 ISO 约定，并且应指代设备当前配置的语言区域
    • $(MODEL) 字符串的值必须与 android.os.Build.MODEL 的值相同
    • $(BUILD) 字符串的值必须与 android.os.Build.ID 的值相同

WebView 配置必须包括对 HTML5 数据库、应用程序缓存和地理位置 API [参考资源，9] 的支持。WebView 必须包括对 HTML5 <video> 标记的支持。HTML5 API（与所有 JavaScript API 一样）在 WebView 中必须默认禁用，除非开发者通过常用的 Android API 显式启用它们。

3.4.2. 浏览器兼容性

设备实现必须包含一个独立的浏览器应用程序，用于用户的一般 Web 浏览。独立浏览器可以基于 WebKit 以外的浏览器技术。但是，即使发布了备用浏览器应用程序，提供给第三方应用程序的 android.webkit.WebView 组件也必须基于 WebKit，如第 3.4.1 节所述。

设备实现**可以**在独立的浏览器应用程序中发布自定义用户代理字符串。

独立的浏览器应用程序（无论是基于上游WebKit浏览器应用程序还是第三方替代品）**应该**尽可能地支持HTML5 [参考资料, 9]。最低限度，设备实现**必须**在独立的浏览器应用程序中支持HTML5地理位置、应用程序缓存和数据库API以及 <video> 标签。

3.5. API 行为兼容性

每种API类型（托管、软、原生和Web）的行为必须与上游Android开源项目的首选实现保持一致 [参考资料, 3]。一些具体的兼容性领域包括：

  • 设备**不得**更改标准Intent的行为或含义
  • 设备**不得**更改特定类型的系统组件（例如Service、Activity、ContentProvider等）的生命周期或生命周期语义
  • 设备**不得**更改特定权限的语义

以上列表并非详尽无遗，设备实现者有责任确保行为兼容性。因此，设备实现者**应该**尽可能使用通过Android开源项目提供的源代码，而不是重新实现系统的重要部分。

兼容性测试套件（CTS）测试了平台行为兼容性的重要部分，但并非全部。设备实现者有责任确保与Android开源项目的行为兼容性。

3.6. API 命名空间

Android遵循Java编程语言定义的包和类命名空间约定。为了确保与第三方应用程序的兼容性，设备实现者**不得**对以下包命名空间进行任何禁止的修改（见下文）：

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

禁止的修改包括：

  • 设备实现**不得**通过更改任何方法或类签名，或删除类或类字段来修改Android平台上公开的API。
  • 设备实现者**可以**修改API的底层实现，但此类修改**不得**影响任何公开API的声明行为和Java语言签名。
  • 设备实现者**不得**在上述API中添加任何公开的元素（例如类或接口，或现有类或接口的字段或方法）。

“公开的元素”是指上游Android源代码中未用“@hide”标记修饰的任何构造。换句话说，设备实现者**不得**在上述命名空间中公开新的API或更改现有API。设备实现者**可以**进行仅限内部的修改，但这些修改**不得**向开发者宣传或以其他方式公开。

设备实现者**可以**添加自定义API，但任何此类API**不得**位于由其他组织拥有或引用其他组织的命名空间中。例如，设备实现者**不得**将API添加到 com.google.* 或类似的命名空间；只有Google可以这样做。同样，Google**不得**将API添加到其他公司的命名空间中。

如果设备实现者提议改进上述包命名空间之一（例如通过向现有API添加有用的新功能，或添加新的API），则实现者**应该**访问 source.android.com 并根据该站点上的信息开始贡献更改和代码的过程。

请注意，上述限制符合Java编程语言中命名API的标准约定；本节旨在加强这些约定，并通过将其纳入此兼容性定义使其具有约束力。

3.7. 虚拟机兼容性

设备实现**必须**支持完整的Dalvik Executable (DEX) 字节码规范和Dalvik虚拟机语义 [参考资料, 10]。

屏幕分类为中等或低密度的设备实现**必须**配置Dalvik，为每个应用程序分配至少16MB的内存。屏幕分类为高密度的设备实现**必须**配置Dalvik，为每个应用程序分配至少24MB的内存。请注意，设备实现**可以**分配比这些数字更多的内存。

3.8. 用户界面兼容性

Android平台包含一些开发者API，允许开发者挂钩到系统用户界面。设备实现**必须**将这些标准UI API整合到他们开发的自定义用户界面中，如下所述。

3.8.1. 小部件

Android定义了一种组件类型以及相应的API和生命周期，允许应用程序向最终用户公开“AppWidget” [参考资料, 11]。Android开源参考版本包含一个Launcher应用程序，其中包含用户界面元素，允许用户从主屏幕添加、查看和删除AppWidget。

设备实现者**可以**替代参考Launcher（即主屏幕）。替代Launcher**应该**包括对AppWidget的内置支持，并公开用户界面元素，以直接在Launcher内添加、配置、查看和删除AppWidget。替代Launcher**可以**省略这些用户界面元素；但是，如果省略了这些元素，设备实现者**必须**提供一个可从Launcher访问的单独应用程序，允许用户添加、配置、查看和删除AppWidget。

3.8.2. 通知

Android包含允许开发者通知用户重要事件的API [参考资料, 12]。设备实现者**必须**提供对定义的每类通知的支持；具体而言：声音、振动、灯光和状态栏。

此外，实现**必须**正确渲染API [参考资料, 13] 或状态栏图标样式指南 [参考资料, 14] 中提供的所有资源（图标、声音文件等）。设备实现者**可以**提供与参考Android开源实现提供的通知不同的用户体验；但是，此类替代通知系统**必须**支持现有的通知资源，如上所述。

Android包含API [参考资料, 15]，允许开发者将搜索整合到他们的应用程序中，并将他们应用程序的数据公开到全局系统搜索中。一般来说，此功能由一个单一的、系统范围的用户界面组成，该界面允许用户输入查询，在用户键入时显示建议，并显示结果。Android API允许开发者重用此界面以在他们自己的应用程序中提供搜索，并允许开发者为公共全局搜索用户界面提供结果。

设备实现**必须**包含一个单一的、共享的、系统范围的搜索用户界面，该界面能够根据用户输入提供实时建议。设备实现**必须**实现允许开发者重用此用户界面以在他们自己的应用程序中提供搜索的API。设备实现**必须**实现允许第三方应用程序在全局搜索模式下运行时向搜索框添加建议的API。如果没有安装利用此功能的第三方应用程序，则默认行为**应该**是显示Web搜索引擎结果和建议。

设备实现**可以**发布替代的搜索用户界面，但**应该**包括一个硬或软的专用搜索按钮，该按钮可以在任何应用程序内的任何时间用于调用搜索框架，其行为在API文档中提供。

3.8.4. Toast 消息

应用程序可以使用“Toast”API（在 [参考资料, 16] 中定义）向最终用户显示简短的非模态字符串，这些字符串在短暂的时间后消失。设备实现**必须**以某种高可见性的方式向最终用户显示来自应用程序的Toast。

3.8.5. 动态壁纸

Android定义了一种组件类型以及相应的API和生命周期，允许应用程序向最终用户公开一个或多个“动态壁纸” [参考资料, 17]。动态壁纸是动画、图案或类似的图像，具有有限的输入功能，作为壁纸显示在其他应用程序后面。

如果硬件能够运行所有动态壁纸，且功能不受限制，以合理的帧速率运行，且不对其他应用程序产生不利影响，则该硬件被认为能够可靠地运行动态壁纸。如果硬件的限制导致壁纸和/或应用程序崩溃、故障、消耗过多的CPU或电池电量，或以不可接受的低帧速率运行，则该硬件被认为无法运行动态壁纸。例如，某些动态壁纸可能使用Open GL 1.0或2.0上下文来渲染其内容。动态壁纸无法在不支持多个OpenGL上下文的硬件上可靠运行，因为动态壁纸对OpenGL上下文的使用可能会与其他也使用OpenGL上下文的应用程序冲突。

能够如上所述可靠运行动态壁纸的设备实现**应该**实现动态壁纸。被确定为不能如上所述可靠运行动态壁纸的设备实现**必须不**实现动态壁纸。

4. 参考软件兼容性

设备实现者**必须**使用以下开源应用程序测试实现兼容性：

  • 计算器（包含在SDK中）
  • 月球着陆器（Lunar Lander）（包含在SDK中）
  • “Apps for Android”应用程序 [参考资料, 18]。
  • Replica Island（在Android Market中可用；仅当设备实现支持OpenGL ES 2.0时才需要）

为了使实现被认为是兼容的，上述每个应用程序**必须**在实现上启动并正确运行。

此外，设备实现**必须**测试这些冒烟测试应用程序的每个菜单项（包括所有子菜单）：

  • ApiDemos（包含在SDK中）
  • ManualSmokeTests（包含在CTS中）

上述应用程序中的每个测试用例**必须**在设备实现上正确运行。

5. 应用打包兼容性

设备实现**必须**安装并运行由官方Android SDK [参考资料, 19] 中包含的“aapt”工具生成的Android“.apk”文件。

设备实现**不得**以阻止这些文件在其他兼容设备上正确安装和运行的方式扩展.apk [参考资料, 20]、Android Manifest [参考资料, 21] 或Dalvik字节码 [参考资料, 10] 格式。设备实现者**应该**使用Dalvik的参考上游实现和参考实现的包管理系统。

6. 多媒体兼容性

设备实现**必须**完全实现所有多媒体API。设备实现**必须**包括对以下描述的所有多媒体编解码器的支持，并且**应该**满足以下描述的声音处理指南。

6.1. 媒体编解码器

设备实现**必须**支持以下多媒体编解码器。所有这些编解码器都在Android开源项目提供的首选Android实现中作为软件实现提供。

请注意，Google和开放手机联盟均未表示这些编解码器不受第三方专利的限制。那些打算在硬件或软件产品中使用此源代码的人员应注意，此代码的实现（包括在开源软件或共享软件中）可能需要获得相关专利持有人的专利许可。

音频
名称 编码器 解码器 详情 文件/容器格式
AAC LC/LTP   X 标准比特率最高达160 kbps且采样率在8到48kHz之间的任意组合的单声道/立体声内容 3GPP (.3gp) 和 MPEG-4 (.mp4, .m4a)。不支持原始AAC (.aac)
HE-AACv1 (AAC+)   X
HE-AACv2 (增强型 AAC+)   X
AMR-NB X X 4.75 到 12.2 kbps，以 8kHz 采样 3GPP (.3gp)
AMR-WB   X 9 种速率，从 6.60 kbit/s 到 23.85 kbit/s，以 16kHz 采样 3GPP (.3gp)
MP3   X 单声道/立体声 8-320Kbps 恒定比特率 (CBR) 或可变比特率 (VBR) MP3 (.mp3)
MIDI   X MIDI 类型 0 和 1。DLS 版本 1 和 2。XMF 和 Mobile XMF。支持铃声格式 RTTTL/RTX、OTA 和 iMelody 类型 0 和 1 (.mid, .xmf, .mxmf)。还有 RTTTL/RTX (.rtttl, .rtx)、OTA (.ota) 和 iMelody (.imy)
Ogg Vorbis   X   Ogg (.ogg)
PCM   X 8 位和 16 位线性 PCM（速率高达硬件限制） WAVE (.wav)
图像
JPEG X X 基本+渐进  
GIF   X    
PNG X X    
BMP   X    
视频
H.263 X X   3GPP (.3gp) 文件
H.264   X   3GPP (.3gp) 和 MPEG-4 (.mp4) 文件
MPEG4 简单配置文件   X   3GPP (.3gp) 文件

请注意，上表未列出大多数视频编解码器的具体比特率要求。原因是实际上，当前的设备硬件不一定支持与相关标准指定的所需比特率完全匹配的比特率。相反，设备实现**应该**支持硬件上可行的最高比特率，直至规范定义的限制。

6.2. 录音

当应用程序使用 android.media.AudioRecord API启动录制音频流时，设备实现**应该**以以下每种行为采样和录制音频：

  • 噪声抑制处理（如果存在）**应该**被禁用。
  • 自动增益控制（如果存在）**应该**被禁用。
  • 设备**应该**表现出近似平坦的幅度与频率特性；具体而言，在 100 Hz 到 4000 Hz 范围内为 ±3 dB
  • 音频输入灵敏度**应该**设置为在 1000 Hz 时 90 dB 声功率级 (SPL) 源产生 16 位采样的 RMS 为 5000。
  • PCM幅度电平**应该**在线性跟踪输入SPL变化，范围至少为30 dB，从-18 dB到+12 dB re 90 dB SPL在麦克风处。
  • 总谐波失真**应该**在 100 Hz 到 4000 Hz 范围内，90 dB SPL 输入电平下小于 1%。

注意： 虽然上述要求在Android 2.2中被声明为“**应该**”，但未来版本的兼容性定义计划将这些更改为“**必须**”。也就是说，这些要求在Android 2.2中是可选的，但**将在未来版本中成为必需**。现有和运行Android 2.2的Android设备**非常强烈地建议在Android 2.2中满足这些要求**，否则它们在升级到未来版本时将无法获得Android兼容性。

6.3. 音频延迟

音频延迟广义上定义为应用程序请求音频播放或录制操作与设备实现实际开始操作之间的时间间隔。许多类别的应用程序依赖于短延迟，以实现实时效果，例如音效或VOIP通信。设备实现**应该**满足本节概述的所有音频延迟要求。

为了本节的目的：

  • “冷输出延迟”定义为应用程序请求音频播放与声音开始播放之间的时间间隔，此时音频系统在请求之前一直处于空闲和断电状态。
  • “热输出延迟”定义为应用程序请求音频播放与声音开始播放之间的时间间隔，此时音频系统最近被使用过但当前处于空闲状态（即，静音）。
  • “连续输出延迟”定义为应用程序发出要播放的采样与扬声器物理播放相应声音之间的时间间隔，此时设备当前正在播放音频。
  • “冷输入延迟”定义为应用程序请求音频录制与通过其回调将第一个采样传递给应用程序之间的时间间隔，此时音频系统和麦克风在请求之前一直处于空闲和断电状态。
  • “连续输入延迟”定义为当环境声音发生时，以及当与该声音对应的采样通过其回调传递给录制应用程序时之间的时间间隔，此时设备处于录制模式。

使用上述定义，设备实现**应该**表现出以下每种属性：

  • 冷输出延迟为 100 毫秒或更短
  • 热输出延迟为 10 毫秒或更短
  • 连续输出延迟为 45 毫秒或更短
  • 冷输入延迟为 100 毫秒或更短
  • 连续输入延迟为 50 毫秒或更短

注意： 虽然上述要求在Android 2.2中被声明为“**应该**”，但未来版本的兼容性定义计划将这些更改为“**必须**”。也就是说，这些要求在Android 2.2中是可选的，但**将在未来版本中成为必需**。现有和运行Android 2.2的Android设备**非常强烈地建议在Android 2.2中满足这些要求**，否则它们在升级到未来版本时将无法获得Android兼容性。

7. 开发者工具兼容性

设备实现**必须**支持Android SDK中提供的Android开发者工具。具体而言，兼容Android的设备**必须**与以下工具兼容：

  • Android 调试桥 (Android Debug Bridge)（称为 adb） [参考资料, 19]
    设备实现**必须**支持Android SDK中记录的所有 adb 功能。设备端 adb 守护进程**应该**默认处于非活动状态，但**必须**存在用户可访问的机制来打开Android调试桥。
  • Dalvik 调试监视服务 (Dalvik Debug Monitor Service)（称为 ddms） [参考资料, 19]
    设备实现**必须**支持Android SDK中记录的所有 ddms 功能。由于 ddms 使用 adb，因此对 ddms 的支持**应该**默认处于非活动状态，但在用户激活Android调试桥时**必须**得到支持，如上所述。
  • Monkey [参考资料, 22]
    设备实现**必须**包括Monkey框架，并使其可供应用程序使用。

8. 硬件兼容性

Android旨在支持设备实现者创建创新的外形和配置。与此同时，Android开发者期望所有Android设备都具有某些硬件、传感器和API。本节列出了所有兼容Android 2.2的设备必须支持的硬件功能。

如果设备包含具有第三方开发者对应API的特定硬件组件，则设备实现**必须**实现该API，如Android SDK文档中所定义。如果SDK中的API与声明为可选的硬件组件交互，并且设备实现不具备该组件：

  • 组件API的类定义**必须**存在
  • API的行为**必须**以某种合理的方式实现为空操作
  • 在SDK文档允许的情况下，API方法**必须**返回空值
  • 在SDK文档不允许返回空值的情况下，API方法**必须**返回类的空操作实现

应用这些要求的典型场景是电话API：即使在非电话设备上，这些API也必须实现为合理的空操作。

设备实现**必须**通过 android.content.pm.PackageManager 类上的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法准确报告准确的硬件配置信息。 [参考资料, 23]

8.1. 显示

Android 2.2包括在某些情况下执行某些自动缩放和转换操作的功能，以确保第三方应用程序在各种硬件配置上合理地运行 [参考资料, 24]。设备**必须**正确实现这些行为，如本节详细介绍。

对于Android 2.2，以下是最常见的显示配置：

屏幕类型 宽度（像素） 高度（像素） 对角线长度范围（英寸） 屏幕尺寸组 屏幕密度组
QVGA 240 320 2.6 - 3.0 小 低
WQVGA 240 400 3.2 - 3.5 正常 低
FWQVGA 240 432 3.5 - 3.8 正常 低
HVGA 320 480 3.0 - 3.5 正常 中
WVGA 480 800 3.3 - 4.0 正常 高
FWVGA 480 854 3.5 - 4.0 正常 高
WVGA 480 800 4.8 - 5.5 大 中
FWVGA 480 854 5.0 - 5.8 大 中

与上述标准配置之一对应的设备实现**必须**配置为通过 android.content.res.Configuration [参考资料, 24] 类向应用程序报告指示的屏幕尺寸。

某些 .apk 包的清单未将其标识为支持特定的密度范围。当运行此类应用程序时，以下约束适用：

  • 设备实现**必须**将 .apk 中缺少密度限定符的资源解释为默认为“中等”（在SDK文档中称为“mdpi”）。
  • 在“低”密度屏幕上运行时，设备实现**必须**将中等/mdpi资源缩小0.75倍。
  • 在“高”密度屏幕上运行时，设备实现**必须**将中等/mdpi资源放大1.5倍。
  • 设备实现**不得**在密度范围内缩放资源，并且**必须**在密度范围之间按这些确切的系数缩放资源。

8.1.2. 非标准显示配置

与第 8.1.1 节中列出的标准配置之一不匹配的显示配置需要额外的考虑和工作才能兼容。设备实现者**必须**按照第 13 节中的描述联系Android兼容性团队，以获得屏幕尺寸桶、密度和缩放因子的分类。当提供此信息时，设备实现**必须**按照指定的方式实现它们。

请注意，某些显示配置（例如非常大或非常小的屏幕，以及某些宽高比）从根本上与Android 2.2不兼容；因此，鼓励设备实现者在开发过程的早期尽可能联系Android兼容性团队。

8.1.3. 显示指标

设备实现**必须**报告 android.util.DisplayMetrics [参考资料, 26] 中定义的所有显示指标的正确值。

8.1.4. 声明的屏幕支持

应用程序可以通过AndroidManifest.xml文件中的 <supports-screens> 属性指示它们支持的屏幕尺寸。设备实现**必须**正确地遵守应用程序声明的对小、中和大屏幕的支持，如Android SDK文档中所述。

8.2. 键盘

设备实现：

  • **必须**包括对输入管理框架的支持（该框架允许第三方开发者创建输入管理引擎 - 即软键盘），详情请访问 developer.android.com
  • **必须**提供至少一个软键盘实现（无论是否存在硬键盘）
  • **可以**包括额外的软键盘实现
  • **可以**包括硬件键盘
  • **不得**包含与 android.content.res.Configuration.keyboard [参考资料, 25] 中指定的格式之一（即，QWERTY或12键）不匹配的硬件键盘

8.3. 非触摸导航

设备实现：

  • **可以**省略非触摸导航选项（即，可以省略轨迹球、D-pad或滚轮）
  • **必须**报告 android.content.res.Configuration.navigation [参考资料, 25] 的正确值

8.4. 屏幕方向

兼容设备**必须**支持应用程序动态地定向到纵向或横向屏幕方向。也就是说，设备必须尊重应用程序对特定屏幕方向的请求。设备实现**可以**选择纵向或横向方向作为默认方向。

设备**必须**报告设备的当前方向的正确值，无论何时通过 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他API查询时。

8.5. 触摸屏输入

设备实现：

  • **必须**具有触摸屏
  • **可以**具有电容式或电阻式触摸屏
  • **必须**报告 android.content.res.Configuration [参考资料, 25] 的值，该值反映设备上特定触摸屏的类型
  • **应该**支持完全独立跟踪的指针，如果触摸屏支持多个指针

8.6. USB

设备实现：

  • **必须**实现USB客户端，可连接到具有标准USB-A端口的USB主机
  • **必须**通过USB实现Android调试桥（如第7节中所述）
  • **必须**实现USB大容量存储规范，以允许连接到设备的主机访问/sdcard卷的内容
  • **应该**在设备侧使用micro USB外形尺寸
  • **可以**在设备侧包括非标准端口，但如果是这样，则**必须**附带一根能够将自定义引脚排列连接到标准USB-A端口的电缆
  • **应该**实现对USB大容量存储规范的支持（以便可以从主机PC访问设备上的可移动或固定存储）

8.7. 导航键

主页、菜单和返回功能对于Android导航范例至关重要。设备实现**必须**始终为用户提供这些功能，无论应用程序状态如何。这些功能**应该**通过专用按钮实现。它们**可以**使用软件、手势、触摸面板等实现，但如果是这样，它们**必须**始终可访问，并且不会遮盖或干扰可用的应用程序显示区域。

设备实现者**应该**还提供一个专用搜索键。设备实现者**可以**还为电话呼叫提供发送和结束键。

8.8. 无线数据网络

设备实现**必须**包括对无线高速数据网络的支持。具体而言，设备实现**必须**包括对至少一种能够达到200Kbit/秒或更高的无线数据标准的支持。满足此要求的技术示例包括EDGE、HSPA、EV-DO、802.11g等。

如果设备实现包括Android SDK包含API的特定模式（即，WiFi、GSM或CDMA），则实现**必须**支持该API。

设备**可以**实现多种形式的无线数据连接。设备**可以**实现有线数据连接（例如以太网），但尽管如此，**必须**至少包括一种形式的无线连接，如上所述。

8.9. 相机

设备实现**必须**包括后置摄像头。包含的后置摄像头：

  • **必须**具有至少200万像素的分辨率
  • **应该**具有硬件自动对焦，或在摄像头驱动程序中实现的软件自动对焦（对应用程序软件透明）
  • **可以**具有固定焦点或EDOF（扩展景深）硬件
  • **可以**包括闪光灯。如果摄像头包括闪光灯，则当 android.hardware.Camera.PreviewCallback 实例已在摄像头预览表面上注册时，闪光灯**不得**亮起，除非应用程序已通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性显式启用了闪光灯。请注意，此约束不适用于设备的内置系统摄像头应用程序，而仅适用于使用 Camera.PreviewCallback 的第三方应用程序。

设备实现**必须**为摄像头相关的API实现以下行为：

  1. 如果应用程序从未调用过 android.hardware.Camera.Parameters.setPreviewFormat(int)，则设备**必须**对提供给应用程序回调的预览数据使用 android.hardware.PixelFormat.YCbCr_420_SP。
  2. 如果应用程序注册了 android.hardware.Camera.PreviewCallback 实例，并且当预览格式为 YCbCr_420_SP 时系统调用了 onPreviewFrame() 方法，则传递到 onPreviewFrame() 中的 byte[] 中的数据必须进一步采用 NV21 编码格式。（这是7k硬件系列本地使用的格式。）也就是说，NV21 **必须**是默认格式。

设备实现**必须**实现Android 2.2 SDK文档 [参考资料, 27] 中包含的完整摄像头API，无论设备是否包含硬件自动对焦或其他功能。例如，缺少自动对焦的摄像头仍然**必须**调用任何已注册的 android.hardware.Camera.AutoFocusCallback 实例（即使这与非自动对焦摄像头无关）。

设备实现**必须**识别并遵守在 android.hardware.Camera.Parameters 类上定义为常量的每个参数名称，如果底层硬件支持该功能。如果设备硬件不支持某个功能，则API的行为必须如文档所述。相反，设备实现**不得**遵守或识别传递给 android.hardware.Camera.setParameters() 方法的字符串常量，除非这些常量在 android.hardware.Camera.Parameters 上记录为常量。也就是说，如果硬件允许，设备实现**必须**支持所有标准摄像头参数，并且**不得**支持自定义摄像头参数类型。

设备实现**可以**包括前置摄像头。但是，如果设备实现包括前置摄像头，则设备上实现的摄像头API**不得**默认使用前置摄像头。也就是说，Android 2.2中的摄像头API仅适用于后置摄像头，并且设备实现**不得**重用或重载API以作用于前置摄像头（如果存在）。请注意，设备实现者为支持前置摄像头而添加的任何自定义API**必须**遵守第3.5节和第3.6节；例如，如果提供了自定义 android.hardware.Camera 或 Camera.Parameters 子类来支持前置摄像头，则它**不得**位于现有命名空间中，如第3.5节和第3.6节所述。请注意，包含前置摄像头不满足设备包含后置摄像头的要求。

8.10. 加速度计

设备实现**必须**包括3轴加速度计，并且**必须**能够以50 Hz或更高的频率传递事件。加速度计使用的坐标系**必须**符合Android API中详细说明的Android传感器坐标系（参见 [参考资料, 28]）。

8.11. 指南针

设备实现**必须**包括3轴指南针，并且**必须**能够以10 Hz或更高的频率传递事件。指南针使用的坐标系**必须**符合Android API中定义的Android传感器坐标系（参见 [参考资料, 28]）。

8.12. GPS

设备实现**必须**包括GPS接收器，并且**应该**包括某种形式的“辅助GPS”技术，以最大限度地缩短GPS锁定时间。

8.13. 电话

Android 2.2 **可以**用于不包含电话硬件的设备。也就是说，Android 2.2与非电话设备兼容。但是，如果设备实现确实包含GSM或CDMA电话功能，则它**必须**实现对该技术API的完全支持。不包含电话硬件的设备实现**必须**将完整的API实现为空操作。

另请参阅第 8.8 节“无线数据网络”。

8.14. 内存和存储

设备实现**必须**至少有92MB的内存可供内核和用户空间使用。这92MB**必须**是内核无法控制的任何专用于硬件组件（如无线电、内存等）的内存之外的。

设备实现**必须**至少有150MB的非易失性存储空间可用于用户数据。也就是说，/data 分区**必须**至少为150MB。

除了上述要求外，设备实现**应该**至少有128MB的内存可供内核和用户空间使用，此外还有任何专用于内核无法控制的硬件组件的内存。设备实现**应该**至少有1GB的非易失性存储空间可用于用户数据。请注意，这些更高的要求计划在未来版本的Android中成为硬性最低要求。强烈建议设备实现者现在满足这些要求，否则他们可能没有资格获得未来版本的Android的兼容性。

8.15. 应用共享存储

设备实现**必须**为应用程序提供共享存储。提供的共享存储**必须**至少为2GB大小。

设备实现**必须**配置为默认情况下“开箱即用”地挂载共享存储。如果共享存储未挂载在Linux路径 /sdcard 上，则设备**必须**包括从 /sdcard 到实际挂载点的Linux符号链接。

设备实现**必须**按照文档规定在共享存储上强制执行 android.permission.WRITE_EXTERNAL_STORAGE 权限。共享存储**必须**可以被任何获得该权限的应用程序写入。

设备实现**可以**具有用于用户可访问的可移动存储的硬件，例如安全数字卡。或者，设备实现**可以**分配内部（不可移动）存储作为应用程序的共享存储。

无论使用何种形式的共享存储，共享存储**必须**实现USB大容量存储，如第8.6节中所述。开箱即用时，共享存储**必须**使用FAT文件系统挂载。

建议考虑两个常见的例子。如果设备实现方案包含一个 SD 卡槽以满足共享存储需求，则在向用户出售设备时，必须随设备附带一个 2GB 或更大容量的 FAT 格式 SD 卡，并且必须默认安装该 SD 卡。或者，如果设备实现方案使用内部固定存储来满足此要求，则该存储必须为 2GB 或更大容量，格式化为 FAT，并挂载到 /sdcard。（或者，如果挂载在其他位置，/sdcard 必须是指向物理位置的符号链接。）

包含多个共享存储路径（例如 SD 卡槽和共享内部存储）的设备实现方案应修改核心应用程序（如媒体扫描器和 ContentProvider），以透明地支持放置在这两个位置的文件。

8.16. 蓝牙

设备实现方案必须包含蓝牙收发器。设备实现方案必须启用基于 RFCOMM 的蓝牙 API，如 SDK 文档 [资源 30] 中所述。设备实现方案应根据设备情况实现相关的蓝牙配置文件，例如 A2DP、AVRCP、OBEX 等。

兼容性测试套件包含涵盖 Android RFCOMM 蓝牙 API 基本操作的用例。但是，由于蓝牙是设备之间的通信协议，因此无法通过在单个设备上运行的单元测试进行全面测试。因此，设备实现方案还必须通过附录 A 中描述的人工驱动蓝牙测试程序。

9. 性能兼容性

Android 兼容性计划的目标之一是为消费者提供一致的应用程序体验。兼容的实现方案必须确保应用程序不仅能在设备上正确运行，而且还能以合理的性能和良好的整体用户体验运行。设备实现方案必须满足下表中定义的 Android 2.2 兼容设备的key performance metrics (关键性能指标)

指标 性能阈值 注释
应用程序启动时间 以下应用程序应在指定时间内启动。
  • 浏览器：小于 1300 毫秒
  • 彩信/短信：小于 700 毫秒
  • 闹钟：小于 650 毫秒
 启动时间的衡量标准是完成加载应用程序默认活动的总时间，包括启动 Linux 进程、将 Android 软件包加载到 Dalvik VM 以及调用 onCreate 所需的时间。
同时运行的应用程序 当启动多个应用程序后，重新启动已在运行的应用程序所花费的时间必须少于原始启动时间。  

10. 安全模型兼容性

设备实现方案必须实现与 Android 平台安全模型一致的安全模型，如 Android 开发者文档的“安全和权限”参考文档 [资源 29] 中所定义。设备实现方案必须支持安装自签名应用程序，而无需任何第三方/机构的额外权限/证书。具体而言，兼容设备必须支持以下小节中描述的安全机制。

10.1. 权限

设备实现方案必须支持 Android 权限模型，如 Android 开发者文档 [资源 29] 中所定义。具体而言，实现方案必须强制执行 SDK 文档中描述的每项权限；不得省略、更改或忽略任何权限。实现方案可以添加额外的权限，前提是新的权限 ID 字符串不在 android.* 命名空间中。

10.2. UID 和进程隔离

设备实现方案必须支持 Android 应用程序沙箱模型，其中每个应用程序都以唯一的 Unix 风格 UID 并在单独的进程中运行。设备实现方案必须支持以相同的 Linux 用户 ID 运行多个应用程序，前提是这些应用程序已正确签名和构建，如“安全和权限”参考文档 [资源 29] 中所定义。

10.3. 文件系统权限

设备实现方案必须支持 Android 文件访问权限模型，如“安全和权限”参考文档 [资源 29] 中所定义。

10.4. 备用执行环境

设备实现方案可以包含运行时环境，这些环境使用 Dalvik 虚拟机或本机代码以外的其他软件或技术来执行应用程序。但是，此类替代执行环境不得损害 Android 安全模型或已安装 Android 应用程序的安全性，如本节所述。

替代运行时本身必须是 Android 应用程序，并遵守标准的 Android 安全模型，如第 10 节其他部分所述。

替代运行时不得被授予访问权限未在运行时环境的 AndroidManifest.xml 文件中通过 <uses-permission> 机制请求的受权限保护的资源。

替代运行时不得允许应用程序使用受限于系统应用程序的 Android 权限保护的功能。

替代运行时必须遵守 Android 沙箱模型。具体而言

  • 替代运行时应通过 PackageManager 将应用安装到单独的 Android 沙箱中（即 Linux 用户 ID 等）。
  • 替代运行时可以提供由所有使用该替代运行时的应用程序共享的单个 Android 沙箱。
  • 替代运行时和使用替代运行时安装的应用程序不得重用设备上安装的任何其他应用程序的沙箱，除非通过共享用户 ID 和签名证书的标准 Android 机制。
  • 替代运行时不得启动、授予或被授予访问与其他 Android 应用程序相对应的沙箱的权限。

替代运行时不得使用、被授予或授予其他应用程序超级用户（root）或任何其他用户 ID 的任何特权。

替代运行时的 .apk 文件可以包含在设备实现方案的系统映像中，但必须使用与用于签署设备实现方案中包含的其他应用程序的密钥不同的密钥进行签名。

在安装应用程序时，替代运行时必须获得用户对应用程序使用的 Android 权限的同意。也就是说，如果应用程序需要使用具有相应 Android 权限（例如摄像头、GPS 等）的设备资源，则替代运行时必须告知用户该应用程序将能够访问该资源。如果运行时环境不以这种方式记录应用程序功能，则运行时环境在安装任何使用该运行时环境的应用程序时，必须列出运行时环境本身持有的所有权限。

11. 兼容性测试套件

设备实现方案必须通过 Android 兼容性测试套件 (CTS) [资源 2]，该套件可从 Android 开源项目获得，并使用设备上的最终发布软件。此外，设备实现者应尽可能使用 Android 开源树中的参考实现方案，并且必须确保在 CTS 中存在歧义以及对参考源代码的任何重新实现的情况下保持兼容性。

CTS 旨在在实际设备上运行。与任何软件一样，CTS 本身可能包含错误。CTS 的版本将独立于此兼容性定义进行版本控制，并且可能会为 Android 2.2 发布 CTS 的多个修订版本。设备实现方案必须通过设备软件完成时可用的最新 CTS 版本。

12. 可更新软件

设备实现方案必须包含一种机制来替换整个系统软件。该机制不需要执行“实时”升级——也就是说，可能需要重新启动设备。

可以使用任何方法，只要它可以替换设备上预安装的全部软件即可。例如，以下任何一种方法都可以满足此要求

  • 通过 OTA（Over-the-air）下载进行空中下载，并通过重启进行离线更新
  • 通过 USB 从主机 PC 进行“有线”更新
  • 通过重启和从可移动存储设备上的文件进行“离线”更新

使用的更新机制必须支持在不擦除用户数据的情况下进行更新。请注意，上游 Android 软件包含满足此要求的更新机制。

如果在设备实现方案发布后但在其合理的产品寿命期内发现错误，并且经与 Android 兼容性团队协商后确定该错误会影响第三方应用程序的兼容性，则设备实现者必须通过软件更新来纠正该错误，该软件更新可以通过刚刚描述的机制应用。

13. 联系我们

如果您有任何疑问或认为本文档未涵盖任何问题，可以通过 compatibility@android.com 联系文档作者进行澄清。

附录 A - 蓝牙测试程序

兼容性测试套件包含涵盖 Android RFCOMM 蓝牙 API 基本操作的用例。但是，由于蓝牙是设备之间的通信协议，因此无法通过在单个设备上运行的单元测试进行全面测试。因此，设备实现方案还必须通过下面描述的人工驱动蓝牙测试程序。

测试程序基于 Android 开源项目树中包含的 BluetoothChat 示例应用。该程序需要两个设备

  • 运行要测试的软件版本的候选设备实现方案
  • 一个单独的、已知兼容的设备实现方案，并且是来自被测设备实现方案的型号——即“已知良好”的设备实现方案

以下测试程序将这些设备分别称为“候选设备”和“已知良好设备”。

设置和安装

  1. 通过 Android 源代码树中的“make samples”构建 BluetoothChat.apk。
  2. 在已知良好设备上安装 BluetoothChat.apk。
  3. 在候选设备上安装 BluetoothChat.apk。

通过应用程序测试蓝牙控制

  1. 在蓝牙禁用的情况下，在候选设备上启动 BluetoothChat。
  2. 验证候选设备是否打开蓝牙，或者提示用户使用对话框打开蓝牙。

测试配对和通信

  1. 在两台设备上启动 Bluetooth Chat 应用。
  2. 在 BluetoothChat 中（使用菜单）使已知良好设备可被发现。
  3. 在候选设备上，从 BluetoothChat 中（使用菜单）扫描蓝牙设备，并与已知良好设备配对。
  4. 从每台设备发送 10 条或更多消息，并验证另一台设备是否正确接收到这些消息。
  5. 按 Home 关闭两台设备上的 BluetoothChat 应用。
  6. 使用设备“设置”应用取消每台设备与另一台设备的配对。

反向测试配对和通信

  1. 在两台设备上启动 Bluetooth Chat 应用。
  2. 在 BluetoothChat 中（使用菜单）使候选设备可被发现。
  3. 在已知良好设备上，从 BluetoothChat 中（使用菜单）扫描蓝牙设备，并与候选设备配对。
  4. 从每台设备发送 10 条或更多消息，并验证另一台设备是否正确接收到这些消息。
  5. 通过反复按“返回”键返回启动器，关闭两台设备上的 Bluetooth Chat 应用。

测试重新启动

  1. 在两台设备上重新启动 Bluetooth Chat 应用。
  2. 从每台设备发送 10 条或更多消息，并验证另一台设备是否正确接收到这些消息。

注意：以上测试的某些用例通过使用“Home”键结束测试部分，而另一些用例则使用“返回”键。这些测试并非冗余，也不是可选的：目的是验证当活动显式终止（通过用户按“返回”键，这将调用 finish()）和隐式发送到后台（通过用户按“Home”键）时，蓝牙 API 和堆栈都能正常工作。每个测试序列都必须按描述执行。