Android 2.3 兼容性定义

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

目录

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

一、简介

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

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

在本文档中，“设备实现者”或“实现者”是指开发运行 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 兼容性计划概述： http://source.android.com/docs/compatibility/index.html
  3. Android 开源项目：http: //source.android.com/
  4. API定义和文档： http://developer.android.com/reference/packages.html
  5. Android 权限参考： http://developer.android.com/reference/android/Manifest.permission.html
  6. android.os.Build参考： http://developer.android.com/reference/android/os/Build.html
  7. Android 2.3 允许的版本字符串： http://source.android.com/docs/compatibility/2.3/versions.html
  8. android.webkit.WebView 类： http://developer.android.com/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 网络数据库 API： http://www.w3.org/TR/webdatabase/
  14. HTML5/W3C IndexedDB API： http://www.w3.org/TR/IndexedDB/
  15. Dalvik 虚拟机规范：可在 Android 源代码中找到，位于 dalvik/docs
  16. 应用程序小部件： http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  17. 通知： http ://developer.android.com/guide/topics/ui/notifiers/notifications.html
  18. 应用程序资源： http://code.google.com/android/reference/available-resources.html
  19. 状态栏图标样式指南： http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstruct
  20. 搜索管理器： http://developer.android.com/reference/android/app/SearchManager.html
  21. 吐司：http: //developer.android.com/reference/android/widget/Toast.html
  22. 动态壁纸： https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  23. 参考工具文档（针对adb、aapt、ddms）： http://developer.android.com/guide/developing/tools/index.html
  24. Android apk文件说明： http://developer.android.com/guide/topics/fundamentals.html
  25. 清单文件： http://developer.android.com/guide/topics/manifest/manifest-intro.html
  26. Monkey测试工具： https://developer.android.com/studio/test/other-testing-tools/monkey
  27. Android 硬件功能列表： http://developer.android.com/reference/android/content/pm/PackageManager.html
  28. 支持多屏幕： http://developer.android.com/guide/practices/screens_support.html
  29. android.util.DisplayMetrics： http://developer.android.com/reference/android/util/DisplayMetrics.html
  30. android.content.res.Configuration： http://developer.android.com/reference/android/content/res/Configuration.html
  31. 传感器坐标空间： http://developer.android.com/reference/android/hardware/SensorEvent.html
  32. 蓝牙 API： http://developer.android.com/reference/android/bluetooth/package-summary.html
  33. NDEF 推送协议： http://source.android.com/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： http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  41. android.hardware.Camera：http://developer.android.com/reference/android/hardware/Camera.html
  42. Android 安全和权限参考： http://developer.android.com/guide/topics/security/security.html
  43. 适用于 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 公开的任何记录的 API 的完整实现，包括所有记录的行为 [参考资料，4 ]。

设备实现不得省略任何托管 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类 [ Resources, 6 ] 上的许多常量，用于描述当前设备。为了跨设备实现提供一致、有意义的值，下表包含设备实现必须遵守的这些值的格式的附加限制。

