Android4.0 CDD中文版

Android 4.0 兼容性定义
修订本1
最近更新时间：2011.11.22
版权所有©2011, Google Inc.保留所有权利.
compatibility@
1.简介
此文档列举了对于设备兼容 Android 4.0 版所必须依次符合的要求。

词汇“必须”、“绝不可以”、“要求的”、“应该”、“不应该”、“建议”、“可以”、“可选的” 的含义依照 RFC2119 [参考, 1]中定义的 IETF 标准。

正如本文档中所使用的，“设备实现者”或者“实现者”是指开发运行 Android 4.0 的硬件/软件解决方案的一个人或者一个组织。

“设备实现”或者“实现”是指所开发的硬件/软件解决方案。

设备实现如要与 Android 4.0 兼容：
必须符合本兼容性定义中所列的各项要求，包含任何通过参考所引用的文档。

必须通过该设备实现的软件完成时可用的最新版本“Android 兼容性测试套件（CTS）” 测试。

（CTS 作为Android 开源项目[参考, 2]的一部分提供。

）许多CTS 测试组件，但不是所有的，在此文档中有概述。

因为此兼容性定义或者 CTS 未提及，存在歧义，或者未完成，设备实现者有责任保证与现有实现的兼容性。

因为这个原因，Android 开源项目[参考, 3]提供一种参考，同时也是一种首选的 Android 实现。

强烈鼓励设备实现者将他们的实现基于来自 Android 开源项目“从下往上”的源代码。

一些组件有可能用其他实现替代，这种做法是强烈不推荐的，因为通过 CTS 测试将会变得相当困难。

实现者有责任保证与标准Android 实现在行为上的完全兼容，包括但不限于 CTS。

最后，要注意某些组件的替代和变更是本文档所明确禁止的。

2. 参考
1.IETF RFC2119 Requirement Levels: /rfc/rfc2119.txt
2. Android Compatibility Program Overview: /compatibility/index.html
3. Android Open Source Project: /
4. API definitions and documentation: /reference/packages.html
5. Android Permissions reference:
/reference/android/Manifest.permission.html
6. android.os.Build reference: /reference/android/os/Build.html
7. Android 4.0 allowed version strings: /compatibility/4.0/versions.html
8. Renderscript: /guide/topics/graphics/renderscript.html
9. Hardware Acceleration: /guide/topics/graphics/hardware-accel.html
10. android.webkit.WebView class: /reference/android/webkit/WebView.html
11. HTML5: /specs/web-apps/current-work/multipage/
12. HTML5 offline capabilities: /html5/spec/Overview.html#offline
13. HTML5 video tag: /html5/spec/Overview.html#video
14. HTML5/W3C geolocation API: /TR/geolocation-API/
15. HTML5/W3C webdatabase API: /TR/webdatabase/
16. HTML5/W3C IndexedDB API: /TR/IndexedDB/
17. Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs
18. AppWidgets: /guide/practices/ui_guidelines/widget_design.html
19. Notifications: /guide/topics/ui/notifiers/notifications.html
20. Application Resources: /android/reference/available-resources.html
21. Status Bar icon style guide:
/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
22. Search Manager: /reference/android/app/SearchManager.html
23. Toasts: /reference/android/widget/Toast.html
24. Themes: /guide/topics/ui/themes.html
25. R.style class: /reference/android/R.style.html
26. Live Wallpapers: /resources/articles/live-wallpapers.html
27. Android Device Administration: /guide/topics/admin/device-admin.html
28. android.app.admin.DevicePolicyManagerclass:
/reference/android/app/admin/DevicePolicyManager.html
29. Android Accessibility Service APIs:
/reference/android/accessibilityservice/package-
summary.html
30. Android Accessibility APIs:
/reference/android/view/accessibility/package-summary.html
31. Eyes Free project: /p/eyes-free
32. Text-To-Speech APIs: /reference/android/speech/tts/package-
summary.html
33. Reference tool documentation (for adb, aapt, ddms):
/guide/developing/tools/index.html
34. Android apk file description: /guide/topics/fundamentals.html
35. Manifest files: /guide/topics/manifest/manifest-intro.html
36. Monkey testing tool: /guide/developing/tools/monkey.html
37. Android android.content.pm.PackageManager class and Hardware Features List:
/reference/android/content/pm/PackageManager.html
38. Supporting Multiple Screens: /guide/practices/screens_support.html
39. android.util.DisplayMetrics: /reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration:
/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent:
/reference/android/hardware/SensorEvent.html
42. Bluetooth API: /reference/android/bluetooth/package-summary.html
43. NDEF Push Protocol: /compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: /documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: /documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: /documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: /documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: /documents/application_note/AN130511.pdf
49. MIFARE AN130411: /documents/application_note/AN130411.pdf
50. Camera orientation API:
/reference/android/hardware/Camera.html
#setDisplayOrientation(int)
51. android.hardware.Camera: /reference/android/hardware/Camera.html
52. Android Open Accessories: /guide/topics/usb/accessory.html
53. USB Host API: /guide/topics/usb/host.html
54. Android Security and Permissions reference:
/guide/topics/security/security.html
55. Apps for Android: /p/apps-for-android
56. android.app.DonloadManager class:
/reference/android/app/Do
wnloadManager.html
57. Android File Transfer: /filetransfer
58. Android Media Formats: /guide/appendix/media-formats.html
59. HTTP Live Streaming Draft Protocol: /html/draft-pantos-http-live-streaming-03
这些参考中许多是直接或间接来自 Android 4.0 SDK 的，并且在信息上与 SDK 中的文档功能对等。

