此页面由 Cloud Translation API 翻译。
Switch to English

Android 2.1兼容性定义

版权所有©2010,GoogleInc。保留所有权利。
兼容性@ android.com

1.简介

本文档列举了使手机与Android 2.1兼容所必须满足的要求。

根据IETF标准,使用“必须”,“必须”,“必须”,“将”,“不应”,“应该”,“不应”,“推荐”,“可以”和“可选”在RFC2119 [ Resources,1 ]中定义。

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

被认为与Android 2.1兼容的设备实现:

  • 必须满足此兼容性定义中提出的要求,包括通过引用并入的所有文档。
  • 在设备实施的软件完成时,必须通过最新版本的Android兼容性测试套件(CTS)。 (CTS是Android开源项目[ 参考资料,2 ]的一部分。)CTS测试了本文档中概述的许多但并非全部组件。

如果此定义或CTS是静默的,模棱两可的或不完整的,则设备实现者有责任确保与现有实现的兼容性。因此,Android Open Source Project [ Resources,3 ]是Android的参考和首选实现。强烈建议设备实施者将其实现基于Android开源项目提供的“上游”源代码。虽然可以假设某些组件可以用替代实现方式代替,但强烈建议不要采用这种做法,因为通过CTS测试将变得更加困难。实现者有责任确保与标准Android实现的行为完全兼容,包括兼容性测试套件以及超越兼容性测试套件的行为。最后,请注意,本文档明确禁止某些组件的替换和修改。

2.资源

  1. IETF RFC2119要求级别: http ://www.ietf.org/rfc/rfc2119.txt
  2. Android兼容计划概述: http : //source.android.com/compatibility/index.html
  3. Android开源项目: http//source.android.com/
  4. API定义和文档: http : //developer.android.com/reference/packages.html
  5. Android权限参考: http : //developer.android.com/reference/android/Manifest.permission.html
  6. android.os.Build参考: http : //developer.android.com/reference/android/os/Build.html
  7. Android 2.1允许的版本字符串: http : //source.android.com/compatibility/2.1/versions.html
  8. android.webkit.WebView类: http : //developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http//www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Dalvik虚拟机规范:可在Android源代码中获得,网址为dalvik / docs
  11. AppWidgets: http : //developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. 通知: http : //developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. 应用程序资源: http : //code.google.com/android/reference/available-resources.html
  14. 状态栏图标样式指南: http : //developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. 搜索管理器: http : //developer.android.com/reference/android/app/SearchManager.html
  16. 敬酒: http : //developer.android.com/reference/android/widget/Toast.html
  17. 动态壁纸: http//developer.android.com/resources/articles/live-wallpapers.html
  18. 适用于Android的应用程序: http : //code.google.com/p/apps-for-android
  19. 参考工具文档(针对adb,aapt,ddms): http : //developer.android.com/guide/developing/tools/index.html
  20. Android APK文件描述: http : //developer.android.com/guide/topics/fundamentals.html
  21. 清单文件: http : //developer.android.com/guide/topics/manifest/manifest-intro.html
  22. 猴子测试工具: http : //developer.android.com/guide/developing/tools/monkey.html
  23. 支持多个屏幕: 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. 传感器坐标空间: http : //developer.android.com/reference/android/hardware/SensorEvent.html
  28. Android安全性和权限参考: http : //developer.android.com/guide/topics/security/security.html
  29. 蓝牙API: http//developer.android.com/reference/android/bluetooth/package-summary.html

这些资源中有许多直接或间接地来自Android 2.1 SDK,并且在功能上与该SDK文档中的信息相同。在此兼容性定义或兼容性测试套件与SDK文档不一致的任何情况下,SDK文档均被视为具有权威性。包括在上面的参考文献中提供的任何技术细节均被视为该兼容性定义的一部分。

3.软件

Android平台包括一组托管API,一组本机API和一组所谓的“软” API,例如Intent系统和Web应用程序API。本节详细介绍了兼容性所必需的硬API和软API,以及某些其他相关的技术和用户界面行为。设备实现必须符合本节中的所有要求。

3.1。托管API兼容性

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

