Android 2.1 Compatibility Definition 中文版 - Android 2.1 兼容性定义

Android 2.1 兼容性定义

版权所有 © 2010, Google Inc. 保留所有权利.

compatibility@android.com

 

中文翻译：Jack Yu          (yjmjack@gmail.com)

1.       简介

此文档列举了对于手机兼容Android 2.1版所必须依次符合的要求。

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

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

设备实现如要与Android 2.1兼容：

必须符合本兼容性定义中所列的各项要求，包含任何通过参考所引用的文档。

必须通过该设备实现的软件完成时可用的最新版本“Android兼容性测试套件（CTS）”测试。（CTS作为Android开源项目[Resources, 2]的一部分提供。）许多CTS测试组件，但不是所有的，在此文档中有概述。

因为此兼容性定义或者CTS未提及，存在歧义，或者未完成，设备实现者有责任保证与现有实现的兼容性。因为这个原因，Android开源项目[参考, 3]提供一种参考，同时也是一种首选的Android实现。强烈鼓励设备实现者将他们的实现基于来自Android开源项目“从下往上”的源代码。一些组件有可能用其他实现所替代，这种做法是强烈不推荐的，因为通过CTS测试将会变得相当困难。实现者有责任保证与标准Android实现在行为上的完全兼容，包括但不限于CTS。最后，要注意某些组件的替代和变更是本文档所明确禁止的。

2.       参考

1.       IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt

2.       Android Compatibility Program Overview: http://source.android.com/compatibility/index.html

3.       Android Open Source Project: http://source.android.com/

4.       API definitions and documentation: http://developer.android.com/reference/packages.html

5.       Android Permissions reference: http://developer.android.com/reference/android/Manifest.permission.html

6.       android.os.Build reference: http://developer.android.com/reference/android/os/Build.html

7.       Android 2.1 allowed version strings: http://source.android.com/compatibility/2.1/versions.xhtml

8.       android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html

9.       HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

10.   Dalvik Virtual Machine specification: available in the Android source code, atdalvik/docs

11.   AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

12.   Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

13.   Application Resources: http://code.google.com/android/reference/available-resources.html

14.   Status Bar icon style guide: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

15.   Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

16.   Toasts: http://developer.android.com/reference/android/widget/Toast.html

17.   Live Wallpapers: http://developer.android.com/resources/articles/live-wallpapers.html

18.   Apps for Android: http://code.google.com/p/apps-for-android

19.   Reference tool documentation (for adb, aapt, ddms):http://developer.android.com/guide/developing/tools/index.html

20.   Android apk file description: http://developer.android.com/guide/topics/fundamentals.html

21.   Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

22.   Monkey testing tool: http://developer.android.com/guide/developing/tools/monkey.html

23.   Supporting Multiple Screens: http://developer.android.com/guide/practices/screens_support.html

24.   android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

25.   android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

26.   android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html

27.   Sensor coordinate space: http://developer.android.com/reference/android/hardware/SensorEvent.html

28.   Android Security and Permissions reference: http://developer.android.com/guide/topics/security/security.html

29.   Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

这些参考中许多是直接或间接来自Android 2.1 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 2.1 SDK[参考, 4]暴露的任何成文API的完整的实现，包括所有成文的行为。

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

3.2.      软API兼容性

除了3.1节的托管API，Android同样包括一种重要的仅运行时的“软”API，他们以这些形式存在，诸如Intent、权限等Android应用程序不能够在编译时被施行的方面。这一节详细叙述Android 2.1兼容性所要求的“软”API和系统行为。设备实现必须符合本节中所有的这些要求。

3.2.1.   权限

设备实现者必须支持和施行由Permission参考页[参考, 5]所列的所有权限常量。注意第10节列出了与Android安全模型相关的附加要求。

3.2.2.   生成参数

Android API在类android.os.Build中包括一些用来描述当前设备的常量。为了在跨设备实现方面提供一致的、有意义的值，下面的这张表格包括了这些值在设备实现上必须符合的附加格式限制。

