Android 2.3 兼容性定义

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

目录

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

1. 简介

本文档列出了手机要与 Android 2.3 兼容必须满足的要求。

“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“建议”、“可以”和“可选”的使用符合 RFC2119 [参考资料，1] 中定义的 IETF 标准。

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

要被视为与 Android 2.3 兼容，设备实现**必须**满足本兼容性定义中提出的要求，包括通过引用并入的任何文档。

如果本定义或第 10 节中描述的软件测试中存在沉默、歧义或不完整之处，则设备实现者有责任确保与现有实现的兼容性。因此，Android 开源项目 [参考资料，3] 既是 Android 的参考实现，也是首选实现。强烈建议设备实现者尽可能基于 Android 开源项目提供的“上游”源代码进行实现。虽然某些组件在理论上可以替换为备选实现，但不强烈建议这样做，因为通过软件测试将变得非常困难。设备实现者有责任确保与标准 Android 实现的完全行为兼容性，包括但不限于兼容性测试套件。最后，请注意，本文档明确禁止某些组件替换和修改。

请注意，本兼容性定义发布时对应于 Android 2.3.3 更新，即 API 级别 10。本定义取代并替换了 2.3.3 之前 Android 2.3 版本的兼容性定义。（即，版本 2.3.1 和 2.3.2 已过时。）未来运行 Android 2.3 的 Android 兼容设备**必须**搭载 2.3.3 或更高版本。

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.3 允许的版本字符串：https://aosp.org.cn/docs/compatibility/2.3/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. HTML5 离线功能：http://dev.w3.org/html5/spec/Overview.html#offline
  11. HTML5 视频标记：http://dev.w3.org/html5/spec/Overview.html#video
  12. HTML5/W3C 地理位置 API：http://www.w3.org/TR/geolocation-API/
  13. HTML5/W3C webdatabase API：http://www.w3.org/TR/webdatabase/
  14. HTML5/W3C IndexedDB API：http://www.w3.org/TR/IndexedDB/
  15. Dalvik 虚拟机规范：可在 Android 源代码的 dalvik/docs 中找到
  16. AppWidget：https://developer.android.com.cn/guide/practices/ui_guidelines/widget_design.html
  17. 通知：https://developer.android.com.cn/guide/topics/ui/notifiers/notifications.html
  18. 应用资源：http://code.google.com/android/reference/available-resources.html
  19. 状态栏图标样式指南：https://developer.android.com.cn/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  20. 搜索管理器：https://developer.android.com.cn/reference/android/app/SearchManager.html
  21. Toast：https://developer.android.com.cn/reference/android/widget/Toast.html
  22. 动态壁纸：https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  23. 参考工具文档（适用于 adb、aapt、ddms）：https://developer.android.com.cn/guide/developing/tools/index.html
  24. Android apk 文件描述：https://developer.android.com.cn/guide/topics/fundamentals.html
  25. 清单文件：https://developer.android.com.cn/guide/topics/manifest/manifest-intro.html
  26. Monkey 测试工具：https://developer.android.com.cn/studio/test/other-testing-tools/monkey
  27. Android 硬件功能列表：https://developer.android.com.cn/reference/android/content/pm/PackageManager.html
  28. 支持多种屏幕：https://developer.android.com.cn/guide/practices/screens_support.html
  29. android.util.DisplayMetrics：https://developer.android.com.cn/reference/android/util/DisplayMetrics.html
  30. android.content.res.Configuration：https://developer.android.com.cn/reference/android/content/res/Configuration.html
  31. 传感器坐标空间：https://developer.android.com.cn/reference/android/hardware/SensorEvent.html
  32. 蓝牙 API：https://developer.android.com.cn/reference/android/bluetooth/package-summary.html
  33. NDEF 推送协议：https://aosp.org.cn/docs/compatibility/ndef-push-protocol.pdf
  34. MIFARE MF1S503X：http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  35. MIFARE MF1S703X：http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  36. MIFARE MF0ICU1：http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  37. MIFARE MF0ICU2：http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  38. MIFARE AN130511：http://www.nxp.com/documents/application_note/AN130511.pdf
  39. MIFARE AN130411：http://www.nxp.com/documents/application_note/AN130411.pdf
  40. 相机方向 API：https://developer.android.com.cn/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  41. android.hardware.Camera：https://developer.android.com.cn/reference/android/hardware/Camera.html
  42. Android 安全和权限参考：https://developer.android.com.cn/guide/topics/security/security.html
  43. Apps for Android：http://code.google.com/p/apps-for-android

许多这些参考资料直接或间接地来源于 Android 2.3 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.3 SDK [参考资料，4] 公开的任何已记录 API 的完整实现，包括所有已记录的行为。

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

本兼容性定义允许设备实现省略 Android 包含 API 的某些类型的硬件。在这种情况下，API **必须**仍然存在并以合理的方式运行。有关此场景的具体要求，请参阅第 7 节。

3.2. 软 API 兼容性

