Android 4.3 兼容性定义

修订版 1
最后更新时间：2013 年 7 月 23 日

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

目录

一、简介
2. 资源
3、软件
4. 应用程序封装兼容性
5. 多媒体兼容性
6. 开发者工具和选项兼容性
7. 硬件兼容性
7.1.显示和图形
7.2.输入设备
7.3.传感器
7.4.数据连接
7.5。相机
7.6。内存和存储
7.7. USB
8. 性能兼容性
9. 安全模型兼容性
10.软件兼容性测试
11. 可更新的软件
12. 联系我们

一、简介

本文档列举了设备与 Android 4.3 兼容必须满足的要求。

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

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

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

如果第 10 节中描述的此定义或软件测试是沉默的、不明确的或不完整的，则设备实现者有责任确保与现有实现的兼容性。

因此，Android 开源项目 [参考资料, 3 ] 既是 Android 的参考实现，也是首选实现。强烈鼓励设备实现者最大程度地基于 Android 开源项目提供的“上游”源代码来实现其实现。虽然假设某些组件可以替换为替代实现，但强烈建议不要这样做，因为通过软件测试将变得更加困难。实现者有责任确保与标准 Android 实现完全行为兼容，包括兼容性测试套件。最后，请注意，本文档明确禁止某些组件替换和修改。

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 4.3 允许的版本字符串： http://source.android.com/docs/compatibility/4.3/versions.html
  8. 渲染脚本： http://developer.android.com/guide/topics/graphics/renderscript.html
  9. 硬件加速： http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView 类： http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5： http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5 离线功能： http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5 视频标签： http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C 地理定位 API： http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C 网络数据库 API： http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB API： http://www.w3.org/TR/IndexedDB/
  17. Dalvik 虚拟机规范：可在 Android 源代码中找到，位于 dalvik/docs
  18. 应用程序小部件： http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. 通知： http ://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. 应用程序资源： http://code.google.com/android/reference/available-resources.html
  21. 状态栏图标样式指南： http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
  22. 搜索管理器： http://developer.android.com/reference/android/app/SearchManager.html
  23. 吐司：http: //developer.android.com/reference/android/widget/Toast.html
  24. 主题：http: //developer.android.com/guide/topics/ui/themes.html
  25. R.style类： http://developer.android.com/reference/android/R.style.html
  26. 动态壁纸： https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. Android 设备管理： http://developer.android.com/guide/topics/admin/device-admin.html
  28. DevicePolicyManager参考： http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. Android 辅助功能服务 API： http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android 辅助功能 API： http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. 眼睛免费项目：http: //code.google.com/p/eyes-free
  32. 文本转语音 API： http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. 参考工具文档（针对adb、aapt、ddms、systrace）： http://developer.android.com/guide/developing/tools/index.html
  34. Android apk文件说明： http://developer.android.com/guide/topics/fundamentals.html
  35. 清单文件： http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Monkey测试工具： https://developer.android.com/studio/test/other-testing-tools/monkey
  37. Android android.content.pm.PackageManager 类和硬件功能列表： http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. 支持多屏幕： http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics： http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration： http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent： http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. 蓝牙 API： http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF 推送协议： http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X： http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X： http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1： http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2： http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511： http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411： http://www.nxp.com/documents/application_note/AN130411.pdf
  50. 相机方向API： http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. 相机： http://developer.android.com/reference/android/hardware/Camera.html
  52. Android 开放配件： http://developer.android.com/guide/topics/usb/accessory.html
  53. USB 主机 API： http://developer.android.com/guide/topics/usb/host.html
  54. Android 安全和权限参考： http://developer.android.com/guide/topics/security/security.html
  55. 适用于 Android 的应用程序：http: //code.google.com/p/apps-for-android
  56. Android 下载管理器： http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android 文件传输：http: //www.android.com/filetransfer
  58. Android 媒体格式： http://developer.android.com/guide/appendix/media-formats.html
  59. HTTP 直播协议草案： http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. NFC 连接切换： http://www.nfc-forum.org/specs/spec_list/#conn_handover
  61. 使用 NFC 进行蓝牙安全简单配对： http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
  62. Wifi 多播 API： http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
  63. 动作辅助： http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
  64. USB 充电规范： http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
  65. Android 光束： http://developer.android.com/guide/topics/nfc/nfc.html
  66. Android USB 音频： http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
  67. Android NFC 共享设置： http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
  68. Wifi 直连（Wifi P2P）： http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
  69. 锁定和主屏幕小部件： http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
  70. 用户管理器参考： http://developer.android.com/reference/android/os/UserManager.html
  71. 外部存储参考：https: //source.android.com/docs/core/storage
  72. 外部存储 API： http://developer.android.com/reference/android/os/Environment.html
  73. 短信短代码： http://en.wikipedia.org/wiki/Short_code
  74. 媒体远程控制客户端： http://developer.android.com/reference/android/media/RemoteControlClient.html
  75. 显示管理器： http://developer.android.com/reference/android/hardware/display/DisplayManager.html
  76. 梦想： http://developer.android.com/reference/android/service/dreams/DreamService.html
  77. Android 应用程序开发相关设置： http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
  78. 相机： http ://developer.android.com/reference/android/hardware/Camera.Parameters.html
  79. EGL 扩展-EGL_ANDROID_RECORDABLE： http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
  80. 运动事件 API： http://developer.android.com/reference/android/view/MotionEvent.html
  81. 触摸输入配置： http://source.android.com/docs/core/interaction/input/touch-devices.html

其中许多资源直接或间接源自 Android 4.3 SDK，并且在功能上与该 SDK 文档中的信息相同。在任何情况下，如果本兼容性定义或兼容性测试套件与 SDK 文档不一致，则 SDK 文档被视为具有权威性。上述参考文献中提供的任何技术细节均被视为包含在本兼容性定义中。

3、软件

3.1.托管 API 兼容性

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

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

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

3.2.软 API 兼容性

除了第 3.1 节中的托管 API 之外，Android 还包括一个重要的仅运行时“软”API，其形式为 Intent、权限和 Android 应用程序的类似方面，这些方面无法在应用程序编译时强制执行。

3.2.1.权限

设备实现者必须支持并强制执行权限参考页 [参考资料，5 ] 中记录的所有权限常量。请注意，第 9 节列出了与 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 4.3，此字段必须具有整数值 18。
android.os.Build.VERSION.SDK_INT当前执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 4.3，此字段必须具有整数值 18。
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.CPU_ABI本机代码的指令集名称（CPU 类型 + ABI 约定）。请参阅第 3.3 节：本机 API 兼容性。
android.os.Build.CPU_ABI2本机代码的第二指令集（CPU 类型 + ABI 约定）的名称。请参阅第 3.3 节：本机 API 兼容性。
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:4.3/JRN53/3359:userdebug/test-keys
指纹不得包含空白字符。如果上述模板中包含的其他字段具有空白字符，则必须在构建指纹中将它们替换为另一个字符，例如下划线（“_”）字符。该字段的值必须可编码为 7 位 ASCII。
android.os.Build.HARDWARE硬件的名称（来自内核命令行或/proc）。它应该是合理的人类可读的。该字段的值必须可编码为 7 位 ASCII 并匹配正则表达式"^[a-zA-Z0-9.,_-]+$" 。
android.os.Build.HOST以人类可读格式唯一标识构建构建的主机的字符串。该字段的具体格式没有要求，但不能为 null 或空字符串 ("")。
android.os.Build.ID设备实现者选择的标识符，用于引用特定版本，采用人类可读的格式。该字段可以与 android.os.Build.VERSION.INCRMENTAL 相同，但应该是一个对于最终用户区分软件版本足够有意义的值。该字段的值必须可编码为 7 位 ASCII 并匹配正则表达式"^[a-zA-Z0-9.,_-]+$" 。
android.os.Build.MANUFACTURER产品原始设备制造商 (OEM) 的商品名称。该字段的具体格式没有要求，但不能为 null 或空字符串 ("")。
android.os.Build.MODEL设备实现者选择的值，包含最终用户已知的设备名称。该名称应与设备营销和销售给最终用户时使用的名称相同。该字段的具体格式没有要求，但不能为 null 或空字符串 ("")。
android.os.Build.Product设备实施者选择的值，包含产品的开发名称或代码名称 (SKU)。必须是人类可读的，但不一定供最终用户查看。该字段的值必须可编码为 7 位 ASCII 并匹配正则表达式"^[a-zA-Z0-9.,_-]+$" 。
android.os.Build.SERIAL硬件序列号（如果有）。该字段的值必须可编码为 7 位 ASCII 并匹配正则表达式"^([a-zA-Z0-9]{0,20})$" 。
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.2 节中引用的每个 Intent 模式被第三方应用程序覆盖。上游 Android 开源实现默认允许这样做；设备实现者不得为系统应用程序使用这些 Intent 模式附加特殊权限，或阻止第三方应用程序绑定到这些模式并承担对这些模式的控制。该禁止具体包括但不限于禁用“选择器”用户界面，该界面允许用户在全部处理相同 Intent 模式的多个应用程序之间进行选择。