参数	注释
android.os.Build.VERSION.RELEASE	人类可读格式的当前所正在执行的Android系统版本。这个字段必须有一个在[参考, 7]中定义的字符串值。
android.os.Build.VERSION.SDK	当前所正在执行的Android系统版本，供第三方应用程序获取的格式。对于Android 2.1，此字段必须为整型值7
android.os.Build.VERSION.INCREMENTAL	人类可读格式的由设备实现者选定的值，指定了当前正在执行的Android系统的特别build号。此值绝不可以被不同的build重复使用交付给用户。此字段一个典型的用途是用来指示使用了哪一个build号或源码控制改变识别码来产生此build。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.BOARD	人类可读格式的由设备实现者选定的值，用来鉴别设备使用的特定内部硬件。此字段一个可能的用途是用来指示设备所基于的板子的特定修正。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.BRAND	人类可读格式的由设备实现者选定的值，用来鉴别生产此设备的公司名称、组织、个人等。此字段一个可能的用途是用来指定OEM和/或销售此设备的承担者。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.DEVICE	一个由设备实现者选定的值，用来鉴别此设备机身（有时称为“工业设计”）特定的配置或修订。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.FINGERPRINT	一个唯一鉴别此build的字符串。它应该是人类合理可读的。它必须遵从下面的模板： $(BRAND)/$(PRODUCT)/$(DEVICE) /$(BOARD):$(VERSION.RELEASE)/$(ID) /$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 例如： acme/mydevice/generic/generic:2.1-update1/ERC77 /3359:userdebug/test-keys 指纹绝不可以包含空格。如果在上面模板中包含的其他字段中有空格，它们应该在指纹中被ASCII码下划线（“_”）字符替代。
android.os.Build.HOST	人类可读格式的一个唯一鉴别生成此build的主机的字符串。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.ID	人类可读格式的由设备实现者选定的值，用来引用一个特定的release。此字段可以与android.os.Build.VERSION.INCREMENTAL相同，但应该是一个对最终用户有足够意义的值，以在软件build间作区别。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.MODEL	一个由设备实现者选定的值，包含为最终用户所知的此设备的名称。它应该与此设备上市和销售到最终用户时是同一个名称。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.PRODUCT	一个由设备实现者选定的值，包含此设备的开发名称或者开发代号。必须是人类可读，但对于最终用户的可见与否不是必需的。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.TAGS	一个由设备实现者选择的以逗号分隔的标签列表，用来进一步区别build。例如，“unsigned,debug”此字段的格式没有特殊要求，除了绝不可以是空值或者空串。
android.os.Build.TIME	一个代表生成时的时间戳的值。
android.os.Build.TYPE	一个由设备实现者选定的值，给出了此build的运行时配置。根据Android运行时配置：“user”、“userdebug”或“eng”，此字段应该是这三种中的一个。
android.os.Build.USER	一个生成此build的用户（或自动用户）的名称或者用户ID。此字段的格式没有特殊要求，除了绝不可以是空值或者空串。

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系统应用程序：

l  Desk Clock

l  Browser

l  Calendar

l  Calculator

l  Camera

l  Contacts

l  Email

l  Gallery

l  GlobalSearch

l  Launcher

l  LivePicker （也就是说，如果设备不支持Live Wallpapers，Live Wallpaper picker应用程序可以被略去，依照3.8.5节）

l  Messaging （也即 “Mms”）

l  Music

l  Phone

l  Settings

l  SoundRecorder

核心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”用户接口。

注意：此节由勘误表EX6580作了修改。

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兼容性

在Dalvik中运行的托管代码能够调用应用程序.apk文件中提供的为相应的设备硬件架构所编译的ELF格式.so文件中的本地代码。设备实现者必须包括在托管环境中使用标准Java本地接口（JNI）语义调用本地代码的支持。下列API必须对本地代码可用：

l  libc (C库)

l  libm (数学库)

l  JNI interface

l  libz (Zlib压缩)

l  liblog (Android log机制)

l  Minimal support for C++

l  对OpenGL的支持，如下面所描述的

设备实现者必须支持OpenGL ES 1.0。缺乏硬件加速的设备必须使用软件渲染实现OpenGL ES 1.0。设备实现应该尽可能多的实现设备支持的OpenGL ES 1.1特性。设备实现应该提供OpenGL ES 2.0的实现，假如硬件对那些API有能力实现合理性能的话。

这些库必须对Android开源项目中Bionic所提供的版本是源代码兼容（也即：头文件兼容）和二进制兼容（对给定的处理器架构）的。因为Bionic的实现不是完全兼容于比如其他GNU C库的实现，设备实现者应该使用Android 实现。如果设备实现者使用了一个这些库的不同实现，他们必须确保头文件、二进制和行为上的兼容。

设备实现必须通过API中android.os.Build.CPU_ABI准确地报告本地应用程序二进制接口（ABI）在本设备的支持情况。ABI必须是最新版本Android NDK位于docs/CPU-ARCH-ABIS.txt中所列条目中的一种。注意Android NDK的附加发布版本有可能为附加ABI引入支持。

做到本地代码兼容具有一定的挑战性。正因为此，必须强调设备实现者被非常强烈地鼓励对上面所列的各个库使用上游实现，以保证兼容性问题。

3.4.      Web API兼容性

许多开发者和应用程序对于他们的用户界面依赖于android.webkit.WebView类的行为[参考, 8]，所以WebView的实现必须是跨Android实现兼容的。Android开源实现使用了WebKit渲染引擎来实现WebView。

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

l  对于Android 2.1，WebView必须使用来自上游Android开源代码树种build号为530.17的WebKit。此build包含了一套对WebView的特定功能和安全修补。