除了第 3.1 节中的托管 API 之外，Android 还包括重要的运行时“软”API，其形式包括 Intent、权限以及应用编译时无法强制执行的 Android 应用的类似方面。本节详细介绍了与 Android 2.3 兼容所需的“软”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.3，此字段**必须**具有整数值 9。
android.os.Build.VERSION.INCREMENTAL 设备实现者选择的值，用于指定当前正在执行的 Android 系统的特定版本，采用人类可读的格式。对于提供给最终用户的不同版本，**不得**重复使用此值。此字段的典型用途是指示用于生成版本的版本号或源代码控制更改标识符。对此字段的具体格式没有要求，但它**不得**为 null 或空字符串 ("")。
android.os.Build.BOARD 设备实现者选择的值，用于以人类可读的格式标识设备使用的特定内部硬件。此字段的可能用途是指示为设备供电的电路板的特定修订版本。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
android.os.Build.BRAND 设备实现者选择的值，用于以人类可读的格式标识生产设备的公司的名称、组织、个人等。此字段的可能用途是指示销售设备的 OEM 和/或运营商。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
android.os.Build.DEVICE 设备实现者选择的值，用于标识设备主体（有时称为“工业设计”）的特定配置或修订版本。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
android.os.Build.FINGERPRINT 唯一标识此版本的字符串。它**应**具有合理的人类可读性。它**必须**遵循以下模板
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例如
acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys
指纹**不得**包含空格字符。如果以上模板中包含的其他字段包含空格字符，则**必须**在构建指纹中将其替换为另一个字符，例如下划线 ("_") 字符。此字段的值**必须**编码为 7 位 ASCII 码。
android.os.Build.HOST 唯一标识构建版本的宿主的字符串，采用人类可读的格式。对此字段的具体格式没有要求，但它**不得**为 null 或空字符串 ("")。
android.os.Build.ID 设备实现者选择的标识符，用于以人类可读的格式指代特定版本。此字段可以与 android.os.Build.VERSION.INCREMENTAL 相同，但**应**是一个对最终用户而言足够有意义的值，以便区分软件版本。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
android.os.Build.MODEL 设备实现者选择的值，其中包含最终用户已知的设备名称。这**应该**与设备向最终用户销售和营销的名称相同。对此字段的具体格式没有要求，但它**不得**为 null 或空字符串 ("")。
android.os.Build.PRODUCT 设备实现者选择的值，其中包含设备的开发名称或代号。**必须**是人类可读的，但不一定旨在供最终用户查看。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
android.os.Build.TAGS 设备实现者选择的以逗号分隔的标记列表，用于进一步区分版本。例如，“unsigned,debug”。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
android.os.Build.TIME 表示构建发生时间的时间戳的值。
android.os.Build.TYPE 设备实现者选择的值，用于指定版本的运行时配置。此字段**应该**具有与三种典型的 Android 运行时配置相对应的值之一：“user”、“userdebug”或“eng”。此字段的值**必须**编码为 7 位 ASCII 码，并与正则表达式 "^[a-zA-Z0-9.,_-]+$" 匹配。
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 系统应用程序

  • 桌面时钟
  • 浏览器
  • 日历
  • 计算器
  • 联系人
  • 电子邮件
  • 图库
  • 全局搜索
  • 启动器
  • 音乐
  • 设置

核心 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.* 命名空间中的 ACTION、CATEGORY 或其他键字符串来遵守任何新 Intent 或广播 Intent 模式的 Android 组件。设备实现者**不得**包含任何使用属于另一个组织的软件包空间中的 ACTION、CATEGORY 或其他键字符串来遵守任何新 Intent 或广播 Intent 模式的 Android 组件。设备实现者**不得**更改或扩展第 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 文件提供的原生代码，该文件是为适当的设备硬件架构编译的。由于原生代码高度依赖于底层处理器技术，因此 Android 在 Android NDK 的文件 docs/CPU-ARCH-ABIS.txt 中定义了许多应用程序二进制接口 (ABI)。如果设备实现与一个或多个定义的 ABI 兼容，则它**应**实现与 Android NDK 的兼容性，如下所示。

如果设备实现包括对 Android ABI 的支持，则它

  • **必须**包括对在托管环境中运行的代码调用原生代码的支持，使用标准 Java Native Interface (JNI) 语义。
  • **必须**与以下列表中每个必需库的源代码兼容（即标头兼容）和二进制兼容（对于 ABI）
  • **必须**通过 android.os.Build.CPU_ABI API 准确报告设备支持的原生应用程序二进制接口 (ABI)
  • **必须**仅报告最新版本的 Android NDK 的文件 docs/CPU-ARCH-ABIS.txt 中记录的那些 ABI
  • **应该**使用上游 Android 开源项目中提供的源代码和头文件进行构建

以下原生代码 API **必须**可用于包含原生代码的应用

  • libc（C 库）
  • libm（数学库）
  • 对 C++ 的最低限度支持
  • JNI 接口
  • liblog（Android 日志记录）
  • libz（Zlib 压缩）
  • libdl（动态链接器）
  • libGLESv1_CM.so (OpenGL ES 1.0)
  • libGLESv2.so (OpenGL ES 2.0)
  • libEGL.so（原生 OpenGL 曲面管理）
  • libjnigraphics.so
  • libOpenSLES.so（开放声音库音频支持）
  • libandroid.so（原生 Android 活动支持）
  • 对 OpenGL 的支持，如下所述

请注意，未来版本的 Android NDK 可能会引入对其他 ABI 的支持。如果设备实现与现有预定义 ABI 不兼容，则**不得**报告对任何 ABI 的支持。

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