但是，如果默认活动为数据 URI 提供更具体的过滤器，则设备实现可以为特定 URI 模式（例如 http://play.google.com）提供默认活动。例如，指定数据 URI“http://www.android.com”的 Intent 过滤器比“http://”的浏览器过滤器更具体。设备实现必须为用户提供一个用户界面来修改意图的默认活动。

3.2.3.3.意图命名空间

设备实现不得包含任何使用 Android.* 或 com.android.* 命名空间中的 ACTION、CATEGORY 或其他键字符串来支持任何新 Intent 或广播 Intent 模式的 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 兼容性

3.3.1 应用程序二进制接口

Dalvik 中运行的托管代码可以调用应用程序 .apk 文件中提供的本机代码，作为针对适当设备硬件架构编译的 ELF .so 文件。由于本机代码高度依赖于底层处理器技术，因此 Android 在 Android NDK 中的文件docs/CPU-ARCH-ABIS.html中定义了许多应用程序二进制接口 (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）
  • libGLESv3.so（OpenGL ES 3.0）
  • libEGL.so（原生 OpenGL 表面管理）
  • libjnigraphics.so
  • libOpenSLES.so（OpenSL ES 1.0.1 音频支持）
  • libOpenMAXAL.so（OpenMAX AL 1.0.1 支持）
  • libandroid.so（原生 Android 活动支持）
  • 支持 OpenGL，如下所述

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

请注意，设备实现必须包含 libGLESv3.so，并且它必须符号链接（符号）链接到 libGLESv2.so。在声明支持 OpenGL ES 3.0 的设备实现上，除了 OpenGL ES 2.0 函数符号之外，libGLESv2.so 还必须导出 OpenGL ES 3.0 函数符号。

本机代码兼容性具有挑战性。因此，应该重申的是，强烈鼓励设备实现者使用上面列出的库的上游实现来帮助确保兼容性。

3.4.网络兼容性

3.4.1.网页视图兼容性

Android 开源实现使用 WebKit 渲染引擎来实现android.webkit.WebView [参考资料，10 ]。由于为 Web 渲染系统开发全面的测试套件是不可行的，因此设备实现者必须在 WebView 实现中使用 WebKit 的特定上游版本。具体来说：

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

WebView 组件应该尽可能多地支持 HTML5 [参考资料，11 ]。至少，设备实现必须支持与 WebView 中的 HTML5 关联的每个 API：

此外，设备实现必须支持 HTML5/W3C webstorage API [参考资料，15 ]，并且应该支持 HTML5/W3C IndexedDB API [参考资料，16 ]。请注意，随着 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 [参考资料，11 ]。设备实现至少必须支持与 HTML5 相关的每个 API：

此外，设备实现必须支持 HTML5/W3C webstorage API [参考资料，15 ]，并且应该支持 HTML5/W3C IndexedDB API [参考资料，16 ]。请注意，随着 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 虚拟机语义 [参考资料, 17 ]。

设备实现必须配置 Dalvik 以根据上游 Android 平台分配内存，并如下表所示。 （有关屏幕尺寸和屏幕密度定义，请参阅第 7.1.1 节。）

请注意，下面指定的内存值被视为最小值，设备实现可以为每个应用程序分配更多内存。

屏幕尺寸屏幕密度应用内存
小/普通/大LDPI/MDPI 16MB
小/普通/大电视分辨率 / 高清分辨率32MB
小/普通/大高清像素64MB
超大平均密度指数32MB
超大电视分辨率 / 高清分辨率64MB
超大高清像素128MB

3.8.用户界面兼容性

3.8.1.启动器（主屏幕）

Android 4.3 包括启动器应用程序（主屏幕）并支持第三方应用程序来替换设备启动器（主屏幕）。允许第三方应用程序替换设备主屏幕的设备实现必须声明平台功能android.software.home_screen 。

3.8.2.小部件

Android 定义了组件类型以及相应的 API 和生命周期，允许应用程序向最终用户公开“AppWidget”[参考资料，18 ]。支持在主屏幕上嵌入小部件的设备实现必须满足以下要求并声明对平台功能android.software.app_widgets的支持。

  • 设备启动器必须包含对 AppWidget 的内置支持，并公开用户界面功能以直接在启动器中添加、配置、查看和删除 AppWidget。
  • 设备实现必须能够渲染标准网格大小为 4 x 4 的小部件。 （有关详细信息，请参阅 Android SDK 文档 [参考资料，18 ] 中的应用程序小部件设计指南。
  • 包括对锁定屏幕的支持的设备实现必须支持锁定屏幕上的应用程序小部件。

3.8.3.通知

Android 包含的 API 允许开发人员使用设备的硬件和软件功能来通知用户值得注意的事件 [参考资料，19 ]。

某些 API 允许应用程序使用硬件（特别是声音、振动和灯光）执行通知或吸引注意。设备实现必须支持使用硬件功能的通知，如 SDK 文档中所述，并尽可能支持设备实现硬件。例如，如果设备实现包含振动器，则它必须正确实现振动 API。如果设备实现缺少硬件，则相应的 API 必须实现为无操作。请注意，第 7 节对此行为进行了进一步详细说明。

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

Android 4.3 支持丰富的通知，例如持续通知的交互式视图。设备实现必须正确显示和执行丰富的通知，如 Android API 中所述。

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

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

3.8.5。吐司

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

3.8.6。主题

Android 提供“主题”作为应用程序在整个 Activity 或应用程序中应用样式的机制。 Android 4.3 包含“Holo”或“全息”主题作为一组定义的样式，供应用程序开发人员在想要匹配 Android SDK 定义的 Holo 主题外观和感觉时使用[参考资料，24 ]。设备实现不得更改向应用程序公开的任何 Holo 主题属性 [参考资料，25 ]。

Android 4.3 包含一个新的“设备默认”主题，作为一组定义的样式，供应用程序开发人员在想要匹配设备实现者定义的设备主题的外观和风格时使用。设备实现可以修改向应用程序公开的 DeviceDefault 主题属性 [参考资料，25 ]。

3.8.7.动态壁纸

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

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

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

3.8.8.最近的应用程序显示

上游 Android 4.3 源代码包括一个用户界面，用于使用用户上次离开应用程序时应用程序图形状态的缩略图来显示最近的应用程序。设备实现可能会改变或消除此用户界面；然而，Android 的未来版本计划更广泛地使用此功能。强烈鼓励设备实现对最近的应用程序使用上游 Android 4.3 用户界面（或类似的基于缩略图的界面），否则它们可能与未来版本的 Android 不兼容。

3.8.9。输入管理

Android 4.3 包括对输入管理的支持以及对第三方输入法编辑器的支持。允许用户在设备上使用第三方输入法的设备实现必须声明平台功能android.software.input_methods并支持 Android SDK 文档中定义的 IME API。

声明android.software.input_methods功能的设备实现必须提供用户可访问的机制来添加和配置第三方输入法。设备实现必须显示设置界面以响应android.settings.INPUT_METHOD_SETTINGS意图。

3.8.10.锁屏媒体遥控器

Android 4.3 包含对远程控制 API 的支持，该 API 允许媒体应用程序与显示在远程视图（如设备锁定屏幕）中的播放控件集成[参考资料，74 ]。支持设备锁定屏幕并允许用户在主屏幕上添加小部件的设备实现必须支持在设备锁定屏幕中嵌入远程控制[参考资料，69 ]。

3.8.11.梦

Android 4.3 支持名为 Dreams 的交互式屏幕保护程序 [参考资料，76 ]。 Dreams 允许用户在充电设备空闲或插入桌面底座时与应用程序交互。设备实现必须包括对 Dreams 的支持，并为用户提供配置 Dreams 的设置选项。

3.9 设备管理

Android 4.3 包含允许安全感知应用程序在系统级别执行设备管理功能的功能，例如通过 Android 设备管理 API 实施密码策略或执行远程擦除 [参考资料，27 ]。设备实现必须提供DevicePolicyManager类的实现 [参考资料，28 ]。包含锁屏支持的设备实现必须支持 Android SDK 文档 [参考资料，27 ] 中定义的全部设备管理策略。

3.10 辅助功能

Android 4.3 提供了一个辅助功能层，可帮助残障用户更轻松地导航其设备。此外，Android 4.3 提供平台 API，使辅助功能服务实现能够接收用户和系统事件的回调并生成备用反馈机制，例如文本转语音、触觉反馈和轨迹球/方向键导航 [资源，29 ] 。设备实现必须提供与默认 Android 实现一致的 Android 辅助功能框架的实现。具体来说，设备实现必须满足以下要求。

  • 设备实现必须通过android.accessibilityservice API 支持第三方辅助功能服务实现 [参考资料，30 ]。
  • 设备实现必须生成AccessibilityEvents并以与默认 Android 实现一致的方式将这些事件传递给所有已注册的AccessibilityService实现。
  • 设备实现必须提供用户可访问的机制来启用和禁用辅助服务，并且必须显示此界面以响应android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS意图。

此外，设备实现应该在设备上提供辅助服务的实现，并且应该为用户提供一种在设备设置期间启用辅助服务的机制。 Eyes Free 项目提供了无障碍服务的开源实现 [参考资料，31 ]。

3.11 文字转语音

Android 4.3 包含的 API 允许应用程序使用文本转语音 (TTS) 服务，并允许服务提供商提供 TTS 服务的实现 [参考资料，32 ]。设备实现必须满足与 Android TTS 框架相关的以下要求：

  • 设备实现必须支持 Android TTS 框架 API，并且应该包括支持设备上可用语言的 TTS 引擎。请注意，上游 Android 开源软件包含功能齐全的 TTS 引擎实现。
  • 设备实现必须支持安装第三方 TTS 引擎。
  • 设备实现必须提供用户可访问的界面，允许用户选择在系统级别使用的 TTS 引擎。

4. 应用程序封装兼容性

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

设备实现不得扩展 .apk [ Resources, 34 ]、Android Manifest [ Resources, 35 ]、Dalvik 字节码 [ Resources, 17 ] 或 renderscript 字节码格式，以免阻止这些文件在设备上正确安装和运行。其他兼容设备。设备实现者应该使用 Dalvik 的参考上游实现以及参考实现的包管理系统。

5. 多媒体兼容性

设备实现必须包含至少一种形式的音频输出，例如扬声器、耳机插孔、外部扬声器连接等。

5.1.媒体编解码器

设备实现必须支持 Android SDK 文档 [参考资料，58 ] 中指定的核心媒体格式，除非本文档明确允许。具体来说，设备实现必须支持下表中定义的媒体格式、编码器、解码器、文件类型和容器格式。所有这些编解码器均作为 Android 开源项目的首选 Android 实现中的软件实现提供。

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

请注意，这些表并未列出大多数视频编解码器的具体比特率要求，因为当前设备硬件不一定支持与相关标准指定的所需比特率精确映射的比特率。相反，设备实现应该支持硬件上实际的最高比特率，最高可达规范定义的限制。

类型格式/编解码器编码器解码器细节文件类型/容器格式
声音的MPEG-4 AAC 配置文件 (AAC LC)对于包含麦克风硬件并定义android.hardware.microphone设备实现是必需的。必需的支持单声道/立体声/5.0/5.1* 内容，标准采样率为 8 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4（.mp4、.m4a）
  • ADTS 原始 AAC（.aac，在 Android 3.1+ 中解码，在 Android 4.0+ 中编码，不支持 ADIF）
  • MPEG-TS（.ts，不可搜索，Android 3.0+）
MPEG-4 HE AAC 配置文件 (AAC+)对于包含麦克风硬件并定义 android.hardware.microphone 的设备实现是必需的必需的支持单声道/立体声/5.0/5.1* 内容，标准采样率为 16 至 48 kHz。
MPEG-4 HE AAC v2 配置文件（增强型 AAC+）必需的支持单声道/立体声/5.0/5.1* 内容，标准采样率为 16 至 48 kHz。
MPEG-4 音频对象类型 ER AAC ELD（增强型低延迟 AAC）对于包含麦克风硬件并定义 android.hardware.microphone 的设备实现是必需的必需的支持单声道/立体声内容，标准采样率为 16 至 48 kHz。
AMR-NB对于包含麦克风硬件并定义android.hardware.microphone设备实现是必需的。必需的8kHz 时采样率为 4.75 至 12.2 kbps 3GPP (.3gp)
AMR-WB对于包含麦克风硬件并定义android.hardware.microphone设备实现是必需的。必需的9 个速率，从 6.60 kbit/s 到 23.85 kbit/s，采样频率为 16kHz 3GPP (.3gp)
FLAC必需的
（安卓3.1+）		单声道/立体声（无多声道）。采样率高达 48 kHz（但在具有 44.1 kHz 输出的设备上建议高达 44.1 kHz，因为 48 至 44.1 kHz 下采样器不包含低通滤波器）。推荐16位； 24 位没有应用抖动。仅限 FLAC (.flac)
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)
  • 玛特罗斯卡 (.mkv)