假如此兼容性定义或者 CTS 与 SDK 文档有出入，那么 SDK 文档是权威的。

由以上这些参考提供的任何技术细节将视作对此兼容性定义补充的一部分。

3. 软件
Android 平台包括一套托管 API、一套本地 API，和一套所谓的“软”API 例如 Intent 系统和 web-application API。

这一节详细叙述一些对于兼容性至关重要的硬 API 和软 API，也包括某些其他相关的技术和用户接口行为。

设备实现者必须遵从本节中的所有要求。

3.1. 托管 API 兼容性
对于 Android 应用程序，托管（基于 Dalvik）执行环境是其主要承载。

Android 应用程序编程接口（API）是一套暴露给运行于托管 VM 环境应用程序的 Android 平台接口。

设备实现必须提供由 Android 4.0 SDK[参考, 4]暴露的任何成文 API 的完整的实现，包括所有成文的行为。

除非特别情况下有本兼容性定义的允许，设备实现绝不可以遗漏任何托管 API，变更 API接口或签名，偏离成文的行为，或者包括空操作。

对于Android包括被设备实现省略的APIs，此兼容性定义允许某些类型的硬件。

在这种情况下，APIs必须仍然以合理的方式存在或表现。

此节的特殊需求，请查看第 7节。

3.2. 软 API 兼容性
除了 3.1 节的托管 API，Android 同样包括一种重要的仅运行时的“软”API，他们以这些形式存在，诸如目的、权限等 Android 应用程序不能够在编译时被施行的方面。

这一节详细叙述 Android 4.0 兼容性所要求的“软”API 和系统行为。

设备实现必须符合本节中所有的这些要求。

3.2.1. 权限
设备实现者必须支持和施行由 Permission 参考页[参考, 5]所列的所有权限常量。

注意第10 节列出了与Android 安全模型相关的附
3.2.2. 生成参数
Android API 在类 android.os.Build 中包括一些用来描述当前设备的常量。

为了在跨设备实现方面提供一致的、有意义的值，下面的这张表格包括了这些值在设备实现上必须符合的附加格式限制。

3.2.3. Intent 兼容性
Android 通过 Intent 达到应用程序间耦合集成。

这一节描述设备实现必须兑呈的与Intent 模式相关的要求。

“兑呈”是指设备实现者必须提供指定了一个匹配的 Intent filter 的Android Activity 或 Service ，并且为每一个特定的 Intent 模式绑定和实现正确的行为。