3.4. Web 兼容性

许多开发者和应用程序都依赖于 android.webkit.WebView 类 [参考资料，8] 的行为来构建其用户界面，因此 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.3 的上游 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 [参考资料，9]。最低限度，设备实现**必须**支持 WebView 中与 HTML5 关联的以下每个 API

此外，设备实现必须支持 HTML5/W3C webstorage API [资源, 13]，并且应该支持 HTML5/W3C IndexedDB API [资源, 14]。请注意，由于 Web 开发标准机构正在转变为支持 IndexedDB 而不是 webstorage，因此 IndexedDB 预计将在未来版本的 Android 中成为必需组件。

HTML5 API，与所有 JavaScript API 一样，默认情况下必须在 WebView 中禁用，除非开发人员通过常用的 Android API 显式启用它们。

3.4.2. 浏览器兼容性

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

实现可以附带独立的浏览器应用程序中的自定义用户代理字符串。

独立的浏览器应用程序（无论是基于上游 WebKit 浏览器应用程序还是第三方替代品）都应该尽可能多地支持 HTML5 [资源, 9]。最低限度，设备实现必须支持与 HTML5 相关的每个 API

此外，设备实现必须支持 HTML5/W3C webstorage API [资源, 13]，并且应该支持 HTML5/W3C IndexedDB API [资源, 14]。请注意，由于 Web 开发标准机构正在转变为支持 IndexedDB 而不是 webstorage，因此 IndexedDB 预计将在未来版本的 Android 中成为必需组件。

3.5. API 行为兼容性

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

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

以上列表并非详尽无遗。兼容性测试套件 (CTS) 测试了平台行为兼容性的重要部分，但并非全部。实施者有责任确保与 Android 开源项目的行为兼容性。因此，设备实施者应尽可能使用通过 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 添加到其他公司的命名空间中。此外，如果设备实现包含标准 Android 命名空间之外的自定义 API，则这些 API 必须打包在 Android 共享库中，以便只有显式使用它们的应用程序（通过 <uses-library> 机制）才会受到此类 API 增加内存使用量的影响。

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

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

3.7. 虚拟机兼容性

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

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

3.8. 用户界面兼容性

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

3.8.1. 微件

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

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

3.8.2. 通知

Android 包含允许开发人员通知用户重要事件的 API [资源, 17]。设备实施者必须提供对定义的每种通知类别的支持；具体来说：声音、振动、灯光和状态栏。

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

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

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

设备实现可以附带替代搜索用户界面，但应该包含一个硬或软专用搜索按钮，该按钮可以随时在任何应用程序中使用，以调用搜索框架，其行为在 API 文档中提供。

3.8.4. Toast

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

3.8.5. 动态壁纸

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

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

能够如上所述可靠运行动态壁纸的设备实现应该实现动态壁纸。确定无法如上所述可靠运行动态壁纸的设备实现不得实现动态壁纸。

4. 应用打包兼容性

设备实现必须安装和运行由官方 Android SDK [资源, 23] 中包含的“aapt”工具生成的 Android “.apk”文件。

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

5. 多媒体兼容性

设备实现必须完全实现所有多媒体 API。设备实现必须包括对下述所有多媒体编解码器的支持，并且应该满足下述声音处理指南。设备实现必须至少包含一种形式的音频输出，例如扬声器、耳机插孔、外部扬声器连接等。

5.1. 媒体编解码器

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

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

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

5.1.1. 媒体解码器

设备实现必须包含表中描述的每种编解码器和格式的解码器实现。请注意，上游 Android 开源项目提供了每种媒体类型的解码器。

音频
名称 详情 文件/容器格式
AAC LC/LTP 标准比特率高达 160 kbps 和采样率在 8 到 48kHz 之间的任意组合的单声道/立体声内容 3GPP (.3gp) 和 MPEG-4 (.mp4, .m4a)。不支持原始 AAC (.aac)
HE-AACv1 (AAC+)
HE-AACv2 (增强型 AAC+)
AMR-NB 4.75 到 12.2 kbps 采样率 @ 8kHz 3GPP (.3gp)
AMR-WB 9 种速率，从 6.60 kbit/s 到 23.85 kbit/s 采样率 @ 16kHz 3GPP (.3gp)
MP3 单声道/立体声 8-320Kbps 恒定 (CBR) 或可变比特率 (VBR) MP3 (.mp3)
MIDI 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   Ogg (.ogg)
PCM 8 位和 16 位线性 PCM（速率高达硬件限制） WAVE (.wav)
图像
JPEG 基本 + 渐进  
GIF    
PNG    
BMP    
视频
H.263   3GPP (.3gp) 文件
H.264   3GPP (.3gp) 和 MPEG-4 (.mp4) 文件
MPEG4 简单配置文件   3GPP (.3gp) 文件

5.1.2. 媒体编码器

设备实现应该包含尽可能多的第 5.1.1 节中列出的媒体格式的编码器。但是，某些编码器对于缺少某些可选硬件的设备没有意义；例如，如果设备缺少任何摄像头，则 H.263 视频的编码器就没有意义。因此，设备实现必须根据下表中描述的条件实现媒体编码器。