PCM/波必需的必需的8 位和 16 位线性 PCM**（速率达到硬件限制）。设备必须支持 8000、16000 和 44100 Hz 频率下原始 PCM 录制的采样率波形 (.wav)
图像JPEG必需的必需的基础+渐进JPEG (.jpg)
动图必需的GIF (.gif)
巴布亚新几内亚必需的必需的PNG (.png)
骨形态发生蛋白必需的位图 (.bmp)
WEBP必需的必需的WebP (.webp)
视频H.263对于包含相机硬件并定义android.hardware.camera或android.hardware.camera.front设备实现是必需的。必需的
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264AVC对于包含相机硬件并定义android.hardware.camera或android.hardware.camera.front设备实现是必需的。必需的基线概况 (BP)
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-TS（.ts，仅限 AAC 音频，不可搜索，Android 3.0+）
MPEG-4 SP必需的3GPP (.3gp)
VP8必需的
（安卓4.3+）		必需的
(安卓2.3.3+)		 WebM (.webm) 和 Matroska (.mkv，Android 4.0+)***
  • *注：仅需要缩混 5.0/5.1 内容；录制或渲染 2 个以上通道是可选的。
  • **注意：16 位线性 PCM 捕获是强制性的。 8 位线性 PCM 捕获不是强制性的。
  • ***注意：设备实现应该支持写入 Matroska WebM 文件。

