Android 7.1 兼容性定义文档

需积分: 9 108 浏览量更新于2024-07-18 收藏 586KB PDF 举报

"这是关于Google Android 7.1的兼容性定义文档，主要涵盖了硬件和软件在Android L平台上的各种需求和规范。这份文档由Google Inc.于2016年12月20日更新，旨在确保设备与Android 7.1系统的无缝协作。" 在Android 7.1的兼容性定义(CCD)中，主要知识点包括： 1. **设备类型** (Device Types): 这部分可能详细介绍了不同类型的Android设备，如智能手机、平板电脑、电视、汽车等，并规定了它们必须遵循的配置和兼容性标准。 2. **设备配置** (Device Configurations): 这里可能涉及到屏幕尺寸、分辨率、硬件组件规格等方面，确保设备在运行Android 7.1时能正确处理各种用户界面和功能。 3. **软件兼容性** (Software): - **管理API兼容性** (Managed API Compatibility): 讨论了如何确保第三方应用和系统API之间的兼容性，尤其是Android Extensions的使用。 - **软API兼容性** (Soft API Compatibility): 包括权限管理、构建参数、意图兼容性等多个子项。 - **权限** (Permissions): 设备应支持Android 7.1的所有必要权限，并正确处理权限请求。 - **构建参数** (Build Parameters): 设备的构建属性需符合Android 7.1的标准。 - **意图兼容性** (Intent Compatibility): 包括核心应用意图、意图解析、意图命名空间和广播意图等，确保意图系统在设备上的正确工作。 - **默认应用设置** (Default App Settings): 详细列出了默认应用设置的兼容性和要求。 - **原生API兼容性** (Native API Compatibility): 关注于应用二进制接口（ABI）、图形库和其他与原生代码相关的兼容性问题。 - **32位ARM原生代码兼容性** (32-bit ARM Native Code Compatibility): 确保设备能够支持32位ARM架构的应用程序。 - **Web兼容性** (Web Compatibility): 分析了WebView和浏览器的兼容性要求，确保网页内容在Android 7.1上能正确渲染和交互。 4. **API行为兼容性** (API Behavioral Compatibility): 详细描述了API的行为应该如何保持一致，即使在不同的硬件或定制系统上。 5. **API命名空间** (APINamespaces): 规定了API组织和分类的规则，保证了API的可发现性和一致性。 6. **运行时兼容性** (Runtime Compatibility): 强调了Android运行时环境对设备的要求，如Dalvik VM或ART的版本和优化。 7. **用户界面兼容性** (User Interface Compatibility): - **启动器(主屏幕)** (Launcher (Home Screen)): 确保主屏幕的布局、小部件和图标在所有设备上的一致性。 - **小部件** (Widgets): 详细列出了小部件的显示和交互要求。 - **通知** (Notifications): 描述了通知栏的样式、功能和行为规范。 - **搜索** (Search): 搜索功能的实现和兼容性标准。 - **吐司** (Toasts): 对弹出消息提示框的显示和消失规则做了规定。 - **主题** (Themes): 设定了主题和视觉元素的兼容性。 - **实时壁纸** (Live Wallpapers): 实时壁纸的性能和功能要求。 - **活动切换** (Activity Switching): 用户在不同应用之间切换的流畅度和一致性。 - **输入管理** (Input Management): 如键盘、触摸屏和其他输入设备的响应性和兼容性。 - **锁屏媒体控制** (Lock Screen Media Control): 设定了在锁屏状态下控制媒体播放的标准。 - **屏幕保护程序** (Screensavers): 可能提到了对于预Android 7.1版本中屏幕保护程序的兼容性要求。这个文档是开发者和制造商确保其设备和应用与Android 7.1系统兼容的重要参考，涵盖了从底层硬件到用户界面的全面兼容性指南。

MUST report the correct PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and

PackageManager#FEATURE_VULKAN_HARDWARE_VERSION feature flags.