l  由WebView报告的用户代理字符串必须是以下格式：

Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17

(KHTML, like Gecko) Version/4.0 Mobile Safari/530.17

²  $(VERSION)字符串的值必须与android.os.Build.VERSION.RELEASE的值相同

²  $(LOCALE) 字符串的值应该遵从ISO中对于国家代码和语言的约定，并应该关联至当前设备的本地配置

²  $(MODEL) 字符串的值必须与android.os.Build.MODEL的值相同

²  $(BUILD) string字符串的值必须与android.os.Build.ID的值相同

实现可以在独立浏览器应用程序中封装一个自定义的用户代理字符串。不仅如此，这个独立浏览器可以基于一个可替代的浏览器技术（例如Firefox、Opera等等。）然而，即使封装了一个可替代浏览器应用程序，对第三方应用程序提供的WebView组件必须是基于WebKit的，如上所述。

WebView配置必须包括对HTML5数据库、应用程序缓存和地理位置API [参考, 9]的支持。WebView必须包括对HTML5中<video>标签的某种形式上的支持。独立浏览器应用程序（无论是基于上游WebKit的浏览器应用程序或者第三方替代者）必须包括对WebView所列相同的HTML5特性的支持。

3.5.      API行为兼容性

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

l  设备绝不可以改变标准Intent的行为或意义

l  设备绝不可以变更某个特定类型的系统组件的生命周期或生命周期语义

l  设备绝不可以改变某个特定的权限语义

上面的列表并不是完整，设备实现者有责任确保行为兼容性。由于这个原因，设备实现者应该尽可能使用通过Android开源项目获得的源代码，而不是重新实现了系统重要部分的源代码。

兼容性测试套件（CTS）对于行为兼容性可以测试平台重要的部分，但不是全部。实现者有责任确保与Android开源项目的行为兼容性。

3.6.      API命名空间

Android遵从由Java编程语言定义的下列包和类的命名空间习惯。为确保与第三方应用程序的兼容性，设备实现者绝不可以对这些包命名空间做禁止的修改（见下）。

l  java.*

l  javax.*

l  sun.*

l  android.*

l  com.android.*

禁止的修改包括：

l  设备实现绝不可以以改变任何方法或类签名，或者删除类或类字段的方式，修改Android平台上暴露的公有API。

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

l  设备实现者绝不可以向上面所述的API添加任何暴露的公有元素（例如类或接口，或者现存类或接口的字段或方法）

“暴露的公有元素”是指上游Android源代码中未经“@hide”标记修饰的任何组成。换而言之，设备实现者绝不可以在上面提到的命名空间中暴露新的API或者变更现有的API。设备实现者可以做仅内部的修改，但那些修改绝不可以被公布或者以其他的方法暴露给开发者。

设备实现者可以添加自定义的API，但任何这样的的API绝不可以出现在一个被该命名空间所有或属于另一个组织的命名空间中。举一个实例，设备实现者绝不可以添加API到com.google.*或者相类似的命名空间；只有Google可以这样做。同样，Google绝不可以添加API到其他公司的命名空间。

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

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

3.7.      虚拟机兼容性

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

设备实现必须配置Dalvik以为设备上的具有中或低屏幕密度的每个应用程序分配至少16MB内存。设备实现必须配置Dalvik以为设备上的具有高屏幕密度的每个应用程序分配至少24MB内存。注意，设备实现可以分配比此数字更多的内存，但不是必需的。

3.8.      用户界面兼容性

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

3.8.1.   Widgets

Android定义了一个组件类型和相应的API和生命周期以允许应用程序为最终用户暴露一个“AppWidget”[参考, 11]。Android开源代码的参考发布包括一个Launcher应用程序，它包含一个用户界面元素允许用户向（从）主屏幕添加、查看和删除AppWidget。

设备实现者可以提供一个此参考Launcher（即：主屏幕）的可替代版本。此可替代Launcher应该包括对AppWidget的内建支持，并暴露用户界面元素从而可以直接在Launcher内添加、配置、查看和删除AppWidget。此可替代Launcher可以忽略这些用户界面元素；然而，如果他们被忽略，设备实现者就必须提供一个独立的可从Launcher访问的应用程序以允许用户来添加、配置、查看和删除AppWidget。

3.8.2.   通知

Android包括一些API以允许开发者来通知用户一些通知性质的事件[参考, 12]。设备实现者必须为每个已定义的通知类型提供支持；特别是：声音、振动、光线和状态栏。

另外，实现必须正确渲染API[参考, 13]中或者状态栏图标风格指南[参考, 14]中要求提供的所有资源（图标、声音文件等等）。设备实现者可以提供一个通知方面的可替代的用户体验，而不用Android开源代码实现的参考体验；然而，这样的可替代通知系统必须支持如上所述的现有的通知资源。