5.2 视频编码

包含后置摄像头并声明android.hardware.camera的 Android 设备实现应该支持以下 H.264 视频编码配置文件。

标清（低质量）标清（高品质）高清（硬件支持时）
视频分辨率176 x 144 像素480 x 360 像素1280 x 720 像素
视频帧率12 帧/秒30 帧/秒30 帧/秒
视频比特率56Kbps 500 Kbps 或更高2 Mbps 或更高
音频编解码器AAC-LC AAC-LC AAC-LC
音频通道1（单声道） 2（立体声） 2（立体声）
音频比特率24Kbps 128Kbps 192Kbps

包含后置摄像头并声明android.hardware.camera Android 设备实现应该支持以下 VP8 视频编码配置文件

标清（低质量）标清（高品质）高清720p
（当硬件支持时）		高清1080p
（当硬件支持时）
视频分辨率320 x 180 像素640 x 360 像素1280 x 720 像素1920 x 1080 像素
视频帧率30 帧/秒30 帧/秒30 帧/秒30 帧/秒
视频比特率800Kbps 2Mbps 4Mbps 10Mbps

5.3 视频解码

Android 设备实现应支持以下 VP8 和 H.264 视频解码配置文件。

标清（低质量）标清（高品质）高清720p
（当硬件支持时）		高清1080p
（当硬件支持时）
视频分辨率320 x 180 像素640 x 360 像素1280 x 720 像素1920 x 1080 像素
视频帧率30 帧/秒30 帧/秒30 帧/秒30 帧/秒
视频比特率800Kbps 2Mbps 8Mbps 20Mbps

5.4.声音录制

当应用程序使用android.media.AudioRecord API 开始录制音频流时，包含麦克风硬件并声明android.hardware.microphone设备实现必须使用以下每种行为采样和录制音频：

  • 该器件应表现出近似平坦的幅度与频率特性；具体来说，±3 dB，从 100 Hz 到 4000 Hz
  • 音频输入灵敏度应设置为 1000 Hz 时 90 dB 声功率级 (SPL) 源对于 16 位样本产生 2500 的 RMS。
  • PCM 幅度电平应在麦克风处的 90 dB SPL 或 -18 dB 至 +12 dB 的至少 30 dB 范围内线性跟踪输入 SPL 变化。
  • 对于 1Khz、90 dB SPL 输入电平，总谐波失真应小于 1%。

除了上述录制规范之外，当应用程序开始使用android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION音频源录制音频流时：

  • 降噪处理（如果存在）必须禁用。
  • 自动增益控制（如果存在）必须禁用。

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

5.5.音频延迟

音频延迟是音频信号通过系统时的时间延迟。许多类别的应用程序依靠短延迟来实现实时声音效果。

就本节而言：

  • “输出延迟”定义为应用程序写入 PCM 编码数据帧与外部收听者听到或传感器观察到相应声音之间的时间间隔
  • “冷输出延迟”定义为第一帧的输出延迟，此时音频输出系统在请求之前已空闲并断电
  • “连续输出延迟”定义为设备已经播放音频后后续帧的输出延迟
  • “输入延迟”是向设备呈现外部声音与应用程序读取相应的 PCM 编码数据帧之间的时间间隔
  • “冷输入延迟”定义为当音频输入系统在请求之前处于空闲状态并断电时，丢失的输入时间与第一帧的输入延迟之和
  • “连续输入延迟”定义为设备已经在捕获音频时后续帧的输入延迟
  • “OpenSL ES PCM 缓冲队列 API”是 Android NDK 中与 PCM 相关的 OpenSL ES API 集合；请参阅NDK_root /docs/opensles/index.html

根据第 5 节，所有兼容设备实现必须包含至少一种形式的音频输出。设备实现应该满足或超过这些输出延迟要求：

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

如果在使用 OpenSL ES PCM 缓冲队列 API 时，设备实现在任何初始校准后满足本节的要求，对于至少一个支持的音频输出设备上的连续输出延迟和冷输出延迟，它可以报告对低延迟音频的支持，通过android.content.pm.PackageManager类报告功能“android.hardware.audio.low-latency”。 [资源，37 ] 相反，如果设备实现不满足这些要求，则它不得报告对低延迟音频的支持。

根据第 7.2.5 节，设备实现可以省略麦克风硬件。

包含麦克风硬件并声明android.hardware.microphone设备实现应满足以下输入音频延迟要求：

  • 冷输入延迟为 100 毫秒或更短
  • 50 毫秒或更短的连续输入延迟

5.6.网络协议

设备必须支持 Android SDK 文档 [参考资料，58 ] 中指定的用于音频和视频播放的媒体网络协议。具体来说，设备必须支持以下媒体网络协议：

  • RTSP（RTP、SDP）
  • HTTP(S) 渐进式流式传输
  • HTTP(S) 实时流媒体草案协议，版本 3 [资源，59 ]

6. 开发者工具和选项兼容性

6.1 开发者工具

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

  • Android 调试桥（称为 adb） [资源，33 ]
    设备实现必须支持 Android SDK 中记录的所有adb函数。默认情况下，设备端adb守护进程必须处于非活动状态，并且必须有用户可访问的机制来打开 Android 调试桥。
  • Android 4.3 包含对安全 adb 的支持。安全 adb 在已知的经过身份验证的主机上启用 adb。设备实现必须支持安全 adb。
  • Dalvik 调试监视器服务（称为 ddms） [资源，33 ]
    设备实现必须支持 Android SDK 中记录的所有ddms功能。由于ddms使用adb ，因此默认情况下对ddms的支持应该处于非活动状态，但每当用户激活 Android 调试桥时就必须支持，如上所述。
  • 猴子[资源，36 ]
    设备实现必须包含 Monkey 框架，并使其可供应用程序使用。
  • SysTrace [资源，33 ]
    设备实现必须支持 Android SDK 中记录的 systrace 工具。 Systrace 默认情况下必须处于非活动状态，并且必须有用户可访问的机制来打开 Systrace。

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

6.2 开发者选项

Android 4.3 支持开发人员配置应用程序开发相关设置。设备实现必须尊重android.settings.application_development_settings意图显示与应用程序开发相关的设置[资源，77 ]。默认情况下，上游Android实现将“开发者选项”菜单隐藏起来，并使用户在设置>“关于设备”>“构建号码”菜单项上按7（7）次之后启动开发人员选项。设备实现必须为开发人员选项提供一致的体验。具体而言，设备实现必须默认使用开发人员选项，并且必须提供一种机制来启用与上游Android实现一致的开发人员选项。

7. 硬件兼容性

如果设备包含具有针对第三方开发人员相应的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)方法准确地报告准确的硬件配置信息。 [资源，37 ]

7.1.显示和图形

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

本节中要求所引用的单位定义如下：

  • “物理对角线大小”是显示器点亮部分的两个相对角的距离。
  • “ DPI”（含义为“每英寸点”）是由1英寸的线性水平或垂直跨度包含的像素的数量。列出了DPI值，水平和垂直DPI都必须在该范围内。
  • “纵横比”是屏幕较长维与较短维度的比率。例如，480x854像素的显示为854 /480 = 1.779，或大致为“ 16：9”。
  • “密度无关的像素”或（“ DP”）是标准化为160 DPI屏幕的虚拟像素单元，计算为： pixels = dps * (density / 160) 。

7.1.1.屏幕配置

屏幕尺寸

