Android 10 兼容性要求详解

需积分: 9 198 浏览量更新于2024-07-16 收藏 912KB PDF 举报

"安卓10兼容性定义文档是Google LLC为确保设备与Android 10系统兼容而制定的一份详细规范。文档包含了不同设备类型（如手持设备、电视、手表、汽车和平板）在硬件、多媒体、软件、性能、电源管理及安全模型等方面所需满足的要求。同时，它还涉及开发者工具和选项的兼容性规定。" 本文档的主要目的是为制造商提供指南，以确保他们的产品能够顺利运行Android 10并与其他Android设备无缝协作。Android的兼容性定义文档(CDD)是平台发展中的核心组成部分，它设定了设备必须遵循的一系列政策和标准。 1.1.1 设备类型要求：根据设备的用途和功能，文档将设备分为手持设备、电视、手表、汽车和平板电脑等类别，并对每一类设备提出特定的兼容性要求。 2.1 设备配置：这部分详细阐述了每种设备类型的硬件配置，包括处理器、内存、存储、显示屏、输入设备等，以确保设备能支持Android 10的基本操作和功能。 2.2 手持设备要求：涵盖手持设备的硬件需求，如处理器速度、内存大小，以及对多媒体支持（如音频、视频编码解码）、软件（包括操作系统版本、预装应用）、性能和电源管理的标准。安全模型部分讨论了如何保护用户数据和隐私，以及对开发者工具和选项的支持，以促进应用程序开发。 2.3 至2.6 对电视、手表、汽车和平板电脑的要求类似，强调了这些特定设备类型在硬件和软件上的独特性，比如电视的显示质量、手表的电池寿命、汽车的车载娱乐系统集成以及平板的多任务处理能力。 3.1 管理API兼容性：这部分规定了设备必须支持的Android扩展和库，以确保应用的兼容性和稳定性。制造商需确保其设备上的API级别与Android 10兼容。 3.2 软件API兼容性：详细说明了软API的兼容性要求，这些API用于应用程序开发，保证了应用程序能在不同设备上正常运行。 3.1.1 Android Extensions和3.1.2 Android Library：这两部分详细介绍了扩展和库的功能，它们为开发者提供了更多的功能和工具，以创建适应不同设备特性的应用。安卓10兼容性定义文档是一个全面的指南，它为设备制造商提供了构建与Android 10兼容产品的蓝图，同时也为开发者提供了一个框架，使他们能够在各种设备上开发出一致体验的应用程序。这份文档的重要性在于，它确保了Android生态系统的统一性和互操作性，从而提升了用户体验。