3.8.3.   搜索

Android包括一些API [参考, 15]，允许开发者将搜索纳入他们的应用程序之中，并将他们应用程序的数据导出到全局系统搜索。通常来说，此功能由一个单一的、泛系统域用户界面组成，以允许用户键入查询请求、以用户的方式显示建议并显示搜索结果。Android API允许开发者复用此界面来在他们自己的应用程序中提供搜索，并允许开发者将结构提供给常规全局搜索用户界面。

设备实现必须包括一个单一的、共享的、泛系统域的可对用户输入提供实时建议的搜索用户界面。设备实现必须实现允许开发者复用此用户界面的API以在他们自己的应用程序中提供搜索。设备实现者必须实现允许第三方应用程序当其运行于全局搜索模式时向搜索框添加建议的API。如果没有安装利用此功能的第三方应用程序，则缺省行为应该是显示web搜索引擎结果和建议。

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

3.8.4.   Toasts

应用程序能够使用“Toasts”API（在[参考, 16]中有定义）来向最终用户显示非强制响应字符串，其会在一小段时间后会消失。对于最终用户的某些高可见性要求，设备实现必须显示Toasts。

3.8.5.   LiveWallpapers

Android定义了一个组件类型和相应的API及生命周期，其可允许应用程序向最终用户暴露一个或多个“Live Wallpaper”[参考,17]。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功能。

4.       参考软件兼容性

设备实现必须用下列开源应用程序测试实现的兼容性：

l  Calculator （包含在SDK中）

l  Lunar Lander（包含在SDK中）

l  “Apps for Android”应用程序 [参考, 18]。

为了认定实现是兼容的，上述的每个应用程序在实现上都必须启动且行为正常。

不仅如此，设备实现必须测试下面这些smoke-test（译者注：冒烟测试，一种测试方法。）应用程序中的每一个菜单项（包括所有的子菜单）：

l  ApiDemos（包含在SDK中）

l  ManualSmokeTests （包含在SDK中）

在设备实现上，上面每一个应用程序测试案例中都必须正确运行。

5.       应用程序包兼容性

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

设备实现绝不可以扩展无论是.apk文件[参考, 20],、Android Manifest[参考, 21],、或者是Dalvik字节码[参考, 10]格式，阻止这些文件在其他相容设备上正确安装和运行。设备实现者应该使用Dalvik的参考上游实现和包管理系统的参考实现。

6.       多媒体兼容性

设备实现必须支持下列多媒体编解码器。所有这些编解码器都是以来自Android开源项目的首选Android实现中的软件实现方式提供的。

请注意，无论是Google或者Open Handset Alliance，都不代表这些编解码器不受第三方专利的制约。打算在软硬件产品中使用此源代码，都被告知实现此代码，包括开源软件或共享软件，可能需要从相关的专利持有者手中获得专利许可。

音频	名称	编码器	解码器	详细细节	文件/容器格式
	AAC LC/LTP		X	单声道/立体声 以任何组合的比特率 最高支持到160 kbps 采样率在8至48kHz间	3GPP (.3gp) and MPEG-4 (.mp4, .m4a). No support for raw AAC (.aac)
	HE-AACv1 (AAC+)		X
	HE-AACv2 (增强 AAC+)		X
	AMR-NB	X	X	4.75至12.2 kbps 采样@ 8kHz	3GPP (.3gp)
	AMR-WB		X	9速率从6.60kbit/s 到23.85kbit/s 采样@16kHz	3GPP (.3gp)
	MP3		X	单声道/立体声 8-320Kbps 常值(CBR)或 变比特率(VBR)	MP3 (.mp3)
	MIDI		X	MIDI 类型0与1。 DLS版本1与2。 XMF和Mobile XMF。 支持铃音格式 RTTTL/RTX, OTA, 与iMelody	类型0与1 (.mid, .xmf, .mxmf)。 和RTTTL/RTX (.rtttl, .rtx), OTA (.ota),与 iMelody (.imy)
	Ogg Vorbis		X		Ogg (.ogg)
	PCM		X	8位与16位 线性PCM (速率以硬件能力为准)	WAVE (.wav)
图片	JPEG	X	X	base+progressive
	GIF		X
	PNG	X	X
	BMP		X
视频	H.263	X	X		3GPP (.3gp)文件
	H.264		X		3GPP (.3gp) 和 MPEG-4 (.mp4)文件
	MPEG4 Simple Profile		X		3GPP (.3gp) 文件

注意上面的表格没有列出对大多数视频编解码器的特定比特率要求。这是因为在实践中，当前设备硬件不需要支持与要求的相关标准的特定比特率绝对相符的比特率。反而，设备实现应该支持该硬件由标准限定的实际上的最高比特率。

7.       开发工具兼容性

设备实现必须支持由Android SDK提供的Android Developer Tools，Android兼容设备必须与下列工具兼容：