有关设备实现可以省略硬件的条件的详细信息，请参阅第 7 节。

音频
名称 详情 文件/容器格式 条件
AMR-NB 4.75 到 12.2 kbps 采样率 @ 8kHz 3GPP (.3gp) 包含麦克风硬件并定义 android.hardware.microphone 的设备实现必须包含这些音频格式的编码器。
AMR-WB 9 种速率，从 6.60 kbit/s 到 23.85 kbit/s 采样率 @ 16kHz 3GPP (.3gp)
AAC LC/LTP 标准比特率高达 160 kbps 和采样率在 8 到 48kHz 之间的任意组合的单声道/立体声内容 3GPP (.3gp) 和 MPEG-4 (.mp4, .m4a)。
图像 JPEG 基本 + 渐进   所有设备实现都必须包含这些图像格式的编码器，因为 Android 2.3 包含应用程序可以用来以编程方式生成这些类型文件的 API。
PNG    
视频 H.263   3GPP (.3gp) 文件 包含摄像头硬件并定义 android.hardware.camera 或 android.hardware.camera.front 的设备实现必须包含这些视频格式的编码器。

除了上面列出的编码器之外，设备实现还应该包含 H.264 编码器。请注意，未来版本的兼容性定义计划将此要求更改为“必须”。也就是说，H.264 编码在 Android 2.3 中是可选的，但在未来版本中将是必需的。强烈建议运行 Android 2.3 的现有设备和新设备在 Android 2.3 中满足此要求，否则它们在升级到未来版本时将无法获得 Android 兼容性。

5.2. 音频录制

当应用程序使用 android.media.AudioRecord API 开始录制音频流时，设备实现应该对音频进行采样和录制，并具有以下每种行为

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

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

5.3. 音频延迟

音频延迟广义上定义为应用程序请求音频播放或录制操作与设备实现实际开始操作之间的时间间隔。许多类别的应用程序依赖于短延迟，以实现实时效果，例如音效或 VOIP 通信。包含麦克风硬件并声明 android.hardware.microphone 的设备实现应该满足本节中概述的所有音频延迟要求。有关设备实现可以省略麦克风硬件的条件的详细信息，请参阅第 7 节。

就本节而言

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

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

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

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

如果设备实现满足本节的要求，则可以通过 android.content.pm.PackageManager 类报告对低延迟音频的支持，并报告功能“android.hardware.audio.low-latency”。 [资源, 27] 相反，如果设备实现不满足这些要求，则不得报告对低延迟音频的支持。

6. 开发者工具兼容性

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

  • Android 调试桥 (称为 adb) [资源, 23]
    设备实现必须支持 Android SDK 中记录的所有 adb 功能。设备端 adb 守护程序默认情况下应处于非活动状态，但必须存在用户可访问的机制来打开 Android 调试桥。
  • Dalvik 调试监视器服务 (称为 ddms) [资源, 23]
    设备实现必须支持 Android SDK 中记录的所有 ddms 功能。由于 ddms 使用 adb，因此对 ddms 的支持默认情况下应处于非活动状态，但只要用户已激活 Android 调试桥（如上所述），就必须支持。
  • Monkey [资源, 26]
    设备实现必须包含 Monkey 框架，并使其可供应用程序使用。

大多数基于 Linux 的系统和 Apple Macintosh 系统都可以使用标准 Android SDK 工具识别 Android 设备，而无需额外支持；但是，Microsoft Windows 系统通常需要新的 Android 设备的驱动程序。（例如，新的供应商 ID，有时是新的设备 ID，需要 Windows 系统的自定义 USB 驱动程序。）如果设备实现未被标准 Android SDK 中提供的 adb 工具识别，则设备实施者必须提供 Windows 驱动程序，允许开发人员使用 adb 协议连接到设备。这些驱动程序必须为 Windows XP、Windows Vista 和 Windows 7 提供，包括 32 位和 64 位版本。

7. 硬件兼容性

Android 旨在使设备实施者能够创建创新的外形尺寸和配置。与此同时，Android 开发人员编写创新的应用程序，这些应用程序依赖于通过 Android API 提供的各种硬件和功能。本节中的要求在设备实施者的创新与开发人员确保他们的应用程序仅在能够正常运行的设备上可用的需求之间取得了平衡。

如果设备包含具有第三方开发人员的相应 API 的特定硬件组件，则设备实现必须按照 Android SDK 文档中的描述实现该 API。如果 SDK 中的 API 与声明为可选的硬件组件交互，并且设备实现不具备该组件

  • 组件 API 的完整类定义（如 SDK 文档所述）必须仍然存在
  • API 的行为必须以某种合理的方式实现为无操作
  • API 方法必须在 SDK 文档允许的情况下返回 null 值
  • API 方法必须在 SDK 文档不允许 null 值的情况下返回类的无操作实现
  • API 方法不得抛出 SDK 文档中未记录的异常

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

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

7.1. 显示和图形

Android 2.3 包含自动调整应用程序资产和 UI 布局以适应设备的设施，以确保第三方应用程序在各种硬件配置上良好运行 [资源, 28]。设备必须正确实现这些 API 和行为，如本节详细说明。

7.1.1. 屏幕配置