Android UI框架支持各种不同的屏幕尺寸，并允许应用程序通过android.content.res.Configuration.screenLayout与SCREENLAYOUT_SIZE_MASK查询设备屏幕大小（aka“屏幕布局”）。设备实现必须报告Android SDK文档[资源，38 ]中定义的正确屏幕大小，并由上游Android平台确定。具体而言，设备实现必须根据以下逻辑密度独立的像素（DP）屏幕尺寸报告正确的屏幕尺寸。

  • 设备必须具有至少426 dp x 320 dp（'small'）的屏幕尺寸
  • 报告屏幕尺寸“正常”的设备必须具有至少480 dp x 320 dp的屏幕尺寸
  • 报告屏幕尺寸“大”的设备必须具有至少640 dp x 480 dp的屏幕尺寸
  • 报告屏幕尺寸“ Xlarge”的设备必须具有至少960 dp x 720 dp的屏幕尺寸

此外，设备必须具有至少2.5英寸的物理对角线尺寸。

设备不得随时更改其报告的屏幕尺寸。

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

屏幕纵横比

长宽比必须在1.3333（4：3）和1.85（16：9）之间。

屏幕密度

Android UI框架定义了一组标准逻辑密度，以帮助应用程序开发人员针对应用程序资源。设备实现必须通过android.util.DisplayMetrics API报告以下逻辑Android框架密度之一，并且必须以此标准密度执行应用程序。

  • 120 DPI，称为“ ldpi”
  • 160 DPI，称为“ MDPI”
  • 213 DPI，称为“ TVDPI”
  • 240 DPI，称为“ HDPI”
  • 320 DPI，称为“ XHDPI”
  • 480 DPI，称为“ xxhdpi”
  • 640 DPI，称为“ xxxhdpi'
设备实现应定义标准的Android框架密度，该密度在数值上最接近屏幕的物理密度，除非该逻辑密度将报告的屏幕尺寸推高以下所支持的最小值。如果在数值上最接近物理密度的标准Android框架密度会导致屏幕尺寸小于最小的兼容屏幕尺寸（320 dp宽度），则设备实现应报告下一个最低的标准Android框架密度。

7.1.2.显示指标

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

7.1.3.屏幕方向

设备必须通过应用程序来支持人像或景观屏幕方向的动态方向。也就是说，设备必须尊重应用程序对特定屏幕方向的请求。设备实现可以选择纵向或横向作为默认方向。

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

更改方向时，设备不得更改报告的屏幕尺寸或密度。

设备必须报告他们支持的屏幕方向（ android.hardware.screen.portrait和/或android.hardware.screen.landscape ），并且必须至少报告一个支持的方向。例如，具有固定取向景观屏幕（例如电视或笔记本电脑）的设备只能报告android.hardware.screen.landscape 。

7.1.4. 2D和3D图形加速度

设备实现必须支持OpenGL ES 1.0和2.0，如Android SDK文档中所体现和详细介绍。设备实现应支持能够支持OpenGL ES 3.0的设备上的OpenGL ES 3.0。设备实现还必须支持Android SDK文档[资源，8 ]中详细介绍的Android Renderscript。

设备实现还必须正确识别自己为支持OpenGL ES 1.0，OpenGL ES 2.0或OpenGL ES 3.0。那是：

  • 托管API（例如通过GLES10.getString()方法）必须报告对OpenGL ES 1.0和OpenGL ES 2.0的支持
  • 本机C/C ++ OpenGL API（即通过Libgles_v1cm.so，Libgles_v2.so或Libegl.so提供的应用程序可用于应用程序的API）必须报告对OpenGL ES 1.0和OpenGL ES 2.0的支持。
  • 声明对OpenGL ES 3.0支持的设备实现必须支持OpenGL ES 3.0托管API，并包括对本机C/C ++ API的支持。在声明对OpenGL ES 3.0支持的设备实现时，LibGlesV2.因此，除了OpenGL ES 2.0函数符号外，必须导出OpenGL ES 3.0功能符号。

设备实现可以实现任何所需的OpenGL ES扩展。但是，设备实现必须通过OpenGL ES托管和本机API报告它们所支持的所有扩展字符串，相反，不得报告不支持的扩展字符串。

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

Android 4.3包括一个机制，用于声明他们希望通过使用明显的标签android:hardwareAccelerated或Direct API调用来启用2D图形的硬件加速度[ Resources，9 ]。

在Android 4.3中，设备实现必须默认启用硬件加速度，并且如果开发人员通过设置android:hardwareAccelerated="false"或直接通过Android View API来禁用硬件加速度，则必须禁用硬件加速度。

此外，设备实现必须表现出与硬件加速器的Android SDK文档一致的行为[ Resources，9 ]。

Android 4.3包括一个TextureView对象，该对象使开发人员可以直接将硬件加速的OpenGL ES纹理整合为UI层次结构中的渲染目标。设备实现必须支持TextureView API，并且必须通过上游Android实现表现出一致的行为。

Android 4.3包括对EGL_ANDROID_RECORDABLE的支持，EGLCONFIG属性指示EGLCONFIG是否支持渲染到将图像记录为视频的AnativeWindow。设备实现必须支持EGL_ANDROID_RECORDABLE扩展名[资源，79 ]。

7.1.5。旧应用兼容模式

Android 4.3指定了一种“兼容模式”，其中该框架以“正常”屏幕尺寸等效（320dp宽度）模式运行，以获取未针对旧版本的Android开发的旧版本，该应用程序是旧版本的，该应用程序是更早的屏幕大小独立性的。设备实现必须包括对上游Android开源代码实现的传统应用程序兼容模式的支持。也就是说，设备实现不得更改激活兼容模式的触发器或阈值，并且不得改变兼容模式本身的行为。

7.1.6。屏幕类型

设备实现屏幕被归类为两种类型之一：

  • 固定像素显示实现：屏幕是一个仅支持单个像素宽度和高度的单个面板。通常，屏幕与设备物理集成。示例包括手机，平板电脑等。
  • 可变像素显示实现：设备实现要么没有嵌入式屏幕，还包括一个视频输出端口，例如VGA，HDMI或用于显示的无线端口，或者具有可以更改像素尺寸的嵌入式屏幕。示例包括电视，机顶盒等。

固定像素设备实现

固定像素设备实现可以使用任何像素维度的屏幕，只要它们符合定义此兼容性定义的要求。

固定像素实现可能包括一个视频输出端口，用于外部显示。但是，如果该显示用于运行应用程序，则该设备必须满足以下要求：

  • 该设备必须报告相同的屏幕配置和显示指标，如固定像素显示器所述，如第7.1.1和7.1.2节所述。
  • 该设备必须报告与固定像素显示器相同的逻辑密度。
  • 该设备必须报告与固定像素显示器相同或非常接近的屏幕尺寸。

例如，具有10英寸对角线尺寸的平板电脑具有1024x600像素分辨率被认为是固定像素大型MDPI显示实现。如果它包含一个在720p或1080p下显示的视频输出端口，则设备实现必须扩展输出，以使输出缩放应用程序仅在大型MDPI窗口中执行，无论固定像素显示还是视频输出端口正在使用。

可变像素设备实现

可变像素设备实现必须支持1280x720或1920x1080中的一个或两个（即720p或1080p）。带有可变像素显示器的设备实现不得支持任何其他屏幕配置或模式。带有可变像素屏幕的设备实现可能会在运行时或启动时间更改屏幕配置或模式。例如，机顶盒的用户可以用1080p显示器替换720p显示屏，并且设备实现可以进行相应调整。

此外，可变像素设备实现必须报告这些像素尺寸的以下配置桶：

  • 1280x720（也称为720p）：“大屏幕尺寸”，“ tvdpi”（213 dpi）密度
  • 1920x1080（也称为1080p）：“大屏幕尺寸”，“ xhdpi”（320 dpi）密度