MUST enumerate layers, contained in native libraries named libVkLayer*.so in the

application package’s native library directory, through the

vkEnumerateInstanceLayerProperties and

vkEnumerateDeviceLayerProperties functions in libvulkan.so

MUST NOT enumerate layers provided by libraries outside of the application package, or

provide other ways of tracing or intercepting the Vulkan API, unless the application has the

android:debuggable=”true” attribute.

Device implementations, if not including support of the Vulkan APIs:

MUST report 0 VkPhysicalDevices through the vkEnumeratePhysicalDevices

call.

MUST NOT delare any of the Vulkan feature flags

PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and

PackageManager#FEATURE_VULKAN_HARDWARE_VERSION .

3.3.2. 32-bit ARM Native Code Compatibility

The ARMv8 architecture deprecates several CPU operations, including some operations used in

existing native code. On 64-bit ARM devices, the following deprecated operations MUST remain

available to 32-bit native ARM code, either through native CPU support or through software emulation:

SWP and SWPB instructions

SETEND instruction

CP15ISB, CP15DSB, and CP15DMB barrier operations

Legacy versions of the Android NDK used /proc/cpuinfo to discover CPU features from 32-bit ARM

native code. For compatibility with applications built using this NDK, devices MUST include the

following lines in /proc/cpuinfo when it is read by 32-bit ARM applications:

"Features: ", followed by a list of any optional ARMv7 CPU features supported by the

device.

"CPU architecture: ", followed by an integer describing the device's highest supported ARM

architecture (e.g., "8" for ARMv8 devices).

These requirements only apply when /proc/cpuinfo is read by 32-bit ARM applications. Devices

SHOULD not alter /proc/cpuinfo when read by 64-bit ARM or non-ARM applications.

3.4. Web Compatibility

3.4.1. WebView Compatibility

Android Watch devices MAY, but all other device implementations MUST provide a complete

implementation of the android.webkit.Webview API.

The platform feature android.software.webview MUST be reported on any device that provides a

complete implementation of the android.webkit.WebView API, and MUST NOT be reported on devices

without a complete implementation of the API. The Android Open Source implementation uses code

from the Chromium Project to implement the android.webkit.WebView . Because it is not feasible to

develop a comprehensive test suite for a web rendering system, device implementers MUST use the

specific upstream build of Chromium in the WebView implementation. Specifically:

Page 14 of 86

Device android.webkit.WebView implementations MUST be based on the Chromium build

from the upstream Android Open Source Project for Android 7.1. This build includes a

specific set of functionality and security fixes for the WebView.

The user agent string reported by the WebView MUST be in this format:

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv)

AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile

Safari/537.36

The value of the $(VERSION) string MUST be the same as the value for

android.os.Build.VERSION.RELEASE.

The value of the $(MODEL) string MUST be the same as the value for

android.os.Build.MODEL.

The value of the $(BUILD) string MUST be the same as the value for

android.os.Build.ID.

The value of the $(CHROMIUM_VER) string MUST be the version of

Chromium in the upstream Android Open Source Project.

Device implementations MAY omit Mobile in the user agent string.

The WebView component SHOULD include support for as many HTML5 features as possible and if it

supports the feature SHOULD conform to the HTML5 specification .

3.4.2. Browser Compatibility

Android Television, Watch, and Android Automotive implementations MAY omit a browser

application, but MUST support the public intent patterns as described in section 3.2.3.1 . All

other types of device implementations MUST include a standalone Browser application for

general user web browsing.

The standalone Browser MAY be based on a browser technology other than WebKit. However, even if

an alternate Browser application is used, the android.webkit.WebView component provided to third-

party applications MUST be based on WebKit, as described in section 3.4.1 .

Implementations MAY ship a custom user agent string in the standalone Browser application.

The standalone Browser application (whether based on the upstream WebKit Browser application or a

third-party replacement) SHOULD include support for as much of HTML5 as possible. Minimally,