3.2.3.1. 核心应用程序 Intents
Android 上游工程定义了一些核心应用程序，例如 phone dialer 、calendar 、contacts book 、music player 等等。

设备实现者可以用替代版本替代这些应用程序。

然而，任何这样的替代版本必须兑呈由上游工程提供的相同的 Intent 模式。

例如：一个设备包含一个替music player ，它仍须兑呈由第三方应用程序发布的 Intent 模式来
挑选一首歌曲。

下列应用程序被认为是核心 Android 系统应用程序： ●
Desk Clock
●Browser
●Calendar
●Contacts
●Gallery
●GlobalSearch
●Launcher
●Music
●Settings
核心Android系统应用程序包括多种被认为是“public”的Activity或Service组件。

也就是说，属性“android:exported”可能会缺失，或者可能拥有一个“true”值。

对在未通过 android:exported 属性值为 false 的被标识为 non-public 的核心 Android 系统应用程序中定义的每一个 Activity 或 Service，设备实现必须包括一个相同类型的与作为核心
Android 系统应用程序实现了相同 Intent filter 模式的组件。

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

3.2.3.2.Intent 覆写
由于Android 是一个可扩展平台，设备实现者必须允许核心系统应用程序所定义的
Intent 模式被第三方应用程序所覆写。

上游 Android 开源项目允许这种做法；设备实现者绝
不可以为系统应用程序对这些 Intent 模式的使用附加特权，或者阻止第三方应用程序对这些
模式的绑定和取得控制。

特别地，此禁止规则包括但不限于禁止允许用户在处理相同 Intent
模式的多个应用程序间选择“Chooser”用户接口。

3.2.3.3.Intent 命名空间
设备实现绝不可以包括任何使用 ACTION、CATEGORY 或其他在 android.*命名空间下
关键字符串兑呈了任何新 Intent 或 Broadcast Intent 模式的 Android 组件。

设备实现者绝不
可以包括任何使用 ACTION、CATEGORY 或其他在属于其他组织的包空间下的关键字符串兑呈
了任何新 Intent 或 Broadcast Intent 模式的 Android 组件。

设备实现者绝不可以变更或扩展任何在3.2.3.1 节中列出的被核心应用程序使用的 Intent 模式。

此禁止规则可类比于在 3.6 节中所明确的 Java 语言类禁止规则。

3.2.3.
4.Broadcast Intents
第三方应用程序依赖于平台来广播某些Intent以通知它们软硬件环境的改变。

Android
兼容设备必须广播这些公共广播Intent，对适当的系统事件做出反应。

Broadcast Intent在SDK
文档中有描述。

3.3.本地API兼容性
3.3.1.应用程序二进制接口
Dalvik 中运行的托管代码能够调用应用程序.apk 文件中提供的为相应的设备硬件架构所编译的 ELF 格式.so 文件中的本地代码。

因为本地代码高度依赖于底层的处理器技术，Android在NDK的DOCS / CPU-ARCH-ABIS.txt文件中，定义了一些应用程序二进制接口（ABI）。

如果一个设备实现兼容一个或多个ABIs，它应该实现与Android NDK的兼容性，如下：
如果一个设备实现包含对Android ABI的支持，它：
●设备实现必须包括对在托管环境中使用标准 Java 本地接口（JNI）语义调用本地代码的支持。

●必须和下表中要求的语言是源代码兼容（也即：头文件兼容）和二进制兼容（对于应用程序二进制接
口）的。

●设备实现必须通过 API 中 android.os.Build.CPU_ABI 准确地报告本地应用程序二进制接口
（ABI）在本设备的支持情况。

●ABI 必须是最新版本 Android NDK 位于 docs/CPU-ARCH-ABIS.txt
●必须使用在上游的Android开源项目中的源代码和头文件建立
下列 API 必须对本地代码可用：
●
l ibc (C 库)
●
l ibm (数学库)
●
J NI interface
●
l ibz (Zlib 压缩)
●
l iblog (Android log 机制)
●
M inimal support for C++
●libdl(dynamic linker)
●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 audio support) libOpenMAXAL.so
(OpenMAX AL 1.0.1 audio support)
●
l ibandroid.so (native Android activity support)
●
对 OpenGL 的支持，如下面所描述的
注意 Android NDK 的附加发布版本有可能为附加 ABI 引入支持。