为了清楚起见，具有可变像素尺寸的设备实现仅限于Android 4.3中的720p或1080p，并且必须配置以报告上面指出的屏幕尺寸和密度桶。

7.1.7。屏幕技术

Android平台包含允许应用程序将丰富图形呈现为显示的API。除非本文档中明确允许，否则设备必须支持Android SDK定义的所有这些API。具体来说：

  • 设备必须支持能够渲染16位颜色图形的显示器，并应支持能够具有24位颜色图形的显示。
  • 设备必须支持能够渲染动画的显示器。
  • 所使用的显示技术必须具有0.9至1.1之间的像素纵横比（PAR）。也就是说，像素纵横比必须在正方形（1.0）附近，其公差为10％。

7.1.8。外部显示

Android 4.3包括对辅助显示的支持，以启用媒体共享功能和开发人员API，以访问外部显示。如果设备通过有线，无线或嵌入式附加显示连接来支持外部显示，则设备实现必须如Android SDK文档[ Resources，75 ]中所述实现显示管理器API。支持安全视频输出并能够支持安全表面的设备实现必须声明对Display.FLAG_SECURE的支持。具体而言，要声明对Display的支持的设备实现Display.FLAG_SECURE ，对于Miracast Wireless Displays或HDCP 1.2或更高的有线显示器，必须支持HDCP 2.x或更高的HDCP 2.x或更高。上游Android开源实现包括对满足此要求的无线（Miracast）和有线（HDMI）显示的支持。

7.2.输入设备

7.2.1.键盘

设备实现：

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

7.2.2.非触摸式导航

设备实现：

  • 可能会省略非接触式导航选项（即可能省略轨迹球，D-pad或车轮）
  • 必须报告android.content.res.Configuration.navigation的正确值[ Resources，40 ]
  • 必须提供合理的替代用户界面机制，以选择和编辑文本，与输入管理引擎兼容。上游Android开源实现包括一种选择机制，适用于缺少非接触导航输入的设备。

7.2.3.导航键

房屋，菜单和背部功能对于Android导航范式至关重要。设备实现必须使这些功能在运行应用程序时始终为用户提供。这些功能可以通过专用的物理按钮（例如机械或电容触摸按钮）实现，也可以使用专用的软件键，手势，触摸面板等实现。Android4.3支持这两个实现。

Android 4.3包括对辅助行动的支持[资源，63 ]。设备实现必须使用户在运行应用程序时始终为用户提供辅助操作。可以通过硬件或软件键实现此功能。

设备实现可以使用屏幕的不同部分显示导航密钥，但是如果是，则必须满足以下要求：

  • 设备实施导航键必须使用屏幕的不同部分，无法使用应用程序，并且不得掩盖或以其他方式干扰应用程序可用的屏幕部分。
  • 设备实现必须使显示的一部分可用于满足第7.1.1节中定义的要求的应用程序。
  • 当应用程序未指定系统UI模式或指定SYSTEM_UI_FLAG_VISIBLE时，设备实现必须显示导航密钥。
  • 设备实现必须在应用程序指定SYSTEM_UI_FLAG_LOW_PROFILE时，将导航密钥显示在不引人注目的“低调”（例如DIM）模式中。
  • 当应用程序指定SYSTEM_UI_FLAG_HIDE_NAVIGATION时，设备实现必须隐藏导航密钥。
  • 当TargetsDkversion <= 10时，设备实现必须给应用程序键键，并且当TargetsDkversion> 10时不应显示菜单密钥。

7.2.4.触摸屏输入

设备实现应具有某种形式的指针输入系统（鼠标状或触摸）。但是，如果设备实现不支持指针输入系统，则不得报告android.hardware.touchscreen或android.hardware.faketouch特征常数。确实包括指针输入系统的设备实现：

  • 如果设备输入系统支持多个指针，则应支持完全独立跟踪的指针
  • 必须报告android.content.res.Configuration.touchscreen [ Resources，40 ]与设备上特定触摸屏的类型相对应的值

Android 4.3包括对各种触摸屏，触摸板和假触摸输入设备的支持。基于触摸屏的设备实现与显示[ Resources，81 ]相关联，因此用户的印象是直接在屏幕上操纵项目。由于用户直接接触屏幕，因此系统不需要任何其他负担来指示被操纵的对象。相比之下，假触摸接口提供了一个近似触摸屏功能子集的用户输入系统。例如，驱动屏幕光标的鼠标或遥控器近似触摸，但要求用户首先或聚焦，然后单击。许多输入设备，例如鼠标，触控板，基于陀螺仪的空气鼠标，陀螺仪，操纵杆和多触摸触控板，都可以支持假触摸互动。 Android 4.0包括功能常数android.hardware.faketouch ，对应于高保真性非接触式（即基于指针的）输入设备，例如鼠标或触控板，可以充分模拟基于触摸的输入（包括基本手势（包括基本的手势）支持），并指示该设备支持触摸屏功能的模拟子集。声明假触摸功能的设备实现必须满足7.2.5节中的假触摸要求。

设备实现必须报告与所使用的输入类型相对应的正确功能。包括触摸屏（单触摸或更高）的设备实现必须报告平台功能Consant android.hardware.touchscreen 。报告该平台功能Constant android.hardware.touchscreen设备实现还必须报告平台功能Constant android.hardware.faketouch 。不包含触摸屏（并且仅依赖指针设备）的设备实现不得报告任何触摸屏功能，并且仅在第7.2.5节中符合假触摸要求，则必须仅报告android.hardware.faketouch 。

7.2.5。假触摸输入

声明支持android.hardware.faketouch的设备实现

  • 必须报告指针位置的绝对X和Y屏幕位置，并在屏幕上显示视觉指针[资源，80 ]
  • 必须用动作代码报告触摸事件[资源，80 ]，该事件指定了屏幕上的指针上或up down状态更改[资源，80 ]
  • 必须在屏幕上的对象up支持down ，该指针允许用户在屏幕上的对象上效仿对象
  • 必须在一个时间阈值之内在屏幕上的对象上的对象上的同一位置down down支撑指针，指针up ，然后up指针，然后在屏幕上的对象上double Take [ Resources，80 ]
  • 必须在屏幕上的任意点down支持指针，指针移动到屏幕上的任何其他任意点，然后up指针，这使用户可以模仿触摸阻力
  • 必须down支持指针，然后允许用户快速将对象移至屏幕上的其他位置，然后在屏幕上up指针，这使用户可以在屏幕上播放对象

声明支持android.hardware.faketouch.multitouch.distinct的设备必须满足上述Faketouch的要求，并且还必须支持对两个或更多独立的指针输入的独特跟踪。

7.2.6。麦克风

设备实现可能会省略麦克风。但是，如果设备实现省略了麦克风，则不得报告android.hardware.microphone功能常数，并且必须根据第7节将音频记录API实现为NO-OPS。相反，确实具有麦克风的设备实现：

  • 必须报告android.hardware.microphone特征常数
  • 应满足第5.4节中的音频质量要求
  • 应满足第5.5节中的音频延迟要求

7.3.传感器

Android 4.3包括用于访问各种传感器类型的API。设备实现通常可能会省略以下小节中规定的这些传感器。如果设备包含具有针对第三方开发人员的相应API的特定传感器类型，则设备实现必须如Android SDK文档中所述实现该API。例如，设备实现：

  • 必须按android.content.pm.PackageManager类准确地报告传感器的存在或不存在。 [资源，37 ]
  • 必须通过SensorManager.getSensorList()和类似的方法返回准确的受支持传感器的列表
  • 必须对所有其他传感器API进行合理的行为（例如，当应用程序试图注册听众时，在适当的情况下返回True或False，而在不存在相应的传感器时不要呼叫传感器侦听器；等）
  • 必须使用Android SDK文档中定义的每个传感器类型的相关国际单位系统（IE度量）值报告所有传感器测量值[ ISSOUTION，41 ]