设备实现可以使用任何像素尺寸的屏幕，前提是它们满足以下要求

  • 屏幕的物理对角线尺寸必须至少为 2.5 英寸
  • 密度必须至少为 100 dpi
  • 宽高比必须在 1.333 (4:3) 和 1.779 (16:9) 之间
  • 使用的显示技术由正方形像素组成

屏幕满足上述要求的设备实现被认为是兼容的，不需要采取额外的措施。Android 框架实现自动计算显示特性，例如屏幕尺寸 bucket 和密度 bucket。在大多数情况下，框架的决策是正确的。如果使用默认框架计算，则不需要采取额外的措施。希望更改默认值或使用不符合上述要求的屏幕的设备实施者必须联系 Android 兼容性团队以获得指导，如第 12 节中所述。

上述要求使用的单位定义如下

  • “物理对角线尺寸”是显示器发光部分的两个相对角之间的英寸距离。
  • “dpi”（意思是“每英寸点数”）是 1 英寸线性水平或垂直跨度内包含的像素数。在列出 dpi 值的地方，水平和垂直 dpi 都必须在范围内。
  • “宽高比”是屏幕较长尺寸与较短尺寸的比率。例如，480x854 像素的显示器的宽高比为 854 / 480 = 1.779，或大致“16:9”。

设备实现必须仅使用具有单一静态配置的显示器。也就是说，设备实现不得启用多个屏幕配置。例如，由于典型的电视支持多种分辨率，例如 1080p、720p 等，因此此配置与 Android 2.3 不兼容。（但是，对此类配置的支持正在调查中，并计划在未来版本的 Android 中实现。）

7.1.2. 显示指标

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

7.1.3. 声明的屏幕支持

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

7.1.4. 屏幕方向

兼容设备必须支持应用程序动态定向到纵向或横向屏幕方向。也就是说，设备必须尊重应用程序对特定屏幕方向的请求。设备实现可以选择纵向或横向方向作为默认方向。无法物理旋转的设备可以通过“信箱模式”来满足此要求，即仅使用可用显示区域的一部分来显示请求纵向模式的应用程序。

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

7.1.5. 3D 图形加速

设备实现必须支持 OpenGL ES 1.0，这是 Android 2.3 API 所要求的。对于缺少 3D 加速硬件的设备，上游 Android 开源项目提供了 OpenGL ES 1.0 的软件实现。设备实现应该支持 OpenGL ES 2.0。

实现可以省略 Open GL ES 2.0 支持；但是，如果省略了支持，则设备实现不得报告为支持 OpenGL ES 2.0。具体来说，如果设备实现缺少 OpenGL ES 2.0 支持

  • 托管 API（例如通过 GLES10.getString() 方法）不得报告支持 OpenGL ES 2.0
  • 原生 C/C++ OpenGL API（即通过 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 提供给应用程序的 API）不得报告支持 OpenGL ES 2.0。

相反，如果设备实现确实支持 OpenGL ES 2.0，则必须通过刚刚列出的途径准确报告该支持。

请注意，Android 2.3 包括对应用程序可选地指定它们需要特定的 OpenGL 纹理压缩格式的支持。这些格式通常是供应商特定的。Android 2.3 不要求设备实现实现任何特定的纹理压缩格式。但是，它们应该通过 OpenGL API 中的 getString() 方法准确报告它们支持的任何纹理压缩格式。

7.2. 输入设备

Android 2.3 支持多种用户输入模式。设备实现必须支持本节中提供的用户输入设备。

7.2.1. 键盘

设备实现

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

7.2.2. 非触摸导航

设备实现

  • 可以省略非触摸导航选项（即，可以省略轨迹球、d-pad 或滚轮）
  • 必须报告 android.content.res.Configuration.navigation [资源, 30] 的正确值
  • 必须为文本的选择和编辑提供合理的替代用户界面机制，该机制与输入管理引擎兼容。上游 Android 开源代码包含适用于缺少非触摸导航输入的设备的选择机制。

7.2.3. 导航键

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

设备实施者还应该提供专用的搜索键。设备实施者也可以为电话呼叫提供发送和结束键。

7.2.4. 触摸屏输入

设备实现

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

7.3. 传感器

Android 2.3 包括用于访问各种传感器类型的 API。设备实现通常可以省略这些传感器，如下面的小节中提供的那样。如果设备包含具有第三方开发人员的相应 API 的特定传感器类型，则设备实现必须按照 Android SDK 文档中的描述实现该 API。例如，设备实现

  • 必须根据 android.content.pm.PackageManager 类准确报告传感器的存在或不存在。 [资源, 27]
  • 必须通过 SensorManager.getSensorList() 和类似方法返回支持传感器的准确列表
  • 必须对所有其他传感器 API 表现出合理的行为（例如，当应用程序尝试注册侦听器时返回 true 或 false，当不存在相应的传感器时不调用传感器侦听器等）

以上列表并非详尽无遗；Android SDK 的文档行为应被视为权威。

某些传感器类型是合成的，这意味着它们可以从一个或多个其他传感器提供的数据中派生出来。（示例包括方向传感器和线性加速度传感器。）当设备实现包含先决条件的物理传感器时，设备实现应该实现这些传感器类型。

Android 2.3 API 引入了“流式”传感器的概念，这是一种连续返回数据而不是仅在数据更改时才返回数据的传感器。对于 Android 2.3 SDK 文档指示为流式传感器的任何 API，设备实现必须持续提供定期数据样本。