做到本地代码兼容具有一定的挑战性。

正因为此，必须强调非常强烈地鼓励设备实现者对上面所列的各个库使用上游实现，以保证兼容性。

3.4. Web 兼容性
3.4.1 WebView的兼容性
许多开发者和应用程序对于他们的用户界面依赖于android.webkit.WebView类的行为所以 WebView 的实现必须是跨 Android 实现兼容的。

Android 开源实现使用了 WebKit 渲染引擎来实现 android.webkit.WebView。

因为对一个web浏览器开发一个广泛的测试套件是不可行的，设备实现者必须使用
WebView 实现中 WebKit 的特定上游 build。

特别地：
●对于Android 4.0，设备实现的android.webkit.WebView 必须使用来自上游Android开源代码树的build
号为534.30 的WebKit。

此build 包含了一套具体的针对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) string 字符串的值必须与 android.os.Build.ID 的值相同
WebView组件应该包括对HTML5尽可能多的支持[参考，11]。

至少，设备的实现必须支持WebView中每一个与 HTML5有关的API：
●应用程序缓存/脱机操作[参考，12]
●<video>标签[参考，13]
●地理位置[参考，14]
此外，设备实现必须支持的HTML5/W3C 网络存储的API[参考，15]，并应支持HTML5/W3C 本地数据库的
API[参考，16]。

请注意，因为Web开发标准机构，转向喜欢通过网络存储来实现本地数据库，本地数据库标准有望成为在未来的Android版本所需的组件。

像所有的JavaScript语言的 API一样，HTML5的APIs必须在WebView中默认禁用，除非开发者通过一般的Android APIs明确的解禁他们。

3.4.2浏览器兼容性
设备实现必须包括独立的浏览器应用程序，为广大用户浏览网页。

独立的浏览器可能是基于不同于WebKit的浏览器技术。

然而，即使使用替代浏览器的应用程序，提供给第三方应用程序的android.webkit.WebView组件必须基于WebKit，如3.4.1节所述。

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

独立的浏览器应用程序（无论是基于上游 WebKit 的浏览器应用程序或者第三方替代者）应尽可能多的包括对HTML5的支持[参考，11]。

至少，设备的实现必须支持WebView中每一个与 HTML5有关的API：
●应用程序缓存/脱机操作[参考，12]
●<video>标签[参考，13]
●地理位置[参考，14]
此外，设备实现必须支持的HTML5/W3C 网络存储的API[参考，15]，并应支持HTML5/W3C 本地数据库的
API[参考，16]。

请注意，因为Web开发标准机构，转向喜欢通过网络存储来实现本地数据库，本地数据库标准有望成为在未来的Android版本所需的组件。

3.5. API 行为兼容性
每一种 API 类型（托管的，软的，本地的和 web）的行为必须与上游 Android 开源项目
[参考, 3]推荐的实现所一致。

一些特定的兼容性方面如下：
●设备绝不可以改变标准Intent的行为或意义
●设备绝不可以变更某个特定类型的系统组件的生命周期或生命周期语义
●设备绝不可以改变某个特定的权限语义
上面的列表并不是完整，设备实现者有责任确保行为兼容性。

由于这个原因，设备实现者应该尽可能使用通过Android开源项目获得的源代码，而不是重新实现了系统重要部分的源代码。

在行为兼容性方面，兼容性测试套件（CTS）可以测试平台中某些重要部分，但不是全部。

实现者有责任确保与Android开源项目的行为兼容性。

3.6. API 命名空间
Android 遵从由 Java 编程语言定义的下列包和类的命名空间习惯。

为确保与第三方应用
程序的兼容性，设备实现者绝不可以对这些包命名空间做禁止的修改（见下）。

