Android 4.0 CTS规范详解：关键API兼容性与应用打包指南

需积分: 0 180 浏览量更新于2024-07-25 收藏 192KB PDF 举报

Android CTS文件是针对Android 4.0（Ice Cream Sandwich）及后续版本的兼容性测试套件（Compatibility Test Suite）文档，它详细规定了Google为确保Android设备之间以及与外部应用之间的软件和硬件交互的一致性而制定的标准。该文件的重要性在于，它帮助厂商在开发、测试和优化产品时遵循Google的官方规范，从而提供一个稳定且一致的用户体验。 1. **Introduction**：文件首先介绍背景，强调了在将Android作为商业产品进行推广时，遵循CTS是为了保证不同设备间的功能和性能一致性，降低开发者在兼容性问题上的困扰。 2. **Resources**：这部分可能涵盖了用于测试的各种资源，如测试工具、文档和参考指南，以帮助开发者了解如何满足CTS的要求。 3. **Software Compatibility**： - **Managed API Compatibility**：关注的是Android系统中受管理的应用程序接口（API），确保它们在不同的设备上行为一致。 - **Soft API Compatibility**：包括权限管理、构建参数设置、意图（Intent）通信、网络浏览器和WebView的行为等，这些都是应用程序与系统交互的关键部分。 - **Native API Compatibility**：着重于设备驱动程序和应用二进制接口（ABI）的兼容性，保证跨设备的原生代码运行一致性。 - **Web Compatibility**：涉及网页浏览和浏览器功能，确保用户在各种设备上的Web体验无差异。 - **API Behavioral Compatibility**：关注API的实际行为，如数据处理和事件响应等，确保一致性。 4. **Application Packaging Compatibility**：涉及应用的安装、更新和卸载过程，确保符合Google的打包规范，以便在各种设备上无缝运行。 5. **Multimedia Compatibility**：强调多媒体处理能力，如媒体编解码器、视频编码、音频录制等，确保高质量的多媒体体验。 6. **Device Administration**：针对设备管理功能的兼容性，包括用户权限控制和远程管理功能的实现。 7. **Accessibility**：关注无障碍设计，确保所有用户，包括有特殊需求的用户，都能正常使用Android应用。 8. **Text-to-Speech**：确保语音合成技术在不同设备上的准确性和可用性。 9. **Application Packaging Compatibility**：这部分详细说明了应用程序包（APK）的打包规则和测试策略。通过阅读Android CTS文件，开发者可以明确了解到哪些方面需要特别注意，从而在设计和实现功能时考虑到跨设备兼容性，并通过严格的测试确保他们的应用能够在广泛的Android设备上正常运行，提供无缝的用户体验。这对于Android生态系统的发展和维护至关重要。

android.os.Build.VERSION.INCREMENTAL

A value chosen by the device implementer designating the specific build of the currently-executing

Android system, in human-readable format. This value MUST NOT be re-used for different builds made

available to end users. A typical use of this field is to indicate which build number or source-control

change identifier was used to generate the build. There are no requirements on the specific format of this

field, except that it MUST NOT be null or the empty string ("").

android.os.Build.BOARD

A value chosen by the device implementer identifying the specific internal hardware used by the device,

in human-readable format. A possible use of this field is to indicate the specific revision of the board

powering the device. The value of this field MUST be encodable as 7-bit ASCII and match the regular

expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.BRAND

A value chosen by the device implementer identifying the name of the company, organization, individual,

etc. who produced the device, in human-readable format. A possible use of this field is to indicate the

OEM and/or carrier who sold the device. The value of this field MUST be encodable as 7-bit ASCII and

match the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.CPU_ABI

The name of the instruction set (CPU type + ABI convention) of native code. See Section 3.3: Native API

Compatibility.

android.os.Build.CPU_ABI2

The name of the second instruction set (CPU type + ABI convention) of native code. See Section 3.3:

Native API Compatibility.

android.os.Build.DEVICE

A value chosen by the device implementer identifying the specific configuration or revision of the body

(sometimes called "industrial design") of the device. The value of this field MUST be encodable as 7-bit