7.3.1. 加速度计

设备实现应该包含 3 轴加速度计。如果设备实现确实包含 3 轴加速度计，则它

  • 必须能够以 50 Hz 或更高的频率传递事件
  • 必须符合 Android API 中详细说明的 Android 传感器坐标系（参见 [资源, 31]）
  • 必须能够在任何三维矢量上测量从自由落体到两倍重力 (2g) 或更大的范围
  • 必须具有 8 位或更高的精度
  • 标准偏差必须不大于 0.05 m/s^2

7.3.2. 磁力计

设备实现应该包含 3 轴磁力计（即指南针）。如果设备确实包含 3 轴磁力计，则它

  • 必须能够以 10 Hz 或更高的频率传递事件
  • 必须符合 Android API 中详细说明的 Android 传感器坐标系（参见 [资源, 31]）。
  • 必须能够采样足以覆盖地磁场范围的场强范围
  • 必须具有 8 位或更高的精度
  • 标准偏差必须不大于 0.5 µT

7.3.3. GPS

设备实现应该包含 GPS 接收器。如果设备实现确实包含 GPS 接收器，则它应该包含某种形式的“辅助 GPS”技术，以最大限度地缩短 GPS 定位时间。

7.3.4. 陀螺仪

设备实现应该包含陀螺仪（即角变化传感器）。除非还包含 3 轴加速度计，否则设备不应包含陀螺仪传感器。如果设备实现包含陀螺仪，则它

  • 必须能够测量高达 5.5*Pi 弧度/秒（即，大约每秒 1,000 度）的方向变化
  • 必须能够以 100 Hz 或更高的频率传递事件
  • 必须具有 8 位或更高的精度

7.3.5. 气压计

设备实现可以包含气压计（即环境气压传感器）。如果设备实现包含气压计，则它

  • 必须能够以 5 Hz 或更高的频率传递事件
  • 必须具有足够的精度以实现估计海拔高度

7.3.7. 温度计

设备实现可以但不应该包含温度计（即温度传感器）。如果设备实现确实包含温度计，则它必须测量设备 CPU 的温度。它不得测量任何其他温度。（请注意，此传感器类型在 Android 2.3 API 中已弃用。）

7.3.7. 光度计

设备实现可以包含光度计（即环境光传感器）。

7.3.8. 接近传感器

设备实现方案可以包含距离传感器。如果设备实现方案确实包含距离传感器，则必须测量与屏幕方向相同的物体的距离。也就是说，距离传感器必须定向为检测靠近屏幕的物体，因为这种传感器类型的主要目的是检测用户是否正在使用手机。如果设备实现方案包含任何其他方向的距离传感器，则不得通过此 API 访问。如果设备实现方案具有距离传感器，则必须具有 1 位或更高的精度。

7.4. 数据连接

网络连接和访问互联网是 Android 的重要功能。同时，设备到设备之间的交互为 Android 设备和应用程序增加了显著价值。设备实现方案必须满足本节中的数据连接要求。

7.4.1. 电话

Android 2.3 API 和本文档中使用的“电话”特指与通过 GSM 或 CDMA 网络进行语音呼叫和发送 SMS 消息相关的硬件。虽然这些语音呼叫可能是也可能不是分组交换的，但出于 Android 2.3 的目的，它们被认为是独立于可能使用相同网络实现的任何数据连接。换句话说，Android 的“电话”功能和 API 特指语音呼叫和 SMS；例如，无法拨打电话或发送/接收 SMS 消息的设备实现方案不得报告“android.hardware.telephony”功能或任何子功能，无论它们是否使用蜂窝网络进行数据连接。

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

7.4.2. IEEE 802.11 (WiFi)

Android 2.3 设备实现方案应该包含对一种或多种形式的 802.11 (b/g/a/n 等) 的支持。如果设备实现方案确实包含对 802.11 的支持，则必须实现相应的 Android API。

7.4.3. 蓝牙

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

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

7.4.4. 近场通信