●java.*
●javax.*
●sun.*
●android.*
●com.android.*
禁止的修改包括：
●设备实现绝不可以以改变任何方法或类签名，或者删除类或类字段的方式，修改
Android平台上暴露的公有API。

●设备实现者可以修改API基础实现，但这样的修改绝不可以影响到已暴露的公有API 的状态行为和
Java语言签名。

●设备实现者绝不可以向上面所述的API添加任何暴露的公有元素（例如类或接口，或者现存类或接口的
字段或方法）
“暴露的公有元素”是指上游Android源代码中未经“@hide”标记修饰的任何组成。

换而言之，设备实现者绝不可以在上面提到的命名空间中暴露新的API或者变更现有的API。

设备实现者可以做仅内部的修改，但那些修改绝不可以被公布或者以其他的方法暴露给开发者。

设备实现者可以添加自定义的API，但任何这样的AP I绝不可以出现在一个被该命名空间所有或属于另一个组织的命名空间中。

举一个实例，设备实现者绝不可以添加API到
com.google.*或者相类似的命名空间；只有Google可以这样做。

同样，Google绝不可以添加
API到其他公司的命名空间。

如果一个设备实现者打算改善上面提到的其中一个包命名空间（例如添加有用的新功能
到一个现有的API，或者添加一个新的API），那么实现者应该访问并且根
据此网站上的信息开始贡献这些更改和代码。

应该注意到上面这些限制是与Java编程语言中的API命名标准习惯所一致的；本节仅只在
强调那些习惯并使它们贯穿于整个兼容新定义之中。

3.7. 虚拟机兼容性
设备实现必须完整支持 Dalvik 可执行字节码（DEX）规范和 Dalvik 虚拟机语义[参考,17]。

为了跟上游的Android平台保持一致，设备实现必须按照下表的规定安装虚拟机分配内存。

（关于屏幕大小和屏幕密度，请查看Section 7.1.1）
注意：下表中规定的内存值，考虑的都是最小值。

设备实现可以为每个应用程序分配更多的内存大小。

3.8. 用户界面兼容性
Android 平台包括一些开发者 API，以允许开发者连接到系统用户界面。

设备实现必须
将这些标准UI API纳入他们开发的自定义用户界面中，如下面所述。

3.8.1. Widgets
Android 定义了一个组件类型和相应的 API 和生命周期以允许应用程序为最终用户暴露一个“AppWidget”[参考, 18]。

Android 开源代码的参考发布包括一个 Launcher 应用程序，它包含一个用户界面元素允许用户向（从）主屏幕添加、查看和删除 AppWidget。

设备实现可以提供一个此参考 Launcher（即：主屏幕）的可替代版本。

此可替代Launcher 应该包括对AppWidget 的内建支持，并暴露用户界面元素从而可以直接在 Launcher内添加、配置、查看和删除AppWidget。

此可替代 Launcher 可以忽略这些用户界面元素；然而，如果他们被忽略，设备实现者就必须提供一个独立的可从 Launcher 访问的应用程序以允许用户来添加、配置、查看和删除 AppWidget。

设备实现必须有能力渲染4x4标准网格尺寸的窗口小部件。

（有关细节请查看Android SDK里的窗体小部件设计指引[参考, 18]）
3.8.2. 通知
Android 包括一些 API 以允许开发者来通知用户一些通知性质的事件[参考, 19]。

一些API允许多个应用程序可以执行通知或吸引注意,使用硬件,特别是声音、振动、和光线。

设备实现必须支持SDK文档中描述的使用硬件功能的通知。

例如,如果一个设备实现包括一个振动器,它必须正确地贯彻振动的api。

如果一个设备实施缺乏硬件,相应的api必须执行no-ops。

注：此功能在第7节中有详细说明。

另外，实现必须正确渲染API[参考, 20]中或者状态栏图标风格指南[参考, 21]中要求提供的所有资源（图标、声音文件等等）。

设备实现者可以提供一个通知方面的可替代的用户体验，而不用Android开源代码实现的参考体验；然而，这样的可替代通知系统必须支持如上
所述的现有的通知资源。