device implementations MUST support each of these APIs associated with HTML5:

application cache/offline operation

<video> tag

geolocation

Additionally, device implementations MUST support the HTML5/W3C webstorage API and SHOULD

support the HTML5/W3C IndexedDB API . Note that as the web development standards bodies are

transitioning to favor IndexedDB over webstorage, IndexedDB is expected to become a required

component in a future version of Android.

3.5. API Behavioral Compatibility

The behaviors of each of the API types (managed, soft, native, and web) must be consistent with the

preferred implementation of the upstream Android Open Source Project . Some specific areas of

compatibility are:

Devices MUST NOT change the behavior or semantics of a standard intent.

Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type of system

component (such as Service, Activity, ContentProvider, etc.).

Page 15 of 86

Devices MUST NOT change the semantics of a standard permission.

The above list is not comprehensive. The Compatibility Test Suite (CTS) tests significant portions of

the platform for behavioral compatibility, but not all. It is the responsibility of the implementer to ensure

behavioral compatibility with the Android Open Source Project. For this reason, device implementers

SHOULD use the source code available via the Android Open Source Project where possible, rather

than re-implement significant parts of the system.

3.6. API Namespaces

Android follows the package and class namespace conventions defined by the Java programming

language. To ensure compatibility with third-party applications, device implementers MUST NOT make

any prohibited modifications (see below) to these package namespaces:

java.*

javax.*

sun.*

android.*

com.android.*

Prohibited modifications include :

Device implementations MUST NOT modify the publicly exposed APIs on the Android

platform by changing any method or class signatures, or by removing classes or class

fields.

Device implementers MAY modify the underlying implementation of the APIs, but such

modifications MUST NOT impact the stated behavior and Java-language signature of any

publicly exposed APIs.

Device implementers MUST NOT add any publicly exposed elements (such as classes or

interfaces, or fields or methods to existing classes or interfaces) to the APIs above.

A “publicly exposed element” is any construct that is not decorated with the“@hide” marker as used in

the upstream Android source code. In other words, device implementers MUST NOT expose new

APIs or alter existing APIs in the namespaces noted above. Device implementers MAY make internal-

only modifications, but those modifications MUST NOT be advertised or otherwise exposed to

developers.

Device implementers MAY add custom APIs, but any such APIs MUST NOT be in a namespace

owned by or referring to another organization. For instance, device implementers MUST NOT add

APIs to the com.google.* or similar namespace: only Google may do so. Similarly, Google MUST NOT

add APIs to other companies' namespaces. Additionally, if a device implementation includes custom

APIs outside the standard Android namespace, those APIs MUST be packaged in an Android shared

library so that only apps that explicitly use them (via the <uses-library> mechanism) are affected by

the increased memory usage of such APIs.

If a device implementer proposes to improve one of the package namespaces above (such as by

adding useful new functionality to an existing API, or adding a new API), the implementer SHOULD

visit source.android.com and begin the process for contributing changes and code, according to the

information on that site.

Note that the restrictions above correspond to standard conventions for naming APIs in the Java

programming language; this section simply aims to reinforce those conventions and make them

binding through inclusion in this Compatibility Definition.

3.7. Runtime Compatibility

Page 16 of 86

剩余85页未读，继续阅读

we_11

粉丝: 0
资源: 3

Android 7.1 兼容性定义文档

ccd 成像原理文档

stm32驱动CCD.zip_CCD 驱动_CCD 驱动 STM32_stm32线性ccd_stm32线性ccd pid_线性c

stm32线性CCD摄像头实验程序.zip_stm32+线性ccd_线性CCD程序32_线性ccd_线性摄像头

线阵CCD和面阵CCD的特性对比

海康威视ccd sdk手册

ccd传感器驱动FPGA

用光源照射CCD，怎样分析是否照坏CCD

面阵CCD和线阵CCD有什么区别？

线阵ccd与面阵ccd

ccd驱动fpga代码

最新资源