Android 4.1 兼容性定义
修订版 3
上次更新时间：2013 年 6 月 24 日
版权 © 2012，Google Inc。保留所有权利。
[email protected]
目录
1.简介
2.资源
3.软件
3.1.受管理 API 兼容性
3.2.软 API 兼容性
3.2.1.权限
3.2.2.build 参数
3.2.3.intent 兼容性
3.2.3.1.核心应用 intent
3.2.3.2.intent 替换
3.2.3.3.intent 命名空间
3.2.3.4.广播 intent
3.3.原生 API 兼容性
3.3.1 应用二进制接口
3.4.Web 兼容性
3.4.1.WebView 兼容性
3.4.2.浏览器兼容性
3.5. API 行为兼容性
3.6. API 命名空间
3.7.虚拟机兼容性
3.8.界面兼容性
3.8.1.widget
3.8.2.通知
3.8.3.搜索
3.8.4.消息框
3.8.5.主题
3.8.6.动态壁纸
3.8.7.最近使用的应用的显示
3.8.8.输入管理 设置
3.8.9.锁定屏幕遥控器
3.9 设备管理
3.10 无障碍功能
3.11 文字转语音
4.应用打包兼容性
5.多媒体兼容性
5.1.媒体编解码器
5.2.视频编码
5.3.录音
5.4.音频延迟
5.5.网络协议
6.开发者工具兼容性
7.硬件兼容性
7.1.显示和图形
7.1.1.屏幕配置
7.1.2.显示指标
7.1.3.屏幕方向
7.1.4. 2D 和 3D 图形 Accleration
7.1.5.旧版应用兼容模式
7.1.6.屏幕类型
7.1.7.屏幕技术
7.2.在输入设备
中，7.2.1.键盘
7.2.2.非触摸导航
7.2.3.导航键
7.2.4.触摸屏输入
7.2.5.模拟触摸输入
7.2.6.麦克风
7.3.传感器
7.3.1.加速度计
7.3.1. 加速度计
7.3.2. 磁力计
7.3.3. GPS
7.3.4.陀螺仪
7.3.5.气压计
7.3.6.温度计
7.3.7.光度计
7.3.8. 近程传感器
7.4.数据连接
7.4.1.电话
7.4.2. IEEE 802.11 (WiFi)
7.4.2.1.Wi-Fi 直连
7.4.3. 蓝牙
7.4.4.近距离无线通信
7.4.5.最低网络功能
7.5. C摄像头
7.5.1.后置摄像头
7.5.2.前置摄像头
7.5.3.摄像头 API 行为
7.5.4.摄像头方向
7.6.内存和存储空间
7.6.1.最小内存和存储空间
7.6.2.应用共享的存储空间
7.7. USB
8.性能兼容性
9.安全模型兼容性
9.1.权限
9.2. UID 和进程隔离
9.3.文件系统权限
9.4.替代执行环境
10.软件兼容性测试
10.1.兼容性测试套件
10.2. CTS 验证程序
10.3. 参考应用
11.可更新软件
12.与我们联系
附录 A - 蓝牙测试程序
1.简介
本文档列出了设备必须满足哪些要求才能与 Android 4.1 兼容。
本文档按照 RFC2119
[资源 1] 中定义的 IETF 标准使用“必须”“不得”“必需”“会”“不会”“应”“不应”“建议”“可以”和“可选”字样。
在本文档中，“设备实现者”或“实现者”是指开发搭载 Android 4.1 的硬件/软件解决方案的个人或组织。
“设备
实现”或“实现”是指所开发的硬件/软件解决方案。
设备实现必须满足本兼容性定义文档（包括以参考资料的形式纳入的所有文档）中列出的要求，才会被视为与 Android 4.1 兼容。
本定义或第 10 节中所述的软件测试如有未提及、含糊不清或不完整之处，设备实现者需负责确保与现有实现兼容。
因此，Android 开源项目 [资源 3] 既是参考 Android 实现，也是首选 Android 实现。
强烈建议设备实现者尽可能使其实现基于 Android 开源项目提供的“上游”源代码。
虽然从理论上来说
某些组件可以替换为备用实现，但强烈建议不要这样做，否则通过软件测试的难度会大大增加。
实现者需负责确保行为与标准 Android 实现（包括兼容性测试套件及其他内容）
完全兼容
。最后请注意，本文档明确禁止替换和修改某些组件。
2.资源
1. IETF RFC2119 要求级别： http://www.ietf.org/rfc/rfc2119.txt
2. Android 兼容性计划概览：
http://source.android.com/compatibility/index.html
3. Android Open Source Project：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.1 版本字符串：
http://source.android.com/compatibility/4.1/versions.html
8. RenderScript：
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 Geolocation API：http://www.w3.org/TR/geolocation-API/
15. HTML5/W3C Webdatabase API: http://www.w3.org/TR/webdatabase/
16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17.Dalvik 虚拟机规范：可在 Android 源代码中的
dalvik/docs
下找到18. AppWidget：
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. 动态壁纸：http://developer.android.com/resources/articles/live-
wal papers.html
27. Android 设备管理：
http://developer.android.com/guide/topics/admin/device-admin.html
28. android.app.admin.DevicePolicyManager 类：
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. Android Accessibility Service 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.Eyes Free 项目：http://code.google.com/p/eyes-free
32. 文字转语音 API：
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.参考工具文档（适用于 adb、aapt、ddms）：
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 Push Protocol: http://source.android.com/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. android.hardware.Camera：
http://developer.android.com/reference/android/hardware/Camera.html
52. Android 开放配件：
http://developer.android.com/guide/topics/usb/accessory.html
53. USB Host 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.app.DownloadManager 类：
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 Live Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-
live--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 Multicast 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 Beam：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. Wi-Fi 直连（Wi-Fi 点对点）：
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69.媒体遥控器客户端：
http://developer.android.com/reference/android/media/RemoteControlClient.html
70. Motion Event API：
http://developer.android.com/reference/android/view/MotionEvent.html
71. 触摸输入配置：http://source.android.com/tech/input/touch-
devices.html
以上很多资源都是直接或间接源自 Android 4.1 SDK，
并且其功能与该 SDK 的文档中所述的功能相同。 如果本兼容性定义文档或兼容性测试套件与 SDK 文档有任何不一致的情况，均以 SDK 文档为准。
上面包含的参考资料内提供的所有技术详细信息都被视为本兼容性定义的一部分。
3.软件
3.1.受管理 API 兼容性
受管理（基于 Dalvik）执行环境是 Android 应用所需的主要容器
。Android 应用编程接口 (API) 是一组 Android 平台接口，可供在受管理虚拟机环境中运行的应用使用。
设备实现必须提供 Android 4.1 SDK 所提供的所有已载述 API 的完整实现（包括所有已载述的行为）[资源 4]。
除非本兼容性定义中明确许可，否则设备实现不得省略任何受管理 API，不得更改 API 接口或签名，不得违背已载述的行为，也不得包含空操作。
本兼容性定义文档允许设备实现省略某些类型的硬件，但前提是 Android 包含适用于它们的 API。
如果省略此类硬件，这些 API 仍必须存在并采取合理的行为方式。
如需了解针对这种情况的具体
要求，请参阅第 7 节。
3.2.软 API 兼容性
除了第 3.1 节中的受管理 API 之外，Android 还包含一个非常重要的
运行时专用“软”API，该 API 采用诸如以下形式：intent、权限，以及 Android 应用中在应用编译期间无法被强制执行的其他类似方面。
3.2.1.权限
设备实现者必须支持并强制采用“权限”参考页面 [资源 5] 中
所述的所有权限常量。请注意，第 10 节
列出了与 Android 安全模型相关的其他要求。
3.2.2.构建参数
Android API 在 android.os.Build 类
[资源 6] 中包含一些用于描述当前设备的常量。为了在各种设备实现之间提供一致且有意义的值，下表中列出了针对这些值的格式的一些额外限制，设备实现必须遵从这些限制。
参数
备注
当前正在执行的 Android 系统的版本，采用人类可读懂的格式。此字段的值必须是 [资源 7] 中定义的字符串值之一
android.os.Build.VERSION.RELEASE
。
当前正在执行的 Android 系统的版本，采用第三方应用代码可访问的格式。
android.os.Build.VERSION.SDK
对于 Android 4.1，此字段的值必须为整数 16。
当前正在执行的 Android 系统的版本，采用第三方应用代码可访问的格式。
android.os.Build.VERSION.SDK_INT
对于 Android 4.1，此字段的值必须为整数 16。
由设备实现者选择的值，用于指定当前正在执行的 Android
系统的具体 build，采用人类可读懂的格式。此值不得重复用于提供给最终用户的不同 build
android.os.Build.VERSION.INCREMENTAL
。此字段的一个典型用途是指明生成相应 build 时使用的是哪个 build 号或哪个源代码控制更改标识符。
此字段不得为 null，也不得为空字符串 ("")，除此之外，对此字段的具体格式没有任何要求。
设备实现者选择的值，用于标识设备使用的特定内部硬件，采用人类可读的格式。
此字段的一个可能用途是指明设备主板的具体修订版本
android.os.Build.BOARD
。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式
“^[a-zA-Z0-9.,_-]+$”
匹配。
设备实现者选择的值，以人类可读的格式标识生产设备的公司、组织、个人等的名称。此字段的一个可能用途是，指明销售设备的 OEM
android.os.Build.BRAND
和/或运营商。此字段的值必须可编码为 7 位的 ASCII 值，并与
正则表达式“^[a-zA-Z0-9.,_-]+$”匹配。
原生代码的指令集名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节：原生 API
android.os.Build.CPU_ABI
兼容性。
原生代码第二个指令集的名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节：原生
android.os.Build.CPU_ABI2
API兼容性。
由设备实现者选择的值，用于标识设备正文（有时称为“工业设计”）的具体配置或修订版本
android.os.Build.DEVICE
。此字段的值必须可编码为 7 位的
ASCII 值，并与正则表达式“^[a-zA-Z0-9.,_-]+$”匹配。
用于唯一标识此 build 的字符串。应采用人类可读懂的格式。必须遵循以下
模板：
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例如：
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
指纹不得包含空格字符。如果上述模板中包含的其他字段内有空白字符，则在 build 指纹中必须将空白字符替换为其他字符，例如下划线 ("_") 字符。
此字段的值必须可编码为 7 位的 ASCII 值。
硬件的名称（来自内核命令行或 /proc）。应采用人类可读懂的格式
android.os.Build.HARDWARE
。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-
zA-Z0-9.,_-]+$”匹配。
一个字符串，以人类可读的格式唯一标识 build 的构建主机。对此字段的具体格式没有任何
android.os.Build.HOST
要求，但不得为 null 或空字符串 ("")。
设备实现者选择的用于引用特定版本的标识符，采用人类可读的格式。此
字段可与 android.os.Build.VERSION.INCREMENTAL 相同，但应是对最终用户来说有充分意义的值，以便他们区分各软件 build。
android.os.Build.ID
此字段的值必须可编码为 7 位的 ASCII 值，
并与正则表达式“^[a-zA-Z0-9.,_-]+$”匹配。
产品的原始设备制造商 (OEM) 的商标名称。对
android.os.Build.MANUFACTURER
此字段的具体格式没有任何要求，但不得为 null 或空字符串 ("")。
设备实现者选择的值，其中包含最终用户所知的设备名称。此
android.os.Build.MODEL
应与销售设备并出售给最终用户时所使用的名称相同。对此字段的具体格式没有任何要求，但不得为 null 或空字符串 ("")。
设备实现者选择的值，其中包含商品
android.os.Build.PRODUCT
(SKU) 的开发名称或代码名称。必须采用人类可读懂的格式，但不一定可供最终用户查看。此
字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9.,_-]+$”匹配。
硬件序列号（如果有）。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^([a-zA-Z0-9]{0,20})$”
android.os.Build.SERIAL
匹配。
设备实现者选择的用于进一步区分 build 的标记的逗号分隔列表。例如，
android.os.Build.TAGS“unsigned,debug”。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9.,_-]+$”匹配。
android.os.Build.TIME
一个值，表示 build 发生的时间戳。
由设备实现者选择的值，用于指定相应 build 的运行时配置。此字段
应是与以下三种典型 Android 运行时配置对应的值之一：“user”“userdebug”或“eng”。
android.os.Build.TYPE
此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9.,_-]+$”匹配。
系统生成 build 的用户（或自动化用户）的名称或用户 ID。对
android.os.Build.USER
此字段的具体格式没有任何要求，但不得为 null 或空字符串 ("")。
3.2.3.intent 兼容性
设备实现必须支持 Android 的松散耦合 intent 系统，
如下文所述。“支持”意味着设备实现者必须提供一个 Android activity 或 Service，用于为每个指定的 intent 模式指定匹配的 intent 过滤器，并为这些模式绑定并实现正确的行为。
3.2.3.1.核心应用 intent
Android 上游项目定义了一些核心应用，例如通讯录、
日历、图库、音乐播放器等。设备实现者可以将这些应用替换为替代版本。
不过，任何此类替代版本都必须支持上游项目提供的相同 intent 模式。
例如，如果设备包含替代音乐播放器，
它仍必须支持第三方应用发出的用于挑选歌曲的 intent 模式。
以下应用被视为核心 Android 系统应用：
桌面时钟
浏览器
日历
通讯录
图库
全球搜索
启动器
音乐
设置
核心 Android 系统应用包含各种被视为“公开”的 activity 或 Service 组件
。也就是说，属性“android:exported”可以不存在，也可以具有值“true”。
对于核心 Android 系统应用中定义的每个 activity 或 service，如果该 activity 或 service 未通过值为“false”的 android:exported 属性标记为非公开，则设备实现必须包含一个实现与核心 Android 系统应用相同 intent 过滤器模式的同类型组件。
换言之，设备实现可以更换核心 Android 系统应用；不过，如果进行此类更换，设备实现必须支持由被更换的每个核心 Android 系统应用所定义的所有 intent 模式。
3.2.3.2.intent 替换项
由于 Android 是一个可扩展的平台，因此设备实现必须允许第三方应用替换第 3.2.3.2 节中提到的每种 intent
模式。
上游 Android 开源实现默认允许这么做；设备
实现者不得为系统应用使用这些 intent 模式的情况附加特殊特权，也不得阻止第三方应用绑定到这些模式并取得对这些模式的控制权。
具体而言，此项规定包括但不限于
停用“选择器”界面（用户可通过该界面在多个均可处理相同 intent 模式的应用之间进行选择）。
不过，如果默认 activity 为数据 URI 提供更具体的过滤器，设备实现可以为特定 URI 模式（例如 http://play.google.com）提供默认 activity。
例如，用于指定数据 URI
“http://www.android.com”的 intent 过滤器比用于指定“http://”的浏览器过滤器更具体。设备
实现必须提供一个界面来供用户修改 intent 的默认 activity
。
3.2.3.3.intent 命名空间
设备实现不得包含任何符合以下条件的 Android 组件：
支持任何使用 ACTION、CATEGORY 或使用 android.* 或 com.android.* 命名空间中的其他键字符串的新 intent 模式或广播 intent 模式。
设备实现者不得添加任何符合以下条件的 Android 组件：遵从任何使用 ACTION、CATEGORY 或属于其他组织的软件包空间中的其他键字符串的新 intent 模式或广播 intent 模式。
设备实现者不得更改或扩展第 3.2.3.1 节列出的核心应用使用的任何 intent
模式。设备实现可以包含所用命名空间明显与其所属组织关联的 intent 模式。
此项规定类似于第
3.6 节中针对 Java 语言类的规定。
3.2.3.4.广播 intent
第三方应用依赖平台广播某些 intent 来获悉硬件或软件环境中发生的变化
。与 Android 兼容的设备
必须广播公共广播 intent 来响应相应的系统事件
。如需关于广播 intent 的介绍，请参阅 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）
libEGL.so（原生 OpenGL 表面管理）
libjnigraphics.so
libOpenSLES.so（OpenSL ES 1.0.1 音频支持）
libOpenMAXAL.so（OpenMAX AL 1.0.1 支持）
libandroid.so（原生 Android activity 支持）
支持 OpenGL，如下所述
请注意，Android NDK 的未来版本可能会引入对其他 ABI 的支持。
如果设备实现与现有的某个预定义 ABI 不兼容，则
不得报告支持任何 ABI。
实现原生代码兼容性是一项颇具挑战性的任务。因此，应重申一下，
强烈建议设备实现者使用上面列出的库的上游实现，以帮助确保兼容性。
3.4.Web 兼容性
3.4.1.WebView 兼容性
Android 开源实现使用 WebKit 渲染引擎来
实现 android.webkit.WebView。由于无法为 Web 呈现系统开发综合测试套件，因此设备实现者必须在 WebView 实现中使用 WebKit 的特定上游 build。
具体而言：
设备实现的 android.webkit.WebView 实现必须基于 Android 4.1 的上游 Android 开源代码树中的 534.30 WebKit build。
此 build 包含一组针对 WebView 的特定功能和安全
修复程序。 设备实现者可以自定义
WebKit 实现；不过，任何此类自定义都不得更改
WebView 的行为，包括呈现行为。
WebView 报告的用户代理字符串必须采用以下格式：
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
The value of the $(VERSION) string MUST be the same as the value for
The value of the $(VERSION) string MUST be the same as the value for
android.os.Build.VERSION.RELEASE
The value of the $(LOCALE) string SHOULD fol ow the ISO conventions for
country code and language, and SHOULD refer to the current configured
locale of the device
The value of the $(MODEL) string MUST be the same as the value for
android.os.Build.MODEL
The value of the $(BUILD) string MUST be the same as the value for
android.os.Build.ID
Device implementations MAY omit Mobile in the user agent string
The WebView component SHOULD include support for as much of HTML5
[Resources, 11] as possible。至少，设备实现必须支持 WebView 中与 HTML5 关联的以下每个 API：
应用缓存/离线操作 [资源 12]
<video> 标记 [资源 13]
地理定位 [资源 14]
此外，设备实现必须支持 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.浏览器兼容性
设备实现必须包含独立的浏览器应用，以供用户进行一般的
网页浏览。独立的浏览器可以基于 WebKit 之外的浏览器技术。
不过，即使使用的是替代浏览器应用，向第三方应用提供的
android.webkit.WebView 组件也必须基于 WebKit，如第 3.4.1 节中所述。
实现可以在独立的浏览器应用中附带自定义用户代理字符串。
独立的浏览器应用（无论是基于上游 WebKit 浏览器应用，还是基于第三方替代应用）应支持尽可能多的 HTML5 功能 [资源 11]。
至少，设备实现必须支持
与 HTML5 相关联的以下每个 API：
应用缓存/离线操作 [资源 12]
<video> 标记 [资源 13]
地理定位 [资源 14]
此外，设备实现必须支持 HTML5/W3C webstorage API
[资源 15]，并且应支持 HTML5/W3C IndexedDB API [资源
16]。请注意，随着 Web 开发标准制定机构逐渐转变为青睐 IndexedDB 胜过 webstorage，IndexedDB 预计会成为未来版本的 Android 中必需的组件。
3.5.API 行为兼容性
每种 API 类型（受管理 API、软 API、原生 API 和 Web API）的行为都必须与上游 Android 开源项目 [资源 3] 的首选实现一致。
以下是一些特定的兼容性方面：
设备不得更改标准 intent 的行为或语义
设备不得更改特定类型的系统组件（例如 Service、activity、ContentProvider 等）的生命周期或生命周期语义
设备不得更改标准权限的语义
上述列表并非详尽无遗。兼容性测试套件 (CTS) 用于测试平台重要部分的行为兼容性，而不是测试整个平台的行为兼容性。
实现者需负责确保与 Android
开源项目保持行为兼容。为此，设备实现者应尽可能使用通过 Android 开源项目获得的源代码，而不是重新实现系统的重要部分。
3.6.API 命名空间
Android 遵循 Java
编程语言定义的软件包和类命名空间惯例。为了确保与第三方应用兼容，设备
实现者不得对以下软件包命名空间进行任何禁止执行的修改（见下文）：
java.*
javax.*
sun.*
android.*
com.android.*
禁止的修改包括：
设备实现不得通过更改任何方法或类签名或者通过移除
类或类字段的方式，修改 Android 平台上公开提供的 API。
设备实现者可以修改 API 的底层实现，但
此类修改不得影响任何公开提供的 API 的规定行为和 Java 语言
签名。
设备实现者不得向上述 API 添加任何公开提供的元素（例如
类或接口，或者现有类或接口中的字段或方法）。
“公开提供的元素”是指在上游 Android 源代码中使用时不带“@hide”标记的任何构造。
换言之，设备
实现者不得在上述命名空间中提供新的 API 或更改现有的 API。
设备实现者可以执行仅限于内部的修改，但不得向开发者通告或以其他方式公开这些修改。
设备实现者可以添加自定义 API，但任何此类 API 均不得位于归其他组织所有或指代其他组织的命名空间内。
例如，设备
实现者不得向 com.google.* 或类似命名空间添加 API；只有
Google 可以向此类命名空间添加 API。同样，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
小 / 正常 / 大
tvdpi / hdpi
32MB
小 / 正常 / 大
xhdpi
64MB
xlarge
mdpi
32MB
xlarge
tvdpi / hdpi
64MB
xlarge
xhdpi
128MB
3.8.界面兼容性
3.8.1. Widget
Android 定义了一种组件类型以及对应的 API 和生命周期，以便
应用向最终用户提供“AppWidget”[Resources, 18]。Android
开源参考版本包含一个启动器应用，该应用包含可让用户从主屏幕添加、查看和移除 AppWidget 的界面功能。
设备实现可以用替代启动器替换参考启动器（即
主屏幕）。替代启动器应包含对 AppWidget 的内置支持，
并提供用于直接在启动器中添加、配置、查看和移除
AppWidget 的界面功能。替代启动器可以省略这些界面元素；不过，如果省略这些界面元素，设备实现必须提供可从启动器访问的单独应用，以便用户添加、配置、查看和移除 AppWidget。
设备实现必须能够呈现标准网格大小为 4 x 4 的 widget
。如需了解详情，请参阅 Android SDK 文档中的“应用 widget 设计准则”
[资源 18]。
3.8.2.通知
Android 包含一些 API，支持开发者使用设备的硬件和软件功能通知用户值得注意的事件
[资源 19]。
一些 API 允许应用使用硬件功能（具体来说是使用声音、振动和指示灯）来发出通知或吸引用户注意。
设备实现必须尽可能使用设备实现硬件来支持使用硬件功能的通知（如 SDK 文档中所述）。
例如，如果设备实现包含振动器，则必须正确实现振动 API。
如果设备实现缺少硬件，则必须将对应的 API 实现为空操作。
请注意，
第 7 节中对此行为进行了进一步的详细说明。
此外，实现必须正确呈现 API [资源 20] 或状态栏/系统栏图标样式指南 [资源 21] 中提供的所有资源（图标、声音文件等）。
设备实现者可以针对通知提供替代用户体验，而不使用 参考 Android 开源实现所提供的体验；不过，此类替代通知系统必须支持现有的通知资源（如上所述）。
Android 4.1 支持内容丰富的通知，例如用于提供持续通知的互动式视图。
设备实现必须正确显示和执行内容丰富的通知（如 Android API 中所述）。
3.8.3.搜索
Android 包含一些 API [资源 22]，可让开发者在其应用中纳入搜索功能，并将其应用数据提供给全局系统搜索功能。
一般而言，此功能由单个系统级界面组成，
可让用户输入查询、在用户输入时显示建议，以及显示结果。
这些 Android API 可让开发者重复使用此界面，以在其应用内提供搜索功能，还可让开发者向通用的全局搜索界面提供搜索结果。
设备实现必须包含单个共享的系统级搜索界面，并且该界面能够在用户输入内容时实时提供建议。
设备
实现必须实现一些 API，以供开发者重复使用此界面，从而在其应用内提供搜索功能。
设备实现
必须实现一些 API，以便在搜索框以全局搜索模式运行时，可让第三方应用向搜索框中添加建议。
如果没有安装任何可利用此功能的第三方应用，则默认行为应为显示 Web 搜索引擎的搜索结果和建议。
3.8.4.消息框
应用可以使用“消息框”API（定义见 [资源 23]）向最终用户显示简短的非模态字符串，这些字符串会在短暂显示后消失。
设备
实现必须以某种可见性非常高的方式向最终用户显示来自应用的消息框。
3.8.5.主题
Android 提供“主题”这一机制，以供应用在整个 activity 或应用中应用样式
。Android 3.0 引入了一个新的“Holo”（即“全息”）
主题，这是一组已定义的样式，如果应用开发者希望与 Android SDK [资源 24] 定义的 Holo 主题外观和风格保持一致，可以使用该主题。
设备
实现不得更改提供给应用的任何 Holo 主题属性
[资源 25]。
Android 4.0 引入了一个新的“设备默认”主题，这是一组已定义的样式，如果应用开发者希望与设备实现者定义的设备主题的外观和风格保持一致，可以使用该主题。
设备实现可以修改提供给应用的
DeviceDefault 主题属性 [资源 25]。
3.8.6.动态壁纸
Android 定义了一种组件类型以及对应的 API 和生命周期，以便应用向最终用户提供一个或多个“动态壁纸”[资源 26]。
动态壁纸是具备有限输入功能且作为壁纸显示在其他应用之后的动画、图案或类似图片。
如果硬件能够在不限制功能且不会对其他应用造成负面影响的情况下，以合理的帧速率运行所有动态壁纸，则会被视为能够可靠地运行动态壁纸。
如果硬件中的限制会导致壁纸
和/或应用崩溃、无法正常运行、占用过多 CPU/消耗过多电池电量，或者
运行时的帧速率低得令人无法接受，相应硬件会被视为无法运行
动态壁纸。例如，有些动态壁纸可能会利用 Open GL 1.0 或 2.0 上下文来呈现其内容。
动态壁纸将无法在不支持多个 OpenGL 上下文的硬件上可靠地运行，因为使用 OpenGL 上下文的动态壁纸可能会与其他同样使用 OpenGL 上下文的应用发生冲突。
如果设备实现能够可靠地运行动态壁纸（如上所述），则应实现动态壁纸。
如果设备实现被判定为无法
可靠地运行动态壁纸（如上所述），则不得实现动态壁纸。
3.8.7.近期应用显示
上游 Android 4.1 源代码包含一个界面，以便使用缩略图来显示用户最近使用的应用，这些缩略图是用户上次离开应用时应用的图形状态。
设备实现可以更改或消除此界面；不过，我们计划在未来版本的 Android 中更广泛地利用此功能。
强烈建议设备实现使用上游 Android 4.1 界面（或类似的基于缩略图的界面）来显示用户最近使用的应用，否则可能会与未来版本的 Android 不兼容。
3.8.8.输入管理设置
Android 4.1 支持输入管理引擎。Android 4.1 API
允许自定义应用 IME 指定用户可调设置。设备实现必须在显示提供此类用户设置的 IME 时，让用户可以随时访问 IME 设置。
3.8.9.锁定屏幕远程控制
Android 4.0 引入了对 Remote Control API 的支持，可让媒体应用与远程视图（例如设备锁定屏幕）中显示的播放控件相集成
[资源 69]。
设备实现应支持
在设备锁定屏幕中嵌入遥控器。
3.9 设备管理
Android 4.1 包含一些可让注重安全性的应用在系统级执行设备管理工作的功能，例如通过 Android Device Administration API [资源 27] 强制执行密码政策或执行远程清除。
设备实现必须提供
DevicePolicyManager 类的实现 [资源 28]，并且应支持 Android SDK 文档中定义的所有
设备管理政策 [资源
27]。
注意：虽然对于 Android 4.1 来说，上文中所述的一些要求规定为“应”满足的要求，但我们计划在针对未来版本的兼容性定义中将其改为“必须”满足的要求。
换言之，这些要求在 Android 4.1 中是非强制性要求，但在未来版本中将成为必须满足
的要求。强烈建议
搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，否则在升级到未来版本时，这些设备将无法实现与 Android 兼容。
3.10 无障碍服务
Android 4.1 提供了一个无障碍服务层，以便残障用户更轻松地在设备上进行导航。
此外，Android 4.1 还提供了一些平台 API，以便
无障碍服务实现接收针对用户和系统事件的回调
并生成替代反馈机制，例如文字转语音、触感
反馈，以及轨迹球 /方向键导航 [R资源 29]。设备实现
必须提供与默认 Android 实现一致的 Android 无障碍功能框架实现。
具体而言，设备实现必须
满足以下要求。
设备实现必须通过 android.accessibilityservice API [资源 30] 支持第三方无障碍服务实现。
设备实现必须生成 AccessibilityEvent，并以与默认 Android 实现一致的方式将这些事件传递给所有已注册的 AccessibilityService 实现。
设备实现必须提供一种可供用户使用的机制，以便用户启用和停用无障碍服务；并且必须显示此界面以响应 android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS intent。
此外，设备实现还应在设备上提供无障碍服务实现，并且应提供一种可让用户在设备设置期间启用无障碍服务的机制。
Eyes Free 项目 [资源 31] 提供了无障碍服务的开源实现。
3.11 文字转语音
Android 4.1 包含一些可让应用使用文字转语音 (TTS)
服务的 API，并允许服务提供商提供 TTS 服务实现
[资源 32]。设备实现必须满足以下与 Android TTS 框架相关的要求：
设备实现必须支持 Android TTS 框架 API，并且应包含支持设备上可用语言的 TTS 引擎。
请注意，上游 Android 开源软件包含功能完善的 TTS 引擎实现。
设备实现必须支持安装第三方 TTS 引擎。
设备实现必须提供一个可供用户使用的界面，以便用户选择在系统级使用的 TTS 引擎。
4.应用打包兼容性
设备实现必须安装并运行官方 Android SDK 中包含的
“aapt”工具生成的 Android“.apk”文件 [资源 33]。
设备实现不得通过会导致相应文件无法在其他兼容设备上正确安装和运行的方式，扩展 .apk [资源 34]、Android 清单 [资源 35]、Dalvik 字节码 [资源 17] 或 renderscript 字节码格式。
设备实现者应使用 Dalvik 的参考上游实现，以及该参考实现的软件包
管理系统。
5.多媒体兼容性
设备实现必须包含至少一种音频输出形式，例如
扬声器、耳机插孔、外部扬声器连接等。
5.1.媒体编解码器
设备实现必须支持 Android SDK 文档中指定的核心媒体格式 [资源 58]，但本文档中明确允许的情况除外。
具体而言，设备实现必须支持下表中定义的媒体格式、编码器、解码器、文件类型和容器格式。
在 Android 开源项目的首选 Android 实现中，所有这些编解码器都是作为软件实现提供的。
请注意，Google 和开放手机联盟 (Open Handset Alliance) 均未做过任何关于这些编解码器中没有使用第三方专利的声明。
打算在硬件或软件产品中使用此源代码的用户请注意，实现此代码（包括在开源软件或共享软件中实现此代码）可能需要获得相关专利持有者的专利许可。
请注意，这些表中并未列出大多数视频编解码器的具体比特率要求
，因为当前的设备硬件不一定支持相关标准指定的必须达到的比特率
。设备实现应支持硬件上可行的最高比特率，但不超过规范规定的上限。
文件类型
格式
类型
编码器
解码器
详细信息
容器
编解码器
格式
支持
必需
单声道/立体声/5.0/5.1*
MPEG-4
对于设备实现
(.3gp)
kHz。
MPEG-4
支持
(.mp4,
MPEG-4
单声道/立体声/5.0/5.1*
.m4a)
HE AAC
内容
ADTS 原始
必需
配置文件
标准采样
AAC (.aac,
(AAC+)
速率从 16 到 48
以
kHz 解码。
Android
3.1 及更高版本
支持
MPEG-4
对于设备
在单声/立体声/5.0/5.1*
HE AAC v2
实现中进行编码，
必须支持
Android
内容
Profile
麦克风硬件和
4.0 及更高版本、ADIF
标准采样
（增强型
定义
不
速率从 16 到 48
AAC+）
android.hardware.microphone
支持）
kHz。
MPEG-TS
MPEG-4
（.ts，不可
音频
对于设备
支持
可跳转
对象类型
实现，其中包含
单声道/立体声内容
Android
ER AAC
麦克风硬件和
必须
使用标准
3.0+）
ELD
定义
采样率
（增强型
android.hardware.microphone
16 到 48 kHz。
低延迟
AAC)
必需
对于包含麦克风硬件且
4.75 到 12.2 kbps
AMR-NB
的设备实现而言，是必需的
必需
3GPP (.3gp)
采样率为 8kHz
并定义
android.hardware.microphone。
必需
对于包含麦克风硬件
AMR-WB
的设备实现而言，是必需的
9 个比特率（介于 6.60-23.85 kbit/s 之间）
3GPP (.3gp)
和定义
采样率为 16kHz
android.hardware.microphone。
单声道/立体声（无
多声道）。
音频
采样率最高可达 48 kHz（但对于输出为 44.1 kHz 且
��建议使用 16 位；对于 24 位，不应用抖动。
单声道/立体声 8-
320Kbps 恒定
MP3
必需
MP3 (.mp3)
(CBR) 或
可变比特率 (VBR)
类型 0 和
MIDI 类型 0 和 1。
1 (.mid、
DLS 版本 1 和
.xmf、.mxmf)
2. XMF 和 Mobile
RTTTL/RTX
MIDI
必需
XMF。支持
（.rtttl、.rtx）
响铃格式
OTA (.ota)
RTTTL/RTX、OTA、
iMelody
和 iMelody
(.imy)
Ogg (.ogg)
Vorbis
必需
Matroska
(.mkv)
8 位和 16 位
线性 PCM**（速率
不超过
硬件限制）。设备
必须支持
PCM/WAVE
必需
必需
WAVE (.wav)
采样率
8000、16000 和
44100 Hz
频率的
原始 PCM 录制
JPEG
必需
必需
Base+progressive
JPEG (.jpg)
GIF
必需
GIF (.gif)
图片
PNG
必需
必需
PNG (.png)
BMP
必需
BMP (.bmp)
WEBP
必需
必需
WebP (.webp)
必需
对于设备实现，必须
包含摄像头硬件和
(.3gp)
H.263
的 3GPP
文件
定义 android.hardware.camera
MPEG-4
或
(.mp4)
android.hardware.camera.front。
3GPP
(.3gp)
必需
MPEG-4
(.mp4)
对于包含摄像头硬件和基准配置文件的设备实现
MPEG-TS
必需
视频
H.264 AVC
必需
（.ts、AAC
定义 android.hardware.camera
(BP)
仅限音频、
或
不可
android.hardware.camera.front.
跳转，
Android
3.0 及更高版本）
MPEG-4
必需
3GPP (.3gp)
SP
WebM (.webm)
必需
和 Matroska
VP8
（Android
(.mkv, Android
2.3.3+)
4.0 及更高版本）
*注意：仅要求对 5.0/5.1 内容进行下混音；录制或渲染超过 2 个声道的音频是可选的。
**注意：执行 16 位线性 PCM 捕获是强制性要求。执行 8 位线性 PCM
捕获不是强制性要求。
5.2 视频编码
如果 Android 设备实现包含后置摄像头并声明了
android.hardware.camera，则应支持以下视频编码配置文件。
高清（如果硬件支持）
标清（低画质）标清（高画质）
）
H.264 基准
H.264 基准
视频编解码器
H.264 基准配置文件
配置文件
配置文件
视频
176 x 144 像素
480 x 360 像素
1280 x 720 像素
分辨率
视频帧12 fps
30 fps
30 fps
速率
500 Kbps
视频码率56 Kbps
2 Mbps 或更高
更高
音频编解码器AAC-LC
AAC-LC
AAC-LC
音频
1 (mono)
2 (stereo)
2 (stereo)
声道
音频码率24 Kbps
128 Kbps
192 Kbps
5.3. 音频录制
当应用已使用 android.media.AudioRecord API 开始录制
音频串流时，包含麦克风硬件并声明了 android.hardware.microphone 的设备实现必须对以下每种行为分别进行音频采样并录音：
设备应表现出大致平坦的幅频特性；具体来说就是：±3 dB (100 Hz - 4000 Hz)
音频输入灵敏度应设置为，以便 1000 Hz 时 90 dB 声功率级 (SPL) 源为 16 位采样生成 2500 的 RMS。
PCM 幅度级别应以线性方式跟踪输入 SPL 变化，至少在 -18 dB 到 +12 dB 的范围内（相对于麦克风的 90 dB SPL）。
对于 90 dB SPL 输入级别，1 Khz 的总谐波失真应低于 1%。
除了上述录制规范外，当应用已经开始使用
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
音频源录制音频串流时：
降噪处理（如果有）必须停用。
自动增益控制（如果有）必须停用。
注意：虽然对于 Android 4.1 来说，上文中所述的一些要求规定为“应”满足的要求，但我们计划在针对未来版本的兼容性定义中将其改为“必须”满足的要求。
换言之，这些要求在 Android 4.1 中是非强制性要求，但在未来版本中将成为必须满足
的要求。强烈建议
搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，否则在升级到未来版本时，这些设备将无法实现与 Android 兼容。
5.4. 音频延迟
音频延迟大体上是指，从应用请求音频播放或录制操作到设备实现实际开始该操作之间的时间间隔。
许多类别的应用都依赖于非常短的延迟来实现
实时效果，例如音效或 VoIP 通信。
如果设备实现包含麦克风硬件并声明了 android.hardware.microphone
，则应满足本节中所述的所有音频延迟要求。请参阅第 7 节，详细了解设备实现可以在什么情况下省略麦克风硬件。
在本部分中：
“冷输出延迟”是指，在音频系统在应用请求播放音频之前已处于空闲状态并已关闭的情况下，从应用请求播放音频到声音开始播放之间的时间间隔。
“温输出延迟”是指，在音频系统最近使用过但当前处于空闲状态（即静默状态）的情况下，从应用请求播放音频到声音开始播放之间的时间间隔。
“连续输出延迟”是指，在设备当前正在播放音频的情况下，从应用发出要播放的样本到扬声器实际播放相应声音之间的时间间隔。
“冷输入延迟”是指，在音频系统和麦克风在应用请求录音之前已处于空闲状态并且已关闭的情况下，从应用请求录音到第一个样本通过回调传送到应用之间的时间间隔。
“连续输入延迟”是指，在设备当前正在录音的情况下，从应用发出要录制的声音到麦克风实际录制相应声音之间的时间间隔。
使用上述定义，设备实现应具有以下各项特性：
冷输出延迟不超过 100 毫秒
温输出延迟不超过 10 毫秒
连续输出延迟不超过 45 毫秒
冷输入延迟不超过 100 毫秒
连续输入延迟不超过 50 毫秒
注意：虽然上面列出的要求对于 Android 4.1 而言是“应”，
但我们计划将未来版本的兼容性定义更改为“必须”。
也就是说，这些要求在 Android 4.1 中是可选的，但未来版本将要求满足这些要求。
强烈建议
搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，否则在升级到未来版本时，这些设备将无法实现与 Android 兼容。
如果设备实现满足本节的要求，则可以通过 android.content.pm.PackageManager 类报告“android.hardware.audio.low-
latency”功能，来报告支持低延迟音频。
[Resources, 37]
反之，如果设备实现不满足这些要求，则不得报告支持低延迟音频。
5.5.网络协议
设备必须支持 Android SDK 文档中指定的适用于音频和视频播放的媒体网络协议
[资源 58]。具体而言，设备
必须支持以下媒体网络协议：
RTSP（RTP、SDP）
HTTP(S) 渐进式流式传输
HTTP(S) Live 草案协议（第 3 版）[资源 59]
6.开发者工具兼容性
设备实现必须支持 Android SDK 中提供的 Android 开发者工具
。具体而言，与 Android 兼容的设备必须与以下各项兼容：
Android 调试桥（简称 adb）[资源 33]
设备实现必须支持 Android SDK 中所述的所有 adb 函数
。设备端 adb 守护程序必须默认处于停用状态，并且必须有一种可供用户使用的机制，以便用户开启 Android 调试桥。
Dalvik 调试监控服务（简称 ddms）[资源 33]
设备实现必须支持 Android SDK 中所述的所有 ddms 功能。
由于 ddms 会使用 adb，因此对 ddms 的支持应默认处于停用状态，但如果用户启用了 Android 调试桥，则必须支持 ddms，如上所述。
Monkey [资源 36]
设备实现必须包含 Monkey 框架，并使其可供应用使用。
大多数基于 Linux 的系统和 Apple Macintosh 系统都使用标准的 Android SDK 工具识别 Android 设备，而无需其他支持；不过，Microsoft
Windows 系统通常需要驱动程序，才能识别新的 Android 设备。
（例如，
新的供应商 ID 需要适用于 Windows 系统的自定义 USB 驱动程序，有时新的设备 ID 也需要此类驱动程序。）
如果标准 Android SDK 中提供的 adb 工具无法识别某个设备实现，设备实现者必须提供相关的 Windows 驱动程序，以便开发者使用 adb 协议连接到设备。
必须为 32 位和 64 位版本的 Windows XP、Windows Vista 和 Windows 7 提供这些驱动程序。
7.硬件兼容性
如果设备包含特定的硬件组件，而该组件具有针对第三方开发者的相应 API，则该设备实现必须实现该 API（如 Android SDK 文档中所述）。
如果 SDK 中的某个 API 需要与某个被规定为可选组件的硬件组件交互，但设备实现不具备该组件，则：
�
设备实现必须能够通过 android.content.pm.PackageManager 类中的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法准确报告准确的硬件配置信息。
[Resources, 37]
7.1.显示屏和图形
Android 4.1 包含一些能够适当地为设备自动调整应用资源和界面布局的方式，以确保第三方应用能够在各种硬件配置上良好地运行 [资源 38]。
设备必须正确实现
本节中详细介绍的这些 API 和行为。
本部分中要求引用的单位定义如下：
“物理对角线尺寸”是指屏幕亮显部分的两个对角之间的距离（以英寸为单位）。
“dpi”（即“每英寸的点数”）是指，1 英寸的线性水平或垂直跨度内包含的像素数。
如果列出了 dpi 值，则水平 dpi 和垂直 dpi 都必须在该范围内。
“宽高比”是指屏幕的长度与宽度之比。
例如，480x854 像素的显示屏的宽高比是 854 / 480 =
1.779，或约为“16:9”。
“密度无关像素”（简称“dp”）是指，按 160
dpi 屏幕标准化的虚拟像素单位，计算公式为：像素 = dps *（密度 / 160）。
7.1.1.屏幕配置
屏幕尺寸
Android 界面框架支持多种不同的屏幕尺寸，并且允许应用通过 android.content.res.Configuration.screenLayout（使用 SCREENLAYOUT_SIZE_MASK 参数）查询设备屏幕尺寸（也称为“屏幕布局”）。
设备实现必须报告 Android SDK 文档中定义且由上游 Android 平台确定的正确屏幕尺寸 [资源 38]。
具体而言，设备实现必须根据以下逻辑密度无关像素 (dp)
屏幕尺寸报告正确的屏幕尺寸。
设备的屏幕尺寸必须至少为 426 dp x 320 dp（“小”）
如果设备报告的屏幕尺寸为“标准”，则屏幕尺寸必须至少为 480
dp x 320 dp
如果设备报告的屏幕尺寸为“大”，则屏幕尺寸必须至少为 640
dp x 480 dp
如果设备报告的屏幕尺寸为“特大”，则屏幕尺寸必须至少为 960
dp x 720 dp
此外，设备的实际对角线屏幕尺寸必须至少为 2.5 英寸
。
在任何时间，设备都不得更改其报告的屏幕尺寸。
应用可以视需要通过 AndroidManifest.xml 文件中的 <supports-
screens> 属性来指明其支持的屏幕尺寸。设备实现必须
正确执行应用对于“小”“标准”“大”和“特大”屏幕的指定支持
（如 Android SDK 文档中所述）。
屏幕宽高比
宽高比必须介于 1.3333 (4:3) 和 1.85 (16:9) 之间。
屏幕密度
Android 界面框架定义了一组标准逻辑密度，以便
应用开发者确定要采用的应用资源。设备实现必须通过 android.util.DisplayMetrics API
报告以下某个逻辑 Android 框架密度，并且必须以该标准
密度执行应用。
120 dpi，称为“ldpi”
160 dpi，称为“mdpi”
213 dpi，称为“tvdpi”
240 dpi，称为“hdpi”
320 dpi，称为“xhdpi”
480 dpi，称为“xxhdpi”
设备实现应定义标准 Android 框架密度，该密度应在数字上最接近屏幕的实际密度，除非逻辑密度
在数字上最接近屏幕的实际密度，除非逻辑密度
将报告的屏幕大小推低到支持的最低值以下。
如果数值最接近物理密度的标准 Android 框架密度会导致屏幕尺寸小于支持的最小兼容屏幕尺寸（宽度为 320 dp），设备实现应报告下一个最低的标准 Android 框架密度。
7.1.2.显示指标
设备实现必须为
android.util.DisplayMetrics [资源 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 文档中对此进行了详细阐述。
设备实现还必须
支持 Android Renderscript，Android SDK 文档
[资源 8] 中对此进行了详细说明。
设备实现还必须将自身正确地标识为支持
OpenGL ES 1.0 和 2.0。即：
受管理 API（例如通过 GLES10.getString() 方法）必须报告
支持 OpenGL ES 1.0 和 2.0
原生 C/C++ OpenGL API（即通过 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 向应用提供的 API）必须报告支持
OpenGL ES 1.0 和 2.0。
设备实现可以实现任何所需的 OpenGL ES 扩展。
不过，设备实现必须通过 OpenGL ES 受管理 API 和
原生 API 报告所支持的所有扩展字符串；反之而言，不得报告不支持的扩展字符串。
请注意，Android 4.1 支持应用视需要指定它们需要使用特定 OpenGL 纹理压缩格式。
这些格式通常为供应商专用格式。
Android 4.1 不要求设备实现必须实现任何特定纹理压缩格式。
不过，设备实现应通过
OpenGL API
中的 getString() 方法准确报告所支持的所有
纹理压缩格式。
Android 4.1 包含一种机制，可让应用通过使用清单标记 android:hardwareAccelerated 或通过直接调用 API 的方式，声明应用希望在应用、activity、窗口或视图级别为 2D 图形启用硬件加速 [资源 9]。
在 Android 4.1 中，设备实现必须默认启用硬件加速；如果开发者通过以下方式请求停用硬件加速，设备实现必须将其停用：
设置 android:hardwareAccelerated="false”，或直接通过 Android View API 停用硬件加速。
此外，设备实现表现出的行为必须与 Android
SDK 文档中关于硬件加速的说明一致 [资源 9]。
Android 4.1 包含一个 TextureView 对象，以便开发者直接将经过硬件加速的 OpenGL ES 纹理作为呈现目标集成到界面层次结构中。
设备实现必须支持 TextureView API，并且必须与上游 Android 实现具有
一致的行为。
7.1.5.旧版应用兼容模式
Android 4.1 指定了一种“兼容模式”，在该模式下，框架能够以与“标准”屏幕尺寸等效的模式（宽度为 320dp）运行，这是为了服务于不是针对旧版 Android（在实现屏幕尺寸独立性之前发布的旧版 Android）开发的旧应用。
设备实现必须支持上游 Android 开放源代码所实现的旧应用兼容模式。
也就是说，设备实现不得更改启用兼容模式的触发条件或阈值，也不得更改兼容模式本身的行为。
7.1.6.屏幕类型
设备实现屏幕分为两种类型：
固定像素显示屏实现：屏幕是仅支持单个像素宽度和高度的单个面板
。通常，屏幕会以物理方式与设备集成
。例如手机、平板电脑等。
可变像素显示屏实现：设备实现没有嵌入式屏幕且包含视频输出端口（例如用于连接显示屏的 VGA、HDMI 或无线端口），或者具有可以更改像素尺寸的嵌入式屏幕。
例如：电视、机顶盒等。
固定像素设备实现
固定像素设备实现可以使用任何像素尺寸的屏幕，
但前提是它们满足本兼容性定义文档中规定的要求。
固定像素实现可以包含视频输出端口，以便与外接
显示屏搭配使用。不过，只要该显示屏会用于运行应用，设备必须满足
以下要求：
设备必须报告与固定像素显示屏相同的屏幕配置和显示指标（第 7.1.1 节和第 7.1.2 节对此进行了详细说明）。
设备必须报告与固定像素显示屏相同的逻辑密度。
设备报告的屏幕尺寸必须与固定像素显示屏的屏幕尺寸相同或非常接近。
例如，对角线尺寸为 7 英寸且分辨率为 1024x600 像素的平板电脑会被视为采用固定像素的大型 mdpi 显示屏实现。
如果设备实现包含以 720p 或 1080p 显示的视频输出端口，则必须扩展输出，以便仅在较大的 mdpi 窗口中执行应用，而不考虑使用的是固定像素显示屏还是视频输出端口。
可变像素设备实现
可变像素设备实现必须支持 1280x720 和/或 1920x1080（即 720p 和/或 1080p）。
具有可变像素
显示屏的设备实现不得支持任何其他屏幕配置或模式。具有可变像素屏幕的设备实现可以在运行时或启动时更改屏幕配置或模式。
例如，机顶盒用户可以将 720p 显示屏更换成 1080p 显示屏，并且设备实现可以相应地进行调整。
此外，可变像素设备实现必须针对这些像素尺寸报告以下配置分组：
1280x720（也称为 720p）：“大”屏幕尺寸、“tvdpi”（213 dpi）密度
1920x1080（也称为 1080p）：“大”屏幕尺寸、“xhdpi”（320 dpi）密度
为清楚起见，特此说明：具有可变像素尺寸的设备实现在 Android 4.1 中仅限采用 720p 或 1080p，并且必须配置为报告上述屏幕尺寸和
密度分组。
7.1.7.屏幕技术
Android 平台包含一些可让应用在显示屏上呈现丰富图形的 API。
除非本文档中明确许可，否则设备必须支持 Android SDK 定义的所有这些 API
。具体而言：
设备必须支持能够呈现 16 位彩色图形的显示屏，并且
应支持能够呈现 24 位彩色图形的显示屏。
设备必须支持能够呈现动画的显示屏。
所用显示技术的像素宽高比 (PAR) 必须介于 0.9
和 1.1 之间。也就是说，像素宽高比必须接近方形 (1.0)，并且公差在 10%的范围内。
7.2.输入设备
7.2.1.键盘
设备实现：
必须支持输入管理框架（可让第三方开发者创建输入管理引擎，即软键盘），详见 http://developer.android.com
必须提供至少一个软键盘实现（无论是否存在硬件键盘）
可以包含其他软键盘实现
可以包含硬件键盘
不得包含与 android.content.res.Configuration.keyboard [资源，40]中指定的任何格式（即 QWERTY 或 12 键）都不匹配的硬件键盘
7.2.2.
非触摸导航
设备实现：
可以省略非触摸导航选项（即可以省略轨迹球、方向键或
滚轮）
必须针对 android.content.res.Configuration.navigation [资源 40]报告正确的值
必须提供适用于文本选择和编辑的合理备选界面机制，该机制与输入管理引擎兼容。
上游 Android 开源软件包含一种适合在缺少非触摸导航输入法的设备上使用的选择机制
。
7.2.3.导航键
“主屏幕”“菜单”和“返回”功能对于 Android 导航
范式至关重要。设备实现必须在运行应用时
随时为用户提供这些功能。可以通过专用实体按钮（例如机械或电容式触控按钮）实现这些功能，也可以使用专用软件按键、手势、触摸板等来实现。Android 4.1 支持这两种实现方式。
Android 4.1 引入了对辅助操作的支持 [资源 63]。设备
实现必须在运行应用时随时向用户提供辅助操作。
此功能可以通过硬件或软件按键来实现。
设备实现可以使用屏幕上的单独部分来显示导航键，但如果这样做，必须满足以下要求：
设备实现导航键必须位于屏幕上的单独部分，不能供应用使用，并且不得遮住或以其他方式影响屏幕上可供应用使用的部分。
设备实现必须将显示屏的一部分提供给应用使用，并且该部分必须满足第 7.1.1 节中定义的要求。
当应用未指定系统界面模式或指定了 SYSTEM_UI_FLAG_VISIBLE 时，设备实现必须显示导航键。
当应用指定了 SYSTEM_UI_FLAG_LOW_PROFILE 时，设备实现必须以不显眼的“低调”（例如灰显）
模式显示导航键。
如果应用指定了 SYSTEM_UI_FLAG_HIDE_NAVIGATION，设备实现必须隐藏导航键。
当 targetSdkVersion <= 10 时，设备实现必须向应用显示菜单键；当 targetSdkVersion > 10 时，设备实现不应显示菜单键。
设备实现必须向符合第 7.1.1 节中定义的要求的应用提供部分显示屏。
7.2.4.触摸屏输入
设备实现应具有某种指针输入系统（类似于鼠标的输入系统或触摸式输入系统）。
不过，如果设备实现不支持指针输入系统，则不得报告 android.hardware.touchscreen 或 android.hardware.faketouch 功能常量。
包含指针输入系统的设备实现：
应支持完全独立跟踪的指针（如果设备输入系统
支持多个指针）
必须报告 android.content.res.Configuration.touchscreen
[资源 40] 的值，并且该值要与
设备
上的具体触摸屏的类型相对应
Android 4.0 支持多种触摸屏、触摸板和模拟触控
输入设备。基于触摸屏的设备实现会与
显示屏 [资源 71] 相关联，从而让用户感觉像是在直接操控
屏幕上的内容。由于用户会直接触摸屏幕，因此系统不需要使用任何额外的方式来指明所操控的对象。
相比之下，模拟触摸界面则会提供一个能够模拟部分触摸屏功能的用户输入系统。
例如，驱动
屏幕光标的鼠标或遥控器能够模拟触摸操作，但需要用户先指向或聚焦到目标，
然后再点击。鼠标、触控板、基于陀螺仪的空中鼠标、
陀螺仪指针、操纵杆和多点触控板等多种输入设备都可以支持模拟触摸交互。
Android 4.0 包含功能常量 android.hardware.faketouch，
该常量对应于高保真非触控（即基于指针）输入设备，例如
鼠标或触控板，可以充分模拟基于触控的输入（包括基本
手势支持），并指示设备支持模拟的部分
触摸屏功能。如果设备实现声明了模拟触摸功能，则
必须满足第 7.2.5 节中的模拟触摸要求。
设备实现必须报告与所用输入法的类型对应的正确功能。
如果设备实现包含触摸屏（单点触控或更好的触摸屏），则
必须报告平台功能常量 android.hardware.touchscreen。如果设备实现报告平台功能常量 android.hardware.touchscreen，还必须要报告平台功能常量 android.hardware.faketouch。
如果设备实现不包含
触摸屏（仅依靠指控设备），则不得报告任何触摸屏
功能，并且仅在满足第 7.2.5 节中的模拟
触摸要求时，才能报告 android.hardware.faketouch。
7.2.5.虚拟触摸输入
声明支持 android.hardware.faketouch 的设备实现
必须报告指针位置的绝对 X 和 Y 屏幕位置，并在屏幕上显示可见指针
[资源 70]
必须通过操作代码报告触摸事件 [资源 70]，指明当指针在屏幕上按下或松开 时发生的状态变化
[资源 70]
必须支持在屏幕上的对象上按下和松开指针，这允许用户在屏幕上的对象上模拟点按
必须支持在屏幕上的对象上按下、松开、按下再松开指针，这允许用户在屏幕上的对象上模拟双点按
[资源 70]
必须支持在屏幕上的任意一点按下指针，然后将指针移动到屏幕上的任意其他一点，接着再松开指针，这允许用户在屏幕上模拟拖动
必须支持按下指针，然后允许用户快速将对象移动到屏幕上的其他位置，接着再松开指针，这允许用户在屏幕上模拟快速滑动对象
声明支持 android.hardware.faketouch.multitouch.distinct 的设备
必须满足上述虚拟触摸功能的要求，并且还必须支持对两个或更多独立指针输入进行区分跟踪。
7.2.6.麦克风
设备实现可以省略麦克风。不过，如果设备实现
省略了麦克风，则不得报告 android.hardware.microphone 功能
常量，并且必须按照第 7 节的规定将录音 API 实现为空操作。
反之，如果设备实现具有麦克风，则必须：
必须报告 android.hardware.microphone 功能常量
应满足第 5.4 节中的音频质量要求
应满足第 5.5 节中的音频延迟要求
7.3。传感器
Android 4.1 包含用于访问多种传感器的 API。设备
实现通常可以省略这些传感器，如后续
小节中所述。如果设备包含某种传感器，而这种传感器具有针对第三方开发者的相应 API，则设备实现必须实现该 API，如 Android SDK 文档中所述。
例如，设备实现：
必须根据 android.content.pm.PackageManager 类准确报告是否存在传感器。
[Resources, 37]
必须通过 SensorManager.getSensorList() 和类似方法返回准确的受支持传感器列表
对于所有其他传感器 API，必须采取合理的行为（例如，在应用尝试注册监听器时视情况返回 true 或 false，在不存在相应的传感器时不调用传感器监听器，等等）
必须采用相关的国际单位制（即指标）值报告所有传感器测量结果，具体取决于 Android SDK 文档中定义的每种传感器类型 [Resources, 41]
上述列表并非详尽无遗；Android SDK 的已记录行为应被视为权威。
有些传感器类型为合成型，也就是说，它们可以从一个或多个其他传感器提供的数据推导出来。
（例如方向传感器和线性加速度传感器。）
设备实现应实现这些传感器
类型，但前提是设备实现包含必要的实体传感器。
Android 4.1 API 中引入了“流式”传感器这一概念，这种传感器会持续返回数据，而不是仅在数据发生变化时才会返回数据。
对于 Android 4.1 SDK 文档指定为流式传感器的任何 API，设备实现都必须持续提供定期数据样本。
7.3.1.加速度计
设备实现应包含 3 轴加速度计。如果设备
实现包含 3 轴加速度计，则：
应能够以 120 Hz 或更高的频率传递事件。请注意，虽然对于 Android 4.1 来说，
上述加速度计频率规定为“应”达到的频率，但我们计划在
未来版本的兼容性定义中将其改为“必须”达到的频率。
换言之，这些标准在 Android 4.1 中是非强制性标准，但在未来版本中将成为必须遵从
的标准。强烈建议搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求 ，以便能够升级到未来的平台版本。
必须遵循 Android 传感器坐标系，如 Android API 中所详述
（请参阅 [资源 41]）
必须能够测量从自由落体到重力两倍 (2g) 或更高加速度的任何三维矢量
必须具有 8 位或更高的精度
必须具有不超过 0.05 米/秒^2 的标准偏差
7.3.2.
磁力计
设备实现应包含 3 轴磁力计（即罗盘）。如果
设备包含三轴磁强计，则必须：
必须能够以 10 Hz 或更高的频率传送事件
必须遵从 Android API 中详述的 Android 传感器坐标系（请参阅 [资源 41]）
必须能够采样足以覆盖地磁场的一系列场强
必须具有 8 位精度或更高
必须具有不超过 0.5 µT 的标准偏差
7.3.3.
GPS
设备实现应包含 GPS 接收器。如果设备实现
包含 GPS 接收器，则应包含某种形式的“辅助 GPS”
技术，以最大限度地缩短 GPS 锁定时间。
7.3.4.陀螺仪
设备实现应包含陀螺仪（即角度变化传感器）。
除非还包含 3 轴加速度计，否则设备不应包含陀螺仪传感器。
如果设备实现包含陀螺仪，则：
必须进行温度补偿
必须能够测量高达 5.5*Pi 弧度/秒（即大约每秒 1,000 度）的方向变化
应能够以 200 Hz 或更高的频率传递事件。
请注意，虽然对于 Android 4.1 来说，
上述陀螺仪频率规定为“应”达到的频率，但我们计划在
针对未来版本的兼容性定义中将其改为“必须”达到的频率
。换言之，这些标准在 Android 4.1 中是非强制性标准，但在未来版本中将成为必须遵从
的标准。
强烈建议搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求 ，以便能够升级到未来的平台版本
必须具有 12 位或更高的准确度
必须具有不超过 1e-7 rad^2 / s^2 / Hz 的方差（每 Hz 的方差，
或 rad^2 / s）。
方差可随采样率而变化，但不得超过此值。
也就是说，如果以 1 Hz 的采样率测量陀螺仪的方差，则方差不应超过 1e-7 rad^2/s^2。
必须具有尽可能接近硬件事件发生时间的戳。
必须移除恒定延迟。
7.3.5.气压计
设备实现可以包含气压计（即环境气压传感器）。如果
设备实现包含气压计，则必须：
必须能够以 5 Hz 或更高的频率传送事件
必须具有足够的精度，以便估算海拔
必须进行温度补偿
7.3.7.温度计
设备实现可以（但不应）包含温度计（即
温度传感器）。如果设备实现包含温度计，则必须
测量设备 CPU 的温度。不得测量任何其他温度。
（请注意，Android 4.1 API 中已废弃此传感器类型。）
7.3.7.光度计
设备实现可以包含光度计（即环境光传感器）。
7.3.8. 近程传感器
设备实现可以包含近程传感器。如果设备实现
包含近程传感器，则必须按与屏幕相同的方向测量物体的接近度。
也就是说，近程传感器必须朝向适当方向，以便检测靠近屏幕的物体，因为此类传感器的主要用途是检测用户正在使用的手机。
如果设备实现包含朝向任何其他方向的
近程传感器，则不得通过此 API 访问此类传感器。如果设备
实现包含近程传感器，则其精度必须至少为 1 位。
7.4.数据连接
7.4.1.电话
在 Android 4.1 API 和本文档中，“电话”专指与通过 GSM 或 CDMA 网络进行语音通话和发送短信相关的
硬件。
虽然这些语音通话可能采用也可能不采用分封交换技术，但都是为了使 Android 4.1 被视为独立于任何可通过同一网络实现的数据连接。
也就是说，Android“电话”
功能和 API 专指语音通话和短信；例如，如果设备实现无法打电话或收发短信，无论它们是否使用移动网络进行数据连接，都不得报告“android.hardware.telephony”功能或任何子功能。
Android 4.1 可以在不包含电话硬件的设备上使用。也就是说，
Android 4.1 与非电话设备兼容。不过，如果设备
实现包含 GSM 或 CDMA 电话，则必须
全面支持针对该技术的 API。如果设备实现不包含电话硬件，则必须将所有相关 API 实现为空操作。
7.4.2. IEEE 802.11 (WiFi)
Android 4.1 设备实现应支持一种或多种形式的 802.11（b/g/a/n 等）
如果设备实现支持 802.11，则
必须实现相应的 Android API。
设备实现必须按照 SDK 文档中所述实现多播 API
[资源 62]。如果设备实现支持 Wi-Fi，则必须支持多播 DNS (mDNS)
。在操作过程中的任何时间（包括屏幕未处于活动状态时），设备实现都不得过滤 mDNS
数据包 (224.0.0.251)。
7.4.2.1. WiFi Direct
设备实现应支持 Wi-Fi 直连（Wi-Fi 点对点）。
如果设备实现支持 Wi-Fi 直连，则必须实现 SDK 文档中所述的对应 Android API [资源 68]。
如果设备实现支持 Wi-Fi 直连，则：
必须支持常规 Wi-Fi 操作
应支持同时进行 Wi-Fi 和 Wi-Fi 直连操作
7.4.3.蓝牙
设备实现应包含蓝牙收发器。如果设备实现包含蓝牙收发器，则必须支持基于 RFCOMM 的蓝牙 API（如 SDK 文档中所述）[资源 42]。
设备
实现应实现适合设备的相关蓝牙配置文件，例如 A2DP、
AVRCP、OBEX 等。
兼容性测试套件包含涵盖 Android
RFCOMM Bluetooth API 基本操作的用例。不过，由于蓝牙是设备之间的通信协议
，在单个设备上运行的单元测试无法对其进行全面测试。
因此，设备实现还必须通过附录 A 中所述的人工驱动蓝牙
测试程序。
7.4.4.近距离无线通信
设备实现应包含用于近距离无线通信 (NFC)
的收发器和相关硬件。如果设备实现包含 NFC 硬件，则：
必须通过 android.content.pm.PackageManager.hasSystemFeature() 方法报告 android.hardware.nfc 功能。
[Resources, 37]
必须能够通过以下 NFC 标准读取和写入 NDEF 消息：
必须能够通过以下 NFC 标准充当 NFC Forum 读取器/写入器（如 NFC Forum 技术规范 NFCForum-TS-DigitalProtocol-1.0 中所定义）：
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS 6319-4)
IsoDep (ISO 14443-4)
NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
应该能够通过以下 NFC 标准读取和写入 NDEF 消息。
请注意：虽然对于 Android 4.1 来说，以下 NFC 标准规定为“应”满足的标准，但我们计划在针对未来版本的兼容性定义中将其改为“必须”满足的标准。
换言之，这些标准在
Android 4.1 中是非强制性标准，但在未来版本中将成为必须遵从的标准。强烈建议搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，以便能够升级到未来的平台版本。
NfcV (ISO 15693)
必须能够通过以下点对点标准和协议传输和接收数据：
ISO 18092
LLCP 1.0 （由 NFC Forum 定义）
SDP 1.0 （由 NFC Forum 定义）
NDEF Push Protocol [Resources, 43]
SNEP 1.0 （由 NFC Forum 定义）
必须支持 Android Beam [Resources, 65]：
必须实现 SNEP 默认服务器。
必须使用 android.nfc.ACTION_NDEF_DISCOVERED intent 将默认 SNEP 服务器收到的有效 NDEF 消息
发送给应用
。在设置中停用 Android Beam 不得导致停止发送收到的 NDEF 消息。
设备实现必须支持 android.settings.NFCSHARING_SETTINGS intent，以显示 NFC 共享设置
[R资源 67]。
必须实现 NPP 服务器。
必须按照处理默认 SNEP 服务器收到的消息时采用的方式，处理 NPP 服务器收到的消息。
必须实现 SNEP 客户端，并且在 Android Beam 处于启用状态时，必须尝试将出站点对点 NDEF 消息发送到默认 SNEP 服务器。
如果未找到默认
SNEP 服务器，则客户端必须尝试将消息发送到 NPP
服务器。
必须允许前台 activity 使用 android.nfc.NfcAdapter.setNdefPushMessage、
android.nfc.NfcAdapter.setNdefPushMessageCal back 和
android.nfc.NfcAdapter.enableForegroundNdefPush 设置出站点对点 NDEF 消息。
应在发送出站点对点 NDEF 消息之前使用手势或屏幕确认（例如“轻触即可发射”）。
应默认启用 Android Beam
必须在设备支持蓝牙对象推送个人资料时支持将 NFC 连接切换到蓝牙。
使用 android.nfc.NfcAdapter.setBeamPushUris 时，设备实现必须支持将连接切换到蓝牙，方法是实现 NFC Forum 提供的
“Connection Handover version 1.2” [Resources, 60] 和“Bluetooth Secure
Simple Pairing Using NFC version 1.0” [Resources, 61] 规范。
此类实现应使用 SNEP GET 请求，以便通过 NFC 交换切换请求 / 部分记录；并且必须使用蓝牙对象推送配置文件进行实际的蓝牙数据传输。
在 NFC 发现模式下，必须轮询所有支持的技术。
当设备处于唤醒状态、屏幕处于活动状态
且锁定屏幕已解锁时，应采用 NFC 发现模式。
（请注意，上面提到的 JIS、ISO 和 NFC Forum 规范没有公开提供的链接。）
此外，设备实现还可以为以下 MIFARE 技术提供读取器/写入器支持。
MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF on MIFARE Classic (NXP AN130511 [Resources, 48], AN130411
[Resources, 49])
请注意，Android 4.1 中包含适用于这些 MIFARE 类型的 API。如果设备
实现支持具有读取器/写入器角色的 MIFARE，则：
必须实现相应的 Android API（如 Android SDK 中所述）
必须通过
android.content.pm.PackageManager.hasSystemFeature() 方法报告功能 com.nxp.mifare。
[资源 37] 请注意，这不是标准的 Android 功能，因此
不会在 PackageManager 类中显示为常量。
不得实现相应的 Android API 也不得报告
com.nxp.mifare 功能，除非它还实现了本节中所述的一般 NFC 支持
如果设备实现不包含 NFC 硬件，则不得通过
android.content.pm.PackageManager.hasSystemFeature()
方法 [资源 37] 声明 android.hardware.nfc 功能，
并且必须将 Android 4.1 NFC API 实现为空操作。
由于类 android.nfc.NdefMessage 和 android.nfc.NdefRecord 代表不依赖于协议的数据表示格式
，因此设备实现必须实现这些 API，即使它们不支持 NFC 或声明 android.hardware.nfc 功能也是如此。
7.4.5.最低网络功能
设备实现必须支持一种或多种形式的数据
网络连接。具体而言，设备实现必须支持至少一种能够达到 200Kbit/sec 或更高传输速率的数据标准。
满足此要求的技术包括 EDGE、HSPA、EV-DO、802.11g、以太网等。
如果采用的物理网络标准（例如以太网）是主要数据连接，设备实现还应支持至少一种常用的
无线数据标准，例如 802.11 (Wi-Fi)。
设备可以实现多种形式的数据连接。
7.5.摄像头
设备实现应包含后置摄像头，并且可以包含
前置摄像头。后置摄像头是指位于设备上背向显示屏一侧的摄像头，也就是说，与传统摄像头一样，它拍摄的是背向设备显示屏一侧的景物。
前置摄像头是指与设备上的显示屏位于同一侧的摄像头，也就是通常用于拍摄用户自己的摄像头，例如用于视频会议及类似应用的摄像头。
7.5.1.后置摄像头
设备实现应包含后置摄像头。如果设备
实现包含后置摄像头，则：
必须具有至少 200 万像素的分辨率
应在摄像头驱动程序中实现硬件自动对焦或软件自动对焦（对应用软件透明）
可以具有固定焦点或 EDOF（扩展景深）硬件
可以包含闪光灯。
如果摄像头包含闪光灯，当已在摄像头预览 surface 上注册 android.hardware.Camera.PreviewCallback 实例时，闪光灯不得亮起，除非应用已通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性明确启用闪光灯。
请注意，此限制不适用于
设备的内置系统摄像头应用，而仅适用于使用 Camera.PreviewCallback 的第三方应用。
7.5.2.前置摄像头
设备实现可以包含前置摄像头。如果设备实现
包含前置摄像头，则：
分辨率不得低于 VGA（即 640x480 像素）
不得将前置摄像头用作相机 API 的默认摄像头。也就是说，
Android 4.1 中的相机 API 对前置摄像头提供专门支持，并且
设备实现不得将该 API 配置为将前置摄像头视为默认后置摄像头，即使它是设备上的唯一摄像头也是如此。
可以包含可供后置摄像头使用的功能（例如自动对焦、闪光灯等）（如第 7.5.1 节中所述）。
必须水平反射（即镜像）应用在 CameraPreview 中显示的流，如下所示：
如果设备实现能够由用户旋转（例如
通过加速度计自动旋转或通过用户输入手动旋转），
相机预览必须相对于设备的当前
屏幕方向水平镜像。
如果当前应用明确请求通过调用 android.hardware.Camera.setDisplayOrientation() [Resources, 50]
方法来旋转相机显示屏，
相机预览必须相对于应用指定的屏幕方向水平镜像。
否则，预览必须沿设备的默认
水平轴镜像。
必须按照镜像摄像头预览图像流时采用的方式，镜像由 postview 显示的图像。
（如果设备实现不支持
postview，此要求显然不适用。）
不得镜像最终拍摄的返回到应用回调或提交到媒体存储空间的静态图像或视频串流
7.5.3.
摄像头 API 行为
设备实现必须为前置摄像头和后置摄像头的摄像头相关 API 实现以下行为：
1.
如果应用从未调用过
android.hardware.Camera.Parameters.setPreviewFormat(int)，
设备必须使用 android.hardware.PixelFormat.YCbCr_420_SP 获取提供给应用回调的预览数据。
2. 如果应用注册了 android.hardware.Camera.PreviewCallback
实例，并且系统在预览
格式为 YCbCr_420_SP 时调用 onPreviewFrame() 方法，那么传递到 onPreviewFrame()
的 byte[] 中的数据必须进一步采用 NV21 编码格式。也就是说，NV21 必须是默认设置。
3.设备实现必须支持使用 YV12 格式（用
android.graphics.ImageFormat.YV12 常量表示）进行前置摄像头和后置摄像头的摄像头预览。
（硬件视频解码器和摄像头可以
使用任何原生像素格式，但设备实现必须支持
转换为 YV12。）
无论设备是否包含硬件自动对焦或其他功能，设备实现都必须实现 Android
4.1 SDK 文档 [资源 51] 中包含的完整相机 API。
例如，没有自动对焦功能的摄像头
仍必须调用所有已注册的 android.hardware.Camera.AutoFocusCallback
实例（即使这与非自动对焦摄像头无关）。请注意，
这适用于前置摄像头；例如，虽然大多数前置
摄像头都不支持自动对焦，但仍必须如所述那样“伪造”API 回调。
如果底层硬件支持相应功能，设备实现必须识别并遵从 android.hardware.Camera.Parameters 类中定义为常量的每个参数名称。
如果设备硬件不支持某项功能，则
API 的行为方式必须与所载述的行为方式一致。反之，设备实现不得遵从或识别传递给 android.hardware.Camera.setParameters() 方法的字符串常量，在 android.hardware.Camera.Parameters 中载述为常量的字符串常量除外。
也就是说，设备
实现必须支持所有标准摄像头参数（如果硬件允许），并且不得支持自定义摄像头参数类型。
每当摄像头拍摄了新照片且相应的照片条目已添加到媒体库时，设备实现都必须广播 Camera.ACTION_NEW_PICTURE intent。
每当摄像头录制了新视频且相应的视频条目已添加到媒体库时，设备实现都必须广播 Camera.ACTION_NEW_VIDEO intent
。
7.5.4.摄像头方向
前置摄像头和后置摄像头（如果存在）都必须朝向正确方向，以便摄像头的长度方向与屏幕的长度方向一致。
也就是说，当
设备处于横向时，摄像头必须
横向拍摄。无论设备的自然方向为何，此规则都适用；也就是说，它适用于以横屏为主的设备以及以竖屏为主的设备。
7.6.内存和存储空间
7.6.1.最低内存和存储空间
设备实现必须有至少 340MB 的内存供内核
和用户空间使用。这 340MB 不包括不在内核控制范围之内的所有专供
硬件组件（例如无线装置、视频等）使用的内存。
设备实现必须有至少 350MB 的非易失性存储空间可用于存储应用专属数据。
也就是说，/data 分区必须至少为 350MB。
Android API 包含一个内容下载管理器，应用可以使用它下载
数据文件 [资源 56]。内容下载管理器的设备实现
必须能够将至少为 100MB 的各个文件下载到
默认的“缓存”位置。
7.6.2.应用共享存储空间
设备实现必须为应用提供共享存储空间。提供的共享
存储空间不得小于 1 GB。
设备实现必须配有默认装载且可直接使用的共享存储空间。
如果共享存储空间未装载在 Linux 路径 /sdcard 下，则
设备必须包含从 /sdcard 指向实际装载点的 Linux 符号链接。
设备实现必须按照文档中所述，对该共享存储空间强制授予
android.permission.WRITE_EXTERNAL_STORAGE 权限。
否则，必须允许任何获得该权限的应用对共享存储空间执行写入操作。
设备实现可以具有相应的硬件来安装可供用户使用的可移动存储设备，
例如安全数字卡。或者，设备实现可以将内部（不可移动的）存储空间分配为应用的共享存储空间。
无论使用什么形式的共享存储空间，设备实现都必须提供某种访问机制，以便从主机计算机访问共享存储空间中的内容，例如使用 USB 大容量存储设备 (UMS) 或媒体传输协议 (MTP)。
设备实现可以使用 USB 大容量存储设备，但应使用媒体传输协议。
如果设备实现支持媒体传输协议，则：
设备实现应与参考 Android
MTP 主机、Android 文件传输 [Resources, 57] 兼容。
设备实现应报告 USB 设备类 0x00。
设备实现应报告 USB 接口名称“MTP”。
如果设备实现缺少 USB 端口，则必须授权主机计算机通过某些其他方式（例如网络文件系统）访问共享存储空间中的内容。
以下两个常见示例具有说明性意义。如果设备实现包含
SD 卡插槽以满足共享存储空间要求，则设备在向用户出售时必须包含至少为 1GB 的 FAT 格式的 SD 卡，并且必须默认装载该卡。
或者，如果设备实现使用内部固定存储空间来满足此要求，则该存储空间必须至少为 1GB，并且必须装载在 /sdcard 上（如果装载在其他位置，则 /sdcard 必须是指向实际位置的符号链接）。
如果设备实现包含多个共享存储空间路径（例如 SD 卡插槽和共享内部存储空间），则应修改核心应用（例如媒体扫描器和 ContentProvider），以透明地支持位于这两个位置的文件。
7.7. USB
设备实现应包含 USB 客户端端口，而且应包含
USB 主机端口。
如果设备实现包含 USB 客户端端口，则：
该端口必须可通过标准 USB-A 端口连接到 USB 主机
该端口应使用设备端的 Micro USB 外形规格。强烈建议搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，以便能够升级到未来的
平台版本
。充电口应位于边缘的中间。
设备实现
应将该端口置于设备底部（根据自然方向
），或为所有应用（包括主屏幕
）启用软件屏幕旋转功能，以便设备在按照该端口位于底部的方位放置时，显示屏能够正确呈现内容。
强烈建议搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，以便能够升级到未来的平台版本。
如果设备有其他端口（例如非 USB 充电端口），则应与 Micro-USB 端口位于同一边缘。
必须允许连接到设备的主机使用 USB 大容量存储或媒体传输协议访问共享存储卷的内容。
必须实现 Android Open Accessory API 和规范（如 Android SDK 文档中所述），并且必须声明对硬件功能 android.hardware.usb.accessory 的支持 [资源，52]。
必须实现 USB 音频类（如 Android SDK 文档中所述）[资源，66]。
应实现对 USB 电池充电规范的支持 [资源，64]。强烈建议搭载 Android 4.1 的现有设备和新设备满足 Android 4.1 中的这些要求，以便能够升级到未来的平台版本。
如果设备实现包含 USB 主机端口，则：
可以使用非标准端口外形规格，但必须附带将该端口转换为标准 USB-A 的线缆或线缆。
必须实现 Android USB 主机 API（如 Android SDK 中所述），并且必须声明对硬件功能 android.hardware.usb.host 的支持 [资源，53]。
设备实现必须实现 Android 调试桥。
如果设备
实现省略了 USB 客户端端口，则必须通过局域网（例如以太网或 802.11）
实现 Android 调试桥
8。性能兼容性
设备实现必须满足下表中定义的 Android 4.1
兼容设备的关键性能指标：
指标
性能阈值
备注
以下应用
应在指定时间内启动。
启动时间是指完成应用默认 activity 加载所用的总时间，
包括启动 Linux 进程、将 Android 软件包加载到 Dalvik 虚拟机以及调用 onCreate 所用的时间。
浏览器：小于 1300 毫秒
应用
1300 毫秒
启动时间
通讯录：小于 700 毫秒
设置：小于 700 毫秒
onCreate。
700 毫秒
在启动了多个应用的情况下，如果重新启动已启动且已在运行的应用，所用时间不得超过原来的启动时间。
应用
已启动
应用
必须
用时短于原来的
启动时间。
9.安全模型兼容性
设备实现必须实现与 Android
平台安全模型（具体定义请参见 Android 开发者文档 > API 指南 > 安全和权限参考文档
[资源 54]）一致的安全模型。设备
实现必须支持安装自签名应用，而且无需从任何第三方/权威机构获得任何额外的权限/证书。
具体而言，兼容的设备必须支持以下小节中所述的安全机制。
9.1.权限
设备实现必须支持 Android 开发者文档 [资源 54] 中定义的 Android 权限模型。
具体而言，实现
必须强制执行定义的每项权限（如 SDK 文档中所述）；不得省略、更改或忽略任何权限。
实现可以添加额外的权限，但前提是新的权限 ID 字符串不在 android.*命名空间内。
9.2. UID 和 进程隔离
设备实现必须支持 Android 应用沙盒模型。在该模型中，每个应用都是在单独的进程中作为独一无二的 Unix 式 UID 运行。
设备实现必须支持以同一 Linux 用户 ID 运行多个应用，但前提是这些应用已经过适当签名和构建（具体定义请参见安全和权限参考文档 [资源 54]）。
9.3.文件系统权限
设备实现必须支持 Android 文件访问权限模型（具体定义请参见安全和权限参考文档 [资源 54]）。
9.4.备选执行环境
设备实现可以包括运行时环境，此类环境是使用 Dalvik 虚拟机或原生代码以外的一些其他软件或技术来执行应用。
不过，此类替代执行环境不得损害
Android 安全模型或已安装的 Android 应用的安全性（如本节中所述）。
替代运行时本身必须是 Android 应用，并且遵循标准的 Android 安全模型（如第 9 节中的其他部分所述）。
不得授权替代运行时访问受以下权限保护的资源：未在替代运行时的 AndroidManifest.xml 文件中通过 <uses-
permission> 机制请求的权限。
替代运行时不得允许应用使用受仅限系统应用享有的 Android 权限保护的功能。
替代运行时必须遵循 Android 沙盒模型。具体而言：
替代运行时应通过 PackageManager 将应用安装到单独的
Android 沙盒（即 Linux 用户 ID 等）
替代运行时可以提供由使用替代运行时的所有应用共享的单个 Android 沙盒
使用替代运行时的替代运行时和已安装应用不得重复使用设备上已安装的任何其他应用的沙盒，除非通过
共享用户 ID 和签名证书这两种标准 Android 机制
替代运行时不得使用、授予或被授予对其他 Android 应用对应的沙盒的访问权限
替代运行时不得使用、授予或被授予对其他应用的任何超级用户（root）权限或任何其他用户 ID 权限。
替代运行时的 .apk 文件可以包含在设备实现的系统映像中，但必须已签名，且签名时所用的密钥必须不同于对设备实现随附的其他应用签名时使用的密钥。
在安装应用时，替代运行时必须就应用使用的 Android 权限获得用户同意。
也就是说，如果某个应用需要使用具有相应 Android 权限的设备资源（例如摄像头、GPS 等），则替代运行时必须通知用户，让他们知道该应用将能够访问相应资源。
如果运行时环境不会以这种方式记录
应用功能，则在安装任何使用该运行时的应用时，运行时环境都必须列出运行时自身拥有的所有权限。
10.软件兼容性测试
设备实现必须通过本节中所述的所有测试。
不过请注意，任何软件测试包都不是详尽无遗的。因此，
强烈建议设备实现者尽可能避免对可从 Android 开源项目获得的 Android 4.1 参考实现和首选实现进行更改。
这样有助于最大限度地降低引入 bug 的风险，从而避免造成需要进行返工和潜在设备更新的不兼容问题。
10.1.兼容性测试套件
设备实现必须通过 Android 开源项目提供的 Android 兼容性测试套件 (CTS)
[资源 2] 的测试（使用设备上最终交付的软件）。
此外，设备实现者应尽可能多地使用 Android 开放源代码树中的
参考实现，并且对于 CTS 中不明确的情况，以及参考源代码中部分内容的任何重新实现，都必须确保兼容性。
CTS 能够在实际设备上运行。与所有软件一样，CTS 自身也可能包含 bug。
CTS 的版本发布独立于本兼容性定义，我们可能会针对 Android 4.1 发布多个 CTS 修订版本。
设备
实现必须通过设备
软件发布时可用的最新 CTS 版本的测试。
10.2.CTS 验证程序
设备实现必须正确执行 CTS
验证程序中的所有适用用例。CTS 验证程序包含在兼容性测试套件中，以便人工操作员运行该验证程序来测试无法由自动化系统测试的功能，例如测试摄像头和传感器能否正常工作。
CTS 验证程序中包含针对多种硬件（其中包括一些选配硬件）的测试。
设备实现必须通过针对其具备的硬件的所有测试；例如，如果某款设备具备加速度计，则必须正确执行 CTS 验证程序中的加速度计测试用例。
对于本兼容性定义文档中注明为选配的功能，可跳过或省略相应的测试用例。
如上所述，每款设备和每个 build 都必须正确运行 CTS 验证程序。
不过，由于很多 build 非常相似，因此设备实现者可能不会对只有细微差别的 build 明确运行 CTS 验证程序。
具体而言，
如果设备实现与某个已通过 CTS
验证程序测试的实现只是在所包含的语言区域、品牌信息等方面存在差别，则可以省略 CTS 验证程序
测试。
10.3.参考应用
设备实现者必须使用以下开源应用测试实现兼容性：
“适用于 Android 的应用”应用 [参考文献，55]
Replica Island（可在 Android 市场中获取）
上述每个应用都必须能够在实现中正确启动并运行，实现才会被视为兼容。
11.可更新软件
设备实现必须包含可用于替换整个
系统软件的机制。该机制不需要执行“实时”升级 - 也就是说，可能需要重新启动设备。
可以使用任何方法，但前提是相应方法可以替换设备上预安装的整个软件
。例如，以下任一方法都满足
此要求：
无线下载 (OTA)（通过重新启动进行离线更新）
通过 USB 从主机 PC 进行“网络共享”更新
通过重新启动进行“离线”更新，并从可移动存储设备上的文件进行更新
使用的更新机制必须支持在不擦除用户数据的情况下进行更新。也就是说，
更新机制必须保留应用专属数据和应用
共享数据。请注意，上游 Android 软件包含满足此要求的更新机制
。
在设备实现发布后，如果在其合理的产品生命周期内发现其中存在错误，并且经与 Android
兼容性团队磋商后确定该错误会影响第三方应用的兼容性，则设备
实现者必须通过可按上述机制应用的可用软件更新来更正该错误。
12.与我们联系
如需澄清说明以及提出您认为本文档未涵盖的任何问题，请通过 [email protected] 与文档作者联系
。
附录 A - 蓝牙测试程序
兼容性测试套件包含涵盖 Android
RFCOMM Bluetooth API 基本操作的用例。不过，由于蓝牙是设备之间的通信协议
，在单个设备上运行的单元测试无法对其进行全面测试。
因此，设备实现还必须通过下文所述的人工操作蓝牙
测试程序。
该测试程序基于 Android
开源项目树中包含的 BluetoothChat 示例应用。该程序需要两台设备：
运行要测试的软件 build 的候选设备实现
一个已知兼容的单独设备实现，以及一个来自被测试的设备实现的模型 - 即一个“已知良好的”
设备实现
以下测试程序分别将上述设备称为“候选”设备和“已知良好”设备。
设置和安装
1.通过 Android 源代码树中的“make sample”构建 BluetoothChat.apk
2.在已知良好的设备上安装 BluetoothChat.apk
3.在候选设备上安装 BluetoothChat.apk
测试各应用的蓝牙控制
1.在蓝牙处于停用状态时，在候选设备上启动 BluetoothChat
2.验证候选设备是开启蓝牙，还是弹出开启蓝牙的对话框来提示用户
测试配对和通信
1.在两部设备上启动 BluetoothChat 应用
2.使 BluetoothChat 内可以发现已知良好设备（使用
菜单）
3.在候选设备上，从 BluetoothChat
（使用“菜单”）中扫描蓝牙设备，然后与已知良好的设备配对
4.分别从其中一台设备分别发送 10 条或更多消息，并确认另一台设备
能否正确接收这些消息
5.通过按主屏幕
6，在两台设备上关闭 BluetoothChat 应用。使用设备的“设置”应用将两台设备相互取消配对
反向测试配对和通信
方向
1.在两部设备上启动 BluetoothChat 应用。
2.使候选设备在 BluetoothChat 中（使用
菜单）处于可检测到状态。
3.在已知良好设备上，从 BluetoothChat
中扫描（使用“菜单”）蓝牙设备，然后与候选设备配对。
4.分别从其中一台设备分别发送 10 条或更多消息，并确认另一台设备
能否正确接收这些消息。
5.反复按“返回”按钮关闭两台设备上的 BluetoothChat 应用，以
前往启动器。
测试重新启动
1.在两台设备上重新启动 BluetoothChat 应用。
2.分别从其中一台设备分别发送 10 条或更多消息，并确认另一台设备
能否正确接收这些消息。
注意：在上述测试中，有些用例使用主屏幕结束一个测试环节，有些用例使用“返回”结束一个测试环节。
这些测试不是多余的，并非可选测试：目的是
验证当 activity 被明确终止（通过用户按“返回”，这样会调用 finish()），并隐式发送到后台（用户按主屏幕按钮）时，Bluetooth API 和堆栈是否正常运行。
必须按照说明执行每个测试序列。