l  Android Debug Bridge (也就是常说的adb) [参考, 19]

设备实现必须支持所有Android SDK中成文的adb功能。设备一边的adb守护进程应该默认是非活动的。但必须有一个用户可访问的机制来打开Android Debug Bridge。

l  Dalvik Debug Monitor Service (也就是常说的ddms) [参考, 19]

设备实现必须支持所有Android SDK中成文的ddms特性。因为ddms使用adb，对ddms的支持应该是默认非活动的，但必须在当用户激活Android Debug Bridge时开始提供支持。

l  Monkey [参考, 22]

设备实现必须包括Monkey框架，并使其对应用程序可用。

8.       硬件兼容性

Android被设计为支持设备实现者创造创新型要素和配置。同时Android开发者在各种Android设备上期望某些硬件、传感器和API。本节列出了所有Android 2.1兼容设备都必须支持的硬件特性。

如果一个设备包括一个拥有对第三方开发者相应API的特定硬件组件，设备实现必须按照Android SDK文档中定义的去实现那些API。

如果SDK中一个API与一个状态是可选的硬件组件交互，且此设备实现并不具有那个组件：

l  该组件API的类定义必须存在

l  API的行为必须以某种合理的方式实现空操作

l  API方法必须返回SDK文档允许的空值

l  当空值不被SDK文档许可时，API方法必须返回类的空操作实现

一个典型的例子是这样一个场景，将这个要求应用到电话API上：甚至在非手机设备上这些API都必须被实现为合理的空操作。

设备实现必须通过android.content.pm.PackageManager类中的getSystemAvailableFeatures()和hasSystemFeature(String)方法精确报告精确的硬件配置信息。

8.1.      显示

Android 2.1包括一些设施用来在某些情况下执行某些自动缩放和转换操作，以确保第三方应用程序能够在多种硬件配置上良好合理地运行[参考,23]。设备必须正确实现这些行为，如本节所详述的。

对于Android 2.1，这是最通常的显示配置：

屏幕类型	宽度（像素）	高度（像素）	对角线长（英寸）	屏幕尺寸分组	屏幕密度分组
QVGA	240	320	2.6 – 3.0	小	低
WQVGA	240	400	3.2 – 3.5	普通	低
FWQVGA	240	432	3.5 – 3.8	普通	低
HVGA	320	480	3.0 – 3.5	普通	中
WVGA	480	800	3.3 – 4.0	普通	高
FWVGA	480	854	3.5 – 4.0	普通	高
WVGA	480	800	4.8 – 5.5	大	中
FWVGA	480	854	5.0 – 5.8	大	中

对应于上面这些标准配置中的一个的设备实现必须被配置为通过android.content.res.Configuration类[参考, 24]为应用程序报告明确的屏幕尺寸。

某些.apk包拥有的manifest不能提供识别其支持的特定屏幕密度范围。当运行此类应用程序时，需要应用下列约束：

l  设备实现必须将.apk包中缺少屏幕密度修饰符的资源转译为默认值“中”（即SDK文档中的“mdpi”）

l  当运行于一个“低”密度屏幕，设备实现必须以0.75为系数向下缩放屏幕密度为中/mdpi的物件

l  当运行于一个“高”密度屏幕，设备实现必须以1.5为系数向上缩放屏幕密度为中/mdpi的物件

l  设备实现绝不可以对处在某个屏幕密度范围中的物件进行缩放，并且必须在各种屏幕密度范围间缩放时使用上面所述的确切系数。

8.1.2. 非标准显示配置

与8.1.1节中列出的任意一个标准配置都不匹配的显示配置需要额外的考虑才能达到兼容工作。设备实现者必须与在第12节中提供的Android兼容性团队取得联系，以获得有关屏幕尺寸、屏幕密度和缩放系数的分类。一旦获得这些信息，设备实现必须按照要求进行实现。

注意到有一些显示配置（例如非常大或非常小的屏幕，以及某些屏幕纵横比）是与Android 2.1根本不兼容的；因此设备实现者在开发进程中被鼓励应尽早尽快地去主动联系Android兼容性团队。

8.1.3. 显示度量

设备实现必须为所有在android.util.DisplayMetrics [参考, 25]中定义的显示度量报告正确的值。

8.2.      键盘

设备实现：

l  必须包含在developer.android.com中详细说明的对Input Management Framework（其允许第三方开发者创建Input Management Engine——也即：软键盘）的支持

l  必须提供至少一个软键盘实现（无论实际上是否有物理键盘）

l  可以包含额外的软键盘实现

l  可以包含一个物理键盘

l  绝不可以包含与android.content.res.Configuration.keyboard [参考, 24]中要求的任何一个格式（也就是QWERT或者12-key键盘）都不匹配的物理键盘

8.3.      非触摸导航