设备实现绝不能忽略任何托管API,更改API接口或签名,背离已记录的行为或包括无操作,除非本兼容性定义明确允许。

3.2。软API兼容性

除了第3.1节中的托管API外,Android还包括一个重要的仅运行时的“软” API,其形式为诸如Intent,权限以及无法在应用程序编译时强制执行的Android应用程序的类似方面。本部分详细介绍了与Android 2.1兼容所需的“软” API和系统行为。设备实现必须满足本节中提出的所有要求。

3.2.1。权限

设备实现者必须支持并强制执行权限参考页[ 参考资料,5 ]中记录的所有权限常量。请注意,第10节列出了与Android安全模型相关的其他要求。

3.2.2。构建参数

Android API在android.os.Build类[ Resources,6 ]上包含许多常量,旨在描述当前设备。为了在设备实现之间提供一致且有意义的值,下表对设备实现必须遵循的这些值的格式进行了附加限制。

参数 注释
android.os.Build.VERSION.RELEASE 当前正在执行的Android系统的版本,格式为人类可读。该字段必须具有[ 资源,7 ]中定义的字符串值之一。
android.os.Build.VERSION.SDK 当前正在执行的Android系统的版本,其格式可供第三方应用程序代码访问。对于Android 2.1,此字段必须具有整数值7。
android.os.Build.VERSION.INCREMENTAL 设备实施者选择的值,以人类可读的格式指定当前正在执行的Android系统的特定版本。不得将此值用于交付给最终用户的其他内部版本。该字段的典型用法是指示使用哪个内部版本号或源代码管理更改标识符来生成内部版本。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.BOARD 设备实施者选择的值,以人类可读的格式标识设备使用的特定内部硬件。该字段的可能用途是指示为设备供电的电路板的特定版本。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.BRAND 设备实施者选择的值,以人类可读的格式标识制造设备的公司,组织,个人等的名称。该字段的可能用途是指示出售设备的OEM和/或运营商。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.DEVICE 由设备实施者选择的一个值,用于标识设备主体的特定配置或版本(有时称为“工业设计”)。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.FINGERPRINT 一个唯一标识此构建的字符串。它应该是合理的人类可读的。它必须遵循以下模板:
$(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 一个字符串,以人类可读的格式唯一地标识构建所基于的主机。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.ID 设备实现者选择的标识符以人类可读的格式引用特定的版本。该字段可以与android.os.Build.VERSION.INCREMENTAL相同,但是应该是一个足以让最终用户区分软件版本的值。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.MODEL 由设备实施者选择的值,包含最终用户已知的设备名称。该名称应与设备销售并出售给最终用户时使用的名称相同。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.PRODUCT 设备实施者选择的值,其中包含设备的开发名称或代码名称。必须是人类可读的,但不一定要供最终用户查看。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。
android.os.Build.TAGS 设备实施者选择的以逗号分隔的标签列表,这些标签进一步区分了版本。例如,“ unsigned,debug”。该字段不得为null或空字符串(“”),但可以使用单个标签(例如“ release”)。
android.os.Build.TIME 表示生成时间的时间戳记的值。
android.os.Build.TYPE 设备实施者选择的值,用于指定构建的运行时配置。该字段应具有与以下三种典型的Android运行时配置相对应的值之一:“ user”,“ userdebug”或“ eng”。
android.os.Build.USER 生成构建的用户(或自动用户)的名称或用户ID。除了必须不得为null或空字符串(“”)之外,对该字段的特定格式没有任何要求。

3.2.3。意向兼容性

Android使用Intents实现应用程序之间的松耦合集成。本节描述与设备实现必须遵循的Intent模式相关的要求。 “荣誉”是指设备实现者必须提供Android活动或服务,该活动或服务指定匹配的Intent过滤器,并绑定到每个指定的Intent模式并实现正确的行为。

3.2.3.1。核心应用意向

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

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

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

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

对于在一个核心Android系统应用中定义的每个未通过android:exported属性标记为“ false”的未标记为非公开的Activity或服务,设备实现都必须包括实现相同Intent过滤器的相同类型的组件模式作为Android系统的核心应用。

换句话说,设备实现可以取代核心的Android系统应用;但是,如果确实如此,则设备实现必须支持被替换的每个核心Android系统应用定义的所有Intent模式。

3.2.3.2。意图替代

由于Android是可扩展的平台,因此设备实现者必须允许第三方应用程序覆盖核心系统应用程序中定义的每个Intent模式。上游Android开源项目默认情况下允许此操作;设备实现者不得为系统应用程序对这些Intent模式的使用赋予特殊特权,或防止第三方应用程序绑定到这些模式并控制这些模式。该禁止特别包括但不限于禁用“选择器”用户界面,该界面允许用户在都处理相同Intent模式的多个应用程序之间进行选择。

3.2.3.3。意向命名空间

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

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

3.2.3.4。广播意图

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

3.3。本机API兼容性

在Dalvik中运行的托管代码可以将应用程序.apk文件中提供的本机代码作为为适当的设备硬件体系结构编译的ELF .so文件进行调用。设备实现必须包括使用标准Java本机接口(JNI)语义支持在托管环境中运行的代码以调用本机代码。以下API必须对本机代码可用:

设备实现必须支持OpenGL ES 1.0。缺乏硬件加速的设备必须使用软件渲染器实现OpenGL ES 1.0。设备实现应实现设备硬件支持的OpenGL ES 1.1。如果硬件能够在这些API上实现合理的性能,则设备实现应提供OpenGL ES 2.0的实现。

这些库必须与Android Open Source项目在Bionic中提供的版本具有源兼容性(即,标头兼容)和二进制兼容性(对于给定的处理器架构)。由于Bionic实现与其他实现(例如GNU C库)不完全兼容,因此设备实现者应使用Android实现。如果设备实现者使用这些库的不同实现,则他们必须确保标头,二进制和行为兼容。

设备实现必须通过android.os.Build.CPU_ABI API准确报告设备支持的本机应用程序二进制接口(ABI)。 ABI必须是最新版本的Android NDK中docs/CPU-ARCH-ABIS.txt 。请注意,Android NDK的其他发行版可能会引入对其他ABI的支持。

本机代码兼容性是具有挑战性的。出于这个原因,应该重复地极力鼓励设备实现者使用上面列出的库的上游实现,以帮助确保兼容性。

3.4。 Web API兼容性

许多开发人员和应用程序的用户界面都依赖android.webkit.WebView类[ Resources,8 ]的行为,因此WebView实现必须在Android实现之间兼容。 Android开源实现使用WebKit呈现引擎来实现WebView。

因为为Web浏览器开发一个全面的测试套件是不可行的,所以设备实现者必须在WebView实现中使用WebKit的特定上游版本。特别:

实现可以在一个独立的浏览器应用程序中发送一个自定义的用户代理字符串。此外,独立的浏览器可能基于备用浏览器技术(例如Firefox,Opera等)。但是,即使随附了备用浏览器应用程序,提供给第三方应用程序的WebView组件也必须基于WebKit,如上。

WebView配置必须包括对HTML5数据库,应用程序缓存和地理位置API的支持[ 参考资料,9 ]。 WebView必须包含对HTML5 <video>标签的某种形式的支持。独立的浏览器应用程序(无论是基于上游WebKit浏览器应用程序还是基于第三方替代品)必须包括对WebView刚刚列出的相同HTML5功能的支持。

3.5。 API行为兼容性

每种API类型(托管,软,本机和Web)的行为都必须与上游Android开源项目的首选实现一致[ Resources,3 ]。兼容性的一些特定领域是:

上面的列表并不全面,设备实施者有责任确保行为兼容。因此,设备实施者应尽可能使用可通过Android Open Source Project获得的源代码,而不是重新实现系统的重要部分。

兼容性测试套件(CTS)测试平台的大部分行为行为兼容性,但不是全部。实现者有责任确保与Android开放源代码项目的行为兼容。

3.6。 API命名空间

Android遵循Java编程语言定义的package和class名称空间约定。为确保与第三方应用程序兼容,设备实现者不得对这些软件包名称空间进行任何禁止的修改(请参见下文):

禁止的修改包括:

“公开元素”是在上游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。小部件

Android定义了一种组件类型以及相应的API和生命周期,允许应用程序向最终用户公开“ AppWidget” [ Resources,11 ]。 Android开放源参考发行版包含一个Launcher应用程序,该应用程序包含用户界面元素,允许用户从主屏幕添加,查看和删除AppWidget。

设备实施者可以用替代方法替代参考启动器(即主屏幕)。替代启动器应包括对AppWidget的内置支持,并公开用户界面元素以直接在启动器中添加,配置,查看和删除AppWidget。替代启动器可以省略这些用户界面元素;但是,如果省略了它们,则设备实现者必须提供可从启动器访问的单独应用程序,该应用程序允许用户添加,配置,查看和删除AppWidget。

3.8.2。通知事项

Android包含一些API,这些API允许开发人员将值得注意的事件通知用户[ 参考资料,12 ]。设备实现者必须为这样定义的每类通知提供支持;具体来说:声音,振动,灯光和状态栏。

另外,实现必须正确呈现API [ 资源,13 ]或状态栏图标样式指南[ 资源,14 ]中提供的所有资源(图标,声音文件等)。设备实现者可以为通知提供不同于参考Android开放源实现所提供的用户体验;但是,如上所述,此类替代通知系统必须支持现有的通知资源。

Android包含API [ Resources,15 ],这些API允许开发人员将搜索合并到其应用程序中,并将其应用程序的数据公开到全局系统搜索中。通常,此功能由单个系统范围的用户界面组成,该界面允许用户输入查询,在用户键入时显示建议并显示结果。 Android API允许开发人员重用此接口以在其自己的应用程序中提供搜索,并允许开发人员将结果提供给通用的全局搜索用户界面。

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

设备实现可以附带其他搜索用户界面,但应包括硬性或软性专用搜索按钮,该按钮可在任何应用程序中随时用于调用搜索框架(API文档中提供了相应的行为)。

3.8.4。敬酒

应用程序可以使用“ Toast” API(在[ 参考资料,16 ]中定义)向最终用户显示简短的非模式字符串,这些字符串会在短时间后消失。设备实现必须以某种高度可见的方式显示从应用程序到最终用户的敬酒。

3.8.5。动态壁纸

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

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

如上所述,能够可靠运行动态壁纸的设备实现应实现动态壁纸。如上所述,确定不能可靠运行动态壁纸的设备实现绝不能实现动态壁纸。

4.参考软件兼容性

设备实施者必须使用以下开源应用程序测试实施兼容性:

上面的每个应用程序都必须启动并在实现上正确运行,以确保实现兼容。

此外,设备实现必须测试以下每个烟雾测试应用程序的每个菜单项(包括所有子菜单):

以上应用程序中的每个测试用例必须在设备实现上正确运行。

5.应用程序包装兼容性

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

设备实现不得扩展.apk [ 资源20 ],Android Manifest [ 资源21 ]或Dalvik字节码[ 资源10 ]格式,以防止这些文件在其他兼容设备上正确安装和运行。设备实施者应该使用Dalvik的参考上游实现以及参考实现的程序包管理系统。

6.多媒体兼容性

设备实现必须支持以下多媒体编解码器。所有这些编解码器在Android开源项目的首选Android实现中均作为软件实现提供。

请注意,无论是Google还是开放手机联盟,都不代表这些编解码器不受第三方专利的限制。建议那些打算在硬件或软件产品中使用此源代码的人,此代码的实现(包括在开放源代码软件或共享软件中)可能需要获得相关专利持有者的专利许可。

音讯
名称 编码器 解码器 细节 文件/容器格式
AAC LC / LTP X Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates between 8 to 48kHz 3GPP (.3gp) and MPEG-4 (.mp4, .m4a). No support for raw AAC (.aac)
HE-AACv1 (AAC+) X
HE-AACv2 (enhanced AAC+) X
AMR-NB X X 4.75 to 12.2 kbps sampled @ 8kHz 3GPP (.3gp)
AMR-WB X 9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz 3GPP (.3gp)
MP3 X Mono/Stereo 8-320Kbps constant (CBR) or variable bit-rate (VBR) MP3 (.mp3)
MIDI X MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for ringtone formats RTTTL/RTX, OTA, and iMelody Type 0 and 1 (.mid, .xmf, .mxmf). Also RTTTL/RTX (.rtttl, .rtx), OTA (.ota), and iMelody (.imy)
Ogg Vorbis X Ogg (.ogg)
PCM X 8- and 16-bit linear PCM (rates up to limit of hardware) WAVE (.wav)
Image
JPEG X X base+progressive
GIF X
PNG X X
BMP X
Video
H.263 X X 3GPP (.3gp) files
H.264 X 3GPP (.3gp) and MPEG-4 (.mp4) files
MPEG4 Simple Profile X 3GPP (.3gp) file

Note that the table above does not list specific bitrate requirements for most video codecs. The reason for this is that in practice, current device hardware does not necessarily support bitrates that map exactly to the required bitrates specified by the relevant standards. Instead, device implementations SHOULD support the highest bitrate practical on the hardware, up to the limits defined by the specifications.

7. Developer Tool Compatibility

Device implemenations MUST support the Android Developer Tools provided in the Android SDK. Specifically, Android-compatible devices MUST be compatible with:

  • Android Debug Bridge (known as adb) [ Resources, 19 ]
    Device implementations MUST support all adb functions as documented in the Android SDK. The device-side adb daemon SHOULD be inactive by default, but there MUST be a user-accessible mechanism to turn on the Android Debug Bridge.
  • Dalvik Debug Monitor Service (known as ddms) [ Resources, 19 ]
    Device implementations MUST support all ddms features as documented in the Android SDK. As ddms uses adb , support for ddms SHOULD be inactive by default, but MUST be supported whenever the user has activated the Android Debug Bridge, as above.
  • Monkey [ Resources, 22 ]
    Device implementations MUST include the Monkey framework, and make it available for applications to use.

8. Hardware Compatibility

Android is intended to support device implementers creating innovative form factors and configurations. At the same time Android developers expect certain hardware, sensors and APIs across all Android device. This section lists the hardware features that all Android 2.1 compatible devices must support.

If a device includes a particular hardware component that has a corresponding API for third-party developers, the device implementation MUST implement that API as defined in the Android SDK documentation. If an API in the SDK interacts with a hardware component that is stated to be optional and the device implementation does not possess that component:

A typical example of a scenario where these requirements apply is the telephony API: even on non-phone devices, these APIs must be implemented as reasonable no-ops.

Device implementations MUST accurate report accurate hardware configuration information via the getSystemAvailableFeatures() and hasSystemFeature(String) methods on the android.content.pm.PackageManager class.

8.1. Display

Android 2.1 includes facilities that perform certain automatic scaling and transformation operations under some circumstances, to ensure that third-party applications run reasonably well on a variety of hardware configurations [ Resources, 23 ]. Devices MUST properly implement these behaviors, as detailed in this section.

For Android 2.1, this are the most common display configurations:

Screen Type Width (Pixels) Height (Pixels) Diagonal Length Range (inches) Screen Size Group Screen Density Group
QVGA 240 320 2.6 - 3.0 Small Low
WQVGA 240 400 3.2 - 3.5 Normal Low
FWQVGA 240 432 3.5 - 3.8 Normal Low
HVGA 320 480 3.0 - 3.5 Normal Medium
WVGA 480 800 3.3 - 4.0 Normal High
FWVGA 480 854 3.5 - 4.0 Normal High
WVGA 480 800 4.8 - 5.5 Large Medium
FWVGA 480 854 5.0 - 5.8 Large Medium

Device implementations corresponding to one of the standard configurations above MUST be configured to report the indicated screen size to applications via the android.content.res.Configuration [ Resources, 24 ] class.

Some .apk packages have manifests that do not identify them as supporting a specific density range. When running such applications, the following constraints apply:

8.1.2. Non-Standard Display Configurations

Display configurations that do not match one of the standard configurations listed in Section 8.1.1 require additional consideration and work to be compatible. Device implementers MUST contact Android Compatibility Team as provided for in Section 12 to obtain classifications for screen-size bucket, density, and scaling factor. When provided with this information, device implementations MUST implement them as specified.

Note that some display configurations (such as very large or very small screens, and some aspect ratios) are fundamentally incompatible with Android 2.1; therefore device implementers are encouraged to contact Android Compatibility Team as early as possible in the development process.

8.1.3. Display Metrics

Device implementations MUST report correct valuesfor all display metrics defined in android.util.DisplayMetrics [ Resources, 25 ].

8.2. Keyboard

Device implementations:

8.3. Non-touch Navigation

Device implementations:

8.4. Screen Orientation

Compatible devices MUST support dynamic orientation by applications to either portrait or landscape screen orientation. That is, the device must respect the application's request for a specific screen orientation. Device implementations MAY select either portrait or landscape orientation as the default.

Devices MUST report the correct value for the device's current orientation, whenever queried via the android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.

8.5. Touchscreen input

Device implementations:

8.6. USB

Device implementations:

8.7. Navigation keys

The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times, regardless of application state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or interfere with the available application display area.

Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also provide send and end keys for phone calls.

8.8. Wireless Data Networking

Device implementations MUST include support for wireless high-speed data networking. Specifically, device implementations MUST include support for at least one wireless data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, etc.

If a device implementation includes a particular modality for which the Android SDK includes an API (that is, WiFi, GSM, or CDMA), the implementation MUST support the API.

Devices MAY implement more than one form of wireless data connectivity. Devices MAY implement wired data connectivity (such as Ethernet), but MUST nonetheless include at least one form of wireless connectivity, as above.

8.9. Camera

Device implementations MUST include a camera. The included camera:

Device implementations MUST implement the following behaviors for the camera-related APIs:

  1. If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
  2. If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. (This is the format used natively by the 7k hardware family.) That is, NV21 MUST be the default.

Device implementations MUST implement the full Camera API included in the Android 2.1 SDK documentation [ Resources, 26 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.)

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters , unless the constants are prefixed with a string indicating the name of the device implementer. That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types unless the parameter names are clearly indicated via a string prefix to be non-standard.

8.10. Accelerometer

Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at 50 Hz or greater. The coordinate system used by the accelerometer MUST comply with the Android sensor coordinate system as detailed in the Android APIs (see [ Resources, 27 ]).

8.11. Compass

Device implementations MUST include a 3-axis compass and MUST be able to deliver events 10 Hz or greater. The coordinate system used by the compass MUST comply with the Android sensor coordinate system as defined in the Android API (see [ Resources, 27 ]).

8.12. GPS

Device implementations MUST include a GPS, and SHOULD include some form of "assisted GPS" technique to minimize GPS lock-on time.

8.13. Telephony

Android 2.1 MAY be used on devices that do not include telephony hardware. That is, Android 2.1 is compatible with devices that are not phones. However, if a device implementation does include GSM or CDMA telephony, it MUST implement the full support for the API for that technology. Device implementations that do not include telephony hardware MUST implement the full APIs as no-ops.

See also Section 8.8, Wireless Data Networking.

8.14. Memory and Storage

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

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

8.15. Application Shared Storage

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

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

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

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

Regardless of the form of shared storage used, the shared storage MUST implement USB mass storage, as described in Section 8.6. As shipped out of the box, the shared storage MUST be mounted with the FAT filesystem.

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 2GB 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 2GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

8.16. Bluetooth

Device implementations MUST include a Bluetooth transceiver. Device implementations MUST enable the RFCOMM-based Bluetooth API as described in the SDK documentation [ Resources, 29 ]. Device implementations SHOULD implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as appropriate for the device.

9. Performance Compatibility

One of the goals of the Android Compatibility Program is to enable consistent application experience to consumers. Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.1 compatible device defined in the table below:

Metric Performance Threshold Comments
Application Launch Time The following applications should launch within the specified time. 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.

10. Security Model Compatibility

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

10.1. Permissions

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

10.2. UID and Process Isolation

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

10.3. Filesystem Permissions

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

11. Compatibility Test Suite

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

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

12. Updatable Software

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

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

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

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

13. Contact Us

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