ASCII and match the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.FINGERPRINT

A string that uniquely identifies this build. It SHOULD be reasonably human-readable. It MUST follow this

template:

$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

For example:

acme/mydevice/generic:4.0/IRK77/3359:userdebug/test-keys

The fingerprint MUST NOT include whitespace characters. If other fields included in the template above

have whitespace characters, they MUST be replaced in the build fingerprint with another character, such

as the underscore ("_") character. The value of this field MUST be encodable as 7-bit ASCII.

android.os.Build.HARDWARE

The name of the hardware (from the kernel command line or /proc). It SHOULD be reasonably human-

readable. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression

"^[a-zA-Z0-9.,_-]+$".

android.os.Build.HOST

A string that uniquely identifies the host the build was built on, in human readable format. There are no

requirements on the specific format of this field, except that it MUST NOT be null or the empty string ("").

android.os.Build.ID

An identifier chosen by the device implementer to refer to a specific release, in human readable format.

This field can be the same as android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value

sufficiently meaningful for end users to distinguish between software builds. The value of this field MUST

be encodable as 7-bit ASCII and match the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.MANUFACTURER

The trade name of the Original Equipment Manufacturer (OEM) of the product. There are no requirements

on the specific format of this field, except that it MUST NOT be null or the empty string ("").

android.os.Build.MODEL

A value chosen by the device implementer containing the name of the device as known to the end user.

This SHOULD be the same name under which the device is marketed and sold to end users. There are

no requirements on the specific format of this field, except that it MUST NOT be null or the empty string

("").

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.

3.2.3.3. Intent Namespaces

Device implementations MUST NOT include any Android component that honors any new Intent or Broadcast Intent

patterns using an ACTION, CATEGORY, or other key string in the android.* or com.android.* namespace. Device

implementers MUST NOT include any Android components that honor any new Intent or Broadcast Intent patterns

using an ACTION, CATEGORY, or other key string in a package space belonging to another organization. Device

implementers MUST NOT alter or extend any of the Intent patterns used by the core apps listed in Section 3.2.3.1.

Device implementations MAY include Intent patterns using namespaces clearly and obviously associated with their

own organization.

This prohibition is analogous to that specified for Java language classes in Section 3.6.

3.2.3.4. Broadcast Intents

Third-party applications rely on the platform to broadcast certain Intents to notify them of changes in the hardware or

software environment. Android-compatible devices MUST broadcast the public broadcast Intents in response to

appropriate system events. Broadcast Intents are described in the SDK documentation.

3.3. Native API Compatibility

3.3.1 Application Binary Interfaces

Managed code running in Dalvik can call into native code provided in the application .apk file as an ELF .so file

compiled for the appropriate device hardware architecture. As native code is highly dependent on the underlying

processor technology, Android defines a number of Application Binary Interfaces (ABIs) in the Android NDK, in the file

docs/CPU-ARCH-ABIS.txt. If a device implementation is compatible with one or more defined ABIs, it SHOULD

implement compatibility with the Android NDK, as below.

If a device implementation includes support for an Android ABI, it:

MUST include support for code running in the managed environment to call into native code, using the standard

Java Native Interface (JNI) semantics.

MUST be source-compatible (i.e. header compatible) and binary-compatible (for the ABI) with each required

library in the list below

剩余25页未读，继续阅读

peacecoming

粉丝: 0
资源: 6

Android 4.0 CTS规范详解：关键API兼容性与应用打包指南

android CTS

Android cts Android cts Android cts Android cts

Android CTS apk and Readme

android-cts-verifier-6.0_r12-linux_x86-arm.zi

跑cts需要如何配置电脑

CTS测试环境如何配置

console:/ # dumpsys deviceidle force-idle com.android.cts.verifier Unknown idle mode: com.android.cts.verifier

ubuntu cts环境搭建

android 选择文件

android.widget.cts:layout/textview_restricted_layout: Binary XML file line #17 in android.widget.cts:layout/textview_restricted_layout: Error inflating class <unknown>

最新资源