设备实现：

l  可以忽略一个非触摸导航选项（也就是，可以忽略一个轨迹球、导航键、或者滚轮）

l  必须向android.content.res.Configuration.navigation [参考, 24]报告正确的值

8.4.      屏幕朝向

兼容设备必须支持应用程序的横竖屏动态朝向。也就是说，设备必须尊重应用程序的屏幕朝向要求。设备实现可以选择横屏或者竖屏中任一种作为默认朝向。

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

8.5.      触摸屏输入

设备实现：

l  必须有一个触摸屏

l  可以使用电容或电阻屏

l  必须以android.content.res.Configuration [参考, 24]中相应的值来反映当前设备屏幕的类型。

8.6.      USB

设备实现：

l  必须实现一个可用标准USB-A型口连接到一个USB主机的USB从机

l  必须在USB上实现Android Debug Bridge（在第7节中定义的）

l  必须实现USB大容量存储设备规范，以允许一个主机连接到设备来访问/sdcard卷中的内容

l  应该在设备端使用micro USB接口形式

l  可以在设备端包括一个非标准的接口，但如果这样做则必须封装一个可以连接此自定义接口到标准USB-A型接口的数据线

8.7.      导航键

主屏幕、菜单、回退功能对于Android导航规范来说是必须的。设备实现必须促使这些功能对用户始终可用，无论应用程序的状态。这些功能应该通过专门的按键实现。它们可以通过软件、手势、触摸板等等来实现，但假如这样做，则它们必须总是可用的并且在有效应用程序显示区域不能被妨碍或遮挡。

设备实现者同样应该提供一个专门的搜索键。设备实现者同样可以为手机电话提供拨打和挂断键

8.8.      无线数据网络

设备实现必须包括对无线高速数据网络的支持。特别地，设备实现必须包括至少一个速率在200Kbit/s以上的无线数据标准的支持。满足这个条件的技术包括EDGE, HSPA, EV-DO, 802.11g等等。

如果一个设备实现包含对Android SDK中所包含的一个API（也即WiFi，GSM，or CDMA）的一个特定形态，这个实现必须支持此API。

设备可以实现多于一个的无线数据链接形式。设备可以实现有线数据链接（例如以太网），但必须至少包含一个无线链接形式，如上所述。

8.9.      摄像头

设备实现必须包括一个摄像头。此摄像头：

l  像素必须至少在200万以上

l  应该有硬件自动对焦或在摄像头驱动程序中实现的软件自动对焦（对应用程序透明）

l  可以有固定焦距或EDOF（扩展景深）硬件

l  可以包含一个闪光灯。如果摄像头包含闪光灯，那么此闪光灯绝不可以在一个android.hardware.Camera.PreviewCallback的实例已在摄像头预览surface上注册时被点亮，除非应用程序明确地通过开启Camera.Parameters对象中的FLASH_MODE_AUTO或FLASH_MODE_ON属性来开启闪光灯。注意此约束并不应用到设备的内建系统摄像头应用程序中，而仅仅是应用到使用Camera.PreviewCallback的第三方应用程序上。

设备实现对于摄像头相关API必须实现下列行为：

1.         如果应用程序从未调用过android.hardware.Camera.Parameters.setPreviewFormat(int)，那么此设备必须使用android.hardware.PixelFormat.YCbCr_420_SP来作为向应用程序回调提供的预览数据。

2.         当预览格式为YCbCr_420_SP时如果应用程序注册了一个android.hardware.Camera.PreviewCallback的实例并且系统调用了onPreviewFrame()方法，传递到onPreviewFrame()方法的byte[]数组内的数据必须是NV21编码格式。（此格式被7k硬件族所本地使用。）也就是说，NV21必须是缺省的。

设备实现必须完全实现Android 2.1 SDK文档[参考, 26]中的摄像头API，无论设备是否包括硬件自动对焦或者其他功能特性。例如，缺少自动对焦功能的摄像头依然必须能够调用任何已注册的android.hardware.Camera.AutoFocusCallback实例（尽管这对与一个非自动对焦摄像头毫不相关。）

设备实现必须识别并兑呈在每个在android.hardware.Camera.Parameters类中作为常量定义的参数名称，如果所依赖的硬件支持此特性的话。如果设备硬件不支持某个特性，API的行为必须像文档中描述的那样。相反，除了那些在android.hardware.Camera.Parameters中的常量，设备实现绝不可以兑呈或识别传递到android.hardware.Camera.setParameters()方法中的字符串常量，除非这些常量是以该设备实现者名称作为前缀的字符串。也就是说，如果硬件允许的话，设备实现必须支持所有标准摄像头参数，并且绝不可以支持自定义摄像头参数类型，除非参数名称是明确以非标准字符串前缀标明的。

8.10.加速计