include a video output port, such as VGA, HDMI, DisplayPort, or a wireless port for display.
The additional requirements in the rest of this section are specific to Android Television device
implementations.
2.3.1. Hardware
Television device implementations:
[ 7.2 .2/T-0-1] MUST support D-pad .
[ 7.2 .3/T-0-1] MUST provide the Home and Back functions.
[ 7.2 .3/T-0-2] MUST send both the normal and long press event of the Back function (
KEYCODE_BACK ) to the foreground application.
[ 7.2 .6.1/T-0-1] MUST include support for game controllers and declare the
android.hardware.gamepad feature flag.
[ 7.2 .7/T] SHOULD provide a remote control from which users can access non-touch
navigation and core navigation keys inputs.
If Television device implementations include a 3-axis gyroscope, they:
[ 7.3 .4/T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
Television device implementations:
[ 7.4 .3/T-0-1] MUST support Bluetooth and Bluetooth LE.
[ 7.6 .1/T-0-1] MUST have at least 4 GB of non-volatile storage available for application
private data (a.k.a. "/data" partition).
If Television device implementations include a USB port that supports host mode, they:
[ 7.5 .3/T-1-1] MUST include support for an external camera that connects through this
USB port but is not necessarily always connected.
If TV device implementations are 32-bit:
[ 7.6 .1/T-1-1] The memory available to the kernel and userspace MUST be at least 896MB
if any of the following densities are used:
400dpi or higher on small/normal screens
xhdpi or higher on large screens
tvdpi or higher on extra large screens
If TV device implementations are 64-bit:
[ 7.6 .1/T-2-1] The memory available to the kernel and userspace MUST be at least
1280MB if any of the following densities are used:
400dpi or higher on small/normal screens
xhdpi or higher on large screens
tvdpi or higher on extra large screens
Note that the "memory available to the kernel and userspace" above refers to the memory space
provided in addition to any memory already dedicated to hardware components such as radio, video,
and so on that are not under the kernel’s control on device implementations.
Television device implementations:
[ 7.8 .1/T] SHOULD include a microphone.
[ 7.8 .2/T-0-1] MUST have an audio output and declare android.hardware.audio.output
.
2.3.2. Multimedia
Television device implementations MUST support the following audio encoding and decoding formats
and make them available to third-party applications:

[ 5.1 /T-0-1] MPEG-4 AAC Profile (AAC LC)
[ 5.1 /T-0-2] MPEG-4 HE AAC Profile (AAC+)
[ 5.1 /T-0-3] AAC ELD (enhanced low delay AAC)
Television device implementations MUST support the following video encoding formats and make
them available to third-party applications:
[ 5.2 /T-0-1] H.264
[ 5.2 /T-0-2] VP8
Television device implementations:
[ 5.2 .2/T-SR] Are STRONGLY RECOMMENDED to support H.264 encoding of 720p and
1080p resolution videos at 30 frames per second.
Television device implementations MUST support the following video decoding formats and make
them available to third-party applications:
[ 5.3.3 /T-0-1] MPEG-4 SP
[ 5.3.4 /T-0-2] H.264 AVC
[ 5.3.5 /T-0-3] H.265 HEVC
[ 5.3.6 /T-0-4] VP8
[ 5.3.7 /T-0-5] VP9
[ 5.3.1 /T-0-6] MPEG-2
Television device implementations MUST support MPEG-2 decoding, as detailed in Section 5.3.1, at
standard video frame rates and resolutions up to and including:
[ 5.3.1 .4/T-1-1] HD 1080p at 59.94 frames per second with Main Profile High Level.
[ 5.3.1 .4/T-1-2] HD 1080i at 59.94 frames per second with Main Profile High Level. They
MUST deinterlace interlaced MPEG-2 video to its progressive equivalent (e.g. from 1080i
at 59.94 frames per second to 1080p at 29.97 frames per second) and make it available to
third-party applications.
Television device implementations MUST support H.264 decoding, as detailed in Section 5.3.4, at
standard video frame rates and resolutions up to and including:
[ 5.3.4 /T-1-1] HD 1080p at 60 frames per second with Baseline Profile
[ 5.3.4 /T-1-2] HD 1080p at 60 frames per second with Main Profile
[ 5.3.4 /T-1-3] HD 1080p at 60 frames per second with High Profile Level 4.2
Television device implementations with H.265 hardware decoders MUST support H.265 decoding, as
detailed in Section 5.3.5, at standard video frame rates and resolutions up to and including:
[ 5.3.5 /T-1-1] HD 1080p at 60 frames per second with Main Profile Level 4.1
If Television device implementations with H.265 hardware decoders support H.265 decoding and the
UHD decoding profile, they:
[ 5.3.5 /T-2-1] MUST support UHD 3480p at 60 frames per second with Main10 Level 5
Main Tier profile
Television device implementations MUST support VP8 decoding, as detailed in Section 5.3.6, at
standard video frame rates and resolutions up to and including:
[ 5.3.6 /T-1-1] HD 1080p at 60 frames per second decoding profile
Television device implementations with VP9 hardware decoders MUST support VP9 decoding, as
detailed in Section 5.3.7, at standard video frame rates and resolutions up to and including:
[ 5.3.7 /T-1-1] HD 1080p at 60 frames per second with profile 0 (8 bit color depth)
If Television device implementations with VP9 hardware decoders support VP9 decoding and the UHD
decoding profile, they:

[ 5.3.7 /T-2-1] MUST support UHD 3480p at 60 frames per second with profile 0 (8 bit color
depth).
[ 5.3.7 /T-2-1] Are STRONGLY RECOMMENDED to support UHD 3480p at 60 frames per
second with profile 2 (10 bit color depth).
Television device implementations:
[ 5.5 /T-0-1] MUST include support for system Master Volume and digital audio output
volume attenuation on supported outputs, except for compressed audio passthrough
output (where no audio decoding is done on the device).
Television device implementations which do not have a built in display, but instead support an
external display connected via HDMI; they:
[ 5.8 /T-0-1] MUST set the HDMI output mode to select the maximum resolution that can
be supported with either a 50Hz or 60Hz refresh rate.
[ 5.8 /T-SR] Are STRONGLY RECOMMENDED to provide a user configurable HDMI refresh
rate selector.
[ 5.8 ] SHOULD set the HDMI output mode refresh rate to either 50Hz or 60Hz, depending
on the video refresh rate for the region the device is sold in.
If Television device implementations who do not have a built in display, but instead support an
external display connected via HDMI; they:
[ 5.8 /T-1-1] MUST support HDCP 2.2.
If Television device implementations which do not support UHD decoding but have but instead
support an external display connected via HDMI; they:
[ 5.8 /T-2-1] MUST support HDCP 1.4
2.3.3. Software
Television device implementations:
[ 3 /T-0-1] MUST declare the features android.software.leanback and
android.hardware.type.television .
[ 3.4 .1/T-0-1] MUST provide a complete implementation of the
android.webkit.Webview API.
If Android Television device implementations support a lock screen,they:
[ 3.8 .10/T-1-1] MUST display the Lock screen Notifications including the Media
Notification Template.
Television device implementations:
[ 3.8 .14/T-SR] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode
multi-window.
[ 3.10 /T-0-1] MUST support third-party accessibility services.
[ 3.10 /T-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the
device comparable with or exceeding functionality of the Switch Access and TalkBack (for
languages supported by the preloaded Text-to-speech engine) accessibility services as
provided in the talkback open source project .
If Television device implementations report the feature android.hardware.audio.output , they:
[ 3.11 /T-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the
languages available on the device.
[ 3.11 /T-1-1] MUST support installation of third-party TTS engines.
Television device implementations:
[ 3.12 /T-0-1] MUST support TV Input Framework.

2.3.4. Performance and Power
[ 8.1 /T-0-1] Consistent frame latency . Inconsistent frame latency or a delay to render
frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1
frames in a second.
[ 8.2 /T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
[ 8.2 /T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
[ 8.2 /T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
[ 8.2 /T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
If Television device implementations include features to improve device power management that are
included in AOSP or extend the features that are included in AOSP, they:
[ 8.3 /T-1-1] MUST provide user affordance to enable and disable the battery saver feature.
If Television device implementations do not have a battery they:
[ 8.3 /T-1-2] MUST register the device as a batteryless device as described in Supporting
Batteryless Devices .
If Television device implementations have a battery they:
[ 8.3 /T-1-3] MUST provide user affordance to display all apps that are exempted from App
Standby and Doze power-saving modes.
Television device implementations:
[ 8.4 /T-0-1] MUST provide a per-component power profile that defines the current
consumption value for each hardware component and the approximate battery drain
caused by the components over time as documented in the Android Open Source Project
site.
[ 8.4 /T-0-2] MUST report all power consumption values in milliampere hours (mAh).
[ 8.4 /T-0-3] MUST report CPU power consumption per each process's UID. The Android
Open Source Project meets the requirement through the uid_cputime kernel module
implementation.
[ 8.4 /T] SHOULD be attributed to the hardware component itself if unable to attribute
hardware component power usage to an application.
[ 8.4 /T-0-4] MUST make this power usage available via the adbshelldumpsys
batterystats shell command to the app developer.
2.3.5. Security Model
Television device implementations:
[ 9.11 /T-0-1] MUST back up the keystore implementation with an isolated execution
environment.
[ 9.11 /T-0-2] MUST have implementations of RSA, AES, ECDSA and HMAC cryptographic
algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the
Android Keystore system's supported algorithms in an area that is securely isolated from
the code running on the kernel and above. Secure isolation MUST block all potential
mechanisms by which kernel or userspace code might access the internal state of the
isolated environment, including DMA. The upstream Android Open Source Project (AOSP)
meets this requirement by using the Trusty implementation, but another ARM TrustZone-
based solution or a third-party reviewed secure implementation of a proper hypervisor-
based isolation are alternative options.
[ 9.11 /T-0-3] MUST perform the lock screen authentication in the isolated execution
environment and only when successful, allow the authentication-bound keys to be used.
Lock screen credentials MUST be stored in a way that allows only the isolated execution
environment to perform lock screen authentication. The upstream Android Open Source
Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can
be used to satisfy this requirement.
[ 9.11 /T-0-4] MUST support key attestation where the attestation signing key is protected
by secure hardware and signing is performed in secure hardware. The attestation signing
keys MUST be shared across large enough number of devices to prevent the keys from

being used as device identifiers. One way of meeting this requirement is to share the same
attestation key unless at least 100,000 units of a given SKU are produced. If more than
100,000 units of an SKU are produced, a different key MAY be used for each 100,000 units.
Note that if a device implementation is already launched on an earlier Android version, such a device
is exempted from the requirement to have a keystore backed by an isolated execution environment
and support the key attestation, unless it declares the android.hardware.fingerprint feature which
requires a keystore backed by an isolated execution environment.
If Television device implementations support a secure lock screen, they:
[ 9.11 /T-1-1] MUST allow the user to choose the Sleep timeout for transition from the
unlocked to the locked state, with a minimum allowable timout up to 15 seconds or less.
2.3.6. Developer Tools and Options Compatibility
Television device implementations:
Perfetto
[ 6.1 /T-0-1] MUST expose a /system/bin/perfetto binary to the shell user
which cmdline complies with the perfetto documentation .
[ 6.1 /T-0-2] The perfetto binary MUST accept as input a protobuf config that
complies with the schema defined in the perfetto documentation .
[ 6.1 /T-0-3] The perfetto binary MUST write as output a protobuf trace that
complies with the schema defined in the perfetto documentation .
[ 6.1 /T-0-4] MUST provide, through the perfetto binary, at least the data
sources described in the perfetto documentation .
2.4. Watch Requirements
An Android Watch device refers to an Android device implementation intended to be worn on the
body, perhaps on the wrist.
Android device implementations are classified as a Watch if they meet all the following criteria:
Have a screen with the physical diagonal length in the range from 1.1 to 2.5 inches.
Have a mechanism provided to be worn on the body.
The additional requirements in the rest of this section are specific to Android Watch device
implementations.
2.4.1. Hardware
Watch device implementations:
[ 7.1 .1.1/W-0-1] MUST have a screen with the physical diagonal size in the range from 1.1
to 2.5 inches.
[ 7.2 .3/W-0-1] MUST have the Home function available to the user, and the Back function
except for when it is in UI_MODE_TYPE_WATCH .
[ 7.2 .4/W-0-1] MUST support touchscreen input.
[ 7.3 .1/W-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
If Watch device implementations include a GPS/GNSS receiver and report the capability to
applications through the android.hardware.location.gps feature flag, they:
[ 7.3 .3/W-1-1] MUST report GNSS measurements, as soon as they are found, even if a
location calculated from GPS/GNSS is not yet reported.
[ 7.3 .3/W-1-2] MUST report GNSS pseudoranges and pseudorange rates, that, in open-sky
conditions after determining the location, while stationary or moving with less than 0.2
meter per second squared of acceleration, are sufficient to calculate position within 20
meters, and speed within 0.2 meters per second, at least 95% of the time.
[ 7.4 .3/W-0-1] MUST support Bluetooth.
[ 7.6 .1/W-0-1] MUST have at least 1 GB of non-volatile storage available for application

剩余128页未读，继续阅读

车载系统小架构

粉丝: 0
资源: 1

Android 10 兼容性要求详解

如何检查Android studioXML文档的版本是否与当前项目的目标SDK兼容

android开发文档怎么写

安卓开发计算器ui设计的实验文档

uniapp 鸿蒙系统

前端 安卓 ios在项目中如何合作

arch: { arm: { instruction_set: "arm", }, },

软件测试需求文档模板

android usb鱼眼摄像头代码实现预览拍照

usb spec download

qca6410 pdf

最新资源

前端安卓 ios在项目中如何合作