Merge pi-dev as of ag/4582919 into stage-aosp-master.
Bug: 112189069
Change-Id: I67297b2d6eb189283acb350c1001010f0e9c81d9
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index e61222c..5f079ac 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -26,6 +26,19 @@
2.5 inches in physical diagonal size.
* [[7.1](#7_1_display-and-graphics).1.3/H-SR] Are STRONGLY RECOMMENDED to
provide users an affordance to change the display size.(Screen Density)
+
+If Handheld device implementations claim support for high dynamic range
+displays through [`Configuration.isScreenHdr()`
+](https://developer.android.com/reference/android/content/res/Configuration.html#isScreenHdr%28%29)
+, they:
+
+* [[7.1](#7_1_display-and-graphics).4.5/H-1-1] MUST advertise support for the
+ `EGL_EXT_gl_colorspace_bt2020_pq`, `EGL_EXT_surface_SMPTE2086_metadata`,
+ `EGL_EXT_surface_CTA861_3_metadata`, `VK_EXT_swapchain_colorspace`, and
+ `VK_EXT_hdr_metadata` extensions.
+
+Handheld device implementations:
+
* [[7.1](#7_1_display-and-graphics).5/H-0-1] 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
@@ -38,8 +51,16 @@
* [[7.2](#7_2_input-devices).3/H-0-2] MUST send both the normal and long press
event of the Back function ([`KEYCODE_BACK`](
http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-to the foreground application.
+to the foreground application. These events MUST NOT be consumed by the system
+and CAN be triggerred by outside of the Android device (e.g. external hardware
+keyboard connected to the Android device).
* [[7.2](#7_2_input-devices).4/H-0-1] MUST support touchscreen input.
+* [[7.2](#7_2_input-devices).4/H-SR] Are STRONGLY RECOMMENDED to launch the
+user-selected assist app, in other words the app that implements
+VoiceInteractionService, or an activity handling the [`ACTION_ASSIST`](https://developer.android.com/reference/android/content/Intent#ACTION_ASSIST)
+on long-press of [`KEYCODE_MEDIA_PLAY_PAUSE`](https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_MEDIA_PLAY_PAUSE)
+or [`KEYCODE_HEADSETHOOK`](https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_HEADSETHOOK)
+if the foreground activity does not handle those long-press events.
* [[7.3](#7_3_sensors).1/H-SR] Are STRONGLY RECOMMENDED to include a 3-axis
accelerometer.
@@ -155,24 +176,15 @@
* [[7.8](#7_8_audio).2/H-0-1] MUST have an audio output and declare
`android.hardware.audio.output`.
-If Handheld device implementations include support for the VR mode, they:
+If Handheld device implementations are capable of meeting all the performance
+requirements for supporting VR mode and include support for it, they:
* [[7.9](#7_9_virtual-reality).1/H-1-1] MUST declare the
-`android.software.vr.mode` feature.
-
-
-If device implementations declare `android.software.vr.mode` feature, they:
-
-* [[7.9](#7_9_virtual-reality).1/H-2-1] MUST include an application
-implementing `android.service.vr.VrListenerService`
-that can be enabled by VR applications via
-`android.app.Activity#setVrModeEnabled`.
-
-If Handheld device implementations are capable of meeting all the requirements
-to declare the `android.hardware.vr.high_performance` feature flag, they:
-
-* [[7.9](#7_9_virtual-reality).2/-1-1] MUST declare the
`android.hardware.vr.high_performance` feature flag.
+* [[7.9](#7_9_virtual-reality).1/H-1-2] MUST include an application
+implementing `android.service.vr.VrListenerService` that can be enabled by VR
+applications via `android.app.Activity#setVrModeEnabled`.
+
### 2.2.2\. Multimedia
@@ -207,13 +219,26 @@
Handheld device implementations:
+* [[3.2.3.1](#3_2_3_1_core-application-intents)/H-0-1] MUST have an
+application that handles the [`ACTION_GET_CONTENT`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_GET_CONTENT),
+[`ACTION_OPEN_DOCUMENT`](
+https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT),
+[`ACTION_OPEN_DOCUMENT_TREE`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE),
+and [`ACTION_CREATE_DOCUMENT`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_CREATE_DOCUMENT)
+intents as described in the SDK documents, and provide the user affordance
+to access the document provider data by using [`DocumentsProvider`](
+https://developer.android.com/reference/android/provider/DocumentsProvider) API.
* [[3.4](#3_4_web-compatibility).1/H-0-1] MUST provide a complete
implementation of the `android.webkit.Webview` API.
* [[3.4](#3_4_web-compatibility).2/H-0-1] MUST include a standalone Browser
application for general user web browsing.
* [[3.8](#3_8_user-interface-compatibility).1/H-SR] Are STRONGLY RECOMMENDED
-to implement a default launcher that supports in-app pinning of shortcuts and
-widgets.
+to implement a default launcher that supports in-app pinning of shortcuts,
+widgets and [widgetFeatures](
+https://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html#widgetFeatures).
* [[3.8](#3_8_user-interface-compatibility).1/H-SR] Are STRONGLY RECOMMENDED
to implement a default launcher that provides quick access to the additional
shortcuts provided by third-party apps through the [ShortcutManager](
@@ -237,10 +262,33 @@
notification shade, providing the user the ability to directly control (e.g.
reply, snooze, dismiss, block) the notifications through user affordance such as
action buttons or the control panel as implemented in the AOSP.
+* [[3.8](#3_8_user-interface-compatibility).3/H-0-5] MUST display the choices
+provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade.
+* [[3.8](#3_8_user-interface-compatibility).3/H-SR] Are STRONGLY RECOMMENDED
+to display the first choice provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade without additional user interaction.
+* [[3.8](#3_8_user-interface-compatibility).3/H-SR] Are STRONGLY RECOMMENDED
+to display all the choices provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade when the user expands all notifications in the
+notification shade.
* [[3.8](#3_8_user-interface-compatibility).4/H-SR] Are STRONGLY RECOMMENDED
to implement an assistant on the device to handle the [Assist action](
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
+If Handheld device implementations support Assist action, they:
+
+* [[3.8](#3_8_user-interface-compatibility).4/H-SR] Are STRONGLY RECOMMENDED
+to use long press on `HOME` key as the designated interaction to launch the
+assist app as described in [section 7.2.3](#7_2_3_navigation_keys) MUST launch
+the user-selected assist app, in other words the app that implements
+[`VoiceInteractionService`](
+https://developer.android.com/reference/android/service/voice/VoiceInteractionService)
+, or an activity handling the `ACTION_ASSIST` intent.
+
If Android Handheld device implementations support a lock screen, they:
* [[3.8](#3_8_user-interface-compatibility).10/H-1-1] MUST display the Lock
@@ -252,6 +300,11 @@
[device administration](
http://developer.android.com/guide/topics/admin/device-admin.html)
policies defined in the Android SDK documentation.
+* [[3.9](#3_9_device-administration)/H-1-2] MUST declare the support of
+managed profiles via the `android.software.managed_users` feature flag, except when the device is configured so that it would [report](
+http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
+itself as a low RAM device or so that it allocates internal (non-removable)
+storage as shared storage.
Handheld device implementations:
@@ -298,11 +351,15 @@
performance of at least 15 MB/s.
* [[8.2](#8_2_file-io-access-performance)/H-0-4] MUST ensure a random read
performance of at least 3.5 MB/s.
-* [[8.3](#8_3_power-saving-modes)/H-0-1] All Apps exempted from App Standby
-and Doze power-saving modes MUST be made visible to the end user.
-* [[8.3](#8_3_power-saving-modes)/H-0-2] The triggering, maintenance, wakeup
-algorithms and the use of global system settings of App Standby and Doze
-power-saving modes MUST not deviate from the Android Open Source Project.
+
+If Handheld device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
+
+* [[8.3](#8_3_power-saving-modes)/H-1-1] MUST provide user affordance to enable
+ and disable the battery saver feature.
+* [[8.3](#8_3_power-saving-modes)/H-1-2] MUST provide user affordance to display
+ all apps that are exempted from App Standby and Doze power-saving modes.
Handheld device implementations:
@@ -342,3 +399,13 @@
https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
intent.
+When Handheld device implementations support a secure lock screen, they:
+
+* [[9.11](#9_11_permissions)/H-1-1] MUST allow the user to choose the shortest
+ sleep timeout, that is a transition time from the unlocked to the locked
+ state, as 15 seconds or less.
+* [[9.11](#9_11_permissions)/H-1-2] MUST provide user affordance to hide
+ notifications and disable all forms of authentication except for the
+ primary authentication described in
+ [9.11.1 Secure Lock Screen](#9_11_1_secure-lock-screen). The AOSP meets the
+ requirement as lockdown mode.
\ No newline at end of file
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 0cf24ed..0856947 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -1,4 +1,3 @@
-## 2.3\. Television Requirements
An **Android Television device** refers to an Android device implementation that
is an entertainment interface for consuming digital media, movies, games, apps,
@@ -50,6 +49,12 @@
non-volatile storage available for application private data
(a.k.a. "/data" partition).
+If Television device implementations include a USB port that supports host mode,
+they:
+
+* [[7.5](#7_5_camera).3/T-1-1] MUST include support for an external camera
+that connects through this USB port but is not necessarily always connected.
+
If TV device implementations are 32-bit:
* [[7.6](#7_6_memory-and-storage).1/T-1-1] The memory available to the kernel
@@ -148,27 +153,32 @@
Television device implementations:
-* [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to support
-simultaneous decoding of secure streams. At minimum, simultaneous decoding of
-two steams is STRONGLY RECOMMENDED.
-
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-* [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2 for all wired
-external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-* [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4 for all wired
-external displays.
-
-Television device implementations:
-
* [[5.5](#5_5_audio-playback).3/T-0-1] MUST include support for system Master
Volume and digital audio output volume attenuation on supported outputs,
except for compressed audio passthrough output (where no audio decoding is done
on the device).
+* [[5.8](#5_8_secure-media)/T-0-1] MUST set the HDMI output mode to
+select the maximum resolution that can be supported with either 50Hz or 60Hz
+refresh rate for all wired displays.
+* [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to provide a user
+configurable HDMI refresh rate selector for all wired displays.
+* [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to support
+simultaneous decoding of secure streams. At minimum, simultaneous decoding of
+two steams is STRONGLY RECOMMENDED.
+* [[5.8](#5_8_secure-media)] SHOULD set the HDMI output mode refresh rate
+to either 50Hz or 60Hz, depending on the video refresh rate for the region the
+device is sold in for all wired displays.
+
+If Television device implementations support UHD decoding and have support
+for external displays, they:
+
+* [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2.
+
+If Television device implementations do not support UHD decoding but have
+support for external displays, they:
+
+* [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4
+
### 2.3.3\. Software
@@ -214,7 +224,7 @@
* [[3.12](#3_12_tv-input-framework)/T-0-1] MUST support TV Input Framework.
-### 2.2.4\. Performance and Power
+### 2.3.4\. Performance and Power
* [[8.1](#8_1_user-experience-consistency)/T-0-1] **Consistent frame latency**.
Inconsistent frame latency or a delay to render frames MUST NOT happen more
@@ -228,12 +238,14 @@
* [[8.2](#8_2_file-io-access-performance)/T-0-4] MUST ensure a random read
performance of at least 3.5MB/s.
+If Television device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
-* [[8.3](#8_3_power-saving-modes)/T-0-1] All apps exempted from App Standby
-and Doze power-saving modes MUST be made visible to the end user.
-* [[8.3](#8_3_power-saving-modes)/T-0-2] The triggering, maintenance, wakeup
-algorithms and use of global system settings of App Standby and Doze
-power-saving modes MUST not deviate from the Android Open Source Project.
+* [[8.3](#8_3_power-saving-modes)/T-1-1] MUST provide user affordance to enable
+ and disable the battery saver feature.
+* [[8.3](#8_3_power-saving-modes)/T-1-2] MUST provide user affordance to display
+ all apps that are exempted from App Standby and Doze power-saving modes.
Television device implementations:
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 6bfacc8..aa5912a 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -78,3 +78,35 @@
* [[3.11](#3_11_text-to-speech)/W-0-1] MUST support installation of
third-party TTS engines.
+
+### 2.4.4\. Performance and Power
+
+If Watch device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
+
+* [[8.3](#8_3_power-saving-modes)/W-SR] Are STRONGLY RECOMMENDED to provide
+ user affordance to display all apps that are exempted from App Standby and
+ Doze power-saving modes.
+* [[8.3](#8_3_power-saving-modes)/W-SR] Are STRONGLY RECOMMENDED to provide
+ user affordance to enable and disable the battery saver feature.
+
+Watch device implementations:
+
+* [[8.4](#8_4_power-consumption-accounting)/W-0-1] MUST provide a
+per-component power profile that defines the [current consumption value](
+http://source.android.com/devices/tech/power/values.html).
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+* [[8.4](#8_4_power-consumption-accounting)/W-0-2] MUST report all power
+consumption values in milliampere hours (mAh).
+* [[8.4](#8_4_power-consumption-accounting)/W-0-3] MUST report CPU power
+consumption per each process's UID. The Android Open Source Project meets the
+requirement through the `uid_cputime` kernel module implementation.
+* [[8.4](#8_4_power-consumption-accounting)/W-0-4] MUST make this power usage
+available via the [`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
+* [[8.4](#8_4_power-consumption-accounting)/W] SHOULD be attributed to the
+hardware component itself if unable to attribute hardware component power usage
+to an application.
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index d529946..9246a37 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -55,7 +55,7 @@
Automotive device implementations:
-* [[7.3](#7_3_sensors).11/A] SHOULD provide current gear as
+* [[7.3](#7_3_sensors).11/A-0-1] MUST provide current gear as
`SENSOR_TYPE_GEAR`.
Automotive device implementations:
@@ -68,16 +68,12 @@
* The underlying ambient light sensor MAY be the same as
[Photometer](#7_3_7_photometer).
-* [[7.3](#7_3_sensors).11.3/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](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed defined as
+* [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed as defined by
`SENSOR_TYPE_CAR_SPEED`.
+* [[7.3](#7_3_sensors).11.5/A-0-1] MUST provide parking brake status as
+defined by `SENSOR_TYPE_PARKING_BRAKE`.
+
* [[7.4](#7_4_data-connectivity).3/A-0-1] MUST support Bluetooth and SHOULD
support Bluetooth LE.
* [[7.4](#7_4_data-connectivity).3/A-0-2] Android Automotive implementations
@@ -86,16 +82,32 @@
* Media playback over Audio Distribution Profile (A2DP).
* Media playback control over Remote Control Profile (AVRCP).
* Contact sharing using the Phone Book Access Profile (PBAP).
-* [[7.4](#7_4_data-connectivity).3/A] SHOULD support Message Access Profile
-(MAP).
+* [[7.4](#7_4_data-connectivity).3/A-SR] Are STRONGLY RECOMMENDED to support
+Message Access Profile (MAP).
* [[7.4](#7_4_data-connectivity).5/A] SHOULD include support for cellular
-network based data connectivity.
+network-based data connectivity.
+* [[7.4](#7_4_data-connectivity).5/A] MAY use the System API
+`NetworkCapabilities#NET_CAPABILITY_OEM_PAID` constant for
+networks that should be available to system apps.
* [[7.6](#7_6_memory-and-storage).1/A-0-1] MUST have at least 4GB of
non-volatile storage available for application private data
(a.k.a. "/data" partition).
+Automotive device implementations:
+
+* [[7.6](#7_6_memory-and-storage).1/A] SHOULD format the data partition
+to offer improved performance and longevity on flash storage, for example
+using `f2fs` file-system.
+
+If Automotive device implementations provide shared external storage via a
+portion of the internal non-removable storage, they:
+
+* [[7.6](#7_6_memory-and-storage).1/A-SR] Are STRONGLY RECOMMENDED to reduce
+I/O overhead on operations performed on the external storage, for example by
+using `SDCardFS`.
+
If Automotive device implementations are 32-bit:
* [[7.6](#7_6_memory-and-storage).1/A-1-1] The memory available to the kernel
@@ -199,10 +211,13 @@
* [[3](#3_0_intro)/A-0-1] MUST declare the feature
`android.hardware.type.automotive`.
-* [[3](#3_0_intro)/A-0-2] MUST support uiMode = [UI_MODE_TYPE_CAR](
+
+* [[3](#3_0_intro)/A-0-2] MUST support uiMode = [`UI_MODE_TYPE_CAR`](
http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR).
-* [[3](#3_0_intro)/A-0-3] Android Automotive implementations MUST support all
-public APIs in the `android.car.*` namespace.
+
+* [[3](#3_0_intro)/A-0-3] MUST support all public APIs in the
+[`android.car.*`](https://developer.android.com/reference/android/car/package-summary)
+namespace.
* [[3.4](#3_4_web-compatibility).1/A-0-1] MUST provide a complete
implementation of the `android.webkit.Webview` API.
@@ -213,23 +228,45 @@
API when requested by third-party applications.
* [[3.8](#3_8_user-interface-compatibility).4/A-0-1] MUST implement an
-assistant on the device to handle the [Assist action](
-http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
+assistant on the device that provides a default implementation of the
+[`VoiceInteractionSession`](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession)
+service.
-* [[3.14](#3_14_media_ui)/A-0-1] MUST include a UI framework to support
-third-party apps using the media APIs as described in section 3.14.
+* [[3.13](#3_13_quick_settings)/A-SR] Are STRONGLY RECOMMENDED to include a
+Quick Settings UI component.
-### 2.2.4\. Performance and Power
+If Automotive device implementations include a push-to-talk button, they:
+
+* [[3.8](#3_8_user-interface-compatibility).4/A-1-1] MUST use a short press of
+the push-to-talk button as the designated interaction to launch the
+user-selected assist app, in other words the app that implements
+[`VoiceInteractionService`](
+https://developer.android.com/reference/android/service/voice/VoiceInteractionService).
Automotive device implementations:
-* [[8.3](#8_3_power-saving-modes)/A-0-1] All Apps exempted from App Standby
-and Doze power-saving modes MUST be made visible to the end user.
-* [[8.3](#8_3_power-saving-modes)/A-0-2] The triggering, maintenance, wakeup
-algorithms and the use of global system settings of App Standby and Doze
-power-saving modes MUST not deviate from the Android Open Source Project.
+* [[3.14](#3_14_media_ui)/A-0-1] MUST include a UI framework to support
+third-party apps using the media APIs as described in section
+[3.14](#3_14_media_ui).
+### 2.5.4\. Performance and Power
+If Automotive device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
+
+* [[8.3](#8_3_power-saving-modes)/A-1-1] MUST provide user affordance to enable
+ and disable the battery saver feature.
+* [[8.3](#8_3_power-saving-modes)/A-1-2] MUST provide user affordance to display
+ all apps that are exempted from App Standby and Doze power-saving modes.
+
+Automotive device implementations:
+
+* [[8.2](#8.2_File I/O Access Performance)/A-0-1] MUST report the number of
+bytes read and written to non-volatile storage per each process's UID so the
+stats are available to developers through System API
+`android.car.storagemonitoring.CarStorageMonitoringManager`. The Android Open
+Source Project meets the requirement through the `uid_sys_stats` kernel module.
* [[8.4](#8_4_power-consumption-accounting)/A-0-1] MUST provide a
per-component power profile that defines the [current consumption value](
http://source.android.com/devices/tech/power/values.html)
@@ -248,15 +285,21 @@
http://source.android.com/devices/tech/power/batterystats.html)
shell command to the app developer.
-### 2.2.5\. Security Model
+### 2.5.5\. Security Model
-If Automotive device implementations include multiple users, they:
+If Automotive device implementations support multiple users, they:
* [[9.5](#9_5_multi-user-support)/A-1-1] MUST include a guest account that
allows all functions provided by the vehicle system without requiring a user to
log in.
+If Automotive device implementations support a secure lock screen, they:
+
+* [[9.9](#9_9_full-disk-encryption).2/A-1-1] MUST support encryption per
+user-specific authentication keys. [File-Based Encryption (FBE)](
+https://source.android.com/security/encryption/file-based) is one way to do it.
+
Automotive device implementations:
* [[9.14](#9_14_automotive-system-isolation)/A-0-1] MUST gatekeep messages
@@ -265,4 +308,4 @@
* [[9.14](#9_14_automotive-system-isolation)/A-0-2] MUST watchdog against
denial of service attacks from the Android framework or third-party apps. This
guards against malicious software flooding the vehicle network with traffic,
-which may lead to malfunctioning vehicle subsystems.
+which may lead to malfunctioning vehicle subsystems.
\ No newline at end of file
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 2e055f5..8051028 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -8,100 +8,6 @@
If device implementations support TIF, they:
* [C-1-1] MUST declare the platform feature `android.software.live_tv`.
-* [C-1-2] MUST preload a TV application (TV App) and meet all requirements
- described in [section 3.12.1](#3_12_tv-input-framework).
-
-### 3.12.1\. TV App
-
-If device implementations support TIF:
-
-* [C-1-1] The TV App MUST provide facilities to install and use [TV Channels](
-http://developer.android.com/reference/android/media/tv/TvContract.Channels.html)
-and meet the following requirements.
-
-The TV app that is required for Android device implementations declaring the
-`android.software.live_tv` feature flag, MUST meet the following requirements:
-
-* Device implementations SHOULD allow third-party TIF-based inputs
- ([third-party inputs](
- https://source.android.com/devices/tv/index.html#third-party_input_example))
- to be installed and managed.
-* Device implementations MAY provide visual separation between pre-installed
- [TIF-based inputs](
- https://source.android.com/devices/tv/index.html#tv_inputs)
- (installed inputs) and third-party inputs.
-* Device implementations SHOULD NOT display the third-party inputs more than a
- single navigation action away from the TV App (i.e. expanding a list of
- third-party inputs from the TV App).
-
-The Android Open Source Project provides an implementation of the TV App that
-meets the above requirements.
-
-#### 3.12.1.1\. Electronic Program Guide
-
-If device implementations support TIF, they:
-
-* [C-1-1] MUST show an informational and
-interactive overlay, which MUST include an electronic program guide (EPG)
-generated from the values in the [TvContract.Programs](
-https://developer.android.com/reference/android/media/tv/TvContract.Programs.html)
-fields.
-* [C-1-2] On channel change, device implementations MUST display EPG data for
- the currently playing program.
-* [SR] The EPG is STRONGLY RECOMMENDED to display installed inputs and
- third-party inputs with equal prominence. The EPG SHOULD NOT display the
- third-party inputs more than a single navigation action away from the
- installed inputs on the EPG.
-* The EPG SHOULD display information from all installed inputs and third-party
- inputs.
-* The EPG MAY provide visual separation between the installed inputs and
- third-party inputs.
-
-#### 3.12.1.2\. Navigation
-
-If device implementations support TIF, they:
-
-* [C-1-1] MUST allow navigation for the following functions via
-the D-pad, Back, and Home keys on the Android Television device’s input
-device(s) (i.e. remote control, remote control application, or game controller):
-
- * Changing TV channels
- * Opening EPG
- * Configuring and tuning to third-party TIF-based inputs (if those inputs are supported)
- * Opening Settings menu
-
-* SHOULD pass key events to HDMI inputs through CEC.
-
-#### 3.12.1.3\. TV input app linking
-
-If device implementations support TIF:
-
-* [C-1-1] Android Television device implementations MUST support
-[TV input app linking](
-http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI),
-which allows all inputs to provide activity links from the current activity to
-another activity (i.e. a link from live programming to related content). The TV
-App SHOULD show TV input app linking when it is provided.
-
-#### 3.12.1.4\. Time shifting
-
-If device implementations support TIF, they:
-
-* [SR] STRONGLY RECOMMENDED to support time shifting, which allows the user
-to pause and resume live content.
-* SHOULD provide the user a way to pause and resume the currently playing
-program, if time shifting for that program [is available](
-https://developer.android.com/reference/android/media/tv/TvInputManager.html#TIME_SHIFT_STATUS_AVAILABLE).
-
-#### 3.12.1.5\. TV recording
-
-If device implementations support TIF, they:
-
-* [SR] STRONGLY RECOMMENDED to support TV recording.
-* SHOULD provide a user interface to play recorded
-programs.
-* If the TV input supports recording and the recording of a program is not
-[prohibited](
-https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED),
-the EPG MAY provide a way to [record a program](
-https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29).
+* [C-1-2] MUST support all TIF APIs such that an application which uses
+these APIs and the [third-party TIF-based inputs](https://source.android.com/devices/tv/index.html#third-party_input_example)
+service can be installed and used on the device.
\ No newline at end of file
diff --git a/3_software/3_14_media-ui.md b/3_software/3_14_media-ui.md
index 18d0f14..fb6d358 100644
--- a/3_software/3_14_media-ui.md
+++ b/3_software/3_14_media-ui.md
@@ -14,7 +14,9 @@
* [C-1-2] MUST display those items as described by MediaSession, e.g.,
metadata, icons, imagery.
* [C-1-3] MUST show app title.
-* [C-1-4] MUST have drawer to present [MediaBrowser](
+* [C-1-4] MUST have a drawer or other mechanism to present [MediaBrowser](
+ http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+ hierarchy and provide user affordance for the [MediaBrowser](
http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
hierarchy.
* [C-1-5] MUST consider double tap of [`KEYCODE_HEADSETHOOK`](
diff --git a/3_software/3_15_instant-apps.md b/3_software/3_15_instant-apps.md
index f8d290f..1091e81 100644
--- a/3_software/3_15_instant-apps.md
+++ b/3_software/3_15_instant-apps.md
@@ -3,8 +3,9 @@
Device implementations MUST satisfy the following requirements:
* [C-0-1] Instant Apps MUST only be granted permissions that have the
- [`android:protectionLevel`](https://developer.android.com/guide/topics/manifest/permission-element.html#plevel)
- set to `"ephemeral"`.
+ [`android:protectionLevel`](
+ https://developer.android.com/reference/android/R.attr#protectionLevel)
+ set to `"instant"`.
* [C-0-2] Instant Apps MUST NOT interact with installed apps via [implicit intents](https://developer.android.com/reference/android/content/Intent.html)
unless one of the following is true:
* The component's intent pattern filter is exposed and has CATEGORY_BROWSABLE
diff --git a/3_software/3_17_Heavyweight_apps.md b/3_software/3_17_Heavyweight_apps.md
new file mode 100644
index 0000000..011b58a
--- /dev/null
+++ b/3_software/3_17_Heavyweight_apps.md
@@ -0,0 +1,31 @@
+## 3.17\. Heavyweight Apps
+
+If device implementations declare the feature [`FEATURE_CANT_SAVE_STATE`](
+https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_CANT_SAVE_STATE),
+then they:
+
+* [C-1-1] MUST have only one installed app that specifies
+ [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
+ running in the system at a time. If the user
+ leaves such an app without explicitly exiting it (for example by pressing
+ home while leaving an active activity the system, instead of pressing back
+ with no remaining active activities in the system), then
+ device implementations MUST prioritize that app in RAM as they do for other
+ things that are expected to remain running, such as foreground services.
+ While such an app is in the background, the system can still apply power
+ management features to it, such as limiting CPU and network access.
+* [C-1-2] MUST provide a UI affordance to chose the app that won't
+ participate in the normal state save/restore mechanism once the user
+ launches a second app declared with [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
+ attribute.
+* [C-1-3] MUST NOT apply other changes in policy to apps that specify
+ [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState),
+ such as changing CPU performance or changing scheduling prioritization.
+
+If device implementations don't declare the feature [`FEATURE_CANT_SAVE_STATE`](
+https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_CANT_SAVE_STATE),
+then they:
+
+* [C-1-1] MUST ignore the [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
+ attribute set by apps and MUST NOT change the app behavior based on that
+ attribute.
\ No newline at end of file
diff --git a/3_software/3_1_managed-api-compatibility.md b/3_software/3_1_managed-api-compatibility.md
index 05b95c2..92eb603 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -5,24 +5,43 @@
set of Android platform interfaces exposed to applications running in the
managed runtime environment.
-* [C-0-1] Device implementations MUST provide complete implementations,
-including all documented behaviors, of any documented API exposed by the
-[Android SDK](http://developer.android.com/reference/packages.html)
-or any API decorated with the “@SystemApi” marker in the upstream Android
-source code.
+Device implementations:
-* [C-0-2] Device implementations MUST support/preserve all classes,
-methods, and associated elements marked by the TestApi annotation (@TestApi).
+* [C-0-1] MUST provide complete implementations, including all documented
+ behaviors, of any documented API exposed by the [Android SDK](
+ http://developer.android.com/reference/packages.html)
+ or any API decorated with the “@SystemApi” marker in the upstream Android
+ source code.
-* [C-0-3] Device implementations MUST NOT omit any managed APIs, alter
-API interfaces or signatures, deviate from the documented behavior, or include
-no-ops, except where specifically allowed by this Compatibility Definition.
+* [C-0-2] MUST support/preserve all classes, methods, and associated elements
+ marked by the TestApi annotation (@TestApi).
-* [C-0-4] Device implementations MUST still keep the APIs present and behave
+* [C-0-3] MUST NOT omit any managed APIs, alter API interfaces or signatures,
+ deviate from the documented behavior, or include no-ops, except where
+ specifically allowed by this Compatibility Definition.
+
+* [C-0-4] MUST still keep the APIs present and behave
in a reasonable way, even when some hardware features for which Android
includes APIs are omitted. See [section 7](#7_hardware_compatibility)
for specific requirements for this scenario.
+* [C-0-5] MUST restrict the use of 3rd-party app usage of hidden APIs,
+ defined as APIs in the android namespace decorated with the `@hidden`
+ annotation but not with a `@SystemAPI` or `@TestApi`, as described in the
+ [SDK documents](https://developer.android.com/preview/restrictions-non-sdk-interfaces)
+ and ship with each and every hidden API on the the same restricted lists as
+ provided via the light-greylist, dark-greylist, and blacklist files in the
+ `prebuilts/runtime/appcompat/` path for the appropriate API level branch
+ in the AOSP. However they:
+
+ * MAY, if a hidden API is absent or implemented differently on the device
+ implementation, move the hidden API into the blacklist or omit it from
+ all restricted lists (i.e. light-grey, dark-grey, black).
+ * MAY, if a hidden API does not already exist in the AOSP, add the hidden
+ API to any of the restricted lists (i.e. light-grey, dark-grey, black).
+ * MAY implement a dynamic update mechanism that moves a hidden API from a
+ restricted list into a less restrictive list, except for the whitelist.
+
## 3.1.1\. Android Extensions
Android includes the support of extending the managed APIs while keeping the
@@ -33,3 +52,18 @@
higher than or equal to the minimum versions allowed per each API level.
For example, Android 7.0 device implementations, running API level 24 MUST
include at least version 1.
+
+## 3.1.2\. Android Library
+
+Due to [Apache HTTP client deprecation](https://developer.android.com/preview/behavior-changes#apache-p),
+device implementations:
+
+* [C-0-1] MUST NOT place the `org.apache.http.legacy` library in the
+bootclasspath.
+* [C-0-2] MUST add the `org.apache.http.legacy` library to the application
+classpath only when the app satisfies one of the following conditions:
+ * Targets API level 28 or lower.
+ * Declares in its manifest that it needs the library by setting the
+ `android:name` attribute of `<uses-library>` to `org.apache.http.legacy`.
+
+The AOSP implementation meets these requirements.
\ No newline at end of file
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 0d4a3ce..169347b 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -175,10 +175,7 @@
</tr>
<tr>
<td>SERIAL</td>
- <td>A hardware serial number, which MUST be available and unique across
- devices with the same MODEL and MANUFACTURER. The value of this field MUST
- be encodable as 7-bit ASCII and match the regular expression
- “^([a-zA-Z0-9]{6,20})$”.</td>
+ <td>MUST return "UNKNOWN".</td>
</tr>
<tr>
<td>TAGS</td>
@@ -237,6 +234,13 @@
encodable as 7-bit ASCII and match the regular expression
“^[a-zA-Z0-9._-,]+$”.</td>
</tr>
+ <tr>
+ <td><a href="https://developer.android.com/reference/android/os/Build.html#getSerial()">getSerial()</a></td>
+ <td> MUST (be or return) a hardware serial number, which MUST be available
+ and unique across devices with the same MODEL and MANUFACTURER. The value of
+ this field MUST be encodable as 7-bit ASCII and match the regular expression
+ “^[a-zA-Z0-9._-,]+$”.</td>
+ </tr>
</table>
### 3.2.3\. Intent Compatibility
@@ -266,8 +270,9 @@
* [C-0-1] As Android is an extensible platform, device implementations MUST
allow each intent pattern referenced in [section 3.2.3.1](#3_2_3_1_core_application_intents)
-to be overridden by third-party applications. The upstream Android open source
-implementation allows this by default.
+, except for Settings, to be overridden by third-party applications. The
+upstream Android open source implementation allows this by default.
+
* [C-0-2] Dvice implementers MUST NOT attach special privileges to system
applications' use of these intent patterns, or prevent third-party applications
from binding to and assuming control of these patterns. This prohibition
@@ -360,13 +365,16 @@
* [C-2-1] MUST provide a settings menu that will call the
[`android.provider.Telephony.ACTION_CHANGE_DEFAULT`](
-http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html)
+http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html#ACTION_CHANGE_DEFAULT)
intent to show a dialog to change the default SMS application.
* [C-2-2] MUST honor the [`android.telecom.action.CHANGE_DEFAULT_DIALER`](
https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER)
intent to show a dialog to allow the user to change the default Phone
application.
+ * MUST use the user-selected default Phone app's UI for incoming and
+ outgoing calls except for emergency calls, which would use the
+ preloaded Phone app.
* [C-2-3] MUST honor the [android.telecom.action.CHANGE_PHONE_ACCOUNTS](
https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_PHONE_ACCOUNTS)
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index c1e4f46..5a8eb57 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -24,20 +24,19 @@
* [C-0-3] MUST be source-compatible (i.e. header-compatible) and
binary-compatible (for the ABI) with each required library in the list
below.
-* [C-0-4] MUST support the equivalent 32-bit ABI if any 64-bit ABI is
- supported.
* [C-0-5] MUST accurately report the native Application Binary Interface
(ABI) supported by the device, via the `android.os.Build.SUPPORTED_ABIS`,
`android.os.Build.SUPPORTED_32_BIT_ABIS`, and
`android.os.Build.SUPPORTED_64_BIT_ABIS` parameters, each a comma separated
list of ABIs ordered from the most to the least preferred one.
-* [C-0-6] MUST report, via the above parameters, only those ABIs documented
- and described in the latest version of the
- [Android NDK ABI Management documentation](
- https://developer.android.com/ndk/guides/abis.html), and MUST include
- support for the [Advanced SIMD](
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html)
- (a.k.a. NEON) extension.
+* [C-0-6] MUST report, via the above parameters, a subset of the following
+ list of ABIs and MUST NOT report any ABI not on the list.
+
+ * `armeabi`
+ * `armeabi-v7a`
+ * `arm64-v8a`
+ * `x86`
+ * `x86-64`
* [C-0-7] MUST make all the following libraries, providing native APIs,
available to apps that include native code:
@@ -79,7 +78,7 @@
in more detail the requirements for when the full implementation of each
corresponding functions are expected.
* [C-0-12] MUST export function symbols for the core Vulkan 1.0 function
- symobls, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
+ symbols, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
`VK_KHR_swapchain`, `VK_KHR_maintenance1`, and
`VK_KHR_get_physical_device_properties2` extensions through the
`libvulkan.so` library. Note that while all the symbols MUST be present,
@@ -88,32 +87,35 @@
* SHOULD be built using the source code and header files available in the
upstream Android Open Source Project
-Note that future releases of the Android NDK may introduce support for
-additional ABIs.
+Note that future releases of Android may introduce support for additional
+ABIs.
### 3.3.2. 32-bit ARM Native Code Compatibility
-If device implementations are 64-bit ARM devices, then:
+If device implementations report the support of the `armeabi` ABI, they:
-* [C-1-1] Although the ARMv8 architecture deprecates several CPU operations,
- including some operations used in existing native code, the following
- deprecated operations MUST remain available to 32-bit native ARM code,
- either through native CPU support or through software emulation:
+* [C-3-1] MUST also support `armeabi-v7a` and report its support, as
+ `armeabi` is only for backwards compatibility with older apps.
- * SWP and SWPB instructions
- * SETEND instruction
- * CP15ISB, CP15DSB, and CP15DMB barrier operations
+If device implementations report the support of the `armeabi-v7a` ABI, for apps
+using this ABI, they:
-If device implementations include a 32-bit ARM ABI, they:
-
-* [C-2-1] MUST include the following lines in `/proc/cpuinfo` when it is read
- by 32-bit ARM applications to ensure compatibility with applications built
- using legacy versions of Android NDK.
+* [C-2-1] MUST include the following lines in `/proc/cpuinfo`, and SHOULD NOT
+ alter the values on the same device, even when they are read by other ABIs.
* `Features: `, followed by a list of any optional ARMv7 CPU features
- supported by the device.
+ supported by the device.
* `CPU architecture: `, followed by an integer describing the device's
- highest supported ARM architecture (e.g., "8" for ARMv8 devices).
+ highest supported ARM architecture (e.g., "8" for ARMv8 devices).
-* SHOULD not alter `/proc/cpuinfo` when read by 64-bit ARM or non-ARM
- applications.
+* [C-2-2] MUST always keep the following operations available, even in the
+ case where the ABI is implemented on an ARMv8 architecture, either through
+ native CPU support or through software emulation:
+
+ * SWP and SWPB instructions.
+ * SETEND instruction.
+ * CP15ISB, CP15DSB, and CP15DMB barrier operations.
+
+* [C-2-3] MUST include support for the [Advanced SIMD](
+ http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html)
+ (a.k.a. NEON) extension.
\ No newline at end of file
diff --git a/3_software/3_5_api-behavioral-compatibility.md b/3_software/3_5_api-behavioral-compatibility.md
index 0e5b9f9..0d51391 100644
--- a/3_software/3_5_api-behavioral-compatibility.md
+++ b/3_software/3_5_api-behavioral-compatibility.md
@@ -1,5 +1,14 @@
## 3.5\. API Behavioral Compatibility
+Device implementations:
+
+* [C-0-9] MUST ensure that API behavioral compatibility is applied for all
+installed apps unless they are restricted as described in
+[Section 3.5.1](#3_5_1-background-restriction).
+* [C-0-10] MUST NOT implement the whitelisting approach that ensures API
+behavioral compatibility only for apps that are selected by device
+implementers.
+
The behaviors of each of the API types (managed, soft, native, and web) must be
consistent with the preferred implementation of the upstream
[Android Open Source Project](http://source.android.com/). Some specific areas
@@ -40,10 +49,65 @@
task that's visible to the user.
* [C-0-8] if the app is targeting API level 25 or higher, they MUST
release the wakelocks the app holds.
+* [C-0-9] Devices MUST return the following security providers as the first
+ seven array values from the [`Security.getProviders()`](
+ https://developer.android.com/reference/java/security/Security.html#getProviders%28%29)
+ method, in the given order and with the given names (as returned by
+ [`Provider.getName()`](
+ https://developer.android.com/reference/java/security/Provider.html#getName%28%29))
+ and classes, unless the app has modified the list via
+ [`insertProviderAt()`](
+ https://developer.android.com/reference/java/security/Security.html#insertProviderAt%28java.security.Provider,%2520int%29)
+ or [`removeProvider()`](
+ https://developer.android.com/reference/java/security/Security.html#removeProvider%28java.lang.String%29). Devices
+ MAY return additional providers after the specified list of providers
+ below.
+ 1. **AndroidNSSP** - `android.security.net.config.NetworkSecurityConfigProvider`
+ 2. **AndroidOpenSSL** - `com.android.org.conscrypt.OpenSSLProvider`
+ 3. **CertPathProvider** - `sun.security.provider.CertPathProvider`
+ 4. **AndroidKeyStoreBCWorkaround** - `android.security.keystore.AndroidKeyStoreBCWorkaroundProvider`
+ 5. **BC** - `com.android.org.bouncycastle.jce.provider.BouncyCastleProvider`
+ 6. **HarmonyJSSE** - `com.android.org.conscrypt.JSSEProvider`
+ 7. **AndroidKeyStore** - `android.security.keystore.AndroidKeyStoreProvider`
The above list is not comprehensive. The Compatibility Test Suite (CTS) tests
significant portions of the platform for behavioral compatibility, but not all.
It is the responsibility of the implementer to ensure behavioral compatibility
with the Android Open Source Project. For this reason, device implementers
SHOULD use the source code available via the Android Open Source Project where
-possible, rather than re-implement significant parts of the system.
\ No newline at end of file
+possible, rather than re-implement significant parts of the system.
+
+## 3.5.1\. Background Restriction
+
+If device implementations implement the app restrictions that are included in
+AOSP or extend the app restrictions, they:
+
+* [C-1-1] MUST provide user affordance where the user can see the list of
+restricted apps.
+* [C-1-2] MUST provide user affordance to turn on / off the restrictions
+on each app.
+* [C-1-3] MUST not automatically apply restrictions without evidence of poor
+system health behaviour, but MAY apply the restrictions on apps upon detection
+of poor system health behaviour like stuck wakelocks, long running services, and
+other criteria. The criteria MAY be determined by device implementers but MUST
+be related to the app’s impact on the system health. Other criteria that is not
+purely related to the　system health, such as the app’s lack of popularity in
+the market, MUST NOT be used as criteria.
+* [C-1-4] MUST not automatically apply app restrictions for apps when a user
+has turned off app restrictions manually, and MAY suggest the user to apply
+app restrictions.
+* [C-1-5] MUST inform users if app restrictions are applied to an app
+automatically.
+* [C-1-6] MUST return `true` for [`ActivityManager.isBackgroundRestricted()`](
+https://developer.android.com/reference/android/app/ActivityManager.html#isBackgroundRestricted%28%29)
+when the restricted app calls this API.
+* [C-1-7] MUST NOT restrict the top foreground app that is explicitly used
+by the user.
+* [C-1-8] MUST suspend restrictions on an app that becomes the top foreground
+application when the user explicitly starts to use the app that used to be
+restricted.
+* [C-1-9] MUST report all app restriction events via [`UsageStats`](
+https://developer.android.com/reference/android/app/usage/UsageStats). If device
+implementations extend the app restrictions that are implemented in AOSP, MUST
+follow the implementation described in [this document](
+https://souce.android.com/devices/tech/power/app_mgmt.html).
\ No newline at end of file
diff --git a/3_software/3_6_api-namespaces.md b/3_software/3_6_api-namespaces.md
index e1e2e17..a010e0d 100644
--- a/3_software/3_6_api-namespaces.md
+++ b/3_software/3_6_api-namespaces.md
@@ -9,6 +9,7 @@
* `javax.*`
* `sun.*`
* `android.*`
+* `androidx.*`
* `com.android.*`
That is, they:
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 9d0a5a1..76c32c2 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -124,7 +124,7 @@
further detailed in [section 7](#7_hardware_compatibility).
* [C-1-2] MUST correctly render all [resources](
https://developer.android.com/guide/topics/resources/available-resources.html)
- (icons, animation files etc.) provided for in the APIs, or in the
+ (icons, animation files, etc.) provided for in the APIs, or in the
Status/System Bar [icon style guide](
http://developer.android.com/design/style/iconography.html), although they
MAY provide an alternative user experience for notifications than that
@@ -140,6 +140,17 @@
third-party app's notification per each channel and app package level.
* [C-1-6] MUST also provide a user affordance to display deleted notification
channels.
+* [C-1-7] MUST correctly render all resources (images, stickers, icons, etc.)
+ provided through [Notification.MessagingStyle](
+ https://developer.android.com/reference/android/app/Notification.MessagingStyle)
+ alongside the notification text without additional user interaction. For
+ example, MUST show all resources including icons provided through
+ [android.app.Person](https://developer.android.com/reference/android/app/Person)
+ in a group conversation that is set through [setGroupConversation](
+ https://developer.android.com/reference/android/app/Notification.MessagingStyle.html?hl=es-AR#setGroupConversation%28boolean%29).
+* [C-SR] Are STRONGLY RECOMMENDED to automatically surface a user affordance
+ to block a certain third-party app's notification per each channel and app
+ package level after the user dismisses that notification multiple times.
* SHOULD support rich notifications.
* SHOULD present some higher priority notifications as heads-up notifications.
* SHOULD have a user affordance to snooze notifications.
@@ -163,6 +174,12 @@
as described in the [`Notification.Builder`](
https://developer.android.com/reference/android/app/Notification.Builder.html)
API class when heads-up notifications are presented.
+* [C-3-2] MUST display the actions provided through
+ [`Notification.Builder.addAction()`](
+ https://developer.android.com/reference/android/app/Notification.Builder#addAction%28android.app.Notification.Action%29)
+ together with the notification content without additional user interaction
+ as described in [the SDK](
+ https://developer.android.com/guide/topics/ui/notifiers/notifications.html#Heads-up).
#### 3.8.3.2\. Notification Listener Service
@@ -259,8 +276,6 @@
in [section 7.2.3](#7_2_3_navigation_keys) MUST launch the user-selected
assist app, in other words the app that implements `VoiceInteractionService`,
or an activity handling the `ACTION_ASSIST` intent.
-* [C-SR] STRONGLY RECOMMENDED to use long press on `HOME` key as this designated
- interaction.
### 3.8.5\. Alerts and Toasts
@@ -433,11 +448,14 @@
### 3.8.12\. Location
If device implementations include a hardware sensor (e.g. GPS) that is capable
-of providing the location coordinates:
+of providing the location coordinates, they
-* [C-1-1] [location modes](
- http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE)
- MUST be displayed in the Location menu within Settings.
+* [C-1-2] MUST display the [current status of location](
+ https://developer.android.com/reference/android/location/LocationManager.html#isLocationEnabled%28%29)
+ in the Location menu within Settings.
+* [C-1-3] MUST NOT display [location modes](
+ https://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE)
+ in the Location menu within Settings.
### 3.8.13\. Unicode and Font
@@ -532,3 +550,26 @@
and minimum width of 240 dp and height of 135 dp for the PIP window when the
`Configuration.uiMode` is configured as [`UI_MODE_TYPE_TELEVISION`](
https://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_TELEVISION)
+
+
+### 3.8.15\. Display Cutout
+
+Android supports a Display Cutout as described
+in the SDK document. The [`DisplayCutout`](
+https://developer.android.com/reference/android/view/DisplayCutout) API defines
+an area on the edge of the display that is not functional for displaying
+content.
+
+If device implementations include display cutout(s), they:
+
+* [C-1-1] MUST only have cutout(s) on the short edge(s) of the device.
+Conversely, if the device's aspect ratio is 1.0(1:1), they MUST NOT have
+cutout(s).
+* [C-1-2] MUST NOT have more than one cutout per edge.
+* [C-1-3] MUST honor the display cutout flags set by the app through the
+[`WindowManager.LayoutParams`](
+https://developer.android.com/reference/android/view/WindowManager.LayoutParams)
+API as described in the SDK.
+* [C-1-4] MUST report correct values for all cutout metrics defined in the
+[`DisplayCutout`](
+https://developer.android.com/reference/android/view/DisplayCutout) API.
\ No newline at end of file
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index eb50d95..f0d4a7b 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -13,12 +13,6 @@
* [C-1-2] MUST support device owner provisioning as described in
[section 3.9.1](#3_9_1_device_provisioning) and
[section 3.9.1.1](#3_9_1_1_device_owner_provisioning).
-* [C-1-3] MUST declare the support of manged profiles via the
- `android.software.managed_users` feature flag, except for when the device is
- configured so that it would [report](
- http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
- itself as a low RAM device or so that it allocate internal (non-removable)
- storage as shared storage.
### 3.9.1 Device Provisioning
@@ -42,9 +36,10 @@
* [C-1-6] MUST report `false` for the [`DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#isProvisioningAllowed\(java.lang.String\)).
* [C-1-7] MUST not enroll any DPC application as the Device Owner App
any more.
-* [C-1-2] MUST NOT set an application (including pre-installed app) as the
- Device Owner app without explicit consent or action from the user or the
- administrator of the device.
+* [C-1-2] MUST require some affirmative action during the provisioning process
+to consent to the app being set as Device Owner. Consent can be via user action
+or by some programmatic means during provisioning but it MUST NOT be hard coded
+or prevent the use of other Device Owner apps.
If device implementations declare `android.software.device_admin`, but also
include a proprietary Device Owner management solution and provide a mechanism
@@ -88,7 +83,7 @@
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage%28android.content.ComponentName, java.lang.CharSequence%29).
* The DPC application’s icon.
-## 3.9.2 Managed Profile Support
+### 3.9.2 Managed Profile Support
If device implementations declare `android.software.managed_users`, they:
@@ -144,3 +139,14 @@
in the preinstalled call log, in-call UI, in-progress and missed-call
notifications, contacts and messaging apps they SHOULD be badged with the
same badge used to indicate managed profile applications.
+
+## 3.9.3 Managed User Support
+
+If device implementations declare `android.software.managed_users`, they:
+
+* [C-1-1] MUST provide a user affordance to logout from the current user and
+ switch back to the primary user in multiple-user session when
+ [`isLogoutEnabled`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isLogoutEnabled%28%29)
+ returns `true`. The user affordance MUST be accessible from the lockscreen
+ without unlocking the device.
\ No newline at end of file
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 1a25035..be0b3d7 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -8,9 +8,13 @@
http://developer.android.com/tools/help/index.html).
* As the above requirement may be challenging, device implementations are
RECOMMENDED to use the AOSP reference implementation's package management
- systemDevice implementations.
+ system.
+
+Device implementations:
+
* [C-0-2] MUST support verifying “.apk” files using the
-[APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html)
+[APK Signature Scheme v3](https://source.android.com/security/apksigning/v3.html)
+, [APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html)
and [JAR signing](
https://source.android.com/security/apksigning/v2.html#v1-verification).
* [C-0-3] MUST NOT extend either the
@@ -22,7 +26,7 @@
installing and running correctly on other compatible devices.
* [C-0-4] MUST NOT allow apps other than the current
"installer of record" for the package to silently uninstall the app without any
-prompt, as documented in the SDK for the [`DELETE_PACKAGE`](
+user confirmation, as documented in the SDK for the [`DELETE_PACKAGE`](
https://developer.android.com/reference/android/Manifest.permission.html#DELETE_PACKAGES)
permission. The only exceptions are the system package verifier app handling
[PACKAGE_NEEDS_VERIFICATION](
@@ -46,10 +50,16 @@
* SHOULD provide a user affordance to grant/revoke the permission to
install apps from unknown sources per application, but MAY choose to implement
-this as a no-op and return `RESULT_CANCELED` for
-[`startActivityForResult()`](http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,
-int%29),
+this as a no-op and return `RESULT_CANCELED` for [`startActivityForResult()`](
+http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,int%29),
if the device implementation does not want to allow users to have this choice.
However, even in such cases, they SHOULD indicate to the user why there is no
-such
-choice presented.
+such choice presented.
+
+* [C-0-7] MUST display a warning dialog with the warning string that is
+provided through the system API `PackageManager.setHarmfulAppWarning`
+to the user before launching an activity in an application that has been marked
+by the same system API `PackageManager.setHarmfulAppWarning` as potentially
+harmful.
+* SHOULD provide a user affordance to choose to uninstall or launch an
+application on the warning dialog.
\ No newline at end of file
diff --git a/5_multimedia/5_10_professional-audio.md b/5_multimedia/5_10_professional-audio.md
index 607bd8c..4af9364 100644
--- a/5_multimedia/5_10_professional-audio.md
+++ b/5_multimedia/5_10_professional-audio.md
@@ -14,9 +14,11 @@
* [C-1-3] MUST include a USB port(s) supporting USB host mode and USB
peripheral mode.
* [C-1-4] MUST report support for feature `android.software.midi`.
-* [C-1-5] MUST meet latencies and USB audio requirements using the
+* [C-1-5] MUST meet latencies and USB audio requirements using both the
[OpenSL ES](https://developer.android.com/ndk/guides/audio/opensl-for-android.html)
-PCM buffer queue API.
+PCM buffer queue and
+[AAudio native audio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)
+APIs.
* [SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU
performance while audio is active and CPU load is varying. This should be tested
using [SimpleSynth](https://github.com/googlesamples/android-audio-high-performance/tree/master/SimpleSynth)
@@ -58,6 +60,8 @@
and output sides of corresponding end-points.
* SHOULD minimize touch latency.
* SHOULD minimize touch latency variability under load (jitter).
+* SHOULD have a latency from touch input to audio output of less than or
+equal to 40 ms.
If device implementations meet all of the above requirements, they:
@@ -66,12 +70,6 @@
http://developer.android.com/reference/android/content/pm/PackageManager.html)
class.
-If device implementations meet the requirements via the OpenSL ES PCM buffer
-queue API, they:
-
-* [SR] STRONGLY RECOMMENDED to also meet the same requirements via the
-[AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html) API.
-
If device implementations include a 4 conductor 3.5mm audio jack, they:
* [C-2-1] MUST have the continuous round-trip audio latency to be 20
@@ -96,4 +94,5 @@
If device implementations include an HDMI port, they:
* [C-4-1] MUST support output in stereo and eight channels at 20-bit or
-24-bit depth and 192 kHz without bit-depth loss or resampling.
\ No newline at end of file
+24-bit depth and 192 kHz without bit-depth loss or resampling,
+in at least one configuration.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index 3b61db4..ea34d0c 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -16,13 +16,16 @@
If device implementations declare support for the
-`android.hardware.audio.output` feature, they must support the following audio
-decoders:
+`android.hardware.audio.output` feature, they must support decoding the
+following audio formats:
* [C-1-1] MPEG-4 AAC Profile (AAC LC)
* [C-1-2] MPEG-4 HE AAC Profile (AAC+)
* [C-1-3] MPEG-4 HE AACv2 Profile (enhanced AAC+)
* [C-1-4] AAC ELD (enhanced low delay AAC)
+* [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, which includes
+ the USAC Baseline Profile, and ISO/IEC 23003-4 Dynamic Range Control
+ Profile)
* [C-1-5] FLAC
* [C-1-6] MP3
* [C-1-7] MIDI
@@ -42,10 +45,27 @@
(DRC)" in ISO/IEC 14496-3, and the `android.media.MediaFormat` DRC keys to
configure the dynamic range-related behaviors of the audio decoder. The
AAC DRC keys were introduced in API 21,and are:
-KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR,
-KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL and
-KEY_AAC_ENCODED_TARGET_LEVEL
+`KEY_AAC_DRC_ATTENUATION_FACTOR`, `KEY_AAC_DRC_BOOST_FACTOR`,
+`KEY_AAC_DRC_HEAVY_COMPRESSION`, `KEY_AAC_DRC_TARGET_REFERENCE_LEVEL` and
+`KEY_AAC_ENCODED_TARGET_LEVEL`
+When decoding USAC audio, MPEG-D (ISO/IEC 23003-4):
+
+* [C-3-1] Loudness and DRC metadata MUST be interpreted and applied
+according to MPEG-D DRC Dynamic Range Control Profile Level 1.
+* [C-3-2] The decoder MUST behave according to the configuration
+set with the following `android.media.MediaFormat` keys:
+`KEY_AAC_DRC_TARGET_REFERENCE_LEVEL` and `KEY_AAC_DRC_EFFECT_TYPE`.
+
+MPEG-4 AAC, HE AAC, and HE AACv2 profile decoders:
+
+* MAY support loudness and dynamic range control using ISO/IEC 23003-4
+Dynamic Range Control Profile.
+
+If ISO/IEC 23003-4 is supported and if both ISO/IEC 23003-4 and
+ISO/IEC 14496-3 metadata are present in a decoded bitstream, then:
+
+* ISO/IEC 23003-4 metadata SHALL take precedence.
### 5.1.3\. Audio Codecs Details
@@ -88,6 +108,17 @@
<td></td>
</tr>
<tr>
+ <td>USAC</td>
+ <td>Support for mono/stereo content with standard sampling rates from 7.35
+ to 48 kHz.</td>
+ <td>
+ <ul>
+ <li>MPEG-4 (.mp4, .m4a)</li>
+ <li>LATM/LOAS (.loas, .xhe)</li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
<td>AMR-NB</td>
<td>4.75 to 12.2 kbps sampled @ 8 kHz</td>
<td>3GPP (.3gp)</td>
@@ -155,7 +186,7 @@
See more details in [5.1.6. Image Codecs Details](#5_1_6_image_codecs_details).
-Device impelementations MUST support encoding the following image decoding:
+Device impelementations MUST support decoding the following image encoding:
* [C-0-1] JPEG
* [C-0-2] GIF
@@ -163,6 +194,7 @@
* [C-0-4] BMP
* [C-0-5] WebP
* [C-0-6] Raw
+* [C-0-7] HEIF (HEIC)
### 5.1.6\. Image Codecs Details
@@ -203,6 +235,11 @@
<td>ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf),
PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)</td>
</tr>
+ <tr>
+ <td>HEIF</td>
+ <td>Image, Image collection, Image sequence</td>
+ <td>HEIF (.heif), HEIC (.heic)</td>
+ </tr>
</table>
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 5cca863..f510887 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -37,6 +37,8 @@
AudioEffect subclasses `Equalizer`, `LoudnessEnhancer`.
* [C-1-2] MUST support the visualizer API implementation, controllable through
the `Visualizer` class.
+* [C-1-3] MUST support the `EFFECT_TYPE_DYNAMICS_PROCESSING` implementation
+controllable through the AudioEffect subclass [`DynamicsProcessing`](https://developer.android.com/reference/android/media/audiofx/DynamicsProcessing).
* SHOULD support the `EFFECT_TYPE_BASS_BOOST`, `EFFECT_TYPE_ENV_REVERB`,
`EFFECT_TYPE_PRESET_REVERB`, and `EFFECT_TYPE_VIRTUALIZER` implementations
controllable through the `AudioEffect` sub-classes `BassBoost`,
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index 7edea1e..5e0699d 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -38,33 +38,49 @@
* **AAudio native audio API**. The set of
[AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html) APIs
within [Android NDK](https://developer.android.com/ndk/index.html).
+* **Timestamp**. A pair consisting of a relative frame position within a
+stream and the estimated time when that frame enters or leaves the
+audio processing pipeline on the associated endpoint. See also
+[AudioTimestamp](https://developer.android.com/reference/android/media/AudioTimestamp).
If device implementations declare `android.hardware.audio.output` they are
STRONGLY RECOMMENDED to meet or exceed the following requirements:
-* [SR] Cold output latency of 100 milliseconds or less
-* [SR] Continuous output latency of 45 milliseconds or less
-* [SR] Minimize the cold output jitter
+* [C-SR] Cold output latency of 100 milliseconds or less
+* [C-SR] Continuous output latency of 45 milliseconds or less
+* [C-SR] Minimize the cold output jitter
+* [C-SR] The output timestamp returned by
+[AudioTrack.getTimestamp](https://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp(android.media.AudioTimestamp))
+and `AAudioStream_getTimestamp` is accurate to +/- 1 ms.
-If device implementations meet the above requirements after any initial
-calibration when using the OpenSL ES PCM buffer queue API, for continuous output
-latency and cold output latency over at least one supported audio output device,
-they are:
+If device implementations meet the above requirements, after any initial
+calibration, when using both the OpenSL ES PCM buffer queue and AAudio native audio APIs,
+for continuous output latency and cold output latency over at least one supported audio
+output device, they are:
-* [SR] STRONGLY RECOMMENDED to report low latency audio by declaring
-`android.hardware.audio.low_latency` feature flag.
-* [SR] STRONGLY RECOMMENDED to also meet the requirements for low-latency
+* [C-SR] STRONGLY RECOMMENDED to report low-latency audio by declaring
+ `android.hardware.audio.low_latency` feature flag.
+* [C-SR] STRONGLY RECOMMENDED to meet the requirements for low-latency
audio via the AAudio API.
+* [C-SR] STRONGLY RECOMMENDED to ensure that for streams that return
+ [`AAUDIO_PERFORMANCE_MODE_LOW_LATENCY`](https://developer.android.com/ndk/guides/audio/aaudio/aaudio#performance-mode)
+ from [`AAudioStream_getPerformanceMode()`](https://developer.android.com/ndk/reference/group/audio#aaudiostream_getperformancemode),
+ the value returned by [`AAudioStream_getFramesPerBurst()`](https://developer.android.com/ndk/reference/group/audio#aaudiostream_getframesperburst)
+ is less than or equal to the value returned by [`android.media.AudioManager.getProperty(String)`](https://developer.android.com/reference/android/media/AudioManager.html#getProperty%28java.lang.String%29)
+ for property key [`AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER`](https://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_OUTPUT_FRAMES_PER_BUFFER).
If device implementations do not meet the requirements for low-latency audio
-via the OpenSL ES PCM buffer queue API, they:
+via both the OpenSL ES PCM buffer queue and AAudio native audio APIs, they:
* [C-1-1] MUST NOT report support for low-latency audio.
If device implementations include `android.hardware.microphone`, they are
STRONGLY RECOMMENDED to meet these input audio requirements:
- * [SR] Cold input latency of 100 milliseconds or less
- * [SR] Continuous input latency of 30 milliseconds or less
- * [SR] Continuous round-trip latency of 50 milliseconds or less
- * [SR] Minimize the cold input jitter
\ No newline at end of file
+ * [C-SR] Cold input latency of 100 milliseconds or less
+ * [C-SR] Continuous input latency of 30 milliseconds or less
+ * [C-SR] Continuous round-trip latency of 50 milliseconds or less
+ * [C-SR] Minimize the cold input jitter
+ * [C-SR] Limit the error in input timestamps, as returned by
+[AudioRecord.getTimestamp](https://developer.android.com/reference/android/media/AudioRecord.html#getTimestamp(android.media.AudioTimestamp,%20int))
+or `AAudioStream_getTimestamp`, to +/- 1 ms.
diff --git a/5_multimedia/5_8_secure-media.md b/5_multimedia/5_8_secure-media.md
index e75a775..7722d80 100644
--- a/5_multimedia/5_8_secure-media.md
+++ b/5_multimedia/5_8_secure-media.md
@@ -15,5 +15,6 @@
If device implementations declare support for `Display.FLAG_SECURE` and
support wired external display, they:
-* [C-3-1] MUST support HDCP 1.2 or higher for all wired external displays.
+* [C-3-1] MUST support HDCP 1.2 or higher for all external displays connected
+via a user-accessible wired port.
diff --git a/6_dev-tools-and-options/6_1_developer_tools.md b/6_dev-tools-and-options/6_1_developer_tools.md
index 2e1477e..9b028e8 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -5,11 +5,41 @@
* [C-0-1] MUST support the Android Developer Tools provided in the Android
SDK.
* [**Android Debug Bridge (adb)**](http://developer.android.com/tools/help/adb.html)
- * [C-0-2] MUST support all adb functions as documented in the Android
- SDK including [dumpsys](https://source.android.com/devices/input/diagnostics.html).
+ * [C-0-2] MUST support adb as documented in the Android SDK and the shell
+ commands provided in the AOSP, which can be used by app developers,
+ including [`dumpsys`](https://source.android.com/devices/input/diagnostics.html)
+ and `cmd stats`.
* [C-0-3] MUST NOT alter the format or the contents of device system
- events (batterystats , diskstats, fingerprint, graphicsstats, netstats,
- notification, procstats) logged via dumpsys.
+ events (batterystats , diskstats, fingerprint, graphicsstats, netstats,
+ notification, procstats) logged via the dumpsys command.
+ * [C-0-10] MUST record, without ommmission, and make the following events
+ accessible and available to the `cmd stats` shell command and the
+ `StatsManager` System API class.
+ * ActivityForegroundStateChanged
+ * AnomalyDetected
+ * AppBreadcrumbReported
+ * AppCrashOccurred
+ * AppStartOccurred
+ * BatteryLevelChanged
+ * BatterySaverModeStateChanged
+ * BleScanResultReceived
+ * BleScanStateChanged
+ * ChargingStateChanged
+ * DeviceIdleModeStateChanged
+ * ForegroundServiceStateChanged
+ * GpsScanStateChanged
+ * JobStateChanged
+ * PluggedStateChanged
+ * ScheduledJobStateChanged
+ * ScreenStateChanged
+ * SyncStateChanged
+ * SystemElapsedRealtime
+ * UidProcessStateChanged
+ * WakelockStateChanged
+ * WakeupAlarmOccurred
+ * WifiLockStateChanged
+ * WifiMulticastLockStateChanged
+ * WifiScanStateChanged
* [C-0-4] MUST have the device-side adb daemon be inactive by default and
there MUST be a user-accessible mechanism to turn on the Android Debug
Bridge.
@@ -32,6 +62,20 @@
* [C-0-8] MUST include the Monkey framework and make it available for
applications to use.
* [**SysTrace**](http://developer.android.com/tools/help/systrace.html)
- * [C-0-9] MUST support systrace tool as documented in the Android SDK.
+ * [C-0-9] MUST support the systrace tool as documented in the Android SDK.
Systrace must be inactive by default and there MUST be a user-accessible
- mechanism to turn on Systrace.
\ No newline at end of file
+ mechanism to turn on Systrace.
+
+If device implementations report the support of Vulkan 1.0 or higher via the
+`android.hardware.vulkan.version` feature flags, they:
+
+* [C-1-1] MUST provide an affordance for the app developer to enable/disable
+ GPU debug layers.
+* [C-1-2] MUST, when the GPU debug layers are enabled, enumerate layers in
+ libraries provided by external tools (i.e. not part of the platform or
+ application package) found in debuggable applications' base directory to
+ support [vkEnumerateInstanceLayerProperties()](
+ https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkEnumerateInstanceLayerProperties.html)
+ and [vkCreateInstance()](
+ https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCreateInstance.html)
+ API methods.
diff --git a/6_dev-tools-and-options/6_2_developer_options.md b/6_dev-tools-and-options/6_2_developer_options.md
index c42d2f0..974ad6f 100644
--- a/6_dev-tools-and-options/6_2_developer_options.md
+++ b/6_dev-tools-and-options/6_2_developer_options.md
@@ -12,8 +12,14 @@
implementation hides the Developer Options menu by default and enables users to
launch Developer Options after pressing seven (7) times on the **Settings** >
**About Device** > **Build Number** menu item.
-* [C-0-2] MUST hide Developer Options by default and MUST provide a mechanism
-to enable Developer Options without the need for any special whitelisting.
+* [C-0-2] MUST hide Developer Options by default.
+* [C-0-3] MUST provide a clear mechanism that does not give preferential
+treatment to one third-party app as opposed to another to enable Developer
+Options. MUST provide a public visible document or website that describes how to
+enable Developer Options. This document or website MUST be linkable from
+the Android SDK documents.
+* SHOULD have an ongoing visual notification to the user when Developer
+Options is enabled and the safety of the user is of concern.
* MAY temporarily limit access to the Developer Options menu, by visually
hiding or disabling the menu, to prevent distraction for scenarios where the
safety of the user is of concern.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 853ba1b..3ab68d0 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -21,14 +21,16 @@
### 7.1.1\. Screen Configuration
-#### 7.1.1.1\. Screen Size
+#### 7.1.1.1\. Screen Size and Shape
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
+Device implementations:
+
+* [C-0-1] 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:
@@ -43,12 +45,22 @@
* 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
+* [C-0-2] 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.
+* MAY have a display with rounded corners.
+
+If device implementations support `UI_MODE_TYPE_NORMAL` and include a display
+with rounded corners, they:
+
+* [C-1-1] MUST ensure that the radius of the rounded corners is less than or
+equal to 32 dp.
+* SHOULD include user affordance to switch to the display mode with the
+rectangular corners.
+
#### 7.1.1.2\. Screen Aspect Ratio
While there is no restriction to the screen aspect ratio value of the physical
@@ -190,11 +202,11 @@
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
+* [C-1-1] MUST support both OpenGL ES 1.1 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.
+* [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
+* SHOULD support OpenGL ES 3.2.
If device implementations support any of the OpenGL ES versions, they:
@@ -238,15 +250,15 @@
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:
+If device implementations support OpenGL ES 3.1, they:
-* [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.0 .
+* [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.1.
If device implementations include a screen or video output, they:
-* SHOULD include support for Vulkan 1.0.
+* SHOULD include support for Vulkan 1.1.
-Device implementations, if including support for Vulkan 1.0:
+If device implementations include support for Vulkan 1.0, they:
* [C-1-1] MUST report the correct integer value with the
`android.hardware.vulkan.level` and `android.hardware.vulkan.version`
@@ -271,14 +283,22 @@
* [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.
+* [C-1-7] MUST support the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain,
+ and VK_KHR_incremental_present extensions
-Device implementations, if not including support for Vulkan 1.0:
+If device implementations do not include support for Vulkan 1.0, they:
* [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()`.
+If device implementations include support for Vulkan 1.1, they:
+
+* [C-3-1] MUST expose support for the `SYNC_FD` external semaphore and handle types.
+* [SR] Are STRONGLY RECOMMENDED to support the
+ `VK_ANDROID_external_memory_android_hardware_buffer` extension.
+
#### 7.1.4.3 RenderScript
* [C-0-1] Device implementations MUST support [Android RenderScript](
@@ -320,14 +340,15 @@
, 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-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
+ DCI-P3 in CIE 1931 xyY space.
+* [C-1-4] MUST support OpenGL ES 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`
+ `EGL_EXT_pixel_format_float`, `EGL_KHR_gl_colorspace`,
+ `EGL_EXT_gl_colorspace_scrgb`, `EGL_EXT_gl_colorspace_scrgb_linear`,
+ `EGL_EXT_gl_colorspace_display_p3`, and `EGL_KHR_gl_colorspace_display_p3`
extensions.
* [SR] Are STRONGLY RECOMMENDED to support `GL_EXT_sRGB`.
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 3a415de..664d7c5 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -115,7 +115,7 @@
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)
+[Touchscreen-based device implementations](https://source.android.com/devices/input/touch-devices)
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
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 8da2e19..b452eff 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -26,10 +26,10 @@
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-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.
@@ -203,12 +203,11 @@
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.
+ * [C-1-6] After making such a location calculation, device
+ implementations MUST determine its location, in open sky, within
+ 5 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:
@@ -229,7 +228,7 @@
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.
+as part of each GPS/GNSS 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()`.
@@ -239,9 +238,9 @@
`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
+* [C-2-1] MUST report GNSS 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
+* [C-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in
open-sky conditions after determining the location, while stationary or moving
with less than 0.2 meter per second squared of acceleration, are sufficient to
calculate position within 20 meters, and speed within 0.2 meters per second,
@@ -259,8 +258,19 @@
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.
+Vertical) as part of each GPS/GNSS location.
+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 "2018" or
+newer, they:
+
+* [C-4-1] MUST continue to deliver normal GPS/GNSS outputs to applications
+during a Mobile Station Based (MS-Based) Network Initiated emergency session
+call.
+* [C-4-2] MUST report positions and measurements to the
+[GNSS Location Provider](https://developer.android.com/reference/android/location/LocationProvider)
+API's.
### 7.3.4\. Gyroscope
@@ -371,21 +381,27 @@
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 measurement range between at least -8g and +8g, SHOULD have
+ a measurement range between at least -16g and +16g.
+ * MUST have a measurement resolution of at least 2048 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 have a maximum measurement frequency of 400 Hz or higher; SHOULD
+ support the SensorDirectChannel [`RATE_VERY_FAST`](
+ https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#RATE_VERY_FAST).
+ * MUST have a measurement noise not above 400 μg/√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.
+ * [C-SR] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at
+ least 80% of Nyquist frequency, and white noise spectrum within this
+ bandwidth.
+ * SHOULD have an acceleration random walk less than 30 μg √Hz tested at
+ room temperature.
+ * SHOULD have a bias change vs. temperature of ≤ +/- 1 mg/°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.
+ * SHOULD have cross-axis sensitivity of < 2.5 % and variation of
+ cross-axis sensitivity < 0.2% in device operation temperature range.
* [C-2-2] MUST have a `TYPE_ACCELEROMETER_UNCALIBRATED` with the same
quality requirements as `TYPE_ACCELEROMETER`.
@@ -394,22 +410,29 @@
* 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 maximum measurement frequency of 400 Hz or higher; SHOULD
+ support the SensorDirectChannel [`RATE_VERY_FAST`](
+ https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#RATE_VERY_FAST).
* 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.
+ * [C-SR] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at
+ least 80% of Nyquist frequency, and white noise spectrum within this
+ bandwidth.
+ * SHOULD have a rate random walk less than 0.001 °/s √Hz tested at room
+ temperature.
* 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.
-
+ * SHOULD have g-sensitivity less than 0.1°/s/g.
+ * SHOULD have cross-axis sensitivity of < 4.0 % and cross-axis sensitivity
+ variation < 0.3% in device operation temperature range.
* [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 range between at least -900 and +900 μT.
* 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.
@@ -418,8 +441,9 @@
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-SR] Is STRONGLY RECOMMENDED to have white noise spectrum from 1 Hz to
+ at least 10 Hz when the report rate is 50 Hz or higher.
+
* [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.
@@ -449,14 +473,16 @@
* 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.
+Accelerometer, Gyroscope, and Magnetometer MUST be within 2.5 milliseconds
+of each other. The event timestamp of the same physical event reported by
+the Accelerometer and Gyroscope SHOULD be within 0.25 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
+* [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`
@@ -492,7 +518,9 @@
* `TYPE_MAGNETIC_FIELD`
* `TYPE_MAGNETIC_FIELD_UNCALIBRATED`
-### 7.3.10\. Fingerprint Sensor
+### 7.3.10\. Biometric Sensors
+
+#### 7.3.10.1\. Fingerprint Sensors
If device implementations include a secure lock screen, they:
@@ -519,8 +547,8 @@
a secure channel to the TEE.
* [C-1-7] 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](
+altered outside of the Trusted Execution Environment (TEE), or a chip with a
+secure channel to the 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-8] MUST prevent adding a fingerprint without first establishing a chain
@@ -534,6 +562,10 @@
* [C-1-11] MUST, when upgraded from a version earlier than Android 6.0, have
the fingerprint data securely migrated to meet the above requirements or
removed.
+* [C-1-12] MUST completely remove all identifiable fingerprint data for a
+user when the user's account is removed (including via a factory reset).
+* [C-1-13] MUST not allow unencrypted access to identifiable fingerprint data
+or any data derived from it (such as embeddings) to the Application Processor.
* [SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
as measured on the device.
* [SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
@@ -542,6 +574,52 @@
* SHOULD use the Android Fingerprint icon provided in the Android Open Source
Project.
+#### 7.3.10.2\. Other Biometric Sensors
+
+If device implementations include one or more non-fingerprint-based-biometric
+sensors and make them available to third-party apps they:
+
+* [C-1-1] MUST have a false acceptance rate not higher than 0.002%.
+* [C-SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate
+not higher than 7%.
+* [C-1-2] MUST disclose that this mode may be less secure than a strong PIN,
+pattern, or password and clearly enumerate the risks of enabling it, if the
+spoof and imposter acceptance rates are higher than 7%.
+* [C-1-3] MUST rate limit attempts for at least 30 seconds after five false
+trials for biometric verification - where a false trial is one with an adequate
+capture quality
+(ACQUIRED_GOOD) that does not match an enrolled biometric
+* [C-1-4] MUST have a hardware-backed keystore implementation, and perform the
+biometric matching in a Trusted Execution Environment (TEE) or on a chip with
+a secure channel to the TEE.
+* [C-1-5] MUST have all identifiable data encrypted and cryptographically
+authenticated such that they cannot be acquired, read or altered outside of the
+Trusted Execution Environment (TEE), or a chip with a secure channel to the 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-6] MUST prevent adding new biometrics 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-7] MUST NOT enable third-party applications to distinguish between
+biometric enrollments.
+* [C-1-8] MUST honor the individual flag for that biometric (ie:
+`DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT`,
+`DevicePolicymanager.KEYGUARD_DISABLE_FACE`, or
+`DevicePolicymanager.KEYGUARD_DISABLE_IRIS`).
+* [C-1-9] MUST completely remove all identifiable biometric data for a user when
+the user's account is removed (including via a factory reset).
+* [C-1-10] MUST not allow unencrypted access to identifiable biometric data or any
+data derived from it (such as embeddings) to the Application Processor outside
+the context of the TEE.
+* [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
+as measured on the device.
+* [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
+when the biometric is detected, until the screen is unlocked, for each
+enrolled biometric.
+
+
### 7.3.11\. Android Automotive-only sensors
Automotive-specific sensors are defined in the
@@ -557,12 +635,16 @@
#### 7.3.11.3\. Driving Status
-See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+This requirement is deprecated.
#### 7.3.11.4\. Wheel Speed
See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+#### 7.3.11.5\. Parking Brake
+
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+
## 7.3.12\. Pose Sensor
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 6f823fa..a3e168f 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -58,6 +58,27 @@
If device implementations report `android.hardware.telephony`, they:
+* [C-1-1] MUST support the `ConnectionService` APIs described in the [SDK](
+ https://developer.android.com/guide/topics/connectivity/telecom/selfManaged.html).
+* [C-1-2] MUST display a new incoming call and provide user affordance to
+ accept or reject the incoming call when the user is on an ongoing call
+ that is made by a third-party app that does not support the hold feature
+ specified via
+ [`CAPABILITY_SUPPORT_HOLD`](
+ https://developer.android.com/reference/android/telecom/Connection.html#CAPABILITY_SUPPORT_HOLD).
+* [C-SR] Are STRONGLY RECOMMENDED to notify the user that answering an
+ incoming call will drop an ongoing call.
+
+ The AOSP implementation meets these requirements by a heads-up notification
+ which indicates to the user that answering an incoming call will cause the
+ the other call to be dropped.
+
+* [C-SR] Are STRONGLY RECOMMENDED to preload the default dialer app that
+ shows a call log entry and the name of a third-party app in its call log
+ when the third-party app sets the
+ [`EXTRA_LOG_SELF_MANAGED_CALLS`](
+ https://developer.android.com/reference/android/telecom/PhoneAccount.html#EXTRA_LOG_SELF_MANAGED_CALLS)
+ extras key on its `PhoneAccount` to `true`.
* [C-SR] Are STRONGLY RECOMMENDED to handle the the audio headset's
`KEYCODE_MEDIA_PLAY_PAUSE` and `KEYCODE_HEADSETHOOK` events for the
[`android.telecom`](https://developer.android.com/reference/android/telecom/package-summary.html)
@@ -70,6 +91,7 @@
when a long press of the key event is detected during an incoming call.
* Toggle the mute status of the [`CallAudioState`](https://developer.android.com/reference/android/telecom/CallAudioState.html)
+
### 7.4.2\. IEEE 802.11 (Wi-Fi)
Device implementations:
@@ -79,30 +101,53 @@
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 Andr:oid API.
+* [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-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:
+ (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.
+* [C-1-5] MUST NOT treat the [`WifiManager.enableNetwork()`](
+ https://developer.android.com/reference/android/net/wifi/WifiManager.html#enableNetwork%28int%2C%20boolean%29)
+ API method call as a sufficient indication to switch the currently active
+ `Network` that is used by default for application traffic and is returned
+ by [`ConnectivityManager`](https://developer.android.com/reference/android/net/ConnectivityManager)
+ API methods such as [`getActiveNetwork`](https://developer.android.com/reference/android/net/ConnectivityManager#getActiveNetwork%28%29)
+ and [`registerDefaultNetworkCallback`](https://developer.android.com/reference/android/net/ConnectivityManager#registerDefaultNetworkCallback%28android.net.ConnectivityManager.NetworkCallback,%20android.os.Handler%29).
+ In other words, they MAY only disable the Internet access provided by any
+ other network provider (e.g. mobile data) if they successfully validate
+ that the Wi-Fi network is providing Internet access.
+* [C-1-6] MUST, when the [`ConnectivityManager.reportNetworkConnectivity()`](
+ https://developer.android.com/reference/android/net/ConnectivityManager.html#reportNetworkConnectivity%28android.net.Network%2C%20boolean%29)
+ API method is called, re-evaluate the Internet access on the `Network` and,
+ once the evaluation determines that the current `Network` no longer provides
+ Internet access, switch to any other available network (e.g. mobile
+ data) that provides Internet access.
+* [C-SR] Are STRONGLY RECOMMENDED to 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
+ 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:
+ request of a scan and the first probe request of the next scan.
+* [C-SR] Are STRONGLY RECOMMENDED, while STA is disconnected, to allow only
+the following elements in probe request frames:
* SSID Parameter Set (0)
* DS Parameter Set (3)
+If device implementations support Wi-Fi and use Wi-Fi for location scanning,
+they:
+
+* [C-2-1] MUST provide a user affordance to enable/disable the value read
+ through the [`WifiManager.isScanAlwaysAvailable`](https://developer.android.com/reference/android/net/wifi/WifiManager.html#isScanAlwaysAvailable%28%29)
+ API method.
+
#### 7.4.2.1\. Wi-Fi Direct
Device implementations:
@@ -116,7 +161,7 @@
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.
+* [C-1-4] MUST support Wi-Fi and Wi-Fi Direct operations concurrently.
#### 7.4.2.2\. Wi-Fi Tunneled Direct Link Setup
@@ -154,6 +199,20 @@
* [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.
+If device implementations include support for Wi-Fi Aware and
+Wi-Fi Location as described in [Section 7.4.2.5](#7_4_2_5_Wi-Fi_Location) and
+exposes these functionalities to third-party apps, then they:
+
+* [C-2-1] MUST implement the location-aware discovery APIs: [setRangingEnabled](
+https://developer.android.com/reference/android/net/wifi/aware/PublishConfig.Builder.html#setRangingEnabled%28boolean%29),
+ [setMinDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMinDistanceMm%28int%29),
+ [setMaxDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMaxDistanceMm%28int%29)
+, and
+ [onServiceDiscoveredWithinRange](
+https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback#onServiceDiscoveredWithinRange%28android.net.wifi.aware.PeerHandle,%20byte[],%20java.util.List%3Cbyte[]%3E,%20int%29).
+
#### 7.4.2.4\. Wi-Fi Passpoint
Device implementations:
@@ -176,6 +235,24 @@
* [C-2-1] The implementation of the Passpoint related `WifiManager`
APIs MUST throw an `UnsupportedOperationException`.
+#### 7.4.2.5\. Wi-Fi Location (Wi-Fi Round Trip Time - RTT)
+
+Device implementations:
+
+* SHOULD include support for [Wi-Fi Location](
+ https://www.wi-fi.org/discover-wi-fi/wi-fi-location).
+
+If device implementations include support for Wi-Fi Location and expose the
+functionality to third-party apps, then they:
+
+* [C-1-1] MUST implement the `WifiRttManager` APIs as described in the
+[SDK documentation](
+http://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager.html).
+* [C-1-2] MUST declare the `android.hardware.wifi.rtt` feature flag.
+* [C-1-3] MUST randomize the source MAC address for each RTT burst
+ which is executed while the Wi-Fi interface on which the RTT is
+ being executed is not associated to an Access Point.
+
### 7.4.3\. Bluetooth
If device implementations support Bluetooth Audio profile, they:
@@ -183,6 +260,10 @@
* SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs
(e.g. LDAC).
+If device implementations support HFP, A2DP and AVRCP, they:
+
+* SHOULD support at least 5 total connected devices.
+
If device implementations declare `android.hardware.vr.high_performance`
feature, they:
@@ -198,8 +279,7 @@
(`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.
-
+ A2DP, AVRCP, OBEX, HFP, etc. as appropriate for the device.
If device implementations include support for Bluetooth Low Energy, they:
@@ -227,6 +307,12 @@
timeout no longer than 15 minutes and rotate the address at timeout to protect
user privacy.
+If device implementations support Bluetooth LE and use Bluetooth LE for
+location scanning, they:
+
+* [C-4-1] MUST provide a user affordance to enable/disable the value read
+ through the System API `BluetoothAdapter.isBleScanAlwaysAvailable()`.
+
### 7.4.4\. Near-Field Communications
Device implementations:
@@ -361,57 +447,56 @@
* [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
+at least one data standard capable of 200 Kbit/sec or greater. Examples of
technologies that satisfy this requirement include EDGE, HSPA, EV-DO,
- 802.11g, Ethernet, Bluetooth PAN, etc.
+ 802.11g, Ethernet and Bluetooth PAN.
* 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
+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.
* [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.
+ * 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.
-
-When connected to an IPv6-capable network:
-
-* [C-1-1] devices MUST provide applications with direct IPv6 connectivity to
-the network, without any form
-of address or port translation happening locally on the device. Both managed
-APIs such as
-[`Socket#getLocalAddress`](https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29)
-or
-[`Socket#getLocalPort`](https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29))
+* [C-0-6] MUST provide third-party applications with direct IPv6 connectivity
+to the network when connected to an IPv6 network, without any form of address or
+port translation happening locally on the device. Both managed APIs such as
+[`Socket#getLocalAddress`](
+https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29)
+or [`Socket#getLocalPort`](
+https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29))
and NDK APIs such as `getsockname()` or `IPV6_PKTINFO` MUST return the IP
address and port that is actually used to send and receive packets on the
network.
-The required level of IPv6 support depends on the network type, as follows:
+The required level of IPv6 support depends on the network type, as shown in
+the following requirements.
-If devices implementations support Wi-Fi networks, they:
+If device implementations support Wi-Fi, they:
-* [C-2-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
+* [C-1-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
-If device implementations support Ethernet networks, they:
+If device implementations support Ethernet, they:
-* [C-3-1] MUST support dual-stack operation on Ethernet.
+* [C-2-1] MUST support dual-stack operation on Ethernet.
-If device implementations support cellular data, they:
+If device implementations support Cellular data, they:
-* [C-4-1] SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
-cellular data.
+* SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
+cellular.
-When devices are simultaneously connected to more than one network, (e.g., Wi-Fi
+If device implementations support more than one network type (e.g., Wi-Fi
and cellular data), they:
-* [C-5-1] MUST simultaneously meet these requirements on each network to which
-they are connected.
+
+* [C-3-1] MUST simultaneously meet the above requirements on each network
+when the device is simultaneously connected to more than one network type.
### 7.4.6\. Sync Settings
@@ -450,3 +535,12 @@
* [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.
+
+### 7.4.8\. Secure Elements
+
+If device implementations support [Open Mobile API](https://developer.android.com/reference/android/se/omapi/package-summary)
+capable secure elements and make them available to 3rd-party apps, they:
+
+* [C-1-1] MUST enumerate the available Secure Elements readers when
+[`android.se.omapi.SEService.getReaders()`](https://developer.android.com/reference/android/se/omapi/SEService#getReaders%28%29)
+method is called.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index b5da828..dda1f9c 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -88,12 +88,15 @@
* MAY include support for an external camera that is not necessarily
always connected.
-If device impelmentations include support for an external camera, they:
+If device implementations 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.
+camera connects through the USB host port.
+* [C-1-3] MUST pass camera CTS tests with a physical external camera device
+connected. Details of camera CTS testing are available at [source.android.com](
+https://source.android.com/compatibility/cts/camera-hal).
* SHOULD support video compressions such as MJPEG to enable transfer of
high-quality unencoded streams (i.e. raw or independently compressed picture
streams).
@@ -191,6 +194,16 @@
* [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.
+* [C-SR] Are STRONGLY RECOMMENDED to support a logical camera device that lists
+capability
+[`CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA`](
+https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA),
+for devices with multiple cameras facing the same direction, consisting of each
+physical camera facing that direction, as long as the physical camera type is
+supported by the framework and
+[`CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL`](
+https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL)
+for the physical cameras is either `LIMITED`, `FULL`, or `LEVEL_3`.
### 7.5.5\. Camera Orientation
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 20c1be6..90db766 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -42,8 +42,8 @@
* 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:
+If device implementations include a USB port and 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).
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 84c08b7..b1ec118 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -49,10 +49,12 @@
#### 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.
+https://source.android.com/devices/accessories/headset/plug-headset-spec)
+using the 3.5mm audio plug across the Android ecosystem, if device
+implementations include one or more analog audio ports, they:
+
+* [C-SR] Are STRONGLY RECOMMENDED to include at least one of the
+audio port(s) to be a 4 conductor 3.5mm audio jack.
If device implementations have a 4 conductor 3.5mm audio jack, they:
@@ -71,13 +73,14 @@
* [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
+* [C-1-7] MUST 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.
-
+* [C-SR] Are STRONGLY RECOMMENDED to support audio plugs with the OMTP
+ pin-out order.
+* [C-SR] Are STRONGLY RECOMMEND to 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
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index 1a8b632..ff9deb2 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -12,18 +12,16 @@
a feature which handles stereoscopic rendering of notifications and disables
monocular system UI components while a VR application has user focus.
-### 7.9.2\. Virtual Reality High Performance
+### 7.9.2\. Virtual Reality Mode - High Performance
-If device implementations identify the support of high performance VR
-for longer user periods through the `android.hardware.vr.high_performance`
-feature flag, they:
+If device implementations support VR mode, they:
* [C-1-1] MUST have at least 2 physical cores.
-* [C-1-2] MUST declare `android.software.vr.mode feature`.
+* [C-1-2] MUST declare the `android.hardware.vr.high_performance` 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-5] MUST support `android.hardware.vulkan.level` 0.
+* SHOULD support `android.hardware.vulkan.level` 1 or higher.
* [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),
@@ -32,12 +30,10 @@
[`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),
+ [`EGL_EXT_image_gl_colorspace`](https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_gl_colorspace.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_EXT_multisampled_render_to_texture2`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture2.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),
@@ -45,33 +41,56 @@
[`GL_EXT_EGL_image_array`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_EGL_image_array.txt),
[`GL_EXT_external_buffer`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_buffer.txt),
and expose the extensions in the list of available GL extensions.
+* [C-1-24] MUST implement
+ [`VK_KHR_shared_presentable_image`](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_KHR_shared_presentable_image),
+ [`VK_GOOGLE_display_timing`](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_GOOGLE_display_timing)
+ and expose the extensions in the list of available Vulkan extensions.
+* [C-1-25] MUST expose at least one Vulkan queue family that where `flags`
+ contain both `VK_QUEUE_GRAPHICS_BIT` and `VK_QUEUE_COMPUTE_BIT`,
+ and `queueCount` is at least 2.
+* [SR] Are STRONGLY RECOMMENDED to support Vulkan 1.1.
+* [SR] Are STRONGLY RECOMMENDED to implement
+ [`VK_ANDROID_external_memory_android_hardware_buffer`](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_ANDROID_external_memory_android_hardware_buffer)
+ and expose it in the list of available Vulkan 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-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.
+ flags `AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER`,
+ `AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA` and
+ `AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT`
+ 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).
+ layer and any combination of the usage flags
+ `AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT`,
+ `AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE`,
+ `AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT`
+ for at least the following formats:
+ `AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM`,
+ `AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM`,
+ `AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM`,
+ `AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT`.
+* [C-1-11] MUST support H.264 decoding at least 3840 x 2160 at 30fps,
+ compressed to an average of 40Mbps (equivalent to 4 instances of
+ 1920 x1080 at 30 fps-10 Mbps or 2 instances of 1920 x 1080 at 60 fps-20 Mbps).
+* [C-1-12] MUST support HEVC and VP9, MUST be capable of decoding at least
+ 1920 x 1080 at 30 fps compressed to an average of 10 Mbps and SHOULD be
+ capable of decoding 3840 x 2160 at 30 fps-20 Mbps (equivalent to
+ 4 instances of 1920 x 1080 at 30 fps-5 Mbps).
* [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.
+ and return accurate values for skin temperature.
+* [C-1-14] MUST have an embedded screen, and its resolution MUST be at least
+ 1920 x 1080.
+* [C-SR] Are STRONGLY RECOMMENDED to have a display resolution of at least
+ 2560 x 1440.
* [C-1-15] The display MUST update at least 60 Hz while in VR Mode.
-* [C-1-16] The display latency (as measured on Gray-to-Gray, White-to-Black, and
-Black-to-White switching time) MUST be ≤ 6 milliseconds.
* [C-1-17] The display MUST support a low-persistence mode with ≤ 5 milliseconds
-persistence, persistence being defined as the amount of time for
-which a pixel is emitting light.
+ persistence, persistence being defined as the amount of time for
+ which a pixel is emitting light.
* [C-1-18] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension
[section 7.4.3](#7_4_3_bluetooth).
-* [C-1-19] MUST support and properly report [Direct Channel Type](
- https://developer.android.com/reference/android/hardware/Sensor.html#isDirectChannelTypeSupported%28int%29")
+* [C-1-19] MUST support and properly report
+ [Direct Channel Type](https://developer.android.com/reference/android/hardware/Sensor#isDirectChannelTypeSupported%28int%29)
for all of the following default sensor types:
* `TYPE_ACCELEROMETER`
* `TYPE_ACCELEROMETER_UNCALIBRATED`
@@ -79,13 +98,22 @@
* `TYPE_GYROSCOPE_UNCALIBRATED`
* `TYPE_MAGNETIC_FIELD`
* `TYPE_MAGNETIC_FIELD_UNCALIBRATED`
-* [C-1-20] MUST support the [`TYPE_HARDWARE_BUFFER`](
-https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_HARDWARE_BUFFER)
+* [C-1-20] MUST support the
+ [`TYPE_HARDWARE_BUFFER`](https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_HARDWARE_BUFFER)
direct channel type for all Direct Channel Types listed above.
-* [SR] Are 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`.
+* [C-1-21] MUST meet the gyroscope, accelerometer, and magnetometer related
+ requirements for `android.hardware.hifi_sensors`, as specified in
+ [section 7.3.9](#7_3_9_high_fidelity_sensors).
+* [SR] Are STRONGLY RECOMMENDED to support the
+ `android.hardware.sensor.hifi_sensors` feature.
+* [C-1-22] MUST have end-to-end motion to photon latency not higher than
+ 28 milliseconds.
+* [SR] Are STRONGLY RECOMMENDED to have end-to-end motion to photon latency
+ not higher than 20 milliseconds.
+* [C-1-23] MUST have first-frame ratio, which is the ratio between the
+ brightness of pixels on the first frame after a transition from black to
+ white and the brightness of white pixels in steady state, of at least 85%.
+* [SR] Are STRONGLY RECOMMENDED to have first-frame ratio of at least 90%.
* 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
diff --git a/8_performance-and-power/8_3_power-saving-modes.md b/8_performance-and-power/8_3_power-saving-modes.md
index 6268303..f5d90ba 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -1,19 +1,39 @@
## 8.3\. Power-Saving Modes
-Android includes App Standby and Doze power-saving modes to optimize battery
-usage.
-* [SR] All Apps exempted from these modes are STRONGLY RECOMMENDED to be made
-visible to the end user.
-* [SR] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of these power-saving modes are STRONGLY RECOMMENDED NOT
-to deviate from the Android Open Source Project.
+If device implementations include features to improve device power management
+that are included in AOSP or extend the features that are included in AOSP,
+they:
+
+* [C-1-1] MUST NOT deviate from the AOSP implementation for the triggering,
+ maintenance, wakeup algorithms and the use of global system settings of App
+ Standby and Doze power-saving modes.
+* [C-1-2] MUST NOT deviate from the AOSP implementation for the use of global
+ settings to manage the throttling of jobs, alarm and network for apps in
+ each bucket for App standby.
+* [C-1-3] MUST NOT deviate from the AOSP implementation for the number of the
+ [App Standby Buckets](
+ https://developer.android.com/topic/performance/appstandby) used for App
+ Standby.
+* [C-1-4] MUST implement [App Standby Buckets](
+ https://developer.android.com/topic/performance/appstandby) and Doze as
+ described in [Power Management](
+ https://source.android.com/devices/tech/power/mgmt).
+* [C-1-5] MUST return `true` for [`PowerManager.isPowerSaveMode()`](
+ https://developer.android.com/reference/android/os/PowerManager#isPowerSaveMode%28%29)
+ when the device is on power save mode.
+* [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to enable and
+ disable the battery saver feature.
+* [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all
+ Apps that are exempted from App Standby and Doze power-saving modes.
In addition to the power-saving modes, Android device implementations MAY
implement any or all of the 4 sleeping power states as defined by the Advanced
Configuration and Power Interface (ACPI).
-If device implementations implements S3 and S4 power states as defined by the
+If device implementations implement S3 and S4 power states as defined by the
ACPI, they:
-* [C-1-1] MUST only enter these states when closing a lid that is physically
- part of the device.
+* [C-1-1] MUST enter these states only after the user has taken an explicit action
+ to put the device in an inactive state (e.g. by closing a lid that is physically
+ part of the device or turning off a vehicle or television) and before the user re-activates the
+ device (e.g. by opening the lid or turning the vehicle or television back on).
\ No newline at end of file
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index 7ac86b0..366b7bd 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -9,8 +9,15 @@
reserved for device implementations upgrading from an earlier version of Android
where this new system API method did not exist.
-Verified boot is a feature that guarantees the integrity of the device
-software. If a device implementation supports the feature, it:
+* [C-0-2] MUST support Verified Boot for device integrity.
+
+If device implementations are already launched without supporting Verified Boot
+on an earlier version of Android and can not add support for this
+feature with a system software update, they MAY be exempted from the
+requirement.
+
+Verified Boot is a feature that guarantees the integrity of the device
+software. If device implementations support the feature, they:
* [C-1-1] MUST declare the platform feature flag
`android.software.verified_boot`.
@@ -28,29 +35,41 @@
any non-verified storage blocks MUST not be used.
* [C-1-7] MUST NOT allow verified partitions on the device to be modified
unless the user has explicitly unlocked the boot loader.
-* [SR] If there are multiple discrete chips in the device (e.g. radio,
+* [C-SR] If there are multiple discrete chips in the device (e.g. radio,
specialized image processor), the boot process of each of those chips is
STRONGLY RECOMMENDED to verify every stage upon booting.
-* [SR] STRONGLY RECOMMENDED to use tamper-evident storage: for when the
+* [C-1-8] MUST use tamper-evident storage: for storing whether the
bootloader is unlocked. Tamper-evident storage means that the boot loader can
-detect if the storage has been tampered with from inside the
-HLOS (High Level Operating System).
-* [SR] STRONGLY RECOMMENDED to prompt the user, while using the device, and
+detect if the storage has been tampered with from inside Android.
+* [C-1-9] MUST prompt the user, while using the device, and
require physical confirmation before allowing a transition from boot loader
locked mode to boot loader unlocked mode.
-* [SR] STRONGLY RECOMMENDED to implement rollback protection for the HLOS
-(e.g. boot, system partitions) and to use tamper-evident storage for storing the
+* [C-1-10] MUST implement rollback protection for partitions used by Android
+(e.g. boot, system partitions) and use tamper-evident storage for storing the
metadata used for determining the minimum allowable OS version.
+* [C-SR] Are STRONGLY RECOMMENDED to verify all privileged app APK files with
+a chain of trust rooted in `/system`, which is protected by Verified Boot.
+* [C-SR] Are STRONGLY RECOMMENDED to verify any executable artifacts loaded by
+a privileged app from outside its APK file (such as dynamically loaded code or
+compiled code) before executing them or STRONGLY RECOMMENDED not to execute them
+at all.
* SHOULD implement rollback protection for any component with persistent
firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
storing the metadata used for determining the minimum allowable version.
+If device implementations are already launched without supporting C-1-8 through
+C-1-10 on an earlier version of Android and can not add support for
+these requirements with a system software update, they MAY be exempted from the
+requirements.
+
The upstream Android Open Source Project provides a preferred implementation of
-this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/)
+this feature in the [`external/avb/`](
+http://android.googlesource.com/platform/external/avb/)
repository, which can be integrated into the boot loader used for loading
Android.
-If device implementations report the feature flag [`android.hardware.ram.normal`](
+If device implementations report the feature flag
+[`android.hardware.ram.normal`](
https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_RAM_NORMAL)
, they:
@@ -60,3 +79,20 @@
on an earlier version of Android, such a device can not add support for this
feature with a system software update and thus are exempted from the
requirement.
+
+Device implementations:
+
+* [C-R] Are RECOMMENDED to support the [Android Protected Confirmation API](
+https://developer.android.com/preview/features/security.html#user-confirmation).
+
+If device implementations support the Android Protected Confirmation
+API they:
+
+* [C-3-1] MUST report `true` for the [`ConfirmationPrompt.isSupported()`](
+https://developer.android.com/reference/android/security/ConfirmationPrompt.html#isSupported%28android.content.Context%29)
+API.
+* [C-3-2] MUST ensure that secure hardware takes full control of display in
+such a way that Android OS cannot block it without detection by the
+secure hardware.
+* [C-3-3] MUST ensure that secure hardware takes full control of the touch
+screen.
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index d409563..7b314dc 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -6,7 +6,7 @@
or the [Keystore API](https://developer.android.com/reference/java/security/KeyStore.html).
Device implementations:
-* [C-0-1] MUST at least allow more than 8,192 keys to be imported.
+* [C-0-1] MUST allow at least 8,192 keys to be imported or generated.
* [C-0-2] The lock screen authentication MUST rate-limit attempts and MUST
have an exponential backoff algorithm. Beyond 150 failed attempts, the delay
MUST be at least 24 hours per attempt.
@@ -14,7 +14,8 @@
When the device implementation supports a secure lock screen, it:
-* [C-1-1] MUST back up the keystore implementation with secure hardware.
+* [C-1-1] MUST back up the keystore implementation with an isolated
+ execution environment.
* [C-1-2] MUST have implementations of RSA, AES, ECDSA and HMAC cryptographic
algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support
the Android Keystore system's supported algorithms in an area that is securely
@@ -39,128 +40,278 @@
requirement is to share the same attestation key unless at least 100,000 units
of a given SKU are produced. If more than 100,000 units of an SKU are produced,
a different key MAY be used for each 100,000 units.
+* [C-1-5] MUST allow the user to choose the Sleep timeout for transition from
+ the unlocked to the locked state, with a minimum allowable timout up to
+ 15 seconds.
Note that if a device implementation is already launched on an earlier Android
-version, such a device is exempted from the requirement to have a
-hardware-backed keystore and support the key attestation, unless it declares
-the `android.hardware.fingerprint` feature which requires a hardware-backed
-keystore.
+version, such a device is exempted from the requirement to have a keystore
+backed by an isolated execution environment and support the key attestation,
+unless it declares the `android.hardware.fingerprint` feature which requires a
+keystore backed by an isolated execution environment.
### 9.11.1\. Secure Lock Screen
-If device implementations have a secure lock screen and include one or more
-trust agent, which implements the `TrustAgentService` System API, then they:
+The AOSP implementation follows a tiered authentication model where a
+knowledge-factory based primary authentication can be backed by either a
+secondary strong biometric, or by weaker tertiary modalities.
-* [C-1-1] MUST indicate the user in the Settings and Lock screen user
-interface of situations where either the screen auto-lock is deferred or the
-screen lock can be unlocked by the trust agent. The AOSP meets the requirement
-by showing a text description for the "Automatically lock setting" and
-"Power button instantly locks setting" menus and a distinguishable icon on
-the lock screen.
-* [C-1-2] MUST respect and fully implement all trust agent APIs in the
-`DevicePolicyManager` class, such as the [`KEYGUARD_DISABLE_TRUST_AGENTS`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
-constant.
-* [C-1-3] MUST NOT fully implement the `TrustAgentService.addEscrowToken()`
-function on a device that is used as the primary personal device
-(e.g. handheld) but MAY fully implement the function on device implementations
-typically shared.
-* [C-1-4] MUST encrypt the tokens added by `TrustAgentService.addEscrowToken()`
-before storing them on the device.
-* [C-1-5] MUST NOT store the encryption key on the device.
-* [C-1-6] MUST inform the user about the security implications before
-enabling the escrow token to decrypt the data storage.
+Device implementations:
-If device implementations add or modify the authentication methods to unlock
-the lock screen, then for such an authentication method to be treated as a
-secure way to lock the screen, they:
+* [C-SR] Are STRONGLY RECOMMENDED to set only one of the following as the primary authentication
+method:
+ * A numerical PIN,
+ * An alphanumerical password, or
+ * A swipe pattern on a grid of exactly 3x3 dots.
+
+Note that the above authentication methods are referred as the recommended
+primary authentication methods in this document.
+
+If device implementations add or modify the recommended primary authentication
+methods and use a new authentication method as a secure way to lock the screen,
+the new authentication method:
* [C-2-1] MUST be the user authentication method as described in
-[Requiring User Authentication For Key Use](https://developer.android.com/training/articles/keystore.html#UserAuthentication).
+ [Requiring User Authentication For Key Use](
+ https://developer.android.com/training/articles/keystore.html#UserAuthentication).
* [C-2-2] MUST unlock all keys for a third-party developer app to use when
-the user unlocks the secure lock screen. For example, all keys MUST be available
-for a third-party developer app through relevant APIs, such as
-[`createConfirmDeviceCredentialIntent`](https://developer.android.com/reference/android/app/KeyguardManager.html#createConfirmDeviceCredentialIntent%28java.lang.CharSequence, java.lang.CharSequence%29)
-and [`setUserAuthenticationRequired`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
+ the user unlocks the secure lock screen. For example, all keys MUST be
+ available for a third-party developer app through relevant APIs, such as
+ [`createConfirmDeviceCredentialIntent`](
+ https://developer.android.com/reference/android/app/KeyguardManager.html#createConfirmDeviceCredentialIntent%28java.lang.CharSequence, java.lang.CharSequence%29)
+ and [`setUserAuthenticationRequired`](
+ https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
If device implementations add or modify the authentication methods to unlock
-the lock screen if based on a known secret then for such an authentication
-method to be treated as a secure way to lock the screen, they:
+the lock screen if based on a known secret and use a new authentication
+method to be treated as a secure way to lock the screen:
* [C-3-1] The entropy of the shortest allowed length of inputs MUST be
-greater than 10 bits.
+ greater than 10 bits.
* [C-3-2] The maximum entropy of all possible inputs MUST be greater than
-18 bits.
-* [C-3-3] MUST not replace any of the existing authentication methods
-(PIN,pattern, password) implemented and provided in AOSP.
-* [C-3-4] MUST be disabled when the Device Policy Controller (DPC)
-application has set the password quality policy via the
-[`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_SOMETHING`.
+ 18 bits.
+* [C-3-3] The new authentication method MUST NOT replace any of the
+ recommended primary authentication methods (i.e. PIN, pattern, password)
+ implemented and provided in AOSP.
+* [C-3-4] The new authentication method MUST be disabled when the Device
+ Policy Controller (DPC) application has set the password quality policy
+ via the
+ [`DevicePolicyManager.setPasswordQuality()`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+ method with a more restrictive quality constant than
+ `PASSWORD_QUALITY_SOMETHING`.
+
+If device implementations add or modify the recommended primary authentication
+methods to unlock the lock screen and use a new authentication method that is
+based on biometrics to be treated as a secure way to lock the screen, the new
+method:
+
+* [C-4-1] MUST meet all requirements described in
+ [section 7.3.10.2](#7_3_10_2_other_biometric_sensors).
+* [C-4-2] MUST have a fall-back mechanism to use one of the recommended
+ primary authentication methods which is based on a known secret.
+* [C-4-3] MUST be disabled and only allow the recommended primary
+ authentication to unlock the screen when the Device Policy Controller (DPC)
+ application has set the keguard feature policy by calling the method
+ [`DevicePolicyManager.setKeyguardDisabledFeatures()`](
+ http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
+ , with any of the associated biometric flags (i.e.
+ `KEYGUARD_DISABLE_BIOMETRICS`, `KEYGUARD_DISABLE_FINGERPRINT`,
+ `KEYGUARD_DISABLE_FACE`, or `KEYGUARD_DISABLE_IRIS`).
+* [C-4-4] MUST challenge the user for the recommended primary authentication
+ (e.g. PIN, pattern, password) at least once very 72 hours or less.
+* [C-4-5] MUST have a false acceptance rate that is equal or stronger than
+ what is required for a fingerprint sensor as described in section
+ [section 7.3.10](#7_3_10_biometric_sensors),
+ or otherwise
+ MUST be disabled and only allow the recommended primary authentication
+ to unlock the screen when the Device Policy Controller (DPC) application
+ has set the password quality policy via the
+ [`DevicePolicyManager.setPasswordQuality()`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
+ method with a more restrictive quality constant than
+ `PASSWORD_QUALITY_BIOMETRIC_WEAK`.
+* [C-SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
+ that are equal to or stronger than what is required for a fingerprint
+ sensor as described in [section 7.3.10](#7_3_10_biometric_sensors).
+* [C-4-6] MUST have a secure processing pipeline such that an operating
+ system or kernel compromise cannot allow data to be directly injected to
+ falsely authenticate as the user.
+* [C-4-7] MUST be paired with an explicit confirm action (eg: a button press)
+ to allow access to keystore keys if the application sets `true` for
+ [`KeyGenParameterSpec.Built.setUserAuthenticationRequired()`](
+ https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)
+ and the biometric is passive (e.g. face or iris where no explicit
+ signal of intent exists).
+* [C-SR] The confirm action for passive biometrics is STRONGLY RECOMMENDED to
+ be secured such that an operating system or kernel compromise cannot spoof
+ it. For example, this means that the confirm action based on a physical
+ button is routed through an input-only general-purpose input/output (GPIO)
+ pin of a secure element (SE) that cannot be driven by any other means
+ than a physical button press.
+
+If the biometric authentication methods do not meet the spoof and imposter
+acceptance rates as described in [section 7.3.10](#7_3_10_biometric_sensors):
+
+* [C-5-1] The methods MUST be disabled if the Device Policy Controller (DPC)
+ application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
+ method with a more restrictive quality constant than
+ `PASSWORD_QUALITY_BIOMETRIC_WEAK`.
+* [C-5-2] The user MUST be challenged for the recommended primary
+ authentication (eg: PIN, pattern, password) after any 4-hour idle timeout
+ period. The idle timeout period is reset after any successful confirmation
+ of the device credentials.
+* [C-5-3] The methods MUST NOT be treated as a secure lock screen, and MUST
+ meet the requirements that start with C-8 in this section below.
If device implementations add or modify the authentication methods to unlock
-the lock screen if based on a physical token or the location, then for such an
-authentication method to be treated as a secure way to lock the screen, they:
+the lock screen and a new authentication method is based on a physical token
+or the location:
-* [C-4-1] MUST have a fall-back mechanism to use one of the primary
-authentication methods which is based on a known secret and meets the
-requirements to be treated as a secure lock screen.
-* [C-4-2] MUST be disabled and only allow the primary authentication to
-unlock the screen when the Device Policy Controller (DPC) application has set
-the policy with either the [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
-method or the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_UNSPECIFIED`.
-* [C-4-3] The user MUST be challenged for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
+* [C-6-1] They MUST have a fall-back mechanism to use one of the recommended
+ primary authentication methods which is based on a known secret and meet
+ the requirements to be treated as a secure lock screen.
+* [C-6-2] The new method MUST be disabled and only allow one of the
+ recommended primary authentication methods to unlock the screen when the
+ Device Policy Controller (DPC) application has set the policy with either
+ the
+ [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](
+ http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
+ method or the
+ [`DevicePolicyManager.setPasswordQuality()`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+ method with a more restrictive quality constant than
+ `PASSWORD_QUALITY_UNSPECIFIED`.
+* [C-6-3] The user MUST be challenged for one of the recommended primary
+ authentication methods (e.g.PIN, pattern, password) at least once every 72
+ hours or less.
+* [C-6-4] The new method MUST NOT be treated as a secure lock screen and MUST
+ follow the constraints listed in C-8 below.
+
+If device implementations have a secure lock screen and include one or more
+trust agent, which implements the `TrustAgentService` System API, they:
+
+* [C-7-1] MUST have clear indication in the settings menu and on the lock
+ screen when device lock is deferred or can be unlocked by trust agent(s).
+ For example, AOSP meets this requirement by showing a text description for
+ the "Automatically lock setting" and "Power button instantly locks" in the
+ settings menu and a distinguishable icon on the lock screen.
+* [C-7-2] MUST respect and fully implement all trust agent APIs in the
+ `DevicePolicyManager` class, such as the
+ [`KEYGUARD_DISABLE_TRUST_AGENTS`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
+ constant.
+* [C-7-3] MUST NOT fully implement the `TrustAgentService.addEscrowToken()`
+ function on a device that is used as a primary personal device
+ (e.g. handheld) but MAY fully implement the function on device
+ implementations that are typically shared (e.g. Android Television or
+ Automotive device).
+* [C-7-4] MUST encrypt all stored tokens added by
+ `TrustAgentService.addEscrowToken()`.
+* [C-7-5] MUST NOT store the encryption key on the same device where the key
+ is used. For example, it is allowed for a key stored on a phone to unlock a
+ user account on a TV.
+* [C-7-6] MUST inform the user about the security implications before
+ enabling the escrow token to decrypt the data storage.
+* [C-7-7] MUST have a fall-back mechanism to use one of the recommended
+ primary authentication methods.
+* [C-7-8] The user MUST be challenged for one of the recommended primary
+ authentication (eg: PIN, pattern, password) methods at least once every 72
+ hours or less.
+* [C-7-9] The user MUST be challenged for one of the recommended primary
+ authentication (eg: PIN, pattern, password) methods after any 4-hour idle
+ timeout period. The idle timeout period is reset after any successful
+ confirmation of the device credentials.
+* [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
+ constraints listed in C-8 below.
If device implementations add or modify the authentication methods to unlock
-the lock screen based on biometrics, then for such an authentication method to
-be treated as a secure way to lock the screen, they:
+the lock screen that is not a secure lock screen as described above, and use
+a new authentication method to unlock the keyguard:
-* [C-5-1] MUST have a fall-back mechanism to use one of the primary
-authentication methods which is based on a known secret and meets the
-requirements to be treated as a secure lock screen.
-* [C-5-2] MUST be disabled and only allow the primary authentication to
-unlock the screen when the Device Policy Controller (DPC) application has set
-the keguard feature policy by calling the method
-[`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29).
-* [C-5-3] MUST have a false acceptance rate that is equal or stronger than
-what is required for a fingerprint sensor as described in section 7.3.10, or
-otherwise MUST be disabled and only allow the primary authentication to unlock
-the screen when the Device Policy Controller (DPC) application has set the
-password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_BIOMETRIC_WEAK`.
-* [SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
-that are equal to or stronger than what is required for a fingerprint sensor as
-described in section 7.3.10.
+* [C-8-1] The new method MUST be disabled when the Device Policy Controller
+ (DPC) application has set the password quality policy via the
+ [`DevicePolicyManager.setPasswordQuality()`](
+ https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+ method with a more restrictive quality constant than
+ `PASSWORD_QUALITY_UNSPECIFIED`.
+* [C-8-2] They MUST NOT reset the password expiration timers set by
+ [`DevicePolicyManager.setPasswordExpirationTimeout()`](
+ http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
+* [C-8-3] They MUST NOT authenticate access to keystores when the application
+ sets `true` for
+ [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired()`](
+ https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
-If the spoof and imposter acceptance rates are not equal to or stronger than
-what is required for a fingerprint sensor as described in
-[section 7.3.10](#7_3_10_fingerprint_sensor) and the Device Policy
-Controller (DPC) application has set the password quality policy via the
-[`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_BIOMETRIC_WEAK`, then:
+### 9.11.2\. StrongBox
-* [C-6-1] MUST disable these biometric methods and allow only the primary
-authentication to unlock the screen.
-* [C-6-2] MUST challenge the user for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
+The [Android Keystore System](
+https://developer.android.com/training/articles/keystore.html) allows
+app developers to store cryptographic keys in a dedicated secure processor as
+well as the isolated execution environment described above.
-If device implementations add or modify the authentication methods to unlock
-the lock screen and if such an authentication method will be used to unlock
-the keyguard, but will not be treated as a secure lock screen, then they:
+Device implementations:
-* [C-7-1] MUST return `false` for both the [`KeyguardManager.isKeyguardSecure()`](http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29)
-and the [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29)
-methods.
-* [C-7-2] MUST be disabled when the Device Policy Controller (DPC)
-application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_UNSPECIFIED`.
-* [C-7-3] MUST NOT reset the password expiration timers set by
-[`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
-* [C-7-4] MUST NOT authenticate access to keystores if the application has
-called [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
+* [C-SR] Are STRONGLY RECOMMENDED to support StrongBox.
+
+If device implementations support StrongBox, they:
+
+* [C-1-1] MUST declare [FEATURE_STRONGBOX_KEYSTORE](
+https://developer.android.com/reference/kotlin/android/content/pm/PackageManager#FEATURE_STRONGBOX_KEYSTORE%3Akotlin.String).
+
+* [C-1-2] MUST provide dedicated secure hardware that is used to back
+keystore and secure user authentication.
+
+* [C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors
+or other core resources with the application processor (AP).
+
+* [C-1-4] MUST ensure that any peripherals shared with the AP cannot alter
+StrongBox processing in any way, or obtain any information from the StrongBox.
+The AP MAY disable or block access to StrongBox.
+
+* [C-1-5] MUST have an internal clock with reasonable accuracy (+-10%)
+that is immune to manipulation by the AP.
+
+* [C-1-6] MUST have a true random number generator that produces
+uniformly-distributed and unpredictable output.
+
+* [C-1-7] MUST have tamper resistance, including resistance against
+physical penetration, and glitching.
+
+* [C-1-8] MUST have side-channel resistance, including resistance against
+leaking information via power, timing, electromagnetic radiation, and thermal
+radiation side channels.
+
+* [C-1-9] MUST have secure storage which ensures confidentiality,
+integrity, authenticity, consistency, and freshness of the
+contents. The storage MUST NOT be able to be read or altered, except
+as permitted by the StrongBox APIs.
+
+* To validate compliance with [C-1-3] through [C-1-9], device
+ implementations:
+
+ * [C-1-10] MUST include the hardware that is certified against the
+ Secure IC Protection Profile [BSI-CC-PP-0084-2014](
+ https://www.commoncriteriaportal.org/files/ppfiles/pp0084b_pdf.pdf) or
+ evaluated by a nationally accredited testing laboratory incorporating
+ High attack potential vulnerability assessment according to the
+ [Common Criteria Application of Attack Potential to Smartcards](
+ https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+ * [C-1-11] MUST include the firmware that is evaluated by a
+ nationally accredited testing laboratory incorporating High attack
+ potential vulnerability assessment according to the
+ [Common Criteria Application of Attack Potential to Smartcards](
+ https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+ * [C-SR] Are STRONGLY RECOMMENDED to include the hardware that is
+ evaluated using a Security Target, Evaluation Assurance Level
+ (EAL) 5, augmented by AVA_VAN.5. EAL 5 certification will likely
+ become a requirement in a future release.
+
+* [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR),
+which means that an insider with access to firmware signing keys cannot produce
+firmware that causes the StrongBox to leak secrets, to bypass functional
+security requirements or otherwise enable access to sensitive user data. The
+recommended way to implement IAR is to allow firmware updates only when the
+primary user password is provided via the IAuthSecret HAL. IAR will likely
+become a requirement in a future release.
\ No newline at end of file
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index 525e9d5..7e6610c 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -37,7 +37,15 @@
uses it
* the runtime permissions are associated with an intent pattern
for which the preinstalled application is set as the default handler
-
+* [C-0-6] MUST grant the `android.permission.RECOVER_KEYSTORE` permission
+ only to system apps that register a properly secured Recovery Agent. A
+ properly secured Recovery Agent is defined as an on-device software agent
+ that synchronizes with an off-device remote storage, that is equipped with
+ secure hardware with protection equivalent or stronger than what is
+ described in
+ [Google Cloud Key Vault Service](
+ https://developer.android.com/preview/features/security/ckv-whitepaper.html)
+ to prevent brute-force attacks on the lockscreen knowledge factor.
If device implementations include a pre-installed app or wish to allow
third-party apps to access the usage statistics, they:
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_security-features.md
similarity index 86%
rename from 9_security-model/9_7_kernel-security-features.md
rename to 9_security-model/9_7_security-features.md
index 1c44acf..84db962 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_security-features.md
@@ -1,4 +1,6 @@
-## 9.7\. Kernel Security Features
+## 9.7\. Security Features
+Device implementations MUST ensure compliance with security features in both the
+kernel and platform as described below.
The Android Sandbox includes features that use the Security-Enhanced Linux
(SELinux) mandatory access control (MAC) system, seccomp sandboxing, and other
@@ -48,9 +50,8 @@
kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`)
on devices originally shipping with API level 28 or higher.
-* [C-0-12] MUST implement kernel page table isolation on all devices with CPUs
-vulnerable to CVE-2017-5754 (Meltdown), and on all devices with kernel versions
-4.4 or higher on devices originally shipping with API level 28 or higher
+* [C-0-12] MUST implement kernel page table isolation on all devices
+originally shipping with API level 28 or higher
(e.g. `CONFIG_PAGE_TABLE_ISOLATION` or `CONFIG_UNMAP_KERNEL_AT_EL0).
* [SR] STRONGLY RECOMMENDED to keep kernel data
which is written only during initialization marked read-only after
@@ -84,3 +85,16 @@
* [C-2-1] MUST use an mandatory access control system that is
equivalent to SELinux.
+
+Android contains mutiple defense-in-depth features that are integral to device
+security.
+
+Device implementations:
+
+* [C-SR] Are STRONGLY RECOMMENDED not to disable Control-Flow Integrity (CFI)
+ or Integer Overflow Sanitization (IntSan) on components that have it
+ enabled.
+* [C-SR] Are STRONGLY RECOMMENDED to enable both CFI and IntSan for any
+ additional security-sensitive userspace components as explained in
+ [CFI](https://source.android.com/devices/tech/debug/cfi) and
+ [IntSan](https://source.android.com/de
\ No newline at end of file
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index a1799a4..61a9b5f 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -11,9 +11,28 @@
* [SR] Are STRONGLY RECOMMENDED to keep the 14 days retention period as
configured by default in the AOSP implementation.
+Android stores the system events using the [`StatsLog`](https://developer.android.com/reference/android/util/StatsLog.html)
+identifiers, and manages such history via the `StatsManager` and the
+`IncidentManager` System API.
+
+Device implementations:
+
+* [C-0-2] MUST only include the fields marked with `DEST_AUTOMATIC` in the
+ incident report created by the System API class `IncidentManager`.
+* [C-0-3] MUST not use the system event identifiers to log any other event
+ than what is described in the [`StatsLog`](https://developer.android.com/reference/android/util/StatsLog.html)
+ SDK documents. If additional system events are logged, they MAY use a
+ different atom identifier in the range between 100,000 and 200,000.
### 9.8.2\. Recording
+Device implementations:
+
+* [C-0-1] MUST NOT preload or distribute software components out-of-box that
+ send the user's private information (e.g. keystrokes, text displayed on the
+ screen) off the device without the user's consent or clear ongoing
+ notifications.
+
If device implementations include functionality in the system that captures
the contents displayed on the screen and/or records the audio stream played
on the device, they:
@@ -74,4 +93,4 @@
always-on VPN service in the `AndroidManifest.xml` file via setting the
[`SERVICE_META_DATA_SUPPORTS_ALWAYS_ON`](
https://developer.android.com/reference/android/net/VpnService.html#SERVICE_META_DATA_SUPPORTS_ALWAYS_ON)
- attribute to `false`.
\ No newline at end of file
+ attribute to `false`.
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 8a14713..60e39ba 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -1,22 +1,23 @@
## 9.9\. Data Storage Encryption
-If device implementations support a secure lock screen as described in
-[section 9.11.1](#9_11_1_secure_lock_screen), they:
+If Advanced Encryption Standard (AES) crypto performance, measured with the most
+performant AES technology available on the device (e.g. the ARM Cryptography
+Extensions), is above 50 MiB/sec, device implementations:
* [C-1-1] MUST support data storage encryption of the application private
-data (`/data partition`), as well as the application shared storage partition
-(`/sdcard partition`) if it is a permanent, non-removable part of the device.
+data (`/data` partition), as well as the application shared storage partition
+(`/sdcard` partition) if it is a permanent, non-removable part of the device,
+except for device implementations that are typically shared (e.g.
+Television).
+* [C-1-2] MUST enable the data storage encryption by default at the time
+the user has completed the out-of-box setup experience, except for device
+implementations that are typically shared (e.g. Television).
-If device implementations support a secure lock screen as described in
-[section 9.11.1](#9_11_1_secure_lock_screen) and support data storage
-encryption with Advanced Encryption Standard (AES) crypto performance
-above 50MiB/sec, they:
+If device implementations are already launched on an earlier Android version
+and cannot meet the requirement through a system software update, they MAY be
+exempted from the above requirements.
-* [C-2-1] MUST enable the data storage encryption by default at the time
-the user has completed the out-of-box setup experience. If device
-implementations are already launched on an earlier Android version with
-encryption disabled by default, such a device cannot meet the requirement
-through a system software update and thus MAY be exempted.
+Device implementations:
* SHOULD meet the above data storage encryption
requirement via implementing [File Based Encryption](
@@ -49,13 +50,14 @@
(eg. passcode, pin, pattern or fingerprint) and the `ACTION_USER_UNLOCKED`
message is broadcasted.
* [C-1-3] MUST NOT offer any method to unlock the CE protected storage
-without the user-supplied credentials.
+without either the user-supplied credentials or a registered escrow key.
* [C-1-4] MUST support Verified Boot and ensure that DE keys are
cryptographically bound to the device's hardware root of trust.
-* [C-1-5] MUST support encrypting file contents using AES with a key length
-of 256-bits in XTS mode.
-* [C-1-6] MUST support encrypting file name using AES with a key length of
-256-bits in CBC-CTS mode.
+* [C-1-5] MUST support encrypting file contents using AES-256-XTS.
+AES-256-XTS refers to the Advanced Encryption Standard with
+a 256-bit key length, operated in XTS mode. The full length of the XTS key
+is 512 bits.
+* [C-1-6] MUST support encrypting file names using AES-256 in CBC-CTS mode.
* The keys protecting CE and DE storage areas:
@@ -68,6 +70,9 @@
* [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
modes by default.
+* [C-SR] Are STRONGLY RECOMMENDED to encrypt file system metadata, such as
+file sizes, ownership, modes, and Extended attributes (xattrs), with a key
+cryptographically bound to the device's hardware root of trust.
* SHOULD make preloaded essential apps (e.g. Alarm, Phone, Messenger)
Direct Boot aware.
@@ -83,12 +88,12 @@
http://source.android.com/devices/tech/security/encryption/index.html)
(FDE), they:
-* [C-1-1] MUST use AES with a key of 128-bits (or greater) and a mode
-designed for storage (for example, AES-XTS, AES-CBC-ESSIV).
+* [C-1-1] MUST use AES in a mode designed for storage (for example, XTS
+or CBC-ESSIV), and with a cipher key length of 128 bits or greater.
* [C-1-2] MUST use a default passcode to wrap the encryption key and
MUST NOT write the encryption key to storage at any time
without being encrypted.
- * [C-1-3] MUST AES encrypt the encryption key by default unless the user
+* [C-1-3] MUST AES encrypt the encryption key by default unless the user
explicitly opts out, except when it is in active use, with the lock screen
credentials stretched using a slow stretching algorithm
(e.g. PBKDF2 or scrypt).