设备实现必须包括一个3轴的加速计并且必须能够以至少50Hz的频率交付事件。加速计使用的坐标系统必须遵从Android API（参见[参考, 27]）中规定的Android传感器坐标系统。

8.11.罗盘

设备实现必须包括一个3轴的罗盘并且必须能够以至少10Hz的频率交付事件。罗盘使用的坐标系统必须遵从Android API（参见[参考, 27]）中规定的Android传感器坐标系统。

8.12.GPS

设备实现必须包括一个GPS，并且应该包括一些“辅助GPS”（译者注：也就是常说的A-GPS）技术来使GPS定位所花的时间最短。

8.13.电话

Android 2.1可以被用于不包含电话硬件的设备上。也就是说，Android 2.1是与非手机类设备兼容的。然而，如果一个设备实现不包括GSM或CDMA电话，它仍必须对那些技术的API实现完整的支持。不包括电话硬件的设备实现必须以空操作实现完整的API。

参见8.8节，无线数据网络。

8.14.内存和存储

设备实现必须拥有至少92MB的可用内存提供给内核和用户空间。这92MB必须是除过任何专用于硬件组件的内存，例如无线电、内存等等不在内核控制之下的部分。

设备实现必须拥有至少150MB可用的非易失性存储介质来用于用户数据。也就是说，/data分区必须至少有150MB。

注意：此节由勘误表EX6580作了修改。

8.15.应用程序共享存储

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

设备实现必须用以默认“开箱即用”挂载的共享存储配置过。如果共享存储没有在Linux路径/sdcard上挂载，那么设备必须包括一个从/sdcard到实际挂载点的Linux符号链接。

设备实现必须在此共享存储上确保文档中强调的android.permission.WRITE_EXTERNAL_STORAGE权限。共享存储在任何应用程序获得此权限后必须是可写的。

设备实现可以拥有用户可访问的可移动存储硬件，例如SD卡。作为另一种选择，设备实现可以为应用程序分配内部（非可移动）存储作为共享存储。

无论共享存储使用的方式，共享存储必须实现USB大容量存储，如8.6节所述。当设备封装出厂时，共享存储必须以FAT文件系统挂载。

这里有两个常见例子。如果一个设备实现包括一个SD卡插槽来满足共享存储要求，则FAT格式的2GB SD卡或者更大容量的必须同设备一道销售给用户，并且必须缺省是已挂载好的。作为另一种选择，如果一个设备实现使用内部固定存储来满足此需求，那么存储介质的大小必须在2GB或以上且已挂载到/sdcard（或者/sdcard必须是一个到别处已挂载的物理位置的符号链接。）

注意：此节由勘误表EX6580作了修改。

8.16.蓝牙

设备实现必须包括一个蓝牙收发器。设备实现必须使能SDK文档[参考, 29]中所述的基于RFCOMM的蓝牙API。设备实现应该实现设备适合的相关的蓝牙标准，例如A2DP、AVRCP、OBEX等。

注意：此节由勘误表EX6580作了修改。

9.       性能兼容性

Android兼容性项目的一个目标就是使用户能有一致的用户体验。兼容的实现必须确保不仅应用程序能简单地在设备上正确运行，而且它们能有合理的性能与良好的综合用户体验。设备实现必须达到下表所定义的Android 2.1兼容设备关键性能度量标准：

度量标准	性能阈值	备注
应用程序启动耗时	下列应用程序应该在指定的时间内启动。 l  Browser：少于1300ms l  MMS/SMS：少于700ms l  AlarmClock：少于650ms	启动时间是以完成为应用程序加载默认activity的总计时间衡量的，这包括了它启动Linux进程、加载Android包到Dalvik VM和调用OnCreate函数的时间。
应用程序并发	当多个应用程序被启动，重新启动一个先前已启动过的、已经在运行的应用程序，所花费的时间应少于最初的启动时间。

10.         安全模型兼容性

设备实现必须实现与在Android开发者文档中安全和权限API参考文档[参考, 28]中定义的Android平台安全模型一致的一个安全模型。设备实现必须支持自签名应用程序的安装，而不需任何额外的来自任何第三方团体/作者的权限/许可。特别地，兼容设备必须支持下面小节中描述的安全机制。

10.1.权限

设备实现必须支持在Android开发者文档[参考, 28]中定义的Android权限模型。特别地，实现必须保障每个权限如同SDK文档中所描述的一样被定义；没有权限被遗漏、变更或忽略。实现可以添加额外的权限，提供的新权限ID字符串不在android.*命名空间中。

10.2.UID与进程隔离

设备实现必须支持Android应用程序沙箱模型，每个应用程序都以一个唯一的Unix风格的UID在一个独立的进程中运行。如安全与权限参考[参考, 28]中定义的，设备实现必须支持同时以相同的Linux用户ID运行多个应用程序，只要应用程序能被正确签名和构造。

10.3.文件系统权限