设备实现方案应该包含近场通信 (NFC) 的收发器和相关硬件。如果设备实现方案确实包含 NFC 硬件，则它

  • 必须从 android.content.pm.PackageManager.hasSystemFeature() 方法报告 android.hardware.nfc 功能。[资源, 27]
  • 必须能够通过以下 NFC 标准读取和写入 NDEF 消息
    • 必须能够通过以下 NFC 标准充当 NFC Forum 读取器/写入器（由 NFC Forum 技术规范 NFCForum-TS-DigitalProtocol-1.0 定义）
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • NfcV (ISO 15693)
      • IsoDep (ISO 14443-4)
      • NFC Forum 标签类型 1、2、3、4（由 NFC Forum 定义）
    • 必须能够通过以下对等标准和协议传输和接收数据
      • ISO 18092
      • LLCP 1.0（由 NFC Forum 定义）
      • SDP 1.0（由 NFC Forum 定义）
      • NDEF 推送协议 [资源, 33]
    • 必须在 NFC 发现模式下扫描所有支持的技术。
    • 应该在设备唤醒且屏幕处于活动状态时处于 NFC 发现模式。

    （请注意，JIS、ISO 和 NFC Forum 上述规范的公开链接不可用。）

    此外，设备实现方案应该支持以下广泛部署的 MIFARE 技术。

    请注意，Android 2.3.3 包含用于这些 MIFARE 类型的 API。如果设备实现方案支持 MIFARE，则它

    • 必须实现 Android SDK 文档中记录的相应 Android API
    • 必须从 android.content.pm.PackageManager.hasSystemFeature() 方法报告 com.nxp.mifare 功能。[资源, 27] 请注意，这不是标准的 Android 功能，因此不会作为 PackageManager 类上的常量出现。
    • 不得实现相应的 Android API，也不得报告 com.nxp.mifare 功能，除非它还实现了本节中描述的通用 NFC 支持

    如果设备实现方案不包含 NFC 硬件，则不得从 android.content.pm.PackageManager.hasSystemFeature() 方法声明 android.hardware.nfc 功能 [资源, 27]，并且必须将 Android 2.3 NFC API 实现为无操作。

    由于类 android.nfc.NdefMessage 和 android.nfc.NdefRecord 表示与协议无关的数据表示格式，因此即使设备实现方案不包含对 NFC 的支持或声明 android.hardware.nfc 功能，也必须实现这些 API。

    7.4.5. 最低网络能力

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

    物理网络标准（如以太网）是主要数据连接的设备实现方案应该还包含对至少一种常见的无线数据标准（如 802.11 (WiFi)）的支持。

    设备可以实现多种形式的数据连接。

    7.5. 相机

    设备实现方案应该包含后置摄像头，并且可以包含前置摄像头。后置摄像头是位于设备显示屏对面一侧的摄像头；也就是说，它像传统相机一样拍摄设备远侧的场景。前置摄像头是位于设备显示屏同一侧的摄像头；也就是说，通常用于拍摄用户图像的摄像头，例如用于视频会议和类似应用。

    7.5.1. 后置摄像头

    设备实现方案应该包含后置摄像头。如果设备实现方案包含后置摄像头，则它

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

    7.5.2. 前置摄像头

    设备实现方案可以包含前置摄像头。如果设备实现方案包含前置摄像头，则它

    • 必须具有至少 VGA（即 640x480 像素）的分辨率
    • 不得将前置摄像头用作摄像头 API 的默认摄像头。也就是说，Android 2.3 中的摄像头 API 对前置摄像头具有特定支持，即使设备上只有前置摄像头，设备实现方案也不得配置 API 将前置摄像头视为默认的后置摄像头。
    • 可以包含后置摄像头可用的功能（例如自动对焦、闪光灯等），如第 7.5.1 节所述。
    • 必须水平反射（即镜像）应用程序在 CameraPreview 中显示的流，如下所示
      • 如果设备实现方案能够由用户旋转（例如通过加速度计自动旋转或通过用户输入手动旋转），则摄像头预览必须相对于设备当前方向水平镜像。
      • 如果当前应用程序已通过调用 android.hardware.Camera.setDisplayOrientation() [资源, 40] 方法显式请求旋转摄像头显示，则摄像头预览必须相对于应用程序指定的方向水平镜像。
      • 否则，预览必须沿设备的默认水平轴镜像。
    • 必须以与摄像头预览图像流相同的方式镜像返回给任何“postview”摄像头回调处理程序的图像数据。（如果设备实现方案不支持 postview 回调，则此要求显然不适用。）
    • 不得镜像返回给应用程序回调或提交到媒体存储的最终捕获的静止图像或视频流

    7.5.3. 相机 API 行为

    设备实现方案必须为前置和后置摄像头实现以下与摄像头相关的 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 编码格式。也就是说，NV21 必须是默认格式。
    3. 设备实现方案应该支持 YV12 格式（由 android.graphics.ImageFormat.YV12 常量表示）用于前置和后置摄像头的摄像头预览。请注意，未来版本的兼容性定义计划将此要求更改为“必须”。也就是说，YV12 支持在 Android 2.3 中是可选的，但在未来版本中将是必需的。强烈鼓励运行 Android 2.3 的现有和新设备在 Android 2.3 中满足此要求，否则它们在升级到未来版本时将无法获得 Android 兼容性。

    设备实现方案必须实现 Android 2.3 SDK 文档 [资源, 41] 中包含的完整摄像头 API，无论设备是否包含硬件自动对焦或其他功能。例如，缺少自动对焦的摄像头仍然必须调用任何注册的 android.hardware.Camera.AutoFocusCallback 实例（即使这与非自动对焦摄像头无关）。请注意，这确实适用于前置摄像头；例如，即使大多数前置摄像头不支持自动对焦，API 回调仍然必须如上所述“伪造”。

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

    7.5.4. 相机方向

    前置和后置摄像头（如果存在）必须定向，以使摄像头的长尺寸与屏幕的长尺寸对齐。也就是说，当设备以横向方向握持时，摄像头必须以横向方向捕获图像。无论设备的自然方向如何，这都适用；也就是说，它既适用于横向为主的设备，也适用于纵向为主的设备。

    7.6. 内存和存储

    Android 2.3 的基本功能是运行应用程序。设备实现方案必须满足本节的要求，以确保足够的存储空间和内存供应用程序正常运行。

    7.6.1. 最低内存和存储空间

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

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

    除了上述要求之外，设备实现方案应该至少具有 1GB 的非易失性存储空间可供用户数据使用。请注意，在未来版本的 Android 中，此较高要求计划成为硬性最低要求。强烈鼓励设备实现方案现在就满足这些要求，否则它们可能没有资格获得未来版本的 Android 兼容性。

    Android API 包含一个下载管理器，应用程序可以使用它来下载数据文件。下载管理器实现方案必须能够下载大小为 55MB 或更大的单个文件。下载管理器实现方案应该能够下载大小为 100MB 或更大的文件。

    7.6.2. 应用共享存储

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

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

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

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

    无论使用何种形式的共享存储，设备实现方案必须提供某种机制来从主机计算机访问共享存储的内容，例如 USB 大容量存储或媒体传输协议。

    考虑两个常见示例来说明这一点。如果设备实现方案包含 SD 卡插槽以满足共享存储要求，则必须在销售给用户时随设备包含 1GB 或更大的 FAT 格式 SD 卡，并且必须默认挂载。或者，如果设备实现方案使用内部固定存储来满足此要求，则该存储必须为 1GB 或更大，并挂载在 /sdcard 上（或者如果挂载在其他位置，则 /sdcard 必须是指向物理位置的符号链接。）

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

    7.7. USB

    设备实现

    • 必须实现 USB 客户端，可连接到带有标准 USB-A 端口的 USB 主机
    • 必须通过 USB 实现 Android 调试桥 (ADB)（如第 7 节所述）
    • 必须实现 USB 大容量存储规范，以允许连接到设备的主机访问 /sdcard 卷的内容
    • 应该在设备端使用 micro USB 外形尺寸
    • 可以在设备端包含非标准端口，但如果是这样，则必须随附能够将自定义引脚排列连接到标准 USB-A 端口的电缆

    8. 性能兼容性

    兼容的实现方案必须不仅确保应用程序在设备上能够正常运行，而且要以合理的性能和良好的整体用户体验运行。设备实现方案必须满足下表中定义的 Android 2.3 兼容设备的关键性能指标

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

    9. 安全模型兼容性

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

    9.1. 权限

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

    9.2. UID 和进程隔离

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

    9.3. 文件系统权限

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

    9.4. 备选执行环境

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

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

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

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

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

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

    备用运行时不得以超级用户 (root) 或任何其他用户 ID 的任何特权启动、被授予或授予给其他应用程序。

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

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

    10. 软件兼容性测试

    Android 开源项目包含各种测试工具，用于验证设备实现方案是否兼容。设备实现方案必须通过本节中描述的所有测试。

    但是，请注意，没有哪个软件测试包是完全全面的。因此，强烈鼓励设备实现者尽可能少地更改 Android 开源项目提供的 Android 2.3 的参考和首选实现。这将最大限度地降低引入错误的风险，这些错误会导致不兼容，需要返工和潜在的设备更新。

    10.1. 兼容性测试套件

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

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

    必须通过设备实现方案软件完成时可用的最新版本的 Android 兼容性测试套件 (CTS)。（CTS 可作为 Android 开源项目 [资源, 2] 的一部分提供。）CTS 测试了本文档中概述的许多组件，但并非全部。

    10.2. CTS 验证程序

    设备实现方案必须正确执行 CTS Verifier 中的所有适用用例。CTS Verifier 包含在兼容性测试套件中，旨在由人工操作员运行，以测试无法通过自动化系统测试的功能，例如摄像头和传感器的正确功能。

    CTS Verifier 具有针对多种硬件的测试，包括一些可选硬件。设备实现方案必须通过其拥有的硬件的所有测试；例如，如果设备拥有加速度计，则必须正确执行 CTS Verifier 中的加速度计测试用例。对于此兼容性定义文档中注明为可选的功能的测试用例可以跳过或省略。

    如上所述，每个设备和每个版本必须正确运行 CTS Verifier。但是，由于许多版本非常相似，因此设备实现者不必显式地在仅在细微方面不同的版本上运行 CTS Verifier。具体而言，与已通过 CTS Verifier 的实现方案仅在包含的语言环境、品牌等集合方面不同的设备实现方案可以省略 CTS Verifier 测试。

    10.3. 参考应用

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

    • “Apps for Android”应用程序 [资源, 43]。
    • Replica Island（在 Android Market 中提供；仅当设备实现方案支持 OpenGL ES 2.0 时才需要）

    对于要被视为兼容的实现方案，上述每个应用程序必须在实现方案上启动并正确运行。

    11. 可更新软件

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

    可以使用任何方法，前提是它可以替换设备上预装的整个软件。例如，以下任何方法都将满足此要求

    • 通过无线 (OTA) 下载并通过重新启动进行离线更新
    • 通过 USB 从主机 PC 进行“有线”更新
    • 通过重新启动和从可移动存储上的文件进行“离线”更新

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

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

    12. 联系我们

    您可以联系文档作者 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 结束测试部分，而另一些用例使用 Back。这些测试不是冗余的，也不是可选的：目的是验证当 Activity 被显式终止（通过用户按 Back 键，这将调用 finish()）和隐式发送到后台（通过用户按 Home 键）时，蓝牙 API 和堆栈是否正常工作。每个测试序列必须按描述执行。