Android的4.0包括支持丰富的通知，如交互式查看正在进行的通知。

像在Android API中记录的一样，设备实现必须正确显示和执行丰富的通知。

3.8.3. 搜索
Android 包括一些 API [参考, 22]，允许开发者将搜索纳入他们的应用程序之中，并将他们应用程序的数据导出到全局系统搜索。

通常来说，此功能由一个单一的、泛系统域用户界面组成，以允许用户键入查询请求、以用户的方式显示建议并显示搜索结果。

Android API允许开发者复用此界面来在他们自己的应用程序中提供搜索，并允许开发者将结构提供给常规全局搜索用户界面。

设备实现必须包括一个单一的、共享的、泛系统域的可对用户输入提供实时建议的搜索用户界面。

设备实现必须实现允许开发者复用此用户界面的 API 以在他们自己的应用程序中提供搜索。

设备实现者必须实现允许第三方应用程序当其运行于全局搜索模式时向搜索框添加建议的 API。

如果没有安装利用此功能的第三方应用程序，则缺省行为应该是显示 web 搜索引擎结果和建议。

设备实现可以封装可替代的搜索用户界面，但应该包括一个专用的硬件或软件搜索按钮，为的是可以在任
意时间在任意应用程序中使用以通过 API 文档中提供的行为调用搜索框架。

3.8.
4. Toasts
应用程序能够使用“Toasts”API（在[参考, 23]中有定义）来向最终用户显示非强制响应字符串，其在一小段时间后会消失。

对于最终用户的某些高可见性要求，设备实现必须显示Toasts。

3.8.5.主题
Android为应用程序在整个活动或应用中的应用样式，提供了一个作为机制的“主题。

Android 3.0的推出了一个新的“河洛”或“全息”的主题。

如果应用程序开发人员想要匹配Android SDK中定义的“河洛”主题的外观和感觉，它可以作为一组定义的样式使用。

[参考24]设备实现必须不能改变任何的暴露给应用程序的“河洛”主题的属性。

[参考25]
Android 4.0推出一个新的设备默认的主题，如果应用程序开发人员想要匹配设备实现者定义的外观和感觉，它可以作为一组定义样式使用。

设备实现可以修改暴露给应用程序的设备默认属性主题。

[参考25]
3.8.6. LiveWallpapers生动的壁纸
Android定义了一个组件类型和相应的API及生命周期，其可允许应用程序向最终用户暴露一个或多个“Live Wallpaper”[参考,26]。

Live Wallpaper是具有有限输入能力的动画、图案或者类似的图形，作为一张壁纸来在其他应用程序背后显示。

如果硬件能够以没有功能上限制地、以合理的帧率、不对其他应用程序产生不利影响地运行各种壁纸，那么它就被认为是可以可靠运行Live Wallpaper的。

如果硬件上的限制导致壁纸和/或应用程序崩溃、故障、过度消耗CPU或电池电力，或者以一种不可接受的低帧率运行，那么这个硬件就被认为是不能够运行Live Wallpaper的。

举一个例子，某些壁纸可能使用
OpenGL 1.0或2.0上下文来渲染其内容。

Live Wallpaper在不支持多OpenGL上下文的硬件上运
行是不可靠的，因为Live Wallpaper使用OpenGL上下文有可能会与其他同样使用OpenGL上下
文的应用程序相冲突。

如上所述的能够可靠运行Live Wallpaper的设备实现应该实现Live Wallpaper功能。

设备实
现不能可靠运行Live Wallpaper的，绝不可以实现Live Wallpaper功能。

3.8.7 最近的应用程序显示
上游的Android4.0的源代码包含一个用户界面来显示最近使用的应用程序。

此用户界面用了一个用户最后离开应用程序时状态的缩略图。

设备实现可以改变或消除这种用户界面，但是，未来版本的Android计划更广泛的使用这一功能。

设备实现强烈鼓励使用上游Android4.0用户界面（或类似的基于缩略图的接口），否则可能不兼容未来版本的Android系统。