设备实现必须支持安全与权限参考[参考, 28]中定义的Android文件访问权限模型。

11.         兼容性测试套件

设备实现必须使最终封装出厂设备上的软件通过来自Android开源项目的Android兼容性测试套件（CTS）的测试。除此以外，设备实现者应该尽可能多的使用Android开源代码树中的参考实现，并且必须以防万一CTS出现歧义和参考代码任何部分重复实现，以确保兼容性。

CTS被设计为运行于实际设备上。如同任何软件一样，CTS自身也可能有bug。CTS将独立于本兼容性定义进行版本升级，并且可能会为Android 2.1发布多个版本的CTS。设备实现必须在设备软件完成时通过其时可用的最新版本CTS的测试。

12.         可升级软件

设备实现必须包括一种机制来替换整体系统软件。此机制不需要执行“live”升级——也就是说，设备有可以被要求重新启动。

只要能够整体替换预先安装在设备上的软件，任何方法都可以使用。例如，任何下列途径都是符合此要求的：

l  “空中下载”（OTA）与通过重新启动的脱机更新

l  通过USB接口从主机PC“系缆”更新

l  通过重新启动的“脱机”更新与从可移动存储上的一个文件进行更新

此更新机制必须支持不清除用户数据的更新。注意上游Android软件包括了一个符合此要求的更新机制。

如果一个设备实现在其发布后发现有错误，只要其还在合理的产品生命周期中，在与Android兼容性团队磋商后认为此问题会影响第三方应用程序的兼容性，那么此设备实现者必须通过应用一个由上述描述的机制可用的软件更新来修正此错误。

13.         与我们联系

你可以通过compatibility@android.com联系此文档的作者以获得澄清和提出任何你认为本文档没有涵盖的问题。

 

附录：Android 2.1兼容性定义，勘误表 EX6580

Android 2.1兼容性定义被此勘误表修正过，如下所列：

3.2.3.2节   Intent 覆写

 

3.2.3.2节对于Intent覆写的叙述被修改，删除了对已不存在的“附录A”的引用。修订后的内容如下。

由于Android是一个可扩展平台，设备实现者必须允许核心系统应用程序所定义的Intent模式被第三方应用程序所覆写。上游Android开源项目允许这种做法；设备实现者绝不可以为系统应用程序对这些Intent模式的使用附加特权，或者阻止第三方应用程序对这些模式的绑定和取得控制。特别地，此禁止规则包括但不限于禁止允许用户在处理相同Intent模式的多个应用程序间选择“Chooser”用户接口。

8.14节   内存和存储

 

8.14节（译者注：原文此处误作3.2.3.2节）内存和存储被修改，改正了对最小内部存储需求所提供的错误值。最小内部存储需求被向下修订了，从290MB降至150MB。修订后的内容如下。

设备实现必须拥有至少92MB的可用内存提供给内核和用户空间。这92MB必须是除过任何专用于硬件组件的内存，例如无线电、内存等等不在内核控制之下的部分。

设备实现必须拥有至少150MB可用的非易失性存储介质来用于用户数据。也就是说，/data分区必须至少有150MB。

8.15节   应用程序共享存储

8.15节是新添加的，为了明确现存的外部/内部存储需求。新添加的内容如下。

 

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

设备实现必须用以默认“开箱即用”挂载的共享存储配置过。如果共享存储没有在Linux路径/sdcard上挂载，那么设备必须包括一个从/sdcard到实际挂载点的Linux符号链接。

设备实现必须在此共享存储上确保文档中强调的android.permission.WRITE_EXTERNAL_STORAGE权限。共享存储在任何应用程序获得此权限后必须是可写的。

设备实现可以拥有用户可访问的可移动存储硬件，例如SD卡。作为另一种选择，设备实现可以为应用程序分配内部（非可移动）存储作为共享存储。

无论共享存储使用的方式，共享存储必须实现USB大容量存储，如8.6节所述。当设备封装出厂时，共享存储必须以FAT文件系统挂载。

这里有两个常见例子。如果一个设备实现包括一个SD卡插槽来满足共享存储要求，则FAT格式的2GB SD卡或者更大容量的必须同设备一道销售给用户，并且必须缺省是已挂载好的。作为另一种选择，如果一个设备实现使用内部固定存储来满足此需求，那么存储介质的大小必须在2GB或以上且已挂载到/sdcard（或者/sdcard必须是一个到别处已挂载的物理位置的符号链接。）

8.16节   蓝牙

8.16节是新添加的，为了明确现存的蓝牙硬件包含要求。新添加的内容如下。

设备实现必须包括一个蓝牙收发器。设备实现必须使能SDK文档[参考, 29]中所述的基于RFCOMM的蓝牙API。设备实现应该实现设备适合的相关的蓝牙标准，例如A2DP、AVRCP、OBEX等。