范围评论
android.os.Build.VERSION.RELEASE当前执行的 Android 系统的版本，采用人类可读的格式。该字段必须具有 [ Resources, 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.INCRMENTAL 相同，但应该是一个对于最终用户区分软件版本足够有意义的值。该字段的值必须可编码为 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由设备实现者选择的以逗号分隔的标签列表，用于进一步区分构建。例如，“未签名，调试”。该字段的值必须可编码为 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.意图兼容性

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

3.2.3.1.核心应用意图

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

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

以下应用程序被视为核心 Android 系统应用程序：

  • 台钟
  • 浏览器
  • 日历
  • 计算器
  • 联系方式
  • 电子邮件
  • 画廊
  • 全球搜索
  • 启动器
  • 音乐
  • 设置

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

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

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

3.2.3.2.意图覆盖

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

3.2.3.3.意图命名空间

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

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

3.2.3.4.广播意图

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

3.3.本机 API 兼容性

Dalvik 中运行的托管代码可以调用应用程序 .apk 文件中提供的本机代码，作为针对适当设备硬件架构编译的 ELF .so 文件。由于本机代码高度依赖于底层处理器技术，因此 Android 在 Android NDK 中的文件docs/CPU-ARCH-ABIS.txt中定义了许多应用程序二进制接口 (ABI)。如果设备实现与一个或多个已定义的 ABI 兼容，则它应该实现与 Android NDK 的兼容性，如下所示。

如果设备实现包含对 Android ABI 的支持，则：

  • 必须支持在托管环境中运行的代码，以使用标准 Java 本机接口 (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.网络兼容性

许多开发人员和应用程序的用户界面都依赖于android.webkit.WebView类 [参考资料, 8 ] 的行为，因此 WebView 实现必须在 Android 实现之间兼容。同样，完整、现代的网络浏览器是 Android 用户体验的核心。设备实现必须包含与上游 Android 软件一致的android.webkit.WebView版本，并且必须包含支持现代 HTML5 的浏览器，如下所述。

3.4.1.网页视图兼容性

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 的行为或语义
  • 设备不得更改特定类型系统组件（例如服务、活动、ContentProvider 等）的生命周期或生命周期语义
  • 设备不得更改标准权限的语义

上面的列表并不全面。兼容性测试套件 (CTS) 测试平台的重要部分（但不是全部）的行为兼容性。实现者有责任确保与 Android 开源项目的行为兼容性。因此，设备实现者应该尽可能使用通过 Android 开源项目提供的源代码，而不是重新实现系统的重要部分。

3.6. API命名空间

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

  • java.*
  • javax.*
  • 太阳。*
  • 安卓。*
  • com.android.*

禁止的修改包括：

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

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

设备实现者可以添加自定义 API，但任何此类 API 不得位于另一个组织拥有或引用另一个组织的命名空间中。例如，设备实现者不得将 API 添加到 com.google.* 或类似的命名空间；只有谷歌可以这样做。同样，Google 不得将 API 添加到其他公司的命名空间中。此外，如果设备实现包含标准 Android 命名空间之外的自定义 API，则这些 API 必须打包在 Android 共享库中，以便只有显式使用它们（通过<uses-library>机制）的应用程序才会受到内存使用量增加的影响此类 API。

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

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

3.7.虚拟机兼容性

设备实现必须支持完整的 Dalvik 可执行文件 (DEX) 字节码规范和 Dalvik 虚拟机语义 [参考资料, 15 ]。

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

3.8.用户界面兼容性

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

3.8.1.小部件

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

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

3.8.2.通知

Android 包含的 API 允许开发人员通知用户值得注意的事件 [参考资料，17 ]。设备实现者必须为如此定义的每一类通知提供支持；具体来说：声音、振动、灯光和状态栏。

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

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

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

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

3.8.4.吐司

应用程序可以使用“ Toast” API（在[资源，21 ]中定义）向最终用户显示短的非模式字符串，该字符串在短时间后消失。设备实现必须以某种高可见性显示从​​应用程序到最终用户的吐司。

3.8.5。动态壁纸

Android定义了一种组件类型和相应的API和生命周期，该应用程序允许应用程序将一个或多个“ Live WallPapers”公开给最终用户[ Resources，22 ]。实时壁纸是动画，图案或类似的图像，其输入功能有限，显示为墙纸，在其他应用程序后面。

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

如上所述，能够可靠地运行实时壁纸的设备实现应实现实时壁纸。如上所述，确定不可靠地运行实时壁纸的设备实现不得实现实时壁纸。

4.应用程序包装兼容性

设备实现必须安装并运行Android“ .apk”文件，该文件由官方Android SDK中包含的“ AAPT”工具生成[ Resources，23 ]。

设备实现不得扩展.APK [资源，24 ]，Android清单[资源，25 ]或Dalvik bytecode [ Resources，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）。不支持RAW 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和移动XMF。支持铃声格式RTTTL/RTX，OTA和IMELODY类型0和1（.mid，.xmf，.mxmf）。还有rtttl/rtx（.rtttl，.rtx），ota（.ota）和imelody（.imy）
Ogg Vorbis ogg（.ogg）
相变材料8-和16位线性PCM（速率达到硬件限制）波（.wav）
图像
JPEG基础+渐进式
动图
巴布亚新几内亚
骨形态发生蛋白
视频
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，应用程序可以用来编程来生成这些类型的文件。
巴布亚新几内亚
视频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振幅水平应线性跟踪至少30 dB上的SPL变化，从-18 dB到+12 dB re 90 dB re 90 dB spl在麦克风上。
  • 在90 dB SPL输入水平下，总谐波失真应小于1％至4000 Hz。

注意：尽管上面概述的要求为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”，通过报告“ android.hardware.audio.low-lat-latency”的功能来报告对低延迟音频的支持。 [ Resources，27 ]相反，如果设备实现不符合这些要求，则不得报告对低延迟音频的支持。

6.开发人员工具兼容性

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

  • Android调试桥（称为ADB） [资源，23 ]
    设备实现必须支持Android SDK中记录的所有adb功能。设备侧adb守护程序默认情况下应无活动，但是必须有一个可访问用户的机制来打开Android调试桥。
  • Dalvik调试监视器服务（称为DDM） [资源，23 ]
    设备实现必须支持Android SDK中记录的所有ddms功能。由于ddms使用adb ，因此默认情况下，对ddms的支持应无效，但是每当用户激活Android Debug Bridge（如上所述）时，必须支持DDMS。
  • 猴子[资源，26 ]
    设备实现必须包括猴子框架，并使其可用于使用应用程序。

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

7.硬件兼容性

Android旨在使设备实施者能够创建创新的形式和配置。同时，Android开发人员编写了创新的应用程序，以依靠Android API可用的各种硬件和功能。本节中的要求在设备实施者可用的创新之间取得了平衡，开发人员的需求是确保其应用程序仅适用于可以正确运行的设备。

如果设备包含具有针对第三方开发人员相应的API的特定硬件组件，则设备实现必须如Android SDK文档中所述实现该API。如果SDK中的API与指定为可选的硬件组件相互作用，并且设备实现不具备该组件：

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

这些需求适用的方案的一个典型示例是电话API：即使在非电话设备上，这些API也必须实现为合理的NO-OPS。

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

7.1.显示和图形

Android 2.3包括适当地调整应用程序资产和UI布局的设施，以确保第三方应用程序在各种硬件配置上运行良好[ Resources，28 ]。如本节所述，设备必须正确实施这些API和行为。

7.1.1.屏幕配置

设备实现可以使用任何像素尺寸的屏幕，只要它们符合以下要求：

  • 屏幕必须至少为2.5英寸
  • 密度必须至少100 dpi
  • 长宽比必须在1.333（4：3）和1.779（16：9）之间
  • 所使用的显示技术由方形像素组成

带有屏幕满足的设备实现以上要求是兼容的，无需采取其他措施。 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中定义的所有显示指标的正确值[ Resources，29 ]。

7.1.3.声明为屏幕支持

应用程序可选地指示通过<Supports-Screens> AndroidManifest.xml文件中的<supports-screens>属性支持的屏幕大小。设备实现必须正确地尊重应用程序对Android SDK文档中所述的小型，中和大屏幕的指定支持。

7.1.4.屏幕方向

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

每当通过android.content.res.configuration.orientation，android.view.display.getorientation（）或其他apis查询时，设备必须报告设备当前方向的正确值。

7.1.5。 3D图形加速度

设备实现必须按照Android 2.3 API的要求支持OpenGL ES 1.0。对于缺少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.键盘

设备实现：

  • 必须包括对输入管理框架的支持（该框架允许第三方开发人员创建输入管理引擎 - 即软键盘），如开发人员。
  • 必须至少提供一个软键盘实现（无论是否存在硬键盘）
  • 可能包括其他软键盘实现
  • 可能包括硬件键盘
  • 不得包含与android.content.res.Configuration.keyboard [ Resources，30 ]中指定的格式之一的硬件键盘（即，Qwerty或12-key）

7.2.2.非接触导航

设备实现：

  • 可能会省略非接触式导航选项（即可能省略轨迹球，D-pad或车轮）
  • 必须报告android.content.res.Configuration.navigation的正确值[ Resources，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轴磁力计（即指南针）。

  • 必须能够在10 Hz或更高的情况下提供活动
  • 必须遵守Android API中详细介绍的Android传感器坐标系（请参阅[资源，31 ]）。
  • 必须能够对足以覆盖地磁场的一系列场强度进行采样
  • 必须具有8位准确性或更多
  • 必须具有不超过0.5 µt的标准偏差

7.3.3.全球定位系统

设备实现应包括GPS接收器。如果设备实现确实包括GPS接收器，则应包括某种形式的“辅助GPS”技术，以最大程度地减少GPS锁定时间。

7.3.4.陀螺仪

设备的实现应包括陀螺仪（即角更换传感器。）设备不应包括陀螺仪传感器，除非还包括3轴加速度计。如果设备实现包括陀螺仪，则它：

  • 必须能够测量最高5.5*pi弧度/秒的方向变化（即每秒约1,000度）
  • 必须能够以100 Hz或更高
  • 必须具有8位准确性或更多

7.3.5.晴雨表

设备实现可能包括晴雨表（即环境气压传感器）。如果设备实现包括晴雨表，则包括：

  • 必须能够在5 Hz或更高的情况下提供活动
  • 必须具有足够的精度才能估算高度

7.3.7。温度计

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

7.3.7。光度计

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

7.3.8。接近传感器

设备实现可能包括接近传感器。如果设备实现确实包括接近传感器，则必须在与屏幕相同的方向上测量对象的接近度。也就是说，必须将接近传感器定向以检测靠近屏幕的对象，因为该传感器类型的主要目的是检测用户使用的手机。如果设备实现包括具有任何其他方向的接近传感器，则不得通过此API访问它。如果设备实现具有接近性传感器，则必须具有1位准确性或更高。

7.4.数据连接

网络连接和访问Internet是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作为NO-OPS实现。

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文档[ Resources，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论坛读者/作者（NFC论坛技术规范NFCFORUM-TS-DIGITAL-PROTOCOCOL-1.0）：
      • NFCA（ISO14443-3A）
      • NFCB（ISO14443-3B）
      • NFCF（JIS 6319-4）
      • NFCV（ISO 15693）
      • ISODEP（ISO 14443-4）
      • NFC论坛标签类型1、2、3、4（由NFC论坛定义）
    • 必须能够通过以下对等标准和协议传输和接收数据：
      • ISO 18092
      • LLCP 1.0（由NFC论坛定义）
      • SDP 1.0（由NFC论坛定义）
      • NDEF推定协议[资源，33 ]
    • 必须在NFC发现模式下扫描所有受支持的技术。
    • 当设备醒着时，应处于NFC发现模式。

    （请注意，上述引用的JIS，ISO和NFC论坛规格不可公开可用的链接。）

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

    请注意，Android 2.3.3包括这些Mifare类型的API。如果设备实现支持Mifare，则它：

    • 必须实现Android SDK记录的相应的Android API
    • 必须从android.content.pm.PackageManager.hasSystemFeature()方法报告功能com.nxp.mifare。 [ Resources，27 ]请注意，这不是标准的Android功能，因此在PackageManager类中并不是一个常数。
    • 不得实现相应的Android API，也不必须报告Com.nxp.Mifare功能，除非它也如本节所述实现一般NFC支持

    如果设备实现不包括NFC硬件，则不得从android.content.pm.PackageManager.hasSystemFeature()方法[资源，27 ]声明Android.hardware.nfc功能，并且必须实现Android 2.3 NFC API为NFC API一个no-op。

    正如类android.nfc.NdefMessage和android.nfc.NdefRecord代表独立于协议的数据表示格式一样，设备实现即使它们不包括对NFC的支持或声明Android.hardware.nfc功能，设备实现也必须实现这些API。

    7.4.5。最小网络能力

    设备实现必须包括对一种或多种形式的数据网络的支持。 Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

    Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (WiFi).

    Devices MAY implement more than one form of data connectivity.

    7.5。相机

    Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

    7.5.1. Rear-Facing Camera

    Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

    • MUST have a resolution of at least 2 megapixels
    • SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
    • MAY have fixed-focus or EDOF (extended depth of field) hardware
    • MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

    7.5.2. Front-Facing Camera

    Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

    • MUST have a resolution of at least VGA (that is, 640x480 pixels)
    • MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android 2.3 has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on装置。
    • MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
    • MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
      • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
      • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 40 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
      • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
    • MUST mirror the image data returned to any "postview" camera callback handlers, in the same manner as the camera preview image stream. (If the device implementation does not support postview callbacks, this requirement obviously does not apply.)
    • MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

    7.5.3. Camera API Behavior

    Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

    1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
    2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
    3. Device implementations SHOULD support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. Note that the Compatibility Definition for a future version is planned to change this requirement to "MUST". That is, YV12 support is optional in Android 2.3 but will be required by a future version. Existing and new devices that run Android 2.3 are very strongly encouraged to meet this requirement in Android 2.3 , or they will not be able to attain Android compatibility when upgraded to the future version.

    Device implementations MUST implement the full Camera API included in the Android 2.3 SDK documentation [ Resources, 41 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

    Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types.

    7.5.4. Camera Orientation

    Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, a cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

    7.6。内存和存储

    The fundamental function of Android 2.3 is to run applications. Device implementations MUST the requirements of this section, to ensure adequate storage and memory for applications to run properly.

    7.6.1. Minimum Memory and Storage

    Device implementations MUST have at least 128MB of memory available to the kernel and userspace. The 128MB MUST be in addition to any memory dedicated to hardware components such as radio, memory, and so on that is not under the kernel's control.

    Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

    Beyond the requirements above, device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that this higher requirement is planned to become a hard minimum in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

    The Android APIs include a Download Manager that applications may use to download data files. The Download Manager implementation MUST be capable of downloading individual files 55MB in size, or larger. The Download Manager implementation SHOULD be capable of downloading files 100MB in size, or larger.

    7.6.2. Application Shared Storage

    Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

    Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

    Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

    Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

    Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage or Media Transfer Protocol.

    It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

    Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

    7.7. USB

    设备实现：

    • MUST implement a USB client, connectable to a USB host with a standard USB-A port
    • MUST implement the Android Debug Bridge over USB (as described in Section 7)
    • MUST implement the USB mass storage specification, to allow a host connected to the device to access the contents of the /sdcard volume
    • SHOULD use the micro USB form factor on the device side
    • MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of connecting the custom pinout to standard USB-A port

    8. Performance Compatibility

    Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.3 compatible device defined in the table below:

    公制Performance Threshold评论
    Application Launch Time The following applications should launch within the specified time.
    • Browser: less than 1300ms
    • MMS/SMS: less than 700ms
    • AlarmClock: less than 650ms
    		 The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
    Simultaneous Applications When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

    9. Security Model Compatibility

    Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 42 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

    9.1.权限

    Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 42 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

    9.2. UID and Process Isolation

    Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 42 ].

    9.3. Filesystem Permissions

    Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 42 ].

    9.4. Alternate Execution Environments

    Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

    Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

    Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

    Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

    Alternate runtimes MUST abide by the Android sandbox model.具体来说：

    • Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
    • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
    • Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
    • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.

    Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

    The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

    When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource 。 If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

    10. Software Compatibility Testing

    The Android Open-Source Project includes various testing tools to verify that device implementations are compatible. Device implementations MUST pass all tests described in this section.

    However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 2.3 available from the Android Open-Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

    10.1. Compatibility Test Suite

    Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

    The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.3. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

    MUST pass the most recent version of the Android Compatibility Test Suite (CTS) available at the time of the device implementation's software is completed. (The CTS is available as part of the Android Open Source Project [ Resources, 2 ].) The CTS tests many, but not all, of the components outlined in this document.

    10.2. CTS验证器

    Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

    The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

    Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

    10.3. Reference Applications

    Device implementers MUST test implementation compatibility using the following open-source applications:

    • The "Apps for Android" applications [ Resources, 43 ].
    • Replica Island (available in Android Market; only required for device implementations that support with OpenGL ES 2.0)

    Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

    11. Updatable Software

    Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades -- that is, a device restart MAY be required.

    Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

    • Over-the-air (OTA) downloads with offline update via reboot
    • "Tethered" updates over USB from a host PC
    • "Offline" updates via a reboot and update from a file on removable storage

    The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

    If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

    12. Contact Us

    You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

    Appendix A - Bluetooth Test Procedure

    The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

    The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

    • a candidate device implementation running the software build to be tested
    • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

    The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

    设置和安装

    1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
    2. Install BluetoothChat.apk on the known-good device.
    3. Install BluetoothChat.apk on the candidate device.

    Test Bluetooth Control by Apps

    1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
    2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

    Test Pairing and Communication

    1. Launch the Bluetooth Chat app on both devices.
    2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
    3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
    4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
    5. Close the BluetoothChat app on both devices by pressing Home .
    6. Unpair each device from the other, using the device Settings app.

    Test Pairing and Communication in the Reverse Direction

    1. Launch the Bluetooth Chat app on both devices.
    2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
    3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
    4. Send 10 or messages from each device, and verify that the other device receives them correctly.
    5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

    Test Re-Launches

    1. Re-launch the Bluetooth Chat app on both devices.
    2. Send 10 or messages from each device, and verify that the other device receives them correctly.

    Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.