fuquan/allwinner_a64
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

upload android base code part4

Browse source
This commit is contained in:
August 2018-08-08 17:00:29 +08:00
parent b9e30e05b1
commit 78ea2404cd
23455 changed files with 5250148 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

32
android/compatibility/cdd/7_hardware-compatibility/7_0_intro.md Normal file
View file

@ -0,0 +1,32 @@
# 7\. Hardware Compatibility
If a device includes a particular hardware component that has a corresponding
API for third-party developers:
* [C-0-1] The device implementation MUST implement that
API as described 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:
* [C-0-2] Complete class definitions (as documented by the SDK) for the component
APIs MUST still be presented.
* [C-0-3] The API’s behaviors MUST be implemented as no-ops in some reasonable
fashion.
* [C-0-4] API methods MUST return null values where permitted by the SDK
documentation.
* [C-0-5] API methods MUST return no-op implementations of classes where null values
are not permitted by the SDK documentation.
* [C-0-6] API methods MUST NOT throw exceptions not documented by the SDK
documentation.
* [C-0-7] Device implementations MUST consistently report accurate hardware
configuration information via the `getSystemAvailableFeatures()` and
`hasSystemFeature(String)` methods on the
[android.content.pm.PackageManager](
http://developer.android.com/reference/android/content/pm/PackageManager.html)
class for the same build fingerprint.
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.

389
android/compatibility/cdd/7_hardware-compatibility/7_1_display-and-graphics.md Normal file
View file

@ -0,0 +1,389 @@
## 7.1\. Display and Graphics
Android includes facilities that automatically adjust application assets and UI
layouts appropriately for the device to ensure that third-party applications
run well on a [variety of hardware configurations](http://developer.android.com/guide/practices/screens_support.html).
Devices MUST properly implement these APIs and behaviors, as detailed in this
section.
The units referenced by the requirements in this section are defined as follows:
* **physical diagonal size**. The distance in inches between two opposing
corners of the illuminated portion of the display.
* **dots per inch (dpi)**. The number of pixels encompassed by a linear
horizontal or vertical span of 1”. Where dpi values are listed, both horizontal
and vertical dpi must fall within the range.
* **aspect ratio**. The ratio of the pixels of the longer dimension to the
shorter dimension of the screen. For example, a display of 480x854 pixels would
be 854/480 = 1.779, or roughly “16:9”.
* **density-independent pixel (dp)**. The virtual pixel unit normalized to a
160 dpi screen, calculated as: pixels = dps * (density/160).
### 7.1.1\. Screen Configuration
#### 7.1.1.1\. Screen Size
* [H-0-1] Handheld device implementations MUST have a screen at least 2.5
inches in physical diagonal size.
* [A-0-1] Android Automotive devices MUST have a screen at least 6 inches
in physical diagonal size.
* [A-0-2] Android Automotive devices MUST have a screen size layout of
at least 750 dp x 480 dp.
* [W-0-1] Android Watch device implementations MUST have a screen with the
physical diagonal size in the range from 1.1 to 2.5 inches.
The Android UI framework supports a variety of different logical screen layout
sizes, and allows applications to query the current configuration's screen
layout size via `Configuration.screenLayout` with the `SCREENLAYOUT_SIZE_MASK`
and `Configuration.smallestScreenWidthDp`.
* [C-0-1] Device implementations MUST report the correct layout size for the
`Configuration.screenLayout` as defined in the Android SDK documentation.
Specifically, device implementations MUST report the correct logical
density-independent pixel (dp) screen dimensions as below:
* Devices with the `Configuration.uiMode` set as any value other than
UI_MODE_TYPE_WATCH, and reporting a `small` size for the
`Configuration.screenLayout`, MUST have at least 426 dp x 320 dp.
* Devices reporting a `normal` size for the `Configuration.screenLayout`,
MUST have at least 480 dp x 320 dp.
* Devices reporting a `large` size for the `Configuration.screenLayout`,
MUST have at least 640 dp x 480 dp.
* Devices reporting a `xlarge` size for the `Configuration.screenLayout`,
MUST have at least 960 dp x 720 dp.
* [C-0-2] Device implementations MUST correctly honor applications' stated
support for screen sizes through the [<`supports-screens`>](
https://developer.android.com/guide/topics/manifest/supports-screens-element.html)
attribute in the AndroidManifest.xml, as described
in the Android SDK documentation.
#### 7.1.1.2\. Screen Aspect Ratio
While there is no restriction to the screen aspect ratio value of the physical
screen display, the screen aspect ratio of the logical display that third-party
apps are rendered within, as can be derived from the height and width values
reported through the [`view.Display`](
https://developer.android.com/reference/android/view/Display.html)
APIs and [Configuration](
https://developer.android.com/reference/android/content/res/Configuration.html)
API, MUST meet the following requirements:
* [C-0-1] Device implementations with the `Configuration.uiMode` set as
`UI_MODE_TYPE_NORMAL` MUST have an aspect ratio value between 1.3333 (4:3)
and 1.86 (roughly 16:9), unless the app can be deemed as ready to be
stretched longer by meeting one of the following conditions:
* The app has declared that it supports a larger screen aspect ratio
through the [`android.max_aspect`](
https://developer.android.com/guide/practices/screens_support.html#MaxAspectRatio)
metadata value.
* The app declares it is resizeable via the [android:resizeableActivity](
https://developer.android.com/guide/topics/ui/multi-window.html#configuring)
attribute.
* The app is targeting API level 26 or higher and does not declare a
[`android:MaxAspectRatio`](
https://developer.android.com/reference/android/R.attr.html#maxAspectRatio)
that would restrict the allowed aspect ratio.
* [C-0-2] Device implementations with the `Configuration.uiMode` set as
`UI_MODE_TYPE_WATCH` MUST have an aspect ratio value set as 1.0 (1:1).
#### 7.1.1.3\. Screen Density
The Android UI framework defines a set of standard logical densities to help
application developers target application resources.
* [C-0-1] By default, device implementations MUST report only one of the
following logical Android framework densities through the
[DENSITY_DEVICE_STABLE](
https://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_DEVICE_STABLE)
API and this value MUST NOT change at any time; however, the device MAY report
a different arbitrary density according to the display configuration changes
made by the user (for example, display size) set after initial boot.
* 120 dpi (ldpi)
* 160 dpi (mdpi)
* 213 dpi (tvdpi)
* 240 dpi (hdpi)
* 260 dpi (260dpi)
* 280 dpi (280dpi)
* 300 dpi (300dpi)
* 320 dpi (xhdpi)
* 340 dpi (340dpi)
* 360 dpi (360dpi)
* 400 dpi (400dpi)
* 420 dpi (420dpi)
* 480 dpi (xxhdpi)
* 560 dpi (560dpi)
* 640 dpi (xxxhdpi)
* Device implementations SHOULD define the standard Android framework density
that is numerically closest to the physical density of the screen, unless that
logical density pushes the reported screen size below the minimum supported. If
the standard Android framework density that is numerically closest to the
physical density results in a screen size that is smaller than the smallest
supported compatible screen size (320 dp width), device implementations SHOULD
report the next lowest standard Android framework density.
* [H-SR] Device implementations are STRONGLY RECOMMENDED to provide users an
affordance to change the display size.
If there is an affordance to change the display size of the device:
* [C-1-1] The display size MUST NOT be scaled any larger than 1.5 times the native density or
produce an effective minimum screen dimension smaller than 320dp (equivalent
to resource qualifier sw320dp), whichever comes first.
* [C-1-2] Display size MUST NOT be scaled any smaller than 0.85 times the native density.
* To ensure good usability and consistent font sizes, it is RECOMMENDED that the
following scaling of Native Display options be provided (while complying with the limits
specified above)
* Small: 0.85x
* Default: 1x (Native display scale)
* Large: 1.15x
* Larger: 1.3x
* Largest 1.45x
### 7.1.2\. Display Metrics
If device implementations include a screen or video output, they:
* [C-1-1] MUST report correct values for all display metrics defined in the
[`android.util.DisplayMetrics`](
https://developer.android.com/reference/android/util/DisplayMetrics.html) API.
If device implementations does not include an embedded screen or video output,
they:
* [C-2-1] MUST report reasonable values for all display metrics defined in
the [`android.util.DisplayMetrics`](
https://developer.android.com/reference/android/util/DisplayMetrics.html) API
for the emulated default `view.Display`.
### 7.1.3\. Screen Orientation
Device implementations:
* [C-0-1] MUST report which screen orientations they support
(`android.hardware.screen.portrait` and/or
`android.hardware.screen.landscape`) and MUST report at least one supported
orientation. For example, a device with a fixed orientation landscape
screen, such as a television or laptop, SHOULD only
report `android.hardware.screen.landscape`.
* [C-0-2] 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.
If device implementations support both screen orientations, they:
* [C-1-1] 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.
* [C-1-2] MUST NOT change the reported screen size or density when changing orientation.
* MAY select either portrait or landscape orientation as the default.
### 7.1.4\. 2D and 3D Graphics Acceleration
#### 7.1.4.1 OpenGL ES
Device implementations:
* [C-0-1] MUST correctly identify the supported OpenGL ES versions (1.1, 2.0,
3.0, 3.1, 3.2) through the managed APIs (such as via the
`GLES10.getString()` method) and the native APIs.
* [C-0-2] MUST include the support for all the corresponding managed APIs and
native APIs for every OpenGL ES versions they identified to support.
If device implementations include a screen or video output, they:
* [C-1-1] MUST support both OpenGL ES 1.0 and 2.0, as embodied and detailed
in the [Android SDK documentation](
https://developer.android.com/guide/topics/graphics/opengl.html).
* [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.0.
* SHOULD support OpenGL ES 3.1 or 3.2.
If device implementations support any of the OpenGL ES versions, they:
* [C-2-1] MUST report via the OpenGL ES managed APIs and native APIs any
other OpenGL ES extensions they have implemented, and conversely MUST
NOT report extension strings that they do not support.
* [C-2-2] MUST support the `EGL_KHR_image`, `EGL_KHR_image_base`,
`EGL_ANDROID_image_native_buffer`, `EGL_ANDROID_get_native_client_buffer`,
`EGL_KHR_wait_sync`, `EGL_KHR_get_all_proc_addresses`,
`EGL_ANDROID_presentation_time`, `EGL_KHR_swap_buffers_with_damage` and
`EGL_ANDROID_recordable` extensions.
* [SR] are STRONGLY RECOMMENDED to support EGL_KHR_partial_update.
* SHOULD accurately report via the `getString()` method, any texture
compression format that they support, which is typically vendor-specific.
If device implementations declare support for OpenGL ES 3.0, 3.1, or 3.2, they:
* [C-3-1] MUST export the corresponding function symbols for these version in
addition to the OpenGL ES 2.0 function symbols in the libGLESv2.so library.
If device implementations support OpenGL ES 3.2, they:
* [C-4-1] MUST support the OpenGL ES Android Extension Pack in its entirety.
If device implementations support the OpenGL ES [Android Extension Pack](
https://developer.android.com/reference/android/opengl/GLES31Ext.html) in its
entirety, they:
* [C-5-1] MUST identify the support through the `android.hardware.opengles.aep`
feature flag.
If device implementations expose support for the `EGL_KHR_mutable_render_buffer`
extension, they:
* [C-6-1] MUST also support the `EGL_ANDROID_front_buffer_auto_refresh`
extension.
#### 7.1.4.2 Vulkan
Android includes support for [Vulkan](
https://www.khronos.org/registry/vulkan/specs/1.0-wsi&lowbarextensions/xhtml/vkspec.html)
, a low-overhead, cross-platform API for high-performance 3D graphics.
If device implementations support OpenGL ES 3.0 or 3.1, they:
* [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.0 .
If device implementations include a screen or video output, they:
* SHOULD include support for Vulkan 1.0.
Device implementations, if including support for Vulkan 1.0:
* [C-1-1] MUST report the correct integer value with the
`android.hardware.vulkan.level` and `android.hardware.vulkan.version`
feature flags.
* [C-1-2] MUST enumarate, at least one `VkPhysicalDevice` for the Vulkan
native API [`vkEnumeratePhysicalDevices()`](
https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkEnumeratePhysicalDevices.html)
.
* [C-1-3] MUST fully implement the Vulkan 1.0 APIs for each enumerated
`VkPhysicalDevice`.
* [C-1-4] MUST enumerate layers, contained in native libraries named as
`libVkLayer*.so` in the application package’s native library directory,
through the Vulkan native APIs [`vkEnumerateInstanceLayerProperties()`](
https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkEnumerateInstanceLayerProperties.html)
and [`vkEnumerateDeviceLayerProperties()`](
https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkEnumerateDeviceLayerProperties.html)
.
* [C-1-5] 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` attribute
set as `true`.
* [C-1-6] MUST report all extension strings that they do support via the
Vulkan native APIs , and conversely MUST NOT report extension strings
that they do not correctly support.
Device implementations, if not including support for Vulkan 1.0:
* [C-2-1] MUST NOT declare any of the Vulkan feature flags (e.g.
`android.hardware.vulkan.level`, `android.hardware.vulkan.version`).
* [C-2-2] MUST NOT enumarate any `VkPhysicalDevice` for the Vulkan native API
`vkEnumeratePhysicalDevices()`.
#### 7.1.4.3 RenderScript
* [C-0-1] Device implementations MUST support [Android RenderScript](
http://developer.android.com/guide/topics/renderscript/), as detailed
in the Android SDK documentation.
#### 7.1.4.4 2D Graphics Acceleration
Android includes a mechanism for applications to declare that they want to
enable hardware acceleration for 2D graphics at the Application, Activity,
Window, or View level through the use of a manifest tag
[android:hardwareAccelerated](
http://developer.android.com/guide/topics/graphics/hardware-accel.html)
or direct API calls.
Device implementations:
* [C-0-1] MUST enable hardware acceleration by default, and MUST
disable hardware acceleration if the developer so requests by setting
android:hardwareAccelerated="false” or disabling hardware acceleration
directly through the Android View APIs.
* [C-0-2] MUST exhibit behavior consistent with the
Android SDK documentation on [hardware acceleration](
http://developer.android.com/guide/topics/graphics/hardware-accel.html).
Android includes a TextureView object that lets developers directly integrate
hardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy.
* [C-0-3] MUST support the TextureView API, and MUST exhibit
consistent behavior with the upstream Android implementation.
#### 7.1.4.5 Wide-gamut Displays
If device implementations claim support for wide-gamut displays through
[`Display.isWideColorGamut()`
](https://developer.android.com/reference/android/view/Display.html#isWideColorGamut%28%29)
, they:
* [C-1-1] MUST have a color-calibrated display.
* [C-1-2] MUST have a display whose gamut covers the sRGB color gamut entirely
in CIE 1931 xyY space.
* [C-1-3] MUST have a display whose gamut has an area of at least 90% of NTSC
1953 in CIE 1931 xyY space.
* [C-1-4] MUST support OpenGL ES 3.0, 3.1, or 3.2 and report it properly.
* [C-1-5] MUST advertise support for the `EGL_KHR_no_config_context`,
`EGL_EXT_pixel_format_float`,`EGL_KHR_gl_colorspace`,
`EGL_EXT_colorspace_scrgb_linear`, and `EGL_GL_colorspace_display_p3`
extensions.
* [SR] Are STRONGLY RECOMMENDED to support `GL_EXT_sRGB`.
Conversely, if device implementations do not support wide-gamut displays, they:
* [C-2-1] SHOULD cover 100% or more of sRGB in CIE 1931 xyY space, although
the screen color gamut is undefined.
### 7.1.5\. Legacy Application Compatibility Mode
Android specifies a “compatibility mode” in which the framework operates in a
'normal' screen size equivalent (320dp width) mode for the benefit of legacy
applications not developed for old versions of Android that pre-date
screen-size independence.
* [H-0-1] Handheld device implementations MUST include support
for legacy application compatibility mode as implemented by the upstream
Android open source code. That is, device implementations MUST NOT alter the
triggers or thresholds at which compatibility mode is activated, and MUST
NOT alter the behavior of the compatibility mode itself.
### 7.1.6\. Screen Technology
The Android platform includes APIs that allow applications to render rich
graphics to the display. Devices MUST support all of these APIs as defined by
the Android SDK unless specifically allowed in this document.
Device implementations:
* [C-0-1] MUST support displays capable of rendering 16-bit color graphics.
* SHOULD support displays capable of 24-bit color graphics.
* [C-0-2] MUST support displays capable of rendering animations.
* [C-0-3] MUST use the display technology that have a pixel aspect ratio (PAR)
between 0.9 and 1.15\. That is, the pixel aspect ratio MUST be near square
(1.0) with a 10 ~ 15% tolerance.
### 7.1.7\. Secondary Displays
Android includes support for secondary display to enable media sharing
capabilities and developer APIs for accessing external displays.
If device implementations support an external display either via a wired,
wireless, or an embedded additional display connection, they:
* [C-1-1] MUST implement the [`DisplayManager`](
https://developer.android.com/reference/android/hardware/display/DisplayManager.html)
system service and API as described in the Android SDK documentation.

388
android/compatibility/cdd/7_hardware-compatibility/7_2_input-devices.md Normal file
View file

@ -0,0 +1,388 @@
## 7.2\. Input Devices
Device implementations:
* [C-0-1] MUST include an input mechanism, such as a
[touchscreen](#7_2_4_touchScreen_input) or [non-touch navigation](#7_2_2_non-touch_navigation),
to navigate between the UI elements.
### 7.2.1\. Keyboard
* [H-0-1] Handheld device implementations MUST include support for
third-party Input Method Editor (IME) applications.
* [T-0-1] Television device implementations MUST include support for
third-party Input Method Editor (IME) applications.
If device implementations include support for third-party
Input Method Editor (IME) applications, they:
* [C-1-1] MUST declare the [`android.software.input_methods`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_INPUT_METHODS)
feature flag.
* [C-1-2] MUST implement fully [`Input Management Framework`](https://developer.android.com/reference/android/view/inputmethod/InputMethodManager.html)
* [C-1-3] MUST have a preloaded software keyboard.
Device implementations:
* [C-0-1] MUST NOT include a hardware keyboard that does not match one of the
formats specified in [android.content.res.Configuration.keyboard](
http://developer.android.com/reference/android/content/res/Configuration.html)
(QWERTY or 12-key).
* SHOULD include additional soft keyboard implementations.
* MAY include a hardware keyboard.
### 7.2.2\. Non-touch Navigation
Android includes support for d-pad, trackball, and wheel as mechanisms for
non-touch navigation.
Television device implementations:
* [T-0-1] MUST support [D-pad](https://developer.android.com/reference/android/content/res/Configuration.html#NAVIGATION_DPAD).
Device implementations:
* [C-0-1] MUST report the correct value for
[android.content.res.Configuration.navigation](
https://developer.android.com/reference/android/content/res/Configuration.html#navigation).
If device implementations lack non-touch navigations, they:
* [C-1-1] MUST provide a reasonable alternative user interface mechanism for the
selection and editing of text, compatible with Input Management Engines. The
upstream Android open source implementation includes a selection mechanism
suitable for use with devices that lack non-touch navigation inputs.
### 7.2.3\. Navigation Keys
The [Home](http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_HOME`),
[Recents](http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_APP_SWITCH`),
and [Back](http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_BACK`)
functions typically provided via an interaction with a dedicated physical button
or a distinct portion of the touch screen, are essential to the Android
navigation paradigm and therefore:
* [H-0-1] Android Handheld device implementations MUST provide the Home,
Recents, and Back functions.
* [H-0-2] Android Handheld device implementations MUST send both the normal
and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
to the foreground application.
* [T-0-1] Android Television device implementations MUST provide the Home
and Back functions.
* [T-0-2] Android Television device implementations MUST send both the normal
and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
to the foreground application.
* [W-0-1] Android Watch device implementations MUST have the Home function
available to the user, and the Back function except for when it is in
`UI_MODE_TYPE_WATCH`.
* [A-0-1] Automotive device implementations MUST provide the Home function
and MAY provide Back and Recent functions.
* [A-0-2] Automotive device implementations MUST send both the normal
and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
to the foreground application.
* [C-0-1] MUST provide the Home function.
* SHOULD provide buttons for the Recents and Back function.
If the Home, Recents, or Back functions are provided, they:
* [C-1-1] MUST be accessible with a single action (e.g. tap, double-click or
gesture) when any of them are accessible.
* [C-1-2] MUST provide a clear indication of which single action would trigger
each function. Having a visible icon imprinted on the button, showing a software
icon on the navigation bar portion of the screen, or walking the user through a
guided step-by-step demo flow during the out-of-box setup experience are
examples of such an indication.
Device implementations:
* [SR] are STRONGLY RECOMMENDED to not provide the input mechanism for the
[Menu function](http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_BACK`)
as it is deprecated in favor of action bar since Android 4.0.
If device implementations provide the Menu function, they:
* [C-2-1] MUST display the action overflow button whenever the action
overflow menu popup is not empty and the action bar is visible.
* [C-2-2] MUST NOT modify the position of the action overflow popup
displayed by selecting the overflow button in the action bar, but MAY render
the action overflow popup at a modified position on the screen when it is
displayed by selecting the Menu function.
If device implementations do not provide the Menu function, for backwards
compatibility, they:
* [C-3-1] MUST make the Menu function available to applications when
`targetSdkVersion` is less than 10, either by a physical button, a software key,
or gestures. This Menu function should be accessible unless hidden together with
other navigation functions.
If device implementations provide the [Assist function]((http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_ASSIST`),
they:
* [C-4-1] MUST make the Assist function accessible with a single action
(e.g. tap, double-click or gesture) when other navigation keys are accessible.
* [SR] STRONGLY RECOMMENDED to use long press on HOME function as this
designated interaction.
If device implementations use a distinct portion of the screen to display the
navigation keys, they:
* [C-5-1] Navigation keys MUST use a distinct portion of the screen, not
available to applications, and MUST NOT obscure or otherwise interfere with
the portion of the screen available to applications.
* [C-5-2] MUST make available a portion of the display to applications that
meets the requirements defined in [section 7.1.1](#7_1_1_screen_configuration).
* [C-5-3] MUST honor the flags set by the app through the [`View.setSystemUiVisibility()`](https://developer.android.com/reference/android/view/View.html#setSystemUiVisibility%28int%29)
API method, so that this distinct portion of the screen
(a.k.a. the navigation bar) is properly hidden away as documented in
the SDK.
### 7.2.4\. Touchscreen Input
Android includes support for a variety of pointer input systems, such as
touchscreens, touch pads, and fake touch input devices.
[Touchscreen-based device implementations](http://source.android.com/devices/tech/input/touch-devices.html)
are associated with a display such that the user has the impression of directly
manipulating items on screen. Since the user is directly touching the screen,
the system does not require any additional affordances to indicate the objects
being manipulated.
* [H-0-1] Handheld device implementations MUST support touchscreen input.
* [W-0-2] Watch device implementations MUST support touchscreen input.
Device implementations:
* SHOULD have a pointer input system of some kind
(either mouse-like or touch).
* SHOULD support fully independently tracked pointers.
If device implementations include a touchscreen (single-touch or better), they:
* [C-1-1] MUST report `TOUCHSCREEN_FINGER` for the [`Configuration.touchscreen`](https://developer.android.com/reference/android/content/res/Configuration.html#touchscreen)
API field.
* [C-1-2] MUST report the `android.hardware.touchscreen` and
`android.hardware.faketouch` feature flags
If device implementations include a touchscreen that can track more than
a single touch, they:
* [C-2-1] MUST report the appropriate feature flags `android.hardware.touchscreen.multitouch`,
`android.hardware.touchscreen.multitouch.distinct`, `android.hardware.touchscreen.multitouch.jazzhand`
corresponding to the type of the specific touchscreen on the device.
If device implementations do not include a touchscreen (and rely on a pointer
device only) and meet the fake touch requirements in
[section 7.2.5](#7_2_5_fake_touch_input), they:
* [C-3-1] MUST NOT report any feature flag starting with
`android.hardware.touchscreen` and MUST report only `android.hardware.faketouch`.
### 7.2.5\. Fake Touch Input
Fake touch interface provides a user input system that approximates a subset of
touchscreen capabilities. For example, a mouse or remote control that drives
an on-screen cursor approximates touch, but requires the user to first point or
focus then click. Numerous input devices like the mouse, trackpad, gyro-based
air mouse, gyro-pointer, joystick, and multi-touch trackpad can support fake
touch interactions. Android includes the feature constant
android.hardware.faketouch, which corresponds to a high-fidelity non-touch
(pointer-based) input device such as a mouse or trackpad that can adequately
emulate touch-based input (including basic gesture support), and indicates that
the device supports an emulated subset of touchscreen functionality.
If device implementations do not include a touchscreen but include another
pointer input system which they want to make available, they:
* SHOULD declare support for the `android.hardware.faketouch` feature flag.
If device implementations declare support for `android.hardware.faketouch`,
they:
* [C-1-1] MUST report the [absolute X and Y screen positions](
http://developer.android.com/reference/android/view/MotionEvent.html)
of the pointer location and display a visual pointer on the screen.
* [C-1-2] MUST report touch event with the action code that specifies the
state change that occurs on the pointer [going down or up on the
screen](http://developer.android.com/reference/android/view/MotionEvent.html).
* [C-1-3] MUST support pointer down and up on an object on the screen, which
allows users to emulate tap on an object on the screen.
* [C-1-4] MUST support pointer down, pointer up, pointer down then pointer up
in the same place on an object on the screen within a time threshold, which
allows users to [emulate double tap](
http://developer.android.com/reference/android/view/MotionEvent.html)
on an object on the screen.
* [C-1-5] MUST support pointer down on an arbitrary point on the screen,
pointer move to any other arbitrary point on the screen, followed by a pointer
up, which allows users to emulate a touch drag.
* [C-1-6] MUST support pointer down then allow users to quickly move the
object to a different position on the screen and then pointer up on the screen,
which allows users to fling an object on the screen.
* [C-1-7] MUST report `TOUCHSCREEN_NOTOUCH` for the [`Configuration.touchscreen`](https://developer.android.com/reference/android/content/res/Configuration.html#touchscreen)
API field.
If device implementations declare support for
`android.hardware.faketouch.multitouch.distinct`, they:
* [C-2-1] MUST declare support for `android.hardware.faketouch`.
* [C-2-2] MUST support distinct tracking of two or more independent pointer
inputs.
If device implementations declare support for
`android.hardware.faketouch.multitouch.jazzhand`, they:
* [C-3-1] MUST declare support for `android.hardware.faketouch`.
* [C-3-2] MUST support distinct tracking of 5 (tracking a hand of fingers)
or more pointer inputs fully independently.
### 7.2.6\. Game Controller Support
#### 7.2.6.1\. Button Mappings
Television device implementations:
* [T-0-1] MUST include support for game controllers and declare the
`android.hardware.gamepad` feature flag.
If device implementations declare the `android.hardware.gamepad` feature flag,
they:
* [C-1-1] MUST have embed a controller or ship with a separate controller
in the box, that would provide means to input all the events listed in the
below tables.
* [C-1-2] MUST be capable to map HID events to it's associated Android
`view.InputEvent` constants as listed in the below tables. The upstream Android
implementation includes implementation for game controllers that satisfies this
requirement.
<table>
<tr>
<th>Button</th>
<th>HID Usage<sup>2</sup></th>
<th>Android Button</th>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_A">A</a><sup>1</sup></td>
<td>0x09 0x0001</td>
<td>KEYCODE_BUTTON_A (96)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_B">B</a><sup>1</sup></td>
<td>0x09 0x0002</td>
<td>KEYCODE_BUTTON_B (97)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_X">X</a><sup>1</sup></td>
<td>0x09 0x0004</td>
<td>KEYCODE_BUTTON_X (99)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_Y">Y</a><sup>1</sup></td>
<td>0x09 0x0005</td>
<td>KEYCODE_BUTTON_Y (100)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_UP">D-pad up</a><sup>1</sup><br />
<a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_DOWN">D-pad down</a><sup>1</sup></td>
<td>0x01 0x0039<sup>3</sup></td>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_Y">AXIS_HAT_Y</a><sup>4</sup></td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_LEFT">D-pad left</a>1<br />
<a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_RIGHT">D-pad right</a><sup>1</sup></td>
<td>0x01 0x0039<sup>3</sup></td>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_X">AXIS_HAT_X</a><sup>4</sup></td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_L1">Left shoulder button</a><sup>1</sup></td>
<td>0x09 0x0007</td>
<td>KEYCODE_BUTTON_L1 (102)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_R1">Right shoulder button</a><sup>1</sup></td>
<td>0x09 0x0008</td>
<td>KEYCODE_BUTTON_R1 (103)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBL">Left stick click</a><sup>1</sup></td>
<td>0x09 0x000E</td>
<td>KEYCODE_BUTTON_THUMBL (106)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBR">Right stick click</a><sup>1</sup></td>
<td>0x09 0x000F</td>
<td>KEYCODE_BUTTON_THUMBR (107)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_HOME">Home</a><sup>1</sup></td>
<td>0x0c 0x0223</td>
<td>KEYCODE_HOME (3)</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK">Back</a><sup>1</sup></td>
<td>0x0c 0x0224</td>
<td>KEYCODE_BACK (4)</td>
</tr>
</table>
<p class="table_footnote">1 <a href="http://developer.android.com/reference/android/view/KeyEvent.html">KeyEvent</a></p>
<p class="table_footnote">2 The above HID usages must be declared within a Game
pad CA (0x01 0x0005).</p>
<p class="table_footnote">3 This usage must have a Logical Minimum of 0, a
Logical Maximum of 7, a Physical Minimum of 0, a Physical Maximum of 315, Units
in Degrees, and a Report Size of 4. The logical value is defined to be the
clockwise rotation away from the vertical axis; for example, a logical value of
0 represents no rotation and the up button being pressed, while a logical value
of 1 represents a rotation of 45 degrees and both the up and left keys being
pressed.</p>
<p class="table_footnote">4 <a
href="http://developer.android.com/reference/android/view/MotionEvent.html">MotionEvent</a></p>
<table>
<tr>
<th>Analog Controls<sup>1</sup></th>
<th>HID Usage</th>
<th>Android Button</th>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_LTRIGGER">Left Trigger</a></td>
<td>0x02 0x00C5</td>
<td>AXIS_LTRIGGER </td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_THROTTLE">Right Trigger</a></td>
<td>0x02 0x00C4</td>
<td>AXIS_RTRIGGER </td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Y">Left Joystick</a></td>
<td>0x01 0x0030<br />
0x01 0x0031</td>
<td>AXIS_X<br />
AXIS_Y</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Z">Right Joystick</a></td>
<td>0x01 0x0032<br />
0x01 0x0035</td>
<td>AXIS_Z<br />
AXIS_RZ</td>
</tr>
</table>
<p class="table_footnote">1 <a
href="http://developer.android.com/reference/android/view/MotionEvent.html">MotionEvent</a></p>
### 7.2.7\. Remote Control
Television device implementations:
* SHOULD provide a remote control from which users can access
[non-touch navigation](#7_2_2_non-touch_navigation) and
[core navigation keys](#7_2_3_navigation_keys) inputs.

636
android/compatibility/cdd/7_hardware-compatibility/7_3_sensors.md Normal file
View file

@ -0,0 +1,636 @@
## 7.3\. Sensors
If device implementations include a particular sensor type that has a
corresponding API for third-party developers, the device implementation
MUST implement that API as described in the Android SDK documentation and
the Android Open Source documentation on [sensors](
http://source.android.com/devices/sensors/).
Device implementations:
* [C-0-1] MUST accurately report the presence or absence of sensors per the
[`android.content.pm.PackageManager`](
http://developer.android.com/reference/android/content/pm/PackageManager.html)
class.
* [C-0-2] MUST return an accurate list of supported sensors via the
`SensorManager.getSensorList()` and similar methods.
* [C-0-3] MUST behave reasonably for all other sensor APIs (for example, by
returning `true` or `false` as appropriate when applications attempt to register
listeners, not calling sensor listeners when the corresponding sensors are not
present; etc.).
If device implementations include a particular sensor type that has a
corresponding API for third-party developers, they:
* [C-1-1] MUST [report all sensor measurements](
http://developer.android.com/reference/android/hardware/SensorEvent.html)
using the relevant International System of Units (metric) values for each
sensor type as defined in the Android SDK documentation.
* [C-1-2] MUST report sensor data with a maximum latency of 100 milliseconds
+ 2 * sample_time for the case of a sensor streamed with a minimum required
latency of 5 ms + 2 * sample_time when the application processor is active.
This delay does not include any filtering delays.
* [C-1-3] MUST report the first sensor sample within 400 milliseconds + 2 *
sample_time of the sensor being activated. It is acceptable for this sample to
have an accuracy of 0.
* [SR] SHOULD [report the event time](
http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp)
in nanoseconds as defined in the Android SDK documentation, representing the
time the event happened and synchronized with the
SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are
**STRONGLY RECOMMENDED** to meet these requirements so they will be able to
upgrade to the future platform releases where this might become a REQUIRED
component. The synchronization error SHOULD be below 100 milliseconds.
* [C-1-7] For any API indicated by the Android SDK documentation to be a
[continuous sensor](
https://source.android.com/devices/sensors/report-modes.html#continuous),
device implementations MUST continuously provide
periodic data samples that SHOULD have a jitter below 3%,
where jitter is defined as the standard deviation of the difference of the
reported timestamp values between consecutive events.
* [C-1-8] MUST ensure that the sensor event stream
MUST NOT prevent the device CPU from entering a suspend state or waking up
from a suspend state.
* When several sensors are activated, the power consumption SHOULD NOT exceed
the sum of the individual sensor’s reported power consumption.
The list above is not comprehensive; the documented behavior of the Android SDK
and the Android Open Source Documentations on
[sensors](http://source.android.com/devices/sensors/) is to be considered
authoritative.
Some sensor types are composite, meaning they can be derived from data provided
by one or more other sensors. (Examples include the orientation sensor and the
linear acceleration sensor.)
Device implementations:
* SHOULD implement these sensor types, when they
include the prerequisite physical sensors as described
in [sensor types](https://source.android.com/devices/sensors/sensor-types.html).
If device implementations include a composite sensor, they:
* [C-2-1] MUST implement the sensor as described in the Android Open Source
documentation on [composite sensors](
https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary).
### 7.3.1\. Accelerometer
* Device implementations SHOULD include a 3-axis accelerometer.
* [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to
include a 3-axis accelerometer.
* [A-SR] Automotive device implementations are STRONGLY RECOMMENDED to
include a 3-axis accelerometer.
* [W-SR] Watch device implementations are STRONGLY RECOMMENDED to
include a 3-axis accelerometer.
If Handheld device implementations include a 3-axis accelerometer, they:
* [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
If Automotive device implementations include a 3-axis accelerometer, they:
* [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
* [A-1-2] MUST comply with the Android
[car sensor coordinate system](
http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
If device implementations include a 3-axis accelerometer, they:
* [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
* [C-1-2] MUST implement and report [`TYPE_ACCELEROMETER`](
http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER)
sensor.
* [C-1-3] MUST comply with the [Android sensor coordinate system](
http://developer.android.com/reference/android/hardware/SensorEvent.html)
as detailed in the Android APIs.
* [C-1-4] MUST be capable of measuring from freefall up to four times the
gravity(4g) or more on any axis.
* [C-1-5] MUST have a resolution of at least 12-bits.
* [C-1-6] MUST have a standard deviation no greater than 0.05 m/s^, where
the standard deviation should be calculated on a per axis basis on samples
collected over a period of at least 3 seconds at the fastest sampling rate.
* [SR] are **STRONGLY RECOMMENDED** to implement the `TYPE_SIGNIFICANT_MOTION`
composite sensor.
* [SR] are STRONGLY RECOMMENDED to implement the
`TYPE_ACCELEROMETER_UNCALIBRATED` sensor if online accelerometer calibration
is available.
* SHOULD implement the `TYPE_SIGNIFICANT_MOTION`, `TYPE_TILT_DETECTOR`,
`TYPE_STEP_DETECTOR`, `TYPE_STEP_COUNTER` composite sensors as described
in the Android SDK document.
* SHOULD report events up to at least 200 Hz.
* SHOULD have a resolution of at least 16-bits.
* SHOULD be calibrated while in use if the characteristics changes over
the life cycle and compensated, and preserve the compensation parameters
between device reboots.
* SHOULD be temperature compensated.
* SHOULD also implement [`TYPE_ACCELEROMETER_UNCALIBRATED`](
https://developer.android.com/reference/android/hardware/Sensor.html#STRING_TYPE_ACCELEROMETER_UNCALIBRATED)
sensor.
If device implementations include a 3-axis accelerometer and any of the
`TYPE_SIGNIFICANT_MOTION`, `TYPE_TILT_DETECTOR`, `TYPE_STEP_DETECTOR`,
`TYPE_STEP_COUNTER` composite sensors are implemented:
* [C-2-1] The sum of their power consumption MUST always be less than 4 mW.
* SHOULD each be below 2 mW and 0.5 mW for when the device is in a dynamic or
static condition.
If device implementations include a 3-axis accelerometer and a gyroscope sensor,
they:
* [C-3-1] MUST implement the `TYPE_GRAVITY` and `TYPE_LINEAR_ACCELERATION`
composite sensors.
* SHOULD implement the `TYPE_GAME_ROTATION_VECTOR` composite sensor.
* [SR] Existing and new Android devices are STRONGLY RECOMMENDED to
implement the `TYPE_GAME_ROTATION_VECTOR` sensor.
If device implementations include a 3-axis accelerometer, a gyroscope sensor
and a magnetometer sensor, they:
* [C-4-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
### 7.3.2\. Magnetometer
* Device implementations SHOULD include a 3-axis magnetometer (compass).
If device impelementations include a 3-axis magnetometer, they:
* [C-1-1] MUST implement the `TYPE_MAGNETIC_FIELD` sensor.
* [C-1-2] MUST be able to report events up to a frequency of at least 10 Hz
and SHOULD report events up to at least 50 Hz.
* [C-1-3] MUST comply with the [Android sensor coordinate system](
http://developer.android.com/reference/android/hardware/SensorEvent.html)
as detailed in the
Android APIs.
* [C-1-4] MUST be capable of measuring between -900 µT and +900 µT on each
axis before saturating.
* [C-1-5] MUST have a hard iron offset value less than 700 µT and SHOULD have
a value below 200 µT, by placing the magnetometer far from
dynamic (current-induced) and static (magnet-induced) magnetic fields.
* [C-1-6] MUST have a resolution equal or denser than 0.6 µT.
* [C-1-7] MUST support online calibration and compensation of the hard iron
bias, and preserve the compensation parameters between device reboots.
* [C-1-8] MUST have the soft iron compensation applied—the calibration can be
done either while in use or during the production of the device.
* [C-1-9] MUST have a standard deviation, calculated on a per axis basis on
samples collected over a period of at least 3 seconds at the fastest sampling
rate, no greater than 1.5 µT; SHOULD have a standard deviation no greater than
0.5 µT.
* SHOULD implement `TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor.
* [SR] Existing and new Android devices are STRONGLY RECOMMENDED to implement the
`TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor.
If device impelementations include a 3-axis magnetometer, an accelerometer
sensor and a gyroscope sensor, they:
* [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
If device impelementations include a 3-axis magnetometer, an accelerometer, they:
* MAY implement the `TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor.
If device impelementations include a 3-axis magnetometer, an accelerometer and
`TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor, they:
* [C-3-1] MUST consume less than 10 mW.
* SHOULD consume less than 3 mW when the sensor is registered for batch mode at 10 Hz.
### 7.3.3\. GPS
Device implementations:
* SHOULD include a GPS/GNSS receiver.
If device implementations include a GPS/GNSS receiver and report the capability
to applications through the `android.hardware.location.gps` feature flag, they:
* [C-1-1] MUST support location outputs at a rate of at least 1 Hz when
requested via `LocationManager#requestLocationUpdate`.
* [C-1-2] MUST be able to determine the location in open-sky conditions
(strong signals, negligible multipath, HDOP < 2) within 10 seconds (fast
time to first fix), when connected to a 0.5 Mbps or faster data speed
internet connection. This requirement is typically met by the use of some
form of Assisted or Predicted GPS/GNSS technique
to minimize GPS/GNSS lock-on time (Assistance data includes Reference Time,
Reference Location and Satellite Ephemeris/Clock).
* [SR] After making such a location calculation, it is
STRONGLY RECOMMENDED for the device to
be able to determine its location, in open sky, within 10 seconds,
when location requests are restarted, up to an hour after the initial
location calculation, even when the subsequent request is made without
a data connection, and/or after a power cycle.
* In open sky conditions after determining the location, while stationary or
moving with less than 1 meter per second squared of acceleration:
* [C-1-3] MUST be able to determine location within 20 meters, and speed
within 0.5 meters per second, at least 95% of the time.
* [C-1-4] MUST simultaneously track and report via
[`GnssStatus.Callback`](
https://developer.android.com/reference/android/location/GnssStatus.Callback.html#GnssStatus.Callback()')
at least 8 satellites from one constellation.
* SHOULD be able to simultaneously track at least 24 satellites, from
multiple constellations (e.g. GPS + at least one of Glonass, Beidou,
Galileo).
* [C-1-5] MUST report the GNSS technology generation through the test API
‘getGnssYearOfHardware’.
* [SR] Continue to deliver normal GPS/GNSS location outputs during an
emergency phone call.
* [SR] Report GNSS measurements from all constellations tracked (as reported
in GnssStatus messages), with the exception of SBAS.
* [SR] Report AGC, and Frequency of GNSS measurement.
* [SR] Report all accuracy estimates (including Bearing, Speed, and Vertical)
as part of each GPS Location.
* [SR] are STRONGLY RECOMMENDED to meet as many as possible from the
additional mandatory requirements for devices reporting the year "2016" or
"2017" through the Test API `LocationManager.getGnssYearOfHardware()`.
If Automotive device implementations include a GPS/GNSS receiver and report
the capability to applications through the `android.hardware.location.gps`
feature flag:
* [A-1-1] GNSS technology generation MUST be the year "2017" or newer.
If device implementations include a GPS/GNSS receiver and report the capability
to applications through the `android.hardware.location.gps` feature flag and the
`LocationManager.getGnssYearOfHardware()` Test API reports the year "2016" or
newer, they:
* [C-2-1] MUST report GPS measurements, as soon as they are found, even if a
location calculated from GPS/GNSS is not yet reported.
* [C-2-2] MUST report GPS 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.
If device implementations include a GPS/GNSS receiver and report the capability
to applications through the `android.hardware.location.gps` feature flag and the
`LocationManager.getGnssYearOfHardware()` Test API reports the year "2017" or
newer, they:
* [C-3-1] MUST continue to deliver normal GPS/GNSS location outputs during an
emergency phone call.
* [C-3-2] MUST report GNSS measurements from all constellations tracked (as
reported in
GnssStatus messages), with the exception of SBAS.
* [C-3-3] MUST report AGC, and Frequency of GNSS measurement.
* [C-3-4] MUST report all accuracy estimates (including Bearing, Speed, and
Vertical) as part of each GPS Location.
### 7.3.4\. Gyroscope
Device implementations:
* SHOULD include a gyroscope (angular change sensor).
* SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is
also included.
If device implementations include a gyroscope, they:
* [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
* [C-1-2] MUST implement the `TYPE_GYROSCOPE` sensor and SHOULD also implement
`TYPE_GYROSCOPE_UNCALIBRATED` sensor.
* [C-1-3] MUST be capable of measuring orientation changes up to 1,000 degrees
per second.
* [C-1-4] MUST have a resolution of 12-bits or more and SHOULD have a
resolution of 16-bits or more.
* [C-1-5] MUST be temperature compensated.
* [C-1-6] MUST be calibrated and compensated while in use, and preserve the
compensation parameters between device reboots.
* [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz
(variance per Hz, or rad^2 / s). The variance is allowed to vary with the
sampling rate, but MUST be constrained by this value. In other words, if you
measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater
than 1e-7 rad^2/s^2.
* [SR] Existing and new Android devices are STRONGLY RECOMMENDED to
implement the `SENSOR_TYPE_GYROSCOPE_UNCALIBRATED` sensor.
* [SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s
when device is stationary at room temperature.
* SHOULD report events up to at least 200 Hz.
If Handheld device implementations include a gyroscope, they:
* [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
If Automotive device implementations include a gyroscope, they:
* [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
If Television device implementations include a gyroscope, they:
* [T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
If device implementations include a gyroscope, an accelerometer sensor and a
magnetometer sensor, they:
* [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
If device implementations include a gyroscope and a accelerometer sensor, they:
* [C-3-1] MUST implement the `TYPE_GRAVITY` and
`TYPE_LINEAR_ACCELERATION` composite sensors.
* [SR] Existing and new Android devices are STRONGLY RECOMMENDED to implement
the `TYPE_GAME_ROTATION_VECTOR` sensor.
* SHOULD implement the `TYPE_GAME_ROTATION_VECTOR` composite sensor.
### 7.3.5\. Barometer
* Device implementations SHOULD include a barometer (ambient air pressure
sensor).
If device implementations include a barometer, they:
* [C-1-1] MUST implement and report `TYPE_PRESSURE` sensor.
* [C-1-2] MUST be able to deliver events at 5 Hz or greater.
* [C-1-3] MUST be temperature compensated.
* [SR] STRONGLY RECOMMENDED to be able to report pressure measurements in the
range 300hPa to 1100hPa.
* SHOULD have an absolute accuracy of 1hPa.
* SHOULD have a relative accuracy of 0.12hPa over 20hPa range
(equivalent to ~1m accuracy over ~200m change at sea level).
### 7.3.6\. Thermometer
Device implementations:
* MAY include an ambient thermometer (temperature sensor).
* MAY but SHOULD NOT include a CPU temperature sensor.
If device implementations include an ambient thermometer (temperature sensor),
they:
* [C-1-1] MUST be defined as `SENSOR_TYPE_AMBIENT_TEMPERATURE` and MUST
measure the ambient (room/vehicle cabin) temperature from where the user
is interacting with the device in degrees Celsius.
* [C-1-2] MUST be defined as `SENSOR_TYPE_TEMPERATURE`.
* [C-1-3] MUST measure the temperature of the device CPU.
* [C-1-4] MUST NOT measure any other temperature.
Note the `SENSOR_TYPE_TEMPERATURE` sensor type was deprecated in Android 4.0.
### 7.3.7\. Photometer
* Device implementations MAY include a photometer (ambient light sensor).
### 7.3.8\. Proximity Sensor
* Device implementations MAY include a proximity sensor.
* Handheld device implementations that can make a voice call and indicate
any value other than `PHONE_TYPE_NONE` in `getPhoneType`
SHOULD include a proximity sensor.
If device implementations include a proximity sensor, they:
* [C-1-1] MUST measure the proximity of an object in the same direction as the
screen. That is, the proximity sensor MUST be oriented to detect objects
close to the screen, as the primary intent of this sensor type is to
detect a phone in use by the user. If device implementations include a
proximity sensor with any other orientation, it MUST NOT be accessible
through this API.
* [C-1-2] MUST have 1-bit of accuracy or more.
### 7.3.9\. High Fidelity Sensors
If device implementations include a set of higher quality sensors as defined
in this section, and make available them to third-party apps, they:
* [C-1-1] MUST identify the capability through the
`android.hardware.sensor.hifi_sensors` feature flag.
If device implementations declare `android.hardware.sensor.hifi_sensors`,
they:
* [C-2-1] MUST have a `TYPE_ACCELEROMETER` sensor which:
* MUST have a measurement range between at least -8g and +8g.
* MUST have a measurement resolution of at least 1024 LSB/G.
* MUST have a minimum measurement frequency of 12.5 Hz or lower.
* MUST have a maximum measurement frequency of 400 Hz or higher.
* MUST have a measurement noise not above 400 uG/√Hz.
* MUST implement a non-wake-up form of this sensor with a buffering
capability of at least 3000 sensor events.
* MUST have a batching power consumption not worse than 3 mW.
* SHOULD have a stationary noise bias stability of \<15 μg √Hz from 24hr static
dataset.
* SHOULD have a bias change vs. temperature of ≤ +/- 1mg / °C.
* SHOULD have a best-fit line non-linearity of ≤ 0.5%, and sensitivity change vs. temperature of ≤
0.03%/C°.
* SHOULD have white noise spectrum to ensure adequate qualification
of sensor’s noise integrity.
* [C-2-2] MUST have a `TYPE_ACCELEROMETER_UNCALIBRATED` with the same
quality requirements as `TYPE_ACCELEROMETER`.
* [C-2-3] MUST have a `TYPE_GYROSCOPE` sensor which:
* MUST have a measurement range between at least -1000 and +1000 dps.
* MUST have a measurement resolution of at least 16 LSB/dps.
* MUST have a minimum measurement frequency of 12.5 Hz or lower.
* MUST have a maximum measurement frequency of 400 Hz or higher.
* MUST have a measurement noise not above 0.014°/s/√Hz.
* SHOULD have a stationary bias stability of < 0.0002 °/s √Hz from 24-hour static dataset.
* SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C.
* SHOULD have a sensitivity change vs. temperature of ≤ 0.02% / °C.
* SHOULD have a best-fit line non-linearity of ≤ 0.2%.
* SHOULD have a noise density of ≤ 0.007 °/s/√Hz.
* SHOULD have white noise spectrum to ensure adequate qualification
of sensor’s noise integrity.
* SHOULD have calibration error less than 0.002 rad/s in
temperature range 10 ~ 40 ℃ when device is stationary.
* [C-2-4] MUST have a `TYPE_GYROSCOPE_UNCALIBRATED` with the same quality
requirements as `TYPE_GYROSCOPE`.
* [C-2-5] MUST have a `TYPE_GEOMAGNETIC_FIELD` sensor which:
* MUST have a measurement range between at least -900 and +900 uT.
* MUST have a measurement resolution of at least 5 LSB/uT.
* MUST have a minimum measurement frequency of 5 Hz or lower.
* MUST have a maximum measurement frequency of 50 Hz or higher.
* MUST have a measurement noise not above 0.5 uT.
* [C-2-6] MUST have a `TYPE_MAGNETIC_FIELD_UNCALIBRATED` with the same quality
requirements as `TYPE_GEOMAGNETIC_FIELD` and in addition:
* MUST implement a non-wake-up form of this sensor with a buffering
capability of at least 600 sensor events.
* SHOULD have white noise spectrum to ensure adequate qualification
of sensor’s noise integrity.
* [C-2-7] MUST have a `TYPE_PRESSURE` sensor which:
* MUST have a measurement range between at least 300 and 1100 hPa.
* MUST have a measurement resolution of at least 80 LSB/hPa.
* MUST have a minimum measurement frequency of 1 Hz or lower.
* MUST have a maximum measurement frequency of 10 Hz or higher.
* MUST have a measurement noise not above 2 Pa/√Hz.
* MUST implement a non-wake-up form of this sensor with a buffering
capability of at least 300 sensor events.
* MUST have a batching power consumption not worse than 2 mW.
* [C-2-8] MUST have a `TYPE_GAME_ROTATION_VECTOR` sensor which:
* MUST implement a non-wake-up form of this sensor with a buffering
capability of at least 300 sensor events.
* MUST have a batching power consumption not worse than 4 mW.
* [C-2-9] MUST have a `TYPE_SIGNIFICANT_MOTION` sensor which:
* MUST have a power consumption not worse than 0.5 mW when device is
static and 1.5 mW when device is moving.
* [C-2-10] MUST have a `TYPE_STEP_DETECTOR` sensor which:
* MUST implement a non-wake-up form of this sensor with a buffering
capability of at least 100 sensor events.
* MUST have a power consumption not worse than 0.5 mW when device is
static and 1.5 mW when device is moving.
* MUST have a batching power consumption not worse than 4 mW.
* [C-2-11] MUST have a `TYPE_STEP_COUNTER` sensor which:
* MUST have a power consumption not worse than 0.5 mW when device is
static and 1.5 mW when device is moving.
* [C-2-12] MUST have a `TILT_DETECTOR` sensor which:
* MUST have a power consumption not worse than 0.5 mW when device is
static and 1.5 mW when device is moving.
* [C-2-13] The event timestamp of the same physical event reported by the
Accelerometer, Gyroscope sensor and Magnetometer MUST be within 2.5
milliseconds of each other.
* [C-2-14] MUST have Gyroscope sensor event timestamps on the same time
base as the camera subsystem and within 1 milliseconds of error.
* [C-2-15] MUST deliver samples to applications within 5 milliseconds from
the time when the data is available on any of the above physical sensors
to the application.
* [C-2-16] MUST not have a power consumption higher than 0.5 mW
when device is static and 2.0 mW when device is moving
when any combination of the following sensors are enabled:
* `SENSOR_TYPE_SIGNIFICANT_MOTION`
* `SENSOR_TYPE_STEP_DETECTOR`
* `SENSOR_TYPE_STEP_COUNTER`
* `SENSOR_TILT_DETECTORS`
* [C-2-17] MAY have a `TYPE_PROXIMITY` sensor, but if present MUST have
a minimum buffer capability of 100 sensor events.
Note that all power consumption requirements in this section do not include the
power consumption of the Application Processor. It is inclusive of the power
drawn by the entire sensor chain—the sensor, any supporting circuitry, any
dedicated sensor processing system, etc.
If device implementations include direct sensor support, they:
* [C-3-1] MUST correctly declare support of direct channel types and direct
report rates level through the [`isDirectChannelTypeSupported`](
https://developer.android.com/reference/android/hardware/Sensor.html#isDirectChannelTypeSupported%28int%29)
and [`getHighestDirectReportRateLevel`](
https://developer.android.com/reference/android/hardware/Sensor.html#getHighestDirectReportRateLevel%28%29)
API.
* [C-3-2] MUST support at least one of the two sensor direct channel types
for all sensors that declare support for sensor direct channel
* [`TYPE_HARDWARE_BUFFER`](https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_HARDWARE_BUFFER)
* [`TYPE_MEMORY_FILE`](https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_MEMORY_FILE)
* SHOULD support event reporting through sensor direct channel for primary
sensor (non-wakeup variant) of the following types:
* `TYPE_ACCELEROMETER`
* `TYPE_ACCELEROMETER_UNCALIBRATED`
* `TYPE_GYROSCOPE`
* `TYPE_GYROSCOPE_UNCALIBRATED`
* `TYPE_MAGNETIC_FIELD`
* `TYPE_MAGNETIC_FIELD_UNCALIBRATED`
### 7.3.10\. Fingerprint Sensor
If device implementations include a secure lock screen, they:
* SHOULD include a fingerprint sensor.
If device implementations include a fingerprint sensor and make the sensor
available to third-party apps, they:
* [C-1-1] MUST declare support for the `android.hardware.fingerprint` feature.
* [C-1-2] MUST fully implement the
[corresponding API](
https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html)
as described in the Android SDK documentation.
* [C-1-3] MUST have a false acceptance rate not higher than 0.002%.
* [C-1-4] MUST rate limit attempts for at least 30 seconds after five false
trials for fingerprint verification.
* [C-1-5] MUST have a hardware-backed keystore implementation, and perform the
fingerprint matching in a Trusted Execution Environment (TEE) or on a chip with
a secure channel to the TEE.
* [C-1-6] MUST have all identifiable fingerprint data encrypted and
cryptographically authenticated such that they cannot be acquired, read or
altered outside of the Trusted Execution Environment (TEE) as documented in the
[implementation guidelines](
https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
on the Android Open Source Project site.
* [C-1-7] MUST prevent adding a fingerprint without first establishing a chain
of trust by having the user confirm existing or add a new device credential
(PIN/pattern/password) that's secured by TEE; the Android Open Source Project
implementation provides the mechanism in the framework to do so.
* [C-1-8] MUST NOT enable 3rd-party applications to distinguish between
individual fingerprints.
* [C-1-9] MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
flag.
* [C-1-10] MUST, when upgraded from a version earlier than Android 6.0, have
the fingerprint data securely migrated to meet the above requirements or
removed.
* [SR] STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
as measured on the device.
* [SR] STRONGLY RECOMMENDED to have a latency below 1 second, measured from
when the fingerprint sensor is touched until the screen is unlocked, for one
enrolled finger.
* SHOULD use the Android Fingerprint icon provided in the Android Open Source
Project.
### 7.3.11\. Android Automotive-only sensors
Automotive-specific sensors are defined in the
`android.car.CarSensorManager API`.
#### 7.3.11.1\. Current Gear
* Android Automotive implementations SHOULD provide current gear as
`SENSOR_TYPE_GEAR`.
#### 7.3.11.2\. Day Night Mode
Automotive device implementations:
* [A-0-1] MUST support day/night mode
defined as `SENSOR_TYPE_NIGHT`.
* [A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag MUST be consistent with
dashboard day/night mode and SHOULD be based on ambient light sensor input.
* The underlying ambient light sensor MAY be the same as
[Photometer](#7_3_7_photometer).
#### 7.3.11.3\. Driving Status
Automotive device implementations:
* [A-0-1] MUST support driving status
defined as `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
`DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked. It is
the responsibility of device manufacturers to configure
`SENSOR_TYPE_DRIVING_STATUS` in compliance with all
laws and regulations that apply to markets where the product is shipping.
#### 7.3.11.4\. Wheel Speed
Automotive device implementations:
* [A-0-1] MUST provide vehicle speed defined as `SENSOR_TYPE_CAR_SPEED`.
## 7.3.12\. Pose Sensor
Device implementations:
* MAY support pose sensor with 6 degrees of freedom.
Handheld device implementations are:
* RECOMMENDED to support this sensor.
If device implementations support pose sensor with 6 degrees of freedom, they:
* [C-1-1] MUST implement and report [`TYPE_POSE_6DOF`](
https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_POSE_6DOF)
sensor.
* [C-1-2] MUST be more accurate than the rotation vector alone.

440
android/compatibility/cdd/7_hardware-compatibility/7_4_data-connectivity.md Normal file
View file

@ -0,0 +1,440 @@
## 7.4\. Data Connectivity
### 7.4.1\. Telephony
“Telephony” as used by the Android APIs and this document refers specifically
to hardware related to placing voice calls and sending SMS messages via a GSM
or CDMA network. While these voice calls may or may not be packet-switched,
they are for the purposes of Android considered independent of any data
connectivity that may be implemented using the same network. In other words,
the Android “telephony” functionality and APIs refer specifically to voice
calls and SMS. For instance, device implementations that cannot place calls or
send/receive SMS messages are not considered a telephony device, regardless of
whether they use a cellular network for data connectivity.
* Android MAY be used on devices that do not include telephony hardware. That
is, Android is compatible with devices that are not phones.
If device implementations include GSM or CDMA telephony, they:
* [C-1-1] MUST declare the `android.hardware.telephony` feature flag and
other sub-feature flags according to the technology.
* [C-1-2] MUST implement full support for the API for that technology.
If device implementations do not include telephony hardware, they:
* [C-2-1] MUST implement the full APIs as no-ops.
#### 7.4.1.1\. Number Blocking Compatibility
If device implementations report the `android.hardware.telephony feature`, they:
* [C-1-1] MUST include number blocking support
* [C-1-2] MUST fully implement [`BlockedNumberContract`](
http://developer.android.com/reference/android/provider/BlockedNumberContract.html)
and the corresponding API as described in the SDK documentation.
* [C-1-3] MUST block all calls and messages from a phone number in
'BlockedNumberProvider' without any interaction with apps. The only exception
is when number blocking is temporarily lifted as described in the SDK
documentation.
* [C-1-4] MUST NOT write to the [platform call log provider](
http://developer.android.com/reference/android/provider/CallLog.html)
for a blocked call.
* [C-1-5] MUST NOT write to the [Telephony provider](
http://developer.android.com/reference/android/provider/Telephony.html)
for a blocked message.
* [C-1-6] MUST implement a blocked numbers management UI, which is opened
with the intent returned by `TelecomManager.createManageBlockedNumbersIntent()`
method.
* [C-1-7] MUST NOT allow secondary users to view or edit the blocked numbers
on the device as the Android platform assumes the primary user to have full
control of the telephony services, a single instance, on the device. All
blocking related UI MUST be hidden for secondary users and the blocked list MUST
still be respected.
* SHOULD migrate the blocked numbers into the provider when a device updates
to Android 7.0.
### 7.4.2\. IEEE 802.11 (Wi-Fi)
Device implementations:
* SHOULD include support for one or more forms of 802.11\.
If device implementations include support for 802.11 and expose the
functionality to a third-party application, they
* [C-1-1] MUST implement the corresponding Android API.
* [C-1-2] MUST report the hardware feature flag `android.hardware.wifi`.
* [C-1-3] MUST implement the [multicast API](
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
as described in the SDK documentation.
* [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets
(224.0.0.251) at any time of operation including:
* Even when the screen is not in an active state.
* For Android Television device implementations, even when in standby
power states.
* SHOULD randomize the source MAC address and sequence number of probe
request frames, once at the beginning of each scan, while STA is disconnected.
* Each group of probe request frames comprising one scan should use one
consistent MAC address (SHOULD NOT randomize MAC address halfway through a
scan).
* Probe request sequence number should iterate as normal (sequentially)
between the probe requests in a scan
* Probe request sequence number should randomize between the last probe
request of a scan and the first probe request of the next scan
* SHOULD only allow the following information elements in probe request
frames, while STA is disconnected:
* SSID Parameter Set (0)
* DS Parameter Set (3)
#### 7.4.2.1\. Wi-Fi Direct
Device implementations:
* SHOULD include support for Wi-Fi Direct (Wi-Fi peer-to-peer).
If device implementations include support for Wi-Fi Direct, they:
* [C-1-1] MUST implement the [corresponding Android API](
http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html)
as described in the SDK documentation.
* [C-1-2] MUST report the hardware feature `android.hardware.wifi.direct`.
* [C-1-3] MUST support regular Wi-Fi operation.
* SHOULD support Wi-Fi and Wi-Fi Direct operations concurrently.
#### 7.4.2.2\. Wi-Fi Tunneled Direct Link Setup
Device implementations:
* SHOULD include support for
[Wi-Fi Tunneled Direct Link Setup (TDLS)](
http://developer.android.com/reference/android/net/wifi/WifiManager.html)
as described in the Android SDK Documentation.
If device implementations include support for TDLS and TDLS is enabled by the
WiFiManager API, they:
* [C-1-1] MUST declare support for TDLS through [`WifiManager.isTdlsSupported`]
(https://developer.android.com/reference/android/net/wifi/WifiManager.html#isTdlsSupported%28%29).
* SHOULD use TDLS only when it is possible AND beneficial.
* SHOULD have some heuristic and NOT use TDLS when its performance might be
worse than going through the Wi-Fi access point.
#### 7.4.2.3\. Wi-Fi Aware
Device implementations:
* SHOULD include support for [Wi-Fi Aware](
http://www.wi-fi.org/discover-wi-fi/wi-fi-aware).
If device implementations include support for Wi-Fi Aware and expose the
functionality to third-party apps, then they:
* [C-1-1] MUST implement the `WifiAwareManager` APIs as described in the
[SDK documentation](
http://developer.android.com/reference/android/net/wifi/aware/WifiAwareManager.html).
* [C-1-2] MUST declare the `android.hardware.wifi.aware` feature flag.
* [C-1-3] MUST support Wi-Fi and Wi-Fi Aware operations concurrently.
* [C-1-4] MUST randomize the Wi-Fi Aware management interface address at intervals
no longer then 30 minutes and whenever Wi-Fi Aware is enabled.
#### 7.4.2.4\. Wi-Fi Passpoint
Device implementations:
* SHOULD include support for [Wi-Fi Passpoint](
http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint).
If device implementations include support for Wi-Fi Passpoint, they:
* [C-1-1] MUST implement the Passpoint related `WifiManager` APIs as
described in the [SDK documentation](
http://developer.android.com/reference/android/net/wifi/WifiManager.html).
* [C-1-2] MUST support IEEE 802.11u standard, specifically related
to Network Discovery and Selection, such as Generic Advertisement
Service (GAS) and Access Network Query Protocol (ANQP).
Conversely if device implementations do not include support for Wi-Fi
Passpoint:
* [C-2-1] The implementation of the Passpoint related `WifiManager`
APIs MUST throw an `UnsupportedOperationException`.
### 7.4.3\. Bluetooth
* [W-0-1] Watch device implementations MUST support Bluetooth.
* [T-0-1] Television device implementations MUST support Bluetooth and
Bluetooth LE.
If device implementations support Bluetooth Audio profile, they:
* SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs
(e.g. LDAC).
If device implementations declare `android.hardware.vr.high_performance`
feature, they:
* [C-1-1] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension.
Android includes support for [Bluetooth and Bluetooth Low Energy](
http://developer.android.com/reference/android/bluetooth/package-summary.html).
If device implementations include support for Bluetooth and Bluetooth
Low Energy, they:
* [C-2-1] MUST declare the relevant platform features
(`android.hardware.bluetooth` and `android.hardware.bluetooth_le`
respectively) and implement the platform APIs.
* SHOULD implement relevant Bluetooth profiles such as
A2DP, AVCP, OBEX, etc. as appropriate for the device.
Automotive device implementations:
* [A-0-1] Automotive device implementations MUST support Bluetooth and
SHOULD support Bluetooth LE.
* [A-0-2] Android Automotive implementations MUST support the following
Bluetooth profiles:
* Phone calling over Hands-Free Profile (HFP).
* Media playback over Audio Distribution Profile (A2DP).
* Media playback control over Remote Control Profile (AVRCP).
* Contact sharing using the Phone Book Access Profile (PBAP).
* SHOULD support Message Access Profile (MAP).
If device implementations include support for Bluetooth Low Energy, they:
* [C-3-1] MUST declare the hardware feature `android.hardware.bluetooth_le`.
* [C-3-2] MUST enable the GATT (generic attribute profile) based Bluetooth
APIs as described in the SDK documentation and
[android.bluetooth](
http://developer.android.com/reference/android/bluetooth/package-summary.html).
* [C-3-3] MUST report the correct value for
`BluetoothAdapter.isOffloadedFilteringSupported()` to indicate whether the
filtering logic for the [ScanFilter](
https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html)
API classes is implemented.
* [C-3-4] MUST report the correct value for
`BluetoothAdapter.isMultipleAdvertisementSupported()` to indicate
whether Low Energy Advertising is supported.
* SHOULD support offloading of the filtering logic to the bluetooth chipset
when implementing the [ScanFilter API](
https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html).
* SHOULD support offloading of the batched scanning to the bluetooth chipset.
* SHOULD support multi advertisement with at least 4 slots.
* [SR] STRONGLY RECOMMENDED to implement a Resolvable Private Address (RPA)
timeout no longer than 15 minutes and rotate the address at timeout to protect
user privacy.
### 7.4.4\. Near-Field Communications
Device implementations:
* SHOULD include a transceiver and related hardware for Near-Field
Communications (NFC).
* [C-0-1] MUST implement `android.nfc.NdefMessage` and
`android.nfc.NdefRecord` APIs even if they do not include support for NFC or
declare the `android.hardware.nfc` feature as the classes represent a
protocol-independent data representation format.
If device implementations include NFC hardware and plan to make it available to
third-party apps, they:
* [C-1-1] MUST report the `android.hardware.nfc` feature from the
[`android.content.pm.PackageManager.hasSystemFeature()` method](
http://developer.android.com/reference/android/content/pm/PackageManager.html).
* MUST be capable of reading and writing NDEF messages via the following NFC
standards as below:
* [C-1-2] MUST be capable of acting as an NFC Forum reader/writer
(as defined by the NFC Forum technical specification
NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
* NfcA (ISO14443-3A)
* NfcB (ISO14443-3B)
* NfcF (JIS X 6319-4)
* IsoDep (ISO 14443-4)
* NFC Forum Tag Types 1, 2, 3, 4, 5 (defined by the NFC Forum)
* [SR] STRONGLY RECOMMENDED to be capable of reading and writing NDEF
messages as well as raw data via the following NFC standards. Note that
while the NFC standards are stated as STRONGLY RECOMMENDED, the
Compatibility Definition for a future version is planned to change these
to MUST. These standards are optional in this version but will be required
in future versions. Existing and new devices that run this version of
Android are very strongly encouraged to meet these requirements now so
they will be able to upgrade to the future platform releases.
* [C-1-3] MUST be capable of transmitting and receiving data via the
following peer-to-peer standards and protocols:
* ISO 18092
* LLCP 1.2 (defined by the NFC Forum)
* SDP 1.0 (defined by the NFC Forum)
* [NDEF Push Protocol](
http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf)
* SNEP 1.0 (defined by the NFC Forum)
* [C-1-4] MUST include support for [Android Beam](
http://developer.android.com/guide/topics/connectivity/nfc/nfc.html) and
SHOULD enable Android Beam by default.
* [C-1-5] MUST be able to send and receive using Android Beam,
when Android Beam is enabled or another proprietary NFC P2p mode is
turned on.
* [C-1-6] MUST implement the SNEP default server. Valid NDEF messages
received by the default SNEP server MUST be dispatched to applications using
the `android.nfc.ACTION_NDEF_DISCOVERED` intent. Disabling Android Beam in
settings MUST NOT disable dispatch of incoming NDEF message.
* [C-1-7] MUST honor the `android.settings.NFCSHARING_SETTINGS` intent to
show [NFC sharing settings](
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS).
* [C-1-8] MUST implement the NPP server. Messages received by the NPP
server MUST be processed the same way as the SNEP default server.
* [C-1-9] MUST implement a SNEP client and attempt to send outbound P2P
NDEF to the default SNEP server when Android Beam is enabled. If no default
SNEP server is found then the client MUST attempt to send to an NPP server.
* [C-1-10] MUST allow foreground activities to set the outbound P2P NDEF
message using `android.nfc.NfcAdapter.setNdefPushMessage`, and
`android.nfc.NfcAdapter.setNdefPushMessageCallback`, and
`android.nfc.NfcAdapter.enableForegroundNdefPush`.
* SHOULD use a gesture or on-screen confirmation, such as 'Touch to
Beam', before sending outbound P2P NDEF messages.
* [C-1-11] MUST support NFC Connection handover to Bluetooth when the
device supports Bluetooth Object Push Profile.
* [C-1-12] MUST support connection handover to Bluetooth when using
`android.nfc.NfcAdapter.setBeamPushUris`, by implementing the
“[Connection Handover version 1.2](
http://members.nfc-forum.org/specs/spec_list/#conn_handover)” and
“[Bluetooth Secure Simple Pairing Using NFC version 1.0](
http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf)”
specs from the NFC Forum. Such an implementation MUST implement the handover
LLCP service with service name “urn:nfc:sn:handover” for exchanging the
handover request/select records over NFC, and it MUST use the Bluetooth Object
Push Profile for the actual Bluetooth data transfer. For legacy reasons (to
remain compatible with Android 4.1 devices), the implementation SHOULD still
accept SNEP GET requests for exchanging the handover request/select records
over NFC. However an implementation itself SHOULD NOT send SNEP GET requests
for performing connection handover.
* [C-1-13] MUST poll for all supported technologies while in NFC discovery
mode.
* SHOULD be in NFC discovery mode while the device is awake with the
screen active and the lock-screen unlocked.
* SHOULD be capable of reading the barcode and URL (if encoded) of
[Thinfilm NFC Barcode](
http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html)
products.
(Note that publicly available links are not available for the JIS, ISO, and NFC
Forum specifications cited above.)
Android includes support for NFC Host Card Emulation (HCE) mode.
If device implementations include an NFC controller chipset capable of HCE (for
NfcA and/or NfcB) and support Application ID (AID) routing, they:
* [C-2-1] MUST report the `android.hardware.nfc.hce` feature constant.
* [C-2-2] MUST support [NFC HCE APIs](
http://developer.android.com/guide/topics/connectivity/nfc/hce.html) as
defined in the Android SDK.
If device implementations include an NFC controller chipset capable of HCE
for NfcF, and implement the feature for third-party applications, they:
* [C-3-1] MUST report the `android.hardware.nfc.hcef` feature constant.
* [C-3-2] MUST implement the [NfcF Card Emulation APIs]
(https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html)
as defined in the Android SDK.
If device implementations include general NFC support as described in this
section and support MIFARE technologies (MIFARE Classic,
MIFARE Ultralight, NDEF on MIFARE Classic) in the reader/writer role, they:
* [C-4-1] MUST implement the corresponding Android APIs as documented by
the Android SDK.
* [C-4-2] MUST report the feature `com.nxp.mifare` from the
[`android.content.pm.PackageManager.hasSystemFeature`()](
http://developer.android.com/reference/android/content/pm/PackageManager.html)
method. Note that this is not a standard Android feature and as such does not
appear as a constant in the `android.content.pm.PackageManager` class.
### 7.4.5\. Minimum Network Capability
Device implementations:
* [C-0-1] MUST include support for one or more forms of
data networking. Specifically, device implementations MUST include support for
at least one data standard capable of 200Kbit/sec or greater. Examples of
technologies that satisfy this requirement include EDGE, HSPA, EV-DO,
802.11g, Ethernet, Bluetooth PAN, etc.
* [C-0-2] MUST include an IPv6 networking stack and support IPv6
communication using the managed APIs, such as `java.net.Socket` and
`java.net.URLConnection`, as well as the native APIs, such as `AF_INET6`
sockets.
* [C-0-3] MUST enable IPv6 by default.
* MUST ensure that IPv6 communication is as reliable as IPv4, for example.
* [C-0-4] MUST maintain IPv6 connectivity in doze mode.
* [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6
connectivity on any IPv6-compliant network that uses RA lifetimes of
at least 180 seconds.
* SHOULD also include support for at least one common wireless data
standard, such as 802.11 (Wi-Fi) when a physical networking standard (such as
Ethernet) is the primary data connection
* MAY implement more than one form of data connectivity.
The required level of IPv6 support depends on the network type, as follows:
If devices implementations support Wi-Fi networks, they:
* [C-1-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
If device impelementations support Ethernet networks, they:
* [C-2-1] MUST support dual-stack operation on Ethernet.
If device implementations support cellular data, they:
* [C-3-1] MUST simultaneously meet these requirements on each network to which
it is connected when a device is simultaneously connected to more than one
network (e.g., Wi-Fi and cellular data), .
* SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
cellular data.
### 7.4.6\. Sync Settings
Device implementations:
* [C-0-1] MUST have the master auto-sync setting on by default so that
the method [`getMasterSyncAutomatically()`](
http://developer.android.com/reference/android/content/ContentResolver.html)
returns “true”.
### 7.4.7\. Data Saver
If device implementations include a metered connection, they are:
* [SR] STRONGLY RECOMMENDED to provide the data saver mode.
If Handheld device implementations include a metered connection, they:
* [H-1-1] MUST provide the data saver mode.
If device implementations provide the data saver mode, they:
* [C-1-1] MUST support all the APIs in the `ConnectivityManager`
class as described in the [SDK documentation](
https://developer.android.com/training/basics/network-ops/data-saver.html)
* [C-1-2] MUST provide a user interface in the settings, that handles the
[`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](
https://developer.android.com/reference/android/provider/Settings.html#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
intent, allowing users to add applications to or remove applications
from the whitelist.
If device implementations do not provide the data saver mode, they:
* [C-2-1] MUST return the value `RESTRICT_BACKGROUND_STATUS_DISABLED` for
[`ConnectivityManager.getRestrictBackgroundStatus()`](
https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus%28%29)
* [C-2-2] MUST NOT broadcast
`ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED`.
* [C-2-3] MUST have an activity that handles the
`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`
intent but MAY implement it as a no-op.

192
android/compatibility/cdd/7_hardware-compatibility/7_5_cameras.md Normal file
View file

@ -0,0 +1,192 @@
## 7.5\. Cameras
If device implementations include at least one camera, they:
* [C-1-1] MUST declare the `android.hardware.camera.any` feature flag.
* [C-1-2] MUST be possible for an application to simultaneously allocate
3 RGBA_8888 bitmaps equal to the size of the images produced by the
largest-resolution camera sensor on the device, while camera is open for the
purpose of basic preview and still capture.
### 7.5.1\. Rear-Facing Camera
A rear-facing camera is a camera located on the side of
the device opposite the display; that is, it images scenes on the far side of
the device, like a traditional camera.
Device implementations:
* SHOULD include a rear-facing camera.
If device implementations include at least one rear-facing camera, they:
* [C-1-1] MUST report the feature flag `android.hardware.camera` and
`android.hardware.camera.any`.
* [C-1-2] MUST have a resolution of at least 2 megapixels.
* SHOULD have either hardware auto-focus or software auto-focus implemented
in the camera driver (transparent to application software).
* MAY have fixed-focus or EDOF (extended depth of field) hardware.
* MAY include a flash.
If the Camera includes a flash:
* [C-2-1] the flash lamp MUST NOT be lit while an
`android.hardware.Camera.PreviewCallback` instance has been registered
on a Camera preview surface, unless the application has explicitly enabled
the flash by enabling the `FLASH_MODE_AUTO` or `FLASH_MODE_ON` attributes
of a `Camera.Parameters` object. Note that this constraint does not apply to the
device’s built-in system camera application, but only to third-party
applications using `Camera.PreviewCallback`.
### 7.5.2\. Front-Facing Camera
A front-facing camera is a camera located on the same side of the device
as the display; that is, a camera typically used to image the user, such
as for video conferencing and similar applications.
Device implementations:
* MAY include a front-facing camera
If device implementations include at least one front-facing camera, they:
* [C-1-1] MUST report the feature flag `android.hardware.camera.any` and
`android.hardware.camera.front`.
* [C-1-2] MUST have a resolution of at least VGA (640x480 pixels).
* [C-1-3] MUST NOT use a front-facing camera as the default for the
Camera API and MUST NOT configure the API to treat a front-facing camera as
the default rear-facing camera, even if it is the only camera on the device.
* [C-1-5] The camera preview MUST be mirrored horizontally relative to the
orientation specified by the application when the current application has
explicitly requested that the Camera
display be rotated via a call to the
[`android.hardware.Camera.setDisplayOrientation()`](
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int))
method. Conversely, the preview MUST be mirrored along the device’s default
horizontal axis when the the current application does not explicitly request
that the Camera display be rotated via a call to the
[`android.hardware.Camera.setDisplayOrientation()`](
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int))
method.
* [C-1-6] MUST NOT mirror the final captured still image or video streams
returned to application callbacks or committed to media storage.
* [C-1-7] MUST mirror the image displayed by the postview in the same manner
as the camera preview image stream.
* MAY include features (such as auto-focus, flash, etc.) available to
rear-facing cameras as described in [section 7.5.1](#7_5_1_rear-facing_camera).
If device implementations are capable of being rotated by user (such as
automatically via an accelerometer or manually via user input):
* [C-2-1] The camera preview MUST be mirrored horizontally relative to
the device’s current orientation.
### 7.5.3\. External Camera
Device implementations:
* MAY include support for an external camera that is not necessarily
always connected.
If device impelmentations include support for an external camera, they:
* [C-1-1] MUST declare the platform feature flag
`android.hardware.camera.external` and `android.hardware camera.any`.
* [C-1-2] MUST support USB Video Class (UVC 1.0 or higher) if the external
camera connects through the USB port.
* SHOULD support video compressions such as MJPEG to enable transfer of
high-quality unencoded streams (i.e. raw or independently compressed picture
streams).
* MAY support multiple cameras.
* MAY support camera-based video encoding. If supported, a simultaneous
unencoded / MJPEG stream (QVGA or greater resolution) MUST be accessible to
the device implementation.
### 7.5.4\. Camera API Behavior
Android includes two API packages to access the camera, the newer
android.hardware.camera2 API expose lower-level camera control to the app,
including efficient zero-copy burst/streaming flows and per-frame controls of
exposure, gain, white balance gains, color conversion, denoising, sharpening,
and more.
The older API package, `android.hardware.Camera`, is marked as deprecated in
Android 5.0 but as it should still be available for apps to use. Android device
implementations MUST ensure the continued support of the API as described in
this section and in the Android SDK.
Device implementations MUST implement the following behaviors for the
camera-related APIs, for all available cameras. Device implementations:
* [C-0-1] MUST use `android.hardware.PixelFormat.YCbCr_420_SP` for preview
data provided to application callbacks when an application has never called
`android.hardware.Camera.Parameters.setPreviewFormat(int)`.
* [C-0-2] MUST further be in the NV21 encoding format when an application
registers an `android.hardware.Camera.PreviewCallback`
instance and the system calls the `onPreviewFrame()` method and the preview
format is YCbCr_420_SP, the data in the byte[] passed into `onPreviewFrame()`.
That is, NV21 MUST be the default.
* [C-0-3] MUST support the YV12 format (as denoted by the
`android.graphics.ImageFormat.YV12` constant) for camera previews for both
front- and rear-facing cameras for `android.hardware.Camera`. (The hardware
video encoder and camera may use any native pixel format, but the device
implementation MUST support conversion to YV12.)
* [C-0-4] MUST support the `android.hardware.ImageFormat.YUV_420_888` and
`android.hardware.ImageFormat.JPEG` formats as outputs through the
`android.media.ImageReader` API for `android.hardware.camera2` devices that
advertise [`REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE`](
https://developer.android.com/reference/android/hardware/camera2/CameraMetadata.html#REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE)
capability in [`android.request.availableCapabilities`](
https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#REQUEST_AVAILABLE_CAPABILITIES).
* [C-0-5] MUST still implement the full [Camera API](
http://developer.android.com/reference/android/hardware/Camera.html)
included in the Android SDK documentation, 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.) Note that this does apply to front-facing
cameras; for instance, even though most front-facing cameras do not support
autofocus, the API callbacks must still be “faked” as described.
* [C-0-6] MUST recognize and honor each parameter name
defined as a constant on the
[`android.hardware.Camera.Parameters`](
http://developer.android.com/reference/android/hardware/Camera.Parameters.html)
class.
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`. That is,
device implementations MUST support all standard Camera parameters if the
hardware allows, and MUST NOT support custom Camera parameter types.
For instance, device implementations that support image capture
using high dynamic range (HDR) imaging techniques MUST support camera parameter
`Camera.SCENE_MODE_HDR`.
* [C-0-7] MUST report the proper level of support with the
[`android.info.supportedHardwareLevel`](
https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL)
property as described in the Android SDK and report the appropriate
[framework feature flags](
http://source.android.com/devices/camera/versioning.html).
* [C-0-8] MUST also declare its individual camera capabilities of
`android.hardware.camera2` via the
`android.request.availableCapabilities` property
and declare the appropriate [feature flags](
http://source.android.com/devices/camera/versioning.html);
MUST define the feature flag if any of its attached camera devices
supports the feature.
* [C-0-9] MUST broadcast the `Camera.ACTION_NEW_PICTURE`
intent whenever a new picture is taken by the camera and the entry of the
picture has been added to the media store.
* [C-0-10] MUST broadcast the `Camera.ACTION_NEW_VIDEO`
intent whenever a new video is recorded by the camera and the entry of the
picture has been added to the media store.
### 7.5.5\. Camera Orientation
If device implementations have a front- or a rear-facing camera, such camera(s):
* [C-1-1] MUST be oriented so that the long dimension of the camera
aligns with the screen’s long dimension. That is, when the device is held in the
landscape orientation, cameras MUST capture images in the landscape orientation.
This applies regardless of the device’s natural orientation; that is, it applies
to landscape-primary devices as well as portrait-primary devices.

189
android/compatibility/cdd/7_hardware-compatibility/7_6_memory-and-storage.md Normal file
View file

@ -0,0 +1,189 @@
## 7.6\. Memory and Storage
### 7.6.1\. Minimum Memory and Storage
Device implementations:
* [C-0-1] MUST include a [Download Manager](
http://developer.android.com/reference/android/app/DownloadManager.html)
that applications MAY use to download data files and they MUST be capable of
downloading individual files of at least 100MB in size to the default
“cache” location.
Television device implementations:
* [T-0-1] MUST have at least 4GB of non-volatile storage available for
application private data (a.k.a. "/data" partition)
Automotive device implementations:
* [A-0-1] MUST have at least 4GB of non-volatile storage available for
application private data (a.k.a. "/data" partition)
Watch device implementations:
* [W-0-1] MUST have at least 1GB of non-volatile storage available for
application private data (a.k.a. "/data" partition)
* [W-0-2] MUST have at least 416MB memory available to the kernel and
userspace.
Handheld device implementations:
* [H-0-1] MUST have at least 4GB of non-volatile storage available for
application private data (a.k.a. "/data" partition)
* [H-0-2] MUST return “true” for `ActivityManager.isLowRamDevice()` when there
is less than 1GB of memory available to the kernel and userspace.
If Handheld device implementations are 32-bit:
* [H-1-1] The memory available to the kernel and userspace MUST
be at least: 512MB if any of the following densities are used:
* 280dpi or lower on small/normal screens
* ldpi or lower on extra large screens
* mdpi or lower on large screens
* [H-2-1] The memory available to the kernel and userspace MUST
be at least: 608MB if any of the following densities are used:
* xhdpi or higher on small/normal screens
* hdpi or higher on large screens
* mdpi or higher on extra large screens
* [H-3-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
* [H-4-1] The memory available to the kernel and userspace MUST
be at least: 1344MB if any of the following densities are used:
* 560dpi or higher on small/normal screens
* 400dpi or higher on large screens
* xhdpi or higher on extra large screens
If Handheld device implementations are 64-bit:
* [H-5-1] The memory available to the kernel and userspace MUST
be at least: 816MB if any of the following densities are used:
* 280dpi or lower on small/normal screens
* ldpi or lower on extra large screens
* mdpi or lower on large screens
* [H-6-1] The memory available to the kernel and userspace MUST
be at least: 944MB if any of the following densities are used:
* xhdpi or higher on small/normal screens
* hdpi or higher on large screens
* mdpi or higher on extra large screens
* [H-7-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
* [H-8-1] The memory available to the kernel and userspace MUST
be at least: 1824MB if any of the following densities are used:
* 560dpi or higher on small/normal screens
* 400dpi or higher on large screens
* xhdpi 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.
### 7.6.2\. Application Shared Storage
Device implementations:
* [C-0-1] MUST offer storage to be shared by applications, also often referred
as “shared external storage”, "application shared storage" or by the Linux
path "/sdcard" it is mounted on.
* [C-0-2] MUST be configured with shared storage mounted by default, in other
words “out of the box”, regardless of whether the storage is implemented on
an internal storage component or a removable storage medium (e.g. Secure
Digital card slot).
* [C-0-3] MUST mount the application shared storage directly on the Linux path
`sdcard` or include a Linux symbolic link from `sdcard` to the actual mount
point.
* [C-0-4] MUST enforce the `android.permission.WRITE_EXTERNAL_STORAGE`
permission on this shared storage as documented in the SDK. Shared storage
MUST otherwise be writable by any application that obtains that permission.
Android handheld device implementations:
* [H-0-1] MUST NOT provide an application shared storage smaller than 1GiB.
Device implementations MAY meet the above requirements using either:
* a user-accessible removable storage, such as a Secure Digital (SD) card slot.
* a portion of the internal (non-removable) storage as implemented in the
Android Open Source Project (AOSP).
If device implementations use removable storage to satisfy the above
requirements, they:
* [C-1-1] MUST implement a toast or pop-up user interface warning the user
when there is no storage medium inserted in the slot.
* [C-1-2] MUST include a FAT-formatted storage medium (e.g. SD card) or show
on the box and other material available at time of purchase that the storage
medium has to be purchased separately.
If device implementations use a protion of the non-removable storage to satisfy
the above requirements, they:
* SHOULD use the AOSP implementation of the internal application shared
storage.
* MAY share the storage space with the application private data.
If device implementations include multiple shared storage paths (such
as both an SD card slot and shared internal storage), they:
* [C-3-1] MUST allow only pre-installed and privileged Android
applications with the `WRITE_EXTERNAL_STORAGE` permission to
write to the secondary external storage, except when writing to their
package-specific directories or within the `URI` returned by firing the
`ACTION_OPEN_DOCUMENT_TREE` intent.
If device implementations have a USB port with USB peripheral mode support,
they:
* [C-3-1] MUST provide a mechanism to access the data on the application
shared storage from a host computer.
* SHOULD expose content from both storage paths transparently through
Android’s media scanner service and `android.provider.MediaStore`.
* MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy
this requirement.
If device implementations have a USB port with USB peripheral mode and support
Media Transfer Protocol, they:
* SHOULD be compatible with the reference Android MTP host,
[Android File Transfer](http://www.android.com/filetransfer).
* SHOULD report a USB device class of 0x00.
* SHOULD report a USB interface name of 'MTP'.
### 7.6.3\. Adoptable Storage
If the device is expected to be mobile in nature unlike Television,
device implementations are:
* [SR] STRONGLY RECOMMENDED to implement the adoptable storage in
a long-term stable location, since accidentally disconnecting them can
cause data loss/corruption.
If the removable storage device port is in a long-term stable location,
such as within the battery compartment or other protective cover,
device implementations are:
* [SR] STRONGLY RECOMMENDED to implement
[adoptable storage](http://source.android.com/devices/storage/adoptable.html).

129
android/compatibility/cdd/7_hardware-compatibility/7_7_usb.md Normal file
View file

@ -0,0 +1,129 @@
## 7.7\. USB
If device implementations have a USB port, they:
* SHOULD support USB peripheral mode and SHOULD support USB host mode.
### 7.7.1\. USB peripheral mode
If handheld device implementations include a USB port supporting peripheral
mode, they:
* [H-1-1] MUST implement the Android Open Accessory (AOA) API.
If device implementations include a USB port supporting peripheral mode:
* [C-1-1] The port MUST be connectable to a USB host that has a standard
type-A or type-C USB port.
* [C-1-2] MUST report the correct value of `iSerialNumber` in USB standard
device descriptor through `android.os.Build.SERIAL`.
* [C-1-3] MUST detect 1.5A and 3.0A chargers per the Type-C resistor
standard and MUST detect changes in the advertisement if they support
Type-C USB.
* [SR] The port SHOULD use micro-B, micro-AB or Type-C USB form factor.
Existing and new Android devices are **STRONGLY RECOMMENDED to meet these
requirements** so they will be able to upgrade to the future platform releases.
* [SR] The port SHOULD be located on the bottom of the device
(according to natural orientation) or enable software screen rotation for
all apps (including home screen), so that the display draws correctly when
the device is oriented with the port at bottom. Existing and new Android
devices are **STRONGLY RECOMMENDED to meet these requirements** so they will
be able to upgrade to future platform releases.
* [SR] SHOULD implement support to draw 1.5 A current during HS chirp
and traffic as specified in the [USB Battery Charging specification, revision 1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
Existing and new Android devices are **STRONGLY RECOMMENDED to meet these
requirements** so they will be able to upgrade to the future platform releases.
* [SR] STRONGLY RECOMMENDED to not support proprietary
charging methods that modify Vbus voltage beyond default levels, or alter
sink/source roles as such may result in interoperability issues with the
chargers or devices that support the standard USB Power Delivery methods. While
this is called out as "STRONGLY RECOMMENDED", in future Android versions we
might REQUIRE all type-C devices to support full interoperability with standard
type-C chargers.
* [SR] STRONGLY RECOMMENDED to support Power Delivery for data and
power role swapping when they support Type-C USB and USB host mode.
* SHOULD support Power Delivery for high-voltage charging and support for
Alternate Modes such as display out.
* SHOULD implement the Android Open Accessory (AOA) API and specification as
documented in the Android SDK documentation.
If device implementations including a USB port, implement the AOA specification,
they:
* [C-2-1] MUST declare support for the hardware feature
[`android.hardware.usb.accessory`](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
* [C-2-2] The USB mass storage class MUST include the string "android" at the
end of the interface description `iInterface` string of the USB mass storage
* SHOULD NOT implement [AOAv2 audio](https://source.android.com/devices/accessories/aoa2#audio-support)
documented in the Android Open Accessory Protocol 2.0 documentation. AOAv2 audio
is deprecated as of Android version 8.0 (API level 26).
### 7.7.2\. USB host mode
If device implementations include a USB port supporting host mode, they:
* [C-1-1] MUST implement the Android USB host API as documented in the
Android SDK and MUST declare support for the hardware feature
[`android.hardware.usb.host`](http://developer.android.com/guide/topics/connectivity/usb/host.html).
* [C-1-2] MUST implement support to connect standard USB peripherals,
in other words, they MUST either:
* Have an on-device type C port or ship with cable(s) adapting an on-device
proprietary port to a standard USB type-C port (USB Type-C device).
* Have an on-device type A or ship with cable(s) adapting an on-device
proprietary port to a standard USB type-A port.
* Have an on-device micro-AB port, which SHOULD ship with a cable adapting
to a standard type-A port.
* [C-1-3] MUST NOT ship with an adapter converting from USB type A or
micro-AB ports to a type-C port (receptacle).
* [SR] STRONGLY RECOMMENDED to implement the [USB audio class](
http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
as documented in the Android SDK documentation.
* SHOULD support charging the connected USB peripheral device while in host
mode; advertising a source current of at least 1.5A as specified in the
Termination Parameters section of the
[USB Type-C Cable and Connector Specification Revision 1.2](
http://www.usb.org/developers/docs/usb_31_021517.zip) for USB Type-C
connectors or using Charging Downstream Port(CDP) output current range as
specified in the [USB Battery Charging specifications, revision 1.2](
http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip)
for Micro-AB connectors.
* SHOULD implement and support USB Type-C standards.
If device implementations include a USB port supporting host mode and the USB
audio class, they:
* [C-2-1] MUST support the [USB HID class](https://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_HID)
* [C-2-2] MUST support the detection and mapping of the following HID data
fields specified in the [USB HID Usage Tables](http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)
and the [Voice Command Usage Request](http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf)
to the [`KeyEvent`](https://developer.android.com/reference/android/view/KeyEvent.html)
constants as below:
* Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
* Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
* Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
* Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
If device implementations include a USB port supporting host mode and
the Storage Access Framework (SAF), they:
* [C-3-1] MUST recognize any remotely connected MTP (Media Transfer Protocol)
devices and make their contents accessible through the `ACTION_GET_CONTENT`,
`ACTION_OPEN_DOCUMENT`, and `ACTION_CREATE_DOCUMENT` intents. .
If device implementations include a USB port supporting host mode and USB
Type-C, they:
* [C-4-1] MUST implement Dual Role Port functionality as defined by the USB
Type-C specification (section 4.5.1.3.3).
* [SR] STRONGLY RECOMMENDED to support DisplayPort, SHOULD support USB
SuperSpeed Data Rates, and are STRONGLY RECOMMENDED to support Power Delivery
for data and power role swapping.
* [SR] STRONGLY RECOMMENDED to NOT support Audio Adapter Accessory Mode as
described in the Appendix A of the
[USB Type-C Cable and Connector Specification Revision 1.2](
http://www.usb.org/developers/docs/).
* SHOULD implement the Try.\* model that is most appropriate for the
device form factor. For example a handheld device SHOULD implement the
Try.SNK model.

127
android/compatibility/cdd/7_hardware-compatibility/7_8_audio.md Normal file
View file

@ -0,0 +1,127 @@
## 7.8\. Audio
### 7.8.1\. Microphone
* [H-0-1] Handheld device implementations MUST include a microphone.
* [W-0-1] Watch device implementations MUST include a microphone.
* [A-0-1] Automotive device implementations MUST include a microphone.
If device implementations include a microphone, they:
* [C-1-1] MUST report the `android.hardware.microphone` feature constant.
* [C-1-2] MUST meet the audio recording requirements in
[section 5.4](#5_4_audio_recording).
* [C-1-3] MUST meet the audio latency requirements in
[section 5.6](#5_6_audio_latency).
* [SR] STRONGLY RECOMMENDED to support near-ultrasound recording as described
in [section 7.8.3](#7_8_3_near_ultrasound).
If device implementations omit a microphone, they:
* [C-2-1] MUST NOT report the `android.hardware.microphone` feature constant.
* [C-2-2] MUST implement the audio recording API at least as no-ops, per
[section 7](#7_hardware_compatibility).
### 7.8.2\. Audio Output
If device implementations include a speaker or an audio/multimedia output
port for an audio output peripheral such as a 4 conductor 3.5mm audio jack or
USB host mode port using [USB audio class](
https://source.android.com/devices/audio/usb#audioClass), they:
* [C-1-1] MUST report the `android.hardware.audio.output` feature constant.
* [C-1-2] MUST meet the audio playback requirements in
[section 5.5](#5_5_audio_playback).
* [C-1-3] MUST meet the audio latency requirements in
[section 5.6](#5_6_audio_latency).
* [SR] STRONGLY RECOMMENDED to support near-ultrasound playback as described
in [section 7.8.3](#7_8_3_near_ultrasound).
If device implementations do not include a speaker or audio output port, they:
* [C-2-1] MUST NOT report the `android.hardware.audio output` feature.
* [C-2-2] MUST implement the Audio Output related APIs as no-ops at least.
* [H-0-1] Handheld device implementations MUST have an audio output and
declare `android.hardware.audio.output`.
* [T-0-1] Television device implementations MUST have an audio output and
declare `android.hardware.audio.output`.
* [A-0-1] Automotive device implementations MUST have an audio output and
declare `android.hardware.audio.output`.
* Watch device implementations MAY but SHOULD NOT have audio output.
For the purposes of this section, an "output port" is a
[physical interface](https://en.wikipedia.org/wiki/Computer_port_%28hardware%29)
such as a 3.5mm audio jack, HDMI, or USB host mode port with USB audio class.
Support for audio output over radio-based protocols such as Bluetooth,
WiFi, or cellular network does not qualify as including an "output port".
#### 7.8.2.1\. Analog Audio Ports
In order to be compatible with the [headsets and other audio accessories](
http://source.android.com/accessories/headset-spec.html)
using the 3.5mm audio plug across the Android ecosystem, if a device
implementation includes one or more analog audio ports, at least one of the
audio port(s) SHOULD be a 4 conductor 3.5mm audio jack.
If device implementations have a 4 conductor 3.5mm audio jack, they:
* [C-1-1] MUST support audio playback to stereo headphones and stereo headsets
with a microphone.
* [C-1-2] MUST support TRRS audio plugs with the CTIA pin-out order.
* [C-1-3] MUST support the detection and mapping to the keycodes for the
following 3 ranges of equivalent impedance between the microphone and ground
conductors on the audio plug:
* **70 ohm or less**: `KEYCODE_HEADSETHOOK`
* **210-290 ohm**: `KEYCODE_VOLUME_UP`
* **360-680 ohm**: `KEYCODE_VOLUME_DOWN`
* [C-1-4] MUST trigger `ACTION_HEADSET_PLUG` upon a plug insert, but
only after all contacts on plug are touching their relevant segments
on the jack.
* [C-1-5] MUST be capable of driving at least 150mV ± 10% of output voltage on
a 32 ohm speaker impedance.
* [C-1-6] MUST have a microphone bias voltage between 1.8V ~ 2.9V.
* [SR] STRONGLY RECOMMENDED to detect and map to the keycode for the following
range of equivalent impedance between the microphone and ground conductors
on the audio plug:
* **110-180 ohm:** `KEYCODE_VOICE_ASSIST`
* SHOULD support audio plugs with the OMTP pin-out order.
* SHOULD support audio recording from stereo headsets with a microphone.
If device implementations have a 4 conductor 3.5mm audio jack and support a
microphone, and broadcast the `android.intent.action.HEADSET_PLUG` with the
extra value microphone set as 1, they:
* [C-2-1] MUST support the detection of microphone on the plugged in audio
accessory.
### 7.8.3\. Near-Ultrasound
Near-Ultrasound audio is the 18.5 kHz to 20 kHz band.
Device implementations:
* MUST correctly report the support of
near-ultrasound audio capability via the [AudioManager.getProperty](
http://developer.android.com/reference/android/media/AudioManager.html#getProperty%28java.lang.String%29)
API as follows:
If [`PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND`](
http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND)
is "true", the following requirements MUST be met by the
`VOICE_RECOGNITION` and `UNPROCESSED` audio sources:
* [C-1-1] The microphone's mean power response in the 18.5 kHz to 20 kHz band
MUST be no more than 15 dB below the response at 2 kHz.
* [C-1-2] The microphone's unweighted signal to noise ratio over 18.5 kHz to 20 kHz
for a 19 kHz tone at -26 dBFS MUST be no lower than 50 dB.
If [`PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND`](
http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND)
is "true":
* [C-2-1] The speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower
than 40 dB below the response at 2 kHz.

100
android/compatibility/cdd/7_hardware-compatibility/7_9_virtual-reality.md Normal file
View file

@ -0,0 +1,100 @@
## 7.9\. Virtual Reality
Android includes APIs and facilities to build "Virtual Reality" (VR)
applications including high quality mobile VR experiences. Device
implementations MUST properly implement these APIs and behaviors,
as detailed in this section.
### 7.9.1\. Virtual Reality Mode
Android includes support for [VR Mode](
https://developer.android.com/reference/android/app/Activity.html#setVrModeEnabled%28boolean, android.content.ComponentName%29),
a feature which handles stereoscopic rendering of notifications and disables
monocular system UI components while a VR application has user focus.
If Handheld device implementations include support for the VR mode, they:
* [H-1-1] MUST declare the `android.software.vr.mode` feature.
If device implementations declare `android.software.vr.mode` feature, they:
* [H-2-1] MUST include an application implementing
`android.service.vr.VrListenerService`
that can be enabled by VR applications via
`android.app.Activity#setVrModeEnabled`.
### 7.9.2\. Virtual Reality High Performance
If Handheld device implementations are capable of meeting all the requirements
to declare the `android.hardware.vr.high_performance` feature flag, they:
* [H-1-1] MUST declare the `android.hardware.vr.high_performance`
feature flag.
If device implementations identify the support of high performance VR
for longer user periods through the `android.hardware.vr.high_performance`
feature flag, they:
* [C-1-1] MUST have at least 2 physical cores.
* [C-1-2] MUST declare `android.software.vr.mode feature`.
* [C-1-3] MUST support sustained performance mode.
* [C-1-4] MUST support OpenGL ES 3.2.
* [C-1-5] MUST support Vulkan Hardware Level 0 and SHOULD support
Vulkan Hardware Level 1.
* [C-1-6] MUST implement
[`EGL_KHR_mutable_render_buffer`](https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_mutable_render_buffer.txt),
[`EGL_ANDROID_front_buffer_auto_refresh`](https://www.khronos.org/registry/EGL/extensions/ANDROID/EGL_ANDROID_front_buffer_auto_refresh.txt),
[`EGL_ANDROID_get_native_client_buffer`](https://www.khronos.org/registry/EGL/extensions/ANDROID/EGL_ANDROID_get_native_client_buffer.txt),
[`EGL_KHR_fence_sync`](https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_fence_sync.txt),
[`EGL_KHR_wait_sync`](https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_wait_sync.txt),
[`EGL_IMG_context_priority`](https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt),
[`EGL_EXT_protected_content`](https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_protected_content.txt),
and expose the extensions in the list of available EGL extensions.
* [C-1-7] The GPU and display MUST be able to synchronize access to the shared
front buffer such that alternating-eye rendering of VR content at 60fps with two
render contexts will be displayed with no visible tearing artifacts.
* [C-1-8] MUST implement
[`GL_EXT_multisampled_render_to_texture`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture.txt),
[`GL_OVR_multiview`](https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview.txt),
[`GL_OVR_multiview2`](https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview2.txt),
[`GL_OVR_multiview_multisampled_render_to_texture`](https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview_multisampled_render_to_texture.txt),
[`GL_EXT_protected_textures`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_protected_textures.txt),
and expose the extensions in the list of available GL extensions.
* [C-1-9] MUST implement support for [`AHardwareBuffer`](https://developer.android.com/ndk/reference/hardware__buffer_8h.html)
flags `AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER` and
`AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA` as
described in the NDK.
* [C-1-10] MUST implement support for `AHardwareBuffers` with more than one
layer.
* [C-1-11] MUST support H.264 decoding at least 3840x2160@30fps-40Mbps
(equivalent to 4 instances of 1920x1080@30fps-10Mbps or 2 instances of
1920x1080@60fps-20Mbps).
* [C-1-12] MUST support HEVC and VP9, MUST be capable to decode at least
1920x1080@30fps-10Mbps and SHOULD be capable to decode
3840x2160@30fps-20Mbps (equivalent to
4 instances of 1920x1080@30fps-5Mbps).
* [C-1-13] MUST support `HardwarePropertiesManager.getDeviceTemperatures` API
and return accurate values for skin temperature.
* [C-1-14] MUST have an embedded screen, and its resolution MUST be at least be
FullHD(1080p) and STRONGLY RECOMMENDED TO BE be QuadHD (1440p) or higher.
* [C-1-15] The display MUST measure between 4.7" and 6.3" diagonal.
* [C-1-16] The display MUST update at least 60 Hz while in VR Mode.
* [C-1-17] The display latency on Gray-to-Gray, White-to-Black, and
Black-to-White switching time MUST be ≤ 3 ms.
* [C-1-18] The display MUST support a low-persistence mode with ≤5 ms
persistence, persistence being defined as the amount of time for
which a pixel is emitting light.
* [C-1-19] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension
[section 7.4.3](#7_4_3_bluetooth).
* [SR] STRONGLY RECOMMENDED to support
`android.hardware.sensor.hifi_sensors` feature and MUST meet the gyroscope,
accelerometer, and magnetometer related requirements for
`android.hardware.hifi_sensors`.
* MAY provide an exclusive core to the foreground
application and MAY support the `Process.getExclusiveCores` API to return
the numbers of the cpu cores that are exclusive to the top foreground
application. If exclusive core is supported then the core MUST not allow
any other userspace processes to run on it (except device drivers used
by the application), but MAY allow some kernel processes to run as
necessary.