Android 4.2 兼容性定义详解
5星 · 超过95%的资源 需积分: 9 126 浏览量
更新于2024-07-26
收藏 211KB PDF 举报 "Android4.2兼容性定义文档是Google在2012年发布的一份详细指南，旨在确保Android4.2系统及其应用在不同设备上具有良好的兼容性。文档涵盖了软件、硬件、Web兼容性、API行为、用户界面等多个方面的内容，确保开发者和设备制造商遵循统一的标准，提供一致的用户体验。"
这篇文档详细阐述了Android4.2版本的兼容性要求，主要分为以下几个部分：
1. **简介**：这部分通常会介绍文档的目的和重要性，强调兼容性对于Android生态系统的重要性，以及遵循这些规定对开发者和设备制造商的意义。
2. **资源**：可能包括开发者需要使用的工具、文档或测试框架，以便于实现和验证兼容性。
3. **软件**：这部分详细讨论了软件层面的兼容性，包括：
- **ManagedAPI兼容性**：涉及Java API的使用，要求应用和系统服务之间的交互应保持稳定。
- **SoftAPI兼容性**：涵盖权限、构建参数和Intent等方面，确保应用能够正确处理不同设备上的权限设置，以及Intent的传递和响应。
- **NativeAPI兼容性**：涉及到C/C++库的接口（Application Binary Interfaces, ABI），保证原生代码在不同设备上的兼容性。
4. **Web兼容性**：包括**WebView兼容性**和**浏览器兼容性**，确保网页在Android4.2内置浏览器中的表现一致性。
5. **API行为兼容性**：讨论了API的行为和功能应如何保持一致，避免因设备差异导致应用出现问题。
6. **API命名空间**：定义了API的命名规则，防止冲突和混乱。
7. **虚拟机兼容性**：可能涉及到Dalvik虚拟机的兼容性问题，保证Dalvik运行时环境的稳定性和性能。
8. **用户界面兼容性**：详细规定了各种UI元素如**小部件**(Widgets)、**通知**(Notifications)、**搜索**(Search)、**吐司**(Toasts)、**主题**(Themes)、**动态壁纸**(Live Wallpapers)、**最近应用显示**(Recent Application Display)、**输入管理设置**(Input Management Settings)、**锁屏及主屏幕小部件**(Lock and Home Screen Widgets)、**锁屏媒体远程控制**(Lock Screen Media Remote Control)、**梦境**(Dreams)等的兼容性标准。
9. **设备管理**：定义了设备管理相关的兼容性需求，如企业级应用的设备管理功能。
10. **无障碍**：确保辅助功能服务在不同设备上的一致性，帮助有特殊需求的用户使用Android设备。
11. **文本转语音**：讨论了TTS（Text-to-Speech）服务的兼容性，保证跨设备的语音输出一致性。
12. **应用打包兼容性**：可能包含关于APK打包和签名的规定，确保应用能在不同Android4.2设备上正确安装和运行。
13. **多语言支持**：可能涉及到对多种语言的兼容性，确保应用在国际市场的可用性。
14. **其他**：可能还包括其他未列出的兼容性细节，如硬件驱动、图形渲染、多媒体支持等。
通过遵循这份文档中的指南，开发者和设备制造商可以确保他们的产品在Android4.2平台上具备良好的兼容性，从而提升用户体验并促进整个Android生态系统的健康发展。
("").
android.os.Build.PRODUCT
A value chosen by the device implementer containing the development name or code name of the
product (SKU). MUST be human-readable, but is not necessarily intended for view by end users. The
value of this field MUST be encodable as 7-bit ASCII and match the regular expression "^[a-zA-Z0-
9.,_-]+$".
android.os.Build.SERIAL
A hardware serial number, if available. The value of this field MUST be encodable as 7-bit ASCII and
match the regular expression "^([a-zA-Z0-9]{0,20})$".
android.os.Build.TAGS
A comma-separated list of tags chosen by the device implementer that further distinguish the build. For
example, "unsigned,debug". The value of this field MUST be encodable as 7-bit ASCII and match the
regular expression "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME A value representing the timestamp of when the build occurred.
android.os.Build.TYPE
A value chosen by the device implementer specifying the runtime configuration of the build. This field
SHOULD have one of the values corresponding to the three typical Android runtime configurations:
"user", "userdebug", or "eng". The value of this field MUST be encodable as 7-bit ASCII and match the
regular expression "^[a-zA-Z0-9.,_-]+$".
android.os.Build.USER
A name or user ID of the user (or automated user) that generated the build. There are no requirements
on the specific format of this field, except that it MUST NOT be null or the empty string ("").
3.2.3. Intent Compatibility
Device implementations MUST honor Android's loose-coupling Intent system, as described in the sections below.
By "honored", it is meant that the device implementer MUST provide an Android Activity or Service that specifies a
matching Intent filter and binds to and implements correct behavior for each specified Intent pattern.
3.2.3.1. Core Application Intents
The Android upstream project defines a number of core applications, such as contacts, calendar, photo gallery,
music player, and so on. Device implementers MAY replace these applications with alternative versions.
However, any such alternative versions MUST honor the same Intent patterns provided by the upstream project. For
example, if a device contains an alternative music player, it must still honor the Intent pattern issued by third-party
applications to pick a song.
The following applications are considered core Android system applications:
Desk Clock
Browser
Calendar
Contacts
Gallery
GlobalSearch
Launcher
Music
Settings
The core Android system applications include various Activity, or Service components that are considered "public".
That is, the attribute "android:exported" may be absent, or may have the value "true".
For every Activity or Service defined in one of the core Android system apps that is not marked as non-public via
an android:exported attribute with the value "false", device implementations MUST include a compontent of the
same type implementing the same Intent filter patterns as the core Android system app.
In other words, a device implementation MAY replace core Android system apps; however, if it does, the device
implementation MUST support all Intent patterns defined by each core Android system app being replaced.
3.2.3.2. Intent Overrides
As Android is an extensible platform, device implementations MUST allow each Intent pattern referenced in Section
3.2.3.2 to be overridden by third-party applications. The upstream Android open source implementation allows this
by default; device implementers MUST NOT attach special privileges to system applications' use of these Intent
patterns, or prevent third-party applications from binding to and assuming control of these patterns. This prohibition
specifically includes but is not limited to disabling the "Chooser" user interface which allows the user to select
between multiple applications which all handle the same Intent pattern.
However, device implementations MAY provide default activities for specific URI patterns (eg.
http://play.google.com) if the default activity provides a more specific filter for the data URI. For example, an intent
filter specifying the data URI "http://www.android.com" is more specific than the browser filter for "http://". Device
implementations MUST provide a user interface for users to modify the default activity for intents.
3.2.3.3. Intent Namespaces
Device implementations MUST NOT include any Android component that honors any new Intent or Broadcast
剩余29页未读，继续阅读
258 浏览量
点击了解资源详情
237 浏览量
点击了解资源详情
200 浏览量
2020-01-22 上传
175 浏览量
139 浏览量
zhenpengli
- 粉丝: 0
- 资源: 1
我的内容管理
展开