3.8.8.输入管理设定
Android4.0包括对输入管理引擎的支持。

Android4.0 API允许客户应用程序输入法指定用户可调设置。

设备实现必须包括用户访问时，它提供诸如用户设置了一个IME显示输入法设置方式。

当现实输入法提供用户设定时，设备实现必须一直包含一个处理输入法设定的方式。

3.9 设备管理
Android4.0包含允许保密应用程序执行系统级的设备管理功能，如通过Android设备管理API，密码政策执行或执行远程擦除 [参考，27]设备的实现必须提供一个DevicePolicyManager的功能。

[参考，28]，并应支持全方位的Android SDK文件中定义的设备管理功能。

[参考，27]
如果设备实现不支持全系列的设备管理政策，他们不能让设备管理应用程序启用。

具体来说，如果设备不支持所有设备的管理政策，该设备实现必须响应
android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN的意图，但必须显示一条消息，通知用户该设备不支持设备管理。

3.10无障碍性
Android4.0提供了一个辅助层，帮助残疾人的用户更方便地使用他们的设备。

此外，Android4.0提供平台的API，使无障碍服务装置接受用户和系统事件的回调，并产生交替的反馈机制，如文本到语音，触觉反馈，轨迹球/ D-垫导航[参考，29] 。

设备实现必须提供一个和Android默认装置一致的Android无障碍框架装置。

具体来说，设备实现必须满足以下要求。

●设备实现必须支持第三方辅助服务实现，通过Android.辅助服务API的[参考，30]
●设备实现必须产生辅助事件和传递这些信息给到所有注册过的辅助服务装置，用和Android默认装置
一致的方。

●设备实现必须提供一个用户访问机制启用和禁用无障碍服务，必须显示此接口去响应
android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS的意图。

此外，设备实现应该提供一个无障碍服务装置，应该在安装过程中为用户提供一种辅助服务机制。

一个开源无障碍服务是从Eyes Free project中可获得的。

[参考，31]。

3.11文本转语音
Android4.0包含的API，允许应用程序使用文本到语音（TTS）服务，允许服务供应商提供的TTS服务 [参考，32]。

设备实现者必须满足这些相关的Android TTS框架下要求：
●设备实现必须支持的Android TTS框架的API，并应包括TTS引擎，支持设备上可用的语言。

需要注意
的是上游的Android开源软件包括一个全功能的TTS引擎的装置。

●设备实现必须支持安装第三方TTS引擎。

●设备实现必须提供一个用户可访问的接口，使用户能够在系统级选择TTS引擎的使用。

4. 应用程序包兼容性
设备实现必须安装和运行由官方Android SDK中所包含的“aapt”工具生成的Android“.apk”文件[参考, 33]。

设备实现绝不可以扩展无论是.apk文件[参考, 34],、Android Manifest[参考, 35],、或者是Dalvik 字节码[参考,17]格式，阻止这些文件在其他相容设备上正确安装和运行。

设备实现者应该使用Dalvik的参考上游实现和包管理系统的参考实现。

5. 多媒体兼容性
设备实现必须包括至少一个音频输出形式，如扬声器，耳机插孔，外置扬声器连接等。

5.1. 多媒体解码器
设备实现必须支持Android SDK文件中规定的核心多媒体格式，除非在此文档中有明确的规定。

具体来说，设备的实现必须支持的多媒体格式，编码器，解码器，文件类型，容器格式如在下面的表中定义的。

所有这些编解码器都是以来自 Android 开源项目的首选 Android 实现中的软件实现方式提供的。

请注意，无论是Google或者Open Handset Alliance，都不代表这些编解码器不受第三方专利的制约。

打算在软硬件产品中使用此源代码，都被告知使用此代码，包括开源软件或共享软件，可能需要从相关的专利持有者手中获得专利许可。

注意下面的表格没有列出对大多数视频编解码器的特定比特率要求。

这是因为在实践
中，当前设备硬件不一定要支持绝对符合相关标准规定的比特率。

反而，设备实现应该支持该硬件由标准限定。