上面的列表不全面； Android SDK的记录行为应被视为权威。

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

Android 4.3包括一个“流”传感器的概念，该概念是连续返回数据的概念，而不是仅在数据更改时。设备实现必须连续提供Android 4.3 SDK文档指示的任何API的周期性数据样本，以作为流传感器。请注意，设备实现必须确保传感器流不得阻止设备CPU进入悬浮状态​​或从悬挂状态醒来。

7.3.1.加速度计

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

  • 应该能够以120 Hz或更高的速度提供活动。请注意，尽管上面的加速度计频率为“应该”为Android 4.3，但计划将未来版本的兼容性定义更改为“必须”。也就是说，这些标准在Android 4.3中是可选的，但将来需要在以后的版本中。非常强烈鼓励运行Android 4.3的现有和新设备在Android 4.3中满足这些要求，以便他们能够升级到将来的平台发行版
  • 必须遵守Android API中详细介绍的Android传感器坐标系（请参阅[资源，41 ]）
  • 必须能够在任何三维矢量上从自由降临到两次重力（2g）或更多的重力测量
  • 必须具有8位准确性或更多
  • 必须具有不超过0.05 m/s^2的标准偏差

7.3.2.磁力计

设备实现应包括3轴磁力计（即指南针）。

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

7.3.3.全球定位系统

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

7.3.4.陀螺仪

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

  • 必须补偿温度
  • 必须能够测量最高5.5*pi弧度/秒的方向变化（即每秒约1,000度）
  • 应该能够在200 Hz或更高的情况下提供活动。请注意，尽管上面的陀螺仪频率为Android 4.3的“应该”，但计划将未来版本的兼容性定义更改为“必须”。也就是说，这些标准在Android 4.3中是可选的，但将来需要在以后的版本中。非常强烈鼓励运行Android 4.3的现有和新设备在Android 4.3中满足这些要求，以便他们能够升级到将来的平台发行版
  • 必须具有12位准确性或更多
  • 必须具有每Hz的差异大于1e-7 rad^2 / s^2（每Hz方差，或rad^2 / s）。允许该方差随采样率而变化，但必须受此值的约束。换句话说，如果在1 Hz采样率下测量陀螺仪的方差，则不应大于1e-7 rad^2/s^2。
  • 必须在硬件事件发生时具有时间戳。必须删除恒定延迟。

7.3.5.晴雨表

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

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

7.3.6。温度计

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

7.3.7.光度计

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

7.3.8.接近传感器

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

7.4.数据连接

7.4.1.电话

Android 4.3 API使用的“电话”和本文档专门指的是与使用GSM或CDMA网络发送SMS消息有关的硬件。尽管这些语音呼叫可能会切换或可能不会被切换，但它们是为了使用同一网络实现的任何数据连接性的Android 4.3。换句话说，Android“电话”功能和API专门指的是语音呼叫和SMS；例如，无法放置呼叫或发送/接收SMS消息的设备实现不得报告“ android.hardware.telephony”功能或任何子功能，无论它们是否使用蜂窝网络进行数据连接。

Android 4.3可以在不包括电话硬件的设备上使用。也就是说，Android 4.3与不是电话的设备兼容。但是，如果设备实现确实包括GSM或CDMA电话，则必须为该技术实施全面支持。不包括电话硬件的设备实现必须将完整的API作为NO-OPS实现。

7.4.2. IEEE 802.11（无线网络）

Android 4.3设备实现应包括对802.11的一种或多种形式的支持（B/G/A/N等），如果设备实现确实包括对802.11的支持，则必须实现相应的Android API。

设备实现必须如SDK文档[资源，62 ]中所述实现多播API。确实包括WiFi支持的设备实现必须支持多播DNS（MDN）。设备实现不得在操作的任何时候过滤MDNS数据包（224.0.0.251），包括屏幕不处于活动状态时。

7.4.2.1。无线直连

设备实现应包括对WiFi Direct（WiFi peer-to-Peer）的支持。如果设备实现确实包括对WiFi Direct的支持，则必须如SDK文档[资源，68 ]中所述实现相应的Android API。如果设备实现包括对WiFi Direct的支持，则IT：

  • 必须支持常规WiFi操作
  • 应支持并发WiFi和WiFi直接操作

7.4.3.蓝牙

设备实现应包括蓝牙收发器。确实包含蓝牙收发器的设备实现必须如SDK文档中所述启用基于RFCOMM的蓝牙API，并声明硬件功能Android.hardware.bluetooth [ Resources，42 ]。设备实现应实现相关的蓝牙配置文件，例如A2DP，AVRCP，OBEX等。

确实包括对蓝牙GATT（通用属性配置文件）的支持的设备实现，以启用与蓝牙智能或智能智能设备进行通信，必须如SDK文档中所述启用基于GATT的蓝牙API，并声明硬件功能Android.hardware.hardware.bluetooth_le [ Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources，Resources》 42 ]。

7.4.4.近场通信

设备实现应包括用于近场通信（NFC）的收发器和相关硬件。如果设备实现确实包括NFC硬件，则它：

  • 必须从android.content.pm.PackageManager.hasSystemFeature()方法报告Android.hardware.nfc功能。 [资源，37 ]
  • 必须能够通过以下NFC标准阅读和编写NDEF消息：
    • 必须能够通过以下NFC标准充当NFC论坛读者/作者（NFC论坛技术规范NFCFORUM-TS-DIGITAL-PROTOCOCOL-1.0）：
      • NFCA（ISO14443-3A）
      • NFCB（ISO14443-3B）
      • NFCF（JIS 6319-4）
      • ISODEP（ISO 14443-4）
      • NFC论坛标签类型1、2、3、4（由NFC论坛定义）
  • 应该能够通过以下NFC标准读取和编写NDEF消息。请注意，尽管下面的NFC标准为Android 4.3表示为“应该”，但计划将未来版本的兼容性定义更改为“必须”。也就是说，这些标准在Android 4.3中是可选的，但将来需要在以后的版本中。强烈鼓励运行Android 4.3的现有和新设备在Android 4.3中满足这些要求，以便他们能够升级到将来的平台版本。
    • NFCV（ISO 15693）
  • 必须能够通过以下对等标准和协议传输和接收数据：
    • ISO 18092
    • LLCP 1.0（由NFC论坛定义）
    • SDP 1.0（由NFC论坛定义）
    • NDEF推动协议[资源，43 ]
    • SNEP 1.0（由NFC论坛定义）
  • 必须包括对Android Beam的支持[资源，65 ]：
    • 必须实现SNEP默认服务器。默认SNEP服务器接收到的有效NDEF消息必须使用Android.nfc.action_ndef_discovered意图将其派往应用程序。在设置中禁用Android Beam不得禁用传入的NDEF消息。
    • 设备实现必须尊重android.settings.nfcsharing_settings，目的是显示NFC共享设置[ Resources，67 ]。
    • 必须实现NPP服务器。 NPP服务器接收到的消息必须与SNEP默认服务器相同。
    • 必须实现SNEP客户端，并尝试在启用Android Beam时将出站P2P NDEF发送到默认的SNEP服务器。如果找不到默认的SNEP服务器，则客户端必须尝试发送到NPP服务器。
    • 必须允许前景活动使用android.nfc.nfcadapter.setndefpushmessage和android.nfc.nfc.nfcadapter.setndeppushmessagecallback，and android.nfc.nfc.nfc.nfc.nfcadapter.enable.enable.enableforefferforefforpush。
    • 在发送出站P2P NDEF消息之前，应使用手势或屏幕上的确认，例如“触摸梁”。
    • 默认情况下应启用Android Beam
    • 当设备支持蓝牙对象推送配置文件时，必须支持NFC连接交接到蓝牙。使用android.nfc.nfcadapter.setbeampushuris时，设备实现必须支持连接移交给蓝牙的连接交接，通过实现“连接移交版1.2” [ Resources，60 ]和“使用NFC版本1.0的蓝牙安全简单配对， NFC论坛。这样的实现应使用SNEP获取请求，以通过NFC交换移交请求 /选择记录，并且必须使用蓝牙对象推送配置文件进行实际的蓝牙数据传输。
  • 必须在NFC发现模式下对所有受支持的技术进行轮询。
  • 当设备醒着时，屏幕处于活动状态并解锁锁定屏幕时，应处于NFC发现模式。

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

此外，设备实现可能包括读者/作者支持以下Mifare技术。

请注意，Android 4.3包括这些Mifare类型的API。如果设备实现支持读者/作者角色中的Mifare，则它：

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

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

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

7.4.5。最低网络能力

设备实现必须包括对一种或多种形式的数据网络的支持。具体而言，设备实现必须包括至少一个能够为200kbit/sec或更高的数据标准的支持。满足此要求的技术的示例包括Edge，HSPA，EV-DO，802.11g，以太网等。

物理网络标准（例如以太网）是主要数据连接的设备实现还应包括至少一种常见的无线数据标准，例如802.11（WiFi）。

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

7.5。相机

设备实现应包括后置摄像头，并且可能包括前置摄像头。后置摄像头是位于显示屏对面设备侧面的相机。也就是说，它像传统的相机一样在设备的另一侧拍摄场景。前置摄像头是与显示器相同的相机。也就是说，通常用于对用户进行映像的相机，例如视频会议和类似的应用程序。

7.5.1.后置摄像头

设备实现应包括后置摄像头。如果设备实现包括后置摄像头，则它：

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

7.5.2.前置摄像头

设备实现可能包括前置摄像头。如果设备实现包括前置摄像头，则它：

  • 必须具有至少VGA的分辨率（即640x480像素）
  • 不得将前置摄像头用作相机API的默认值。也就是说，Android 4.3中的相机API对前置摄像机具有特定的支持，并且设备实现不得配置API以将前置摄像机视为默认的后置摄像头，即使它是唯一的摄像头，装置。
  • 如第7.5.1节所述，可能包括可用于后置摄像机的功能（例如自动对焦，闪存等）。
  • 必须水平反射（即镜像）应用程序中的应用显示的流，如下所示：
    • 如果设备实现能够由用户旋转（例如，通过加速度计或通过用户输入手动旋转），则相对于设备的当前方向，摄像机预览必须水平镜像。
    • 如果当前应用程序已明确要求通过呼叫android.hardware.Camera.setDisplayOrientation() [ Resources，50 ]方法旋转相机显示器，则相对于应用程序指定的方向，摄像机预览必须水平镜像。
    • 否则，必须沿设备的默认水平轴镜像预览。
  • 必须以与摄像机预览图像流相同的方式镜像图像显示的图像。 （如果设备实现不支持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 4.3 SDK文档中包含的完整摄像头API [资源，51 ]），无论该设备是否包括硬件自动对焦或其他功能。例如，缺乏自动对焦的摄像机仍然必须调用任何已注册的android.hardware.Camera.AutoFocusCallback实例（即使这与非Autofocus相机无关，请注意）请注意，这确实适用于前面的摄像头；例如，即使大多数面向前置的摄像头不支持自动对焦，但API回调仍然必须如所述“伪造”。

设备实现必须识别并尊重每个参数名称，该名称在android.hardware.Camera.Parameters类上定义为常数，如果基础硬件支持该功能。如果设备硬件不支持功能，则API必须按照记录。 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. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.4.相机方向

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, 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。内存和存储

7.6.1.最小内存和存储

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

Device implementations MUST have at least 512MB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 512MB. Device implementations that run Android 4.3 are very strongly encouraged to have at least 1GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2.应用程序共享存储

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

必须使用默认安装的“开箱即用”安装的共享存储配置设备实现。如果共享存储未安装在Linux路径/sdcard上，则该设备必须包括从/sdcard到实际安装点的Linux符号链接。

设备实现必须按照记录的android.permission.WRITE_EXTERNAL_STORAGE在此共享存储中执行。共享存储否则必须通过获得该许可的任何应用程序可写。

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

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 (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

  • The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
  • The device implementation SHOULD report a USB device class of 0x00 .
  • The device implementation SHOULD report a USB interface name of 'MTP'.

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

考虑两个常见的例子是说明的。 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

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

  • the port MUST be connectable to a USB host with a standard USB-A port
  • the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 so they will be able to upgrade to the future platform releases
  • the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 so they will be able to upgrade to future platform releases.
  • if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
  • it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
  • it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
  • it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
  • it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 so they will be able to upgrade to the future platform releases

If a device implementation includes a USB host port:

  • it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
  • it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. 性能兼容性

Device implementations MUST meet the key performance metrics of an Android 4.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
  • Contacts: less than 700ms
  • Settings: less than 700ms
 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. 安全模型兼容性

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, 54 ] in the Android developer documentation.设备实现必须支持安装自签名的应用程序，而无需任何第三方/当局的任何其他权限/证书。具体而言，兼容的设备必须支持以下小节中描述的安全机制。

9.1.权限

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ].具体而言，实施必须执行按照SDK文档中描述的每个许可；无法省略，更改或忽略权限。如果新的权限ID字符串不在Android中。*名称空间，则实现可能会增加其他权限。

9.2. UID 和进程隔离

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, 54 ].

9.3.文件系统权限

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

9.4.备用执行环境

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.

9.5。多用户支持

Android 4.3 includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support [ Resources, 71 ]:

  • As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
  • Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]
  • Android 4.3 includes support for restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Device implementations that include support for multiple users MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage. The upstream Android Open Source Project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage.

9.6. Premium SMS Warning

Android 4.3 includes support for warning users for any outgoing premium SMS message [ Resources, 73 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. Kernel Security Features

The Android Sandbox in Android 4.3 includes features that can use the SELinux mandatory access control system (MAC) and other security features in the Linux kernel. Device implementations MUST support SELinux MAC. Note that the upstream Android Open Source Project provides an implementation that satisfies this requirement.

SELinux or any security features implemented below the Android framework MUST maintain compatibility with existing applications. These features SHOULD be invisible to users and developers. These features SHOULD NOT be user or developer configurable. If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility. To ensure continued compatibility the reference implementation allows the use of SELinux in a permissive mode and supports dynamic policy updates without requiring a system image update. Device implementations using SELinux MUST support this permissive mode, support dynamic policy updates and log any policy violations without breaking applications or affecting system behavior. Implementations using SELinux SHOULD load policy from /sepolicy file on the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement. Device implementations SHOULD use the reference implementation in the Android Open Source Project, and device implementations MUST be compatible with the upstream Android Open Source Project.

10.软件兼容性测试

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 4.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.兼容性测试套件

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.此外，设备实施者应尽可能地使用Android开源树中的参考实现，并且必须确保在CTS含糊不清以及参考源代码部分的任何重新实现的情况下兼容。

CTS设计为在实际设备上运行。像任何软件一样，CTS本身可能包含错误。 The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.3.设备实现必须传递设备软件完成时可用的最新CTS版本。

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 Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3.参考应用

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

  • The "Apps for Android" applications [ Resources, 55 ]
  • Replica Island (available in Google Play Store)

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

11. 可更新的软件

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.

只要可以替换设备上预装的整个软件，就可以使用任何方法。 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. That is, the update mechanism MUST preserve application private data and application shared data.请注意，上游Android软件包括满足此要求的更新机制。

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可根据刚才描述的机制应用的更新。

12. 联系我们

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.