Snap for 6838321 from b0122f7d6a05335108e6df17f83ac4a3a9acd739 to mainline-release
Change-Id: Icfb353840e009ff825527af48094096a7cb9344e
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 971300a..00930b0 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -8,7 +8,9 @@
following criteria:
* Have a power source that provides mobility, such as a battery.
-* Have a physical diagonal screen size in the range of 2.5 to 8 inches.
+* Have a physical diagonal screen size in the range of 3.3 inches (or
+ 2.5 inches for devices which launched on an API level earlier than
+ Android 11) to 8 inches.
The additional requirements in the rest of this section are specific to Android
Handheld device implementations.
@@ -23,12 +25,28 @@
Handheld device implementations:
* [[7.1](#7_1_display_and_graphics).1.1/H-0-1] MUST have at least one
-Android-compatible display at least 2.5 inches in physical diagonal size and
-each Android-compatible display MUST meet all requirements described on this
+Android-compatible display that meets all requirements described on this
document.
* [[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 support software screen rotation, they:
+
+* [[7.1](#7_1_display_and_graphics).1.1/H-1-1]* MUST make the logical screen
+that is made available for third party applications be at least 2 inches on the
+short edge(s) and 2.7 inches on the long edge(s).
+Devices which launched on an API level earlier than that of this document are
+exempted from this requirement.
+
+If Handheld device implementations do not support software screen rotation,
+they:
+
+* [[7.1](#7_1_display_and_graphics).1.1/H-2-1]* MUST make the logical screen
+that is made available for third party applications be at least 2.7 inches on
+the short edge(s).
+Devices which launched on an API level earlier than that of this document are
+exempted from this requirement.
+
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)
@@ -41,6 +59,27 @@
Handheld device implementations:
+* [[7.1](#7_1_display_and_graphics).4.6/H-0-1] MUST report whether the device
+ supports the GPU profiling capability via a system property
+ `graphics.gpu.profiler.support`.
+
+If Handheld device implementations declare support via a system property
+`graphics.gpu.profiler.support`, they:
+
+* [[7.1](#7_1_display_and_graphics).4.6/H-1-1] MUST report as output a
+ protobuf trace that complies with the schema for GPU counters and GPU
+ renderstages defined in the [Perfetto documentation](https://developer.android.com/studio/command-line/perfetto).
+* [[7.1](#7_1_display_and_graphics).4.6/H-1-2] MUST report conformant values
+ for the device’s GPU counters following the
+ [gpu counter trace packet proto](https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/gpu/gpu_counter_event.proto).
+* [[7.1](#7_1_display_and_graphics).4.6/H-1-3] MUST report conformant values
+ for the device’s GPU RenderStages following the
+ [render stage trace packet proto](https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/gpu/gpu_render_stage_event.proto).
+* [[7.1](#7_1_display_and_graphics).4.6/H-1-4] MUST report a GPU Frequency
+ tracepoint as specified by the format: [power/gpu_frequency](https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/ftrace/power.proto).
+
+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
@@ -356,6 +395,58 @@
terminal types and broadcast Intent ACTION_HEADSET_PLUG in less than
1000 milliseconds.
+If Handheld device implementations include at least one haptic actuator, they:
+
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED NOT to use an
+ eccentric rotating mass (ERM) haptic actuator(vibrator).
+* [[7.10](#7_10_haptics)/H]* SHOULD position the placement of the actuator
+ near the location where the device is typically held or touched by hands.
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to implement all
+ public constants for [clear haptics](https://source.android.com/devices/haptics)
+ in [android.view.HapticFeedbackConstants](https://developer.android.com/reference/android/view/HapticFeedbackConstants#constants)
+ namely (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE,
+ KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY,
+ VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START and GESTURE_END).
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to implement all
+ public constants for [clear haptics](https://source.android.com/devices/haptics)
+ in [android.os.VibrationEffect](https://developer.android.com/reference/android/os/VibrationEffect)
+ namely (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK and
+ EFFECT_DOUBLE_CLICK) and all public constants for [rich haptics](https://source.android.com/devices/haptics)
+ in [android.os.VibrationEffect.Composition](https://developer.android.com/reference/android/os/VibrationEffect.Composition)
+ namely (PRIMITIVE_CLICK and PRIMITIVE_TICK).
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to use these linked
+ haptic constants [mappings](https://source.android.com/devices/haptics).
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to follow
+ [quality assessment](https://source.android.com/devices/haptics)
+ for [createOneShot()](https://developer.android.com/reference/android/os/VibrationEffect#createOneShot%28long,%20int%29)
+ and [createWaveform()](https://developer.android.com/reference/android/os/VibrationEffect#createOneShot%28long,%20int%29)
+ API's.
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to verify the
+ capabilities for amplitude scalability by running
+ [android.os.Vibrator.hasAmplitudeControl()](https://developer.android.com/reference/android/os/Vibrator#hasAmplitudeControl%28%29).
+
+Linear resonant actuator (LRA) is a single mass spring system which has a
+dominant resonant frequency where the mass translates in the direction of
+desired motion.
+
+If Handheld device implementations include at least one linear resonant
+actuator, they:
+
+* [[7.10](#7_10_haptics)/H]* SHOULD move the haptic actuator in the X-axis of
+ portrait orientation.
+
+If Handheld device implementations have a haptic actuator which is X-axis
+Linear resonant actuator (LRA), they:
+
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to have the resonant
+ frequency of the X-axis LRA be under 200 Hz.
+
+If handheld device implementations follow haptic constants mapping, they:
+
+* [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to perform a
+ [quality assessment](https://source.android.com/devices/haptics)
+ for haptic constants.
+
### 2.2.2\. Multimedia
Handheld device implementations MUST support the following audio encoding and
@@ -386,7 +477,7 @@
Handheld device implementations:
-* [[3.2.3.1](#3_2_3_1_core_application_intents)/H-0-1] MUST have an
+* [[3.2.3.1](#3_2_3_1_common_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`](
@@ -398,6 +489,15 @@
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.2.3.1](#3_2_3_1_common_application_intents)/H-0-2]* MUST preload one
+or more applications or service components with an intent handler, for
+all the public intent filter patterns defined by the following application
+intents listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
+* [[3.2.3.1](#3_2_3_1_common_application_intents)/H-SR] Are STRONGLY
+RECOMMENDED to preload an email application which can handle [ACTION_SENDTO](https://developer.android.com/reference/android/content/Intent#ACTION_SENDTO)
+or [ACTION_SEND](https://developer.android.com/reference/android/content/Intent#ACTION_SEND)
+or [ACTION_SEND_MULTIPLE](https://developer.android.com/reference/android/content/Intent#ACTION_SEND_MULTIPLE)
+intents to send an email.
* [[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
@@ -460,6 +560,16 @@
https://developer.android.com/reference/android/service/voice/VoiceInteractionService)
, or an activity handling the `ACTION_ASSIST` intent.
+If Handheld device implementations support [`conversation notifications`](https://developer.android.com/preview/features/conversations#api-notifications)
+and group them into a separate section from alerting and silent non-conversation
+notifications, they:
+
+* [[3.8](#3_8_user_interface_compatibility).4/H-1-1]* MUST display
+ conversation notifications ahead of non conversation notifications with
+ the exception of ongoing foreground service notifications and
+ [importance:high](https://developer.android.com/reference/android/app/NotificationManager#IMPORTANCE_HIGH)
+ notifications.
+
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
@@ -477,6 +587,40 @@
itself as a low RAM device or so that it allocates internal (non-removable)
storage as shared storage.
+If Handheld device implementations include support for
+[`ControlsProviderService`](https://developer.android.com/reference/android/service/controls/ControlsProviderService)
+and [`Control`](https://developer.android.com/reference/android/service/controls/Control)
+APIs and allow third-party applications to publish [`device controls`](
+https://developer.android.com/preview/features/device-control), then they:
+
+* [[3.8](#3_8_user_interface_compatibility).16/H-1-1] MUST declare the feature
+ flag [`android.software.controls`](https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_CONTROLS)
+ and set it to `true`.
+* [[3.8](#3_8_user_interface_compatibility).16/H-1-2] MUST provide a user
+ affordance with the ability to add, edit, select, and operate the user’s
+ favorite device controls from the controls registered by the third-party
+ applications through the [`ControlsProviderService`](https://developer.android.com/reference/android/service/controls/ControlsProviderService)
+ and the [`Control`](https://developer.android.com/reference/android/service/controls/Control#getDeviceType%28%29)
+ APIs.
+* [[3.8](#3_8_user_interface_compatibility).16/H-1-3] MUST provide access to
+ this user affordance within three interactions from a default Launcher.
+* [[3.8](#3_8_user_interface_compatibility).16/H-1-4] MUST accurately render
+ in this user affordance the name and icon of each third-party app that
+ provides controls via the [`ControlsProviderService`](https://developer.android.com/reference/android/service/controls/ControlsProviderService)
+ API as well as any specified fields provided by the [`Control`](https://developer.android.com/reference/android/service/controls/Control)
+ APIs.
+
+Conversely, If Handheld device implementations do not implement such controls,
+they:
+
+* [[3.8](#3_8_user_interface_compatibility).16/H-2-1] MUST report `null` for
+ the [`ControlsProviderService`](https://developer.android.com/reference/android/service/controls/ControlsProviderService)
+ and the [`Control`](https://developer.android.com/reference/android/service/controls/Control)
+ APIs.
+* [[3.8](#3_8_user_interface_compatibility).16/H-2-2] MUST declare the feature
+ flag [`android.software.controls`](https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_CONTROLS)
+ and set it to `false`.
+
Handheld device implementations:
* [[3.10](#3_10_accessibility)/H-0-1] MUST support third-party accessibility
@@ -659,3 +803,5 @@
* [[6.1](#6_1_developer_tools)/H-0-5]\* MUST provide, through the perfetto
binary, at least the data sources described in [the perfetto documentation](
https://developer.android.com/studio/command-line/perfetto).
+ * [[6.1](#6_1_developer_tools)/H-0-6]\* The perfetto traced daemon MUST be
+ enabled by default (system property `persist.traced.enable`).
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 97e4064..a0db0f8 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -213,6 +213,10 @@
[`android.software.leanback`](
http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK)
and `android.hardware.type.television`.
+* [[3.2.3.1](#3_2_3_1_common_application_intents)/T-0-1] MUST preload one or
+more applications or service components with an intent handler, for all the
+public intent filter patterns defined by the following application intents
+listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
* [[3.4](#3_4_web_compatibility).1/T-0-1] MUST provide a complete
implementation of the `android.webkit.Webview` API.
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 64c35a6..0d67308 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -56,7 +56,7 @@
* [[7.8](#7_8_audio).1/W-0-1] MUST include a microphone.
-* [[7.8](#7_8_audio).2/W] MAY but SHOULD NOT have audio output.
+* [[7.8](#7_8_audio).2/W] MAY have audio output.
### 2.4.2\. Multimedia
@@ -71,6 +71,10 @@
* [[3](#3_0_intro)/W-0-2] MUST support uiMode =
[UI_MODE_TYPE_WATCH](
http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH).
+* [[3.2.3.1](#3_2_3_1_common_application_intents)/W-0-1] MUST preload one
+or more applications or service components with an intent handler, for
+all the public intent filter patterns defined by the following application
+intents listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
Watch device implementations:
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index dbf4dd8..86b5e7b 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -73,6 +73,20 @@
gyroscope’s measurement range to +/-250dps in order to maximize the resolution
possible
+If Automotive device implementations include a GPS/GNSS receiver, but do not
+include cellular network-based data connectivity, they:
+
+* [[7.3](#7_3_sensors).3/A-3-1] MUST determine location the very first time
+ the GPS/GNSS receiver is turned on or after 4+ days within 60 seconds.
+* [[7.3](#7_3_sensors).3/A-3-2] MUST meet the time-to-first-fix criteria as
+ described in [7.3.3/C-1-2](#7_3_3_gps) and [7.3.3/C-1-6](#7_3_3_gps)
+ for all other location requests (i.e requests which are not the first time
+ ever or after 4+ days). The requirement [7.3.3/C-1-2](#7_3_3_gps) is
+ typically met in vehicles without cellular network-based data connectivity,
+ by using GNSS orbit predictions calculated on the receiver, or using the
+ last known vehicle location along with the ability to dead reckon for at
+ least 60 seconds with a position accuracy satisfying
+ [7.3.3/C-1-3](#7_3_3_gps), or a combination of both.
Automotive device implementations:
@@ -250,10 +264,28 @@
[`android.car.*`](https://developer.android.com/reference/android/car/package-summary)
namespace.
+If Automotive device implementations provide a proprietary API using
+[`android.car.CarPropertyManager`](https://developer.android.com/reference/android/car/hardware/property/CarPropertyManager) with
+[`android.car.VehiclePropertyIds`](https://developer.android.com/reference/android/car/VehiclePropertyIds),
+they:
+
+* [[3](#3_0_intro)/A-1-1] MUST NOT attach special privileges to system
+ application's use of these properties, or prevent third-party applications
+ from using these properties.
+* [[3](#3_0_intro)/A-1-2] MUST NOT replicate a vehicle property that already
+ exists in the [SDK](https://developer.android.com/reference/android/car/VehiclePropertyIds).
+
+Automotive device implementations:
+
* [[3.2](#3_2_soft_api_compatibility).1/A-0-1] MUST support and enforce all
permissions constants as documented by the [Automotive Permission reference page](
https://developer.android.com/reference/android/car/Car).
+* [[3.2.3.1](#3_2_3_1_common_application_intents)/A-0-1] MUST preload one or
+more applications or service components with an intent handler, for all the
+public intent filter patterns defined by the following application intents
+listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
+
* [[3.4](#3_4_web_compatibility).1/A-0-1] MUST provide a complete
implementation of the `android.webkit.Webview` API.
@@ -331,18 +363,13 @@
Automotive device implementations:
* [[3.8](#3_8_user-interface-compatibility)/A] MAY restrict the application
- requests to limit the ability to enter a full screen mode as described in
- [`immersive documentation`](
+ requests to enter a full screen mode as described in [`immersive documentation`](
https://developer.android.com/training/system-ui/immersive).
* [[3.8](#3_8_user-interface-compatibility)/A] MAY keep the status bar and
the navigation bar visible at all times.
* [[3.8](#3_8_user-interface-compatibility)/A] MAY restrict the application
- requests to limit the ability to change the colors behind the system UI
- elements, to ensure those elements are clearly visible at all times,
- as described in the [`WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS`](
- https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS)
- and [`WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION`](
- https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION).
+ requests to change the colors behind the system UI elements, to ensure
+ those elements are clearly visible at all times.
### 2.5.4\. Performance and Power
@@ -430,12 +457,6 @@
unless it declares the `android.hardware.fingerprint` feature which requires a
keystore backed by an isolated execution environment.
-If Automotive device implementations support a secure lock screen, they:
-
-* [[9.11](#9_11_permissions)/A-1-1] MUST allow the user to choose the Sleep
- timeout for transition from the unlocked to the locked state, with a
- minimum allowable timeout up to 15 seconds or less.
-
Automotive device implementations:
* [[9.14](#9_14_automotive_system_isolation)/A-0-1] MUST gatekeep messages
diff --git a/2_device-types/2_6_tablet-reqs.md b/2_device-types/2_6_tablet-reqs.md
index bbbb5f9..7babded 100644
--- a/2_device-types/2_6_tablet-reqs.md
+++ b/2_device-types/2_6_tablet-reqs.md
@@ -48,3 +48,10 @@
**Keys and Credentials (Section 9.11)**
Refer to Section [[9.11](#9_11_permissions)].
+
+### 2.6.2\. Software
+
+* [[3.2.3.1](#3_2_3_1_common_application_intents)/Tab-0-1] MUST preload one
+or more applications or service components with an intent handler, for all the
+public intent filter patterns defined by the following application intents
+listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
\ No newline at end of file
diff --git a/3_software/3_10_accessibility.md b/3_software/3_10_accessibility.md
index 1f52271..1b934fb 100644
--- a/3_software/3_10_accessibility.md
+++ b/3_software/3_10_accessibility.md
@@ -16,9 +16,6 @@
`AccessibilityEvent` to all registered [`AccessibilityService`](
http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html)
implementations as documented in the SDK.
-* [C-1-3] MUST honor the `android.settings.ACCESSIBILITY_SETTINGS` intent to
- provide a user-accessible mechanism to enable and disable the third-party
- accessibility services alongside the preinstalled accessibility services.
* [C-1-4] MUST add a button in the system's navigation bar allowing the user
to control the accessibility service when the enabled accessibility services
declare the [`AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON`](
diff --git a/3_software/3_15_instant-apps.md b/3_software/3_15_instant-apps.md
index 53ea0dc..6791ed8 100644
--- a/3_software/3_15_instant-apps.md
+++ b/3_software/3_15_instant-apps.md
@@ -33,3 +33,9 @@
is available on the device.
* [C-0-7] MUST allow running Instant Apps to be accessed from the Recents
function if the Recents function is available on the device.
+
+If device implementations support Instant Apps, they:
+
+* [C-1-1] MUST preload one or more applications or service components
+ with an intent handler for the intents listed in the SDK [here](https://developer.android.com/topic/google-play-instant/instant-app-intents)
+ and make the intents visible for Instant Apps.
\ No newline at end of file
diff --git a/3_software/3_18_contacts.md b/3_software/3_18_contacts.md
new file mode 100644
index 0000000..deb327e
--- /dev/null
+++ b/3_software/3_18_contacts.md
@@ -0,0 +1,65 @@
+## 3.18\. Contacts
+
+Android includes [`Contacts
+Provider`](https://developer.android.com/guide/topics/providers/contacts-provider)
+APIs to allow applications to manage contact information stored on the device.
+Contact data that is entered directly into the device is typically synchronized
+with a web service, but the data MAY also only reside locally on the device.
+Contacts that are only stored on the device are referred to as **local
+contacts.**
+
+[RawContacts](https://developer.android.com/reference/android/provider/ContactsContract.RawContacts)
+are "associated with" or "stored in" an
+[Account](https://developer.android.com/reference/android/accounts/Account)
+when the
+[`ACCOUNT_NAME`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_NAME),
+and
+[`ACCOUNT_TYPE`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_TYPE),
+columns for the raw contacts match the corresponding
+[Account.name](https://developer.android.com/reference/android/accounts/Account#name)
+and
+[Account.type](https://developer.android.com/reference/android/accounts/Account#type)
+fields of the account.
+
+**Default local account**: an account for raw contacts that are only stored on
+the device and not associated with an Account in the [AccountManager](
+https://developer.android.com/reference/android/accounts/AccountManager), which are
+created with *null* values for the
+[`ACCOUNT_NAME`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_NAME),
+and
+[`ACCOUNT_TYPE`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_TYPE),
+columns.
+
+**Custom local account**: an account for raw contacts that are only stored on the
+device and not associated with an Account in the AccountManager, which are
+created with *at least one non-null value* for the
+[`ACCOUNT_NAME`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_NAME),
+and
+[`ACCOUNT_TYPE`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_TYPE),
+columns.
+
+Device implementations:
+
+* [C-SR] Are STRONGLY RECOMMENDED to not create **custom local accounts**.
+
+If device implementations use a **custom local account**:
+
+* [C-1-1] The
+ [`ACCOUNT_NAME`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_NAME),
+ of the **custom local account** MUST be returned by
+ [`ContactsContract.RawContacts.getLocalAccountName`](https://developer.android.com/reference/android/provider/ContactsContract.RawContacts.html#getLocalAccountName\(\))
+* [C-1-2] The
+ [`ACCOUNT_TYPE`](https://developer.android.com/reference/android/provider/ContactsContract.SyncColumns.html#ACCOUNT_TYPE),
+ of the **custom local account** MUST be returned by
+ [`ContactsContract.RawContacts.getLocalAccountType`](https://developer.android.com/reference/android/provider/ContactsContract.RawContacts.html#getLocalAccountType\(\))
+* [C-1-3] Raw contacts that are inserted by third party applications with
+ the **default local account** (i.e. by setting null values for
+ `ACCOUNT_NAME` and `ACCOUNT_TYPE`) MUST be inserted to the **custom local
+ account**.
+* [C-1-4] Raw contacts inserted into the **custom local account** MUST not be
+ removed when accounts are added or removed.
+* [C-1-5] Delete operations performed against the **custom local account**
+ MUST result in raw contacts being purged immediately (as if the
+ [`CALLER_IS_SYNCADAPTER`](https://developer.android.com/reference/android/provider/ContactsContract.html#CALLER_IS_SYNCADAPTER)
+ param was set to true), even if the `CALLER\_IS\_SYNCADAPTER` param was set
+ to false or not specified.
\ 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 a2eabb6..c89308a 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -53,14 +53,27 @@
### 3.1.1\. Android Extensions
-Android includes the support of extending the managed APIs while keeping the
-same API level version.
+Android supports extending the managed API surface of a particular API level by
+updating the extension version for that API level. The
+`android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)` API returns the
+extension version of the provided `apiLevel`, if there are extensions for that
+API level.
-* [C-0-1] Android device implementations MUST preload the AOSP implementation
-of both the shared library `ExtShared` and services `ExtServices` with versions
-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.
+Android device implementations:
+
+* [C-0-1] MUST preload the AOSP implementation of both the shared library
+ `ExtShared` and services `ExtServices` with versions greater 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.
+
+* [C-0-2] MUST only return valid extension version number that have been
+ defined by the AOSP.
+
+* [C-0-3] MUST support all the APIs defined by the extension versions
+ returned by `android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)`
+ in the same manner as other managed APIs are supported, following the
+ requirements in [section 3.1](#3_1_managed-api-compatibility).
### 3.1.2\. Android Library
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 38c0358..39a7937 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -243,35 +243,31 @@
### 3.2.3\. Intent Compatibility
-#### 3.2.3.1\. Core Application Intents
+#### 3.2.3.1\. Common Application Intents
Android intents allow application components to request functionality from
other Android components. The Android upstream project includes a list of
-applications considered core Android applications, which implements several
-intent patterns to perform common actions.
+applications which implement several intent patterns to perform common actions.
-* [C-0-1] Device implementations MUST preload one or more applications or
+Device implementations:
+
+* [C-SR] Are STRONGLY RECOMMENDED to preload one or more applications or
service components with an intent handler, for all the public intent filter
-patterns defined by the following core android applications in AOSP:
+patterns defined by the following application intents listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30)
+and provide fulfillment i.e meet with the developer expectation for these common
+application intents as described in the SDK.
- * Desk Clock
- * Browser
- * Calendar
- * Contacts
- * Gallery
- * GlobalSearch
- * Launcher
- * Music
- * Settings
+Please refer to [Section 2](#2_device_types) for mandatory application intents
+for each device type.
#### 3.2.3.2\. Intent Resolution
* [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)
+allow each intent pattern referenced in [section 3.2.3.1](#3_2_3_1_common_application_intents)
, 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
+* [C-0-2] Device implementers MUST NOT attach special privileges to system
applications' use of these intent patterns, or prevent third-party applications
from binding to and assuming control of these patterns. This prohibition
specifically includes but is not limited to disabling the “Chooser” user
@@ -327,7 +323,7 @@
honor any new intent or broadcast intent patterns using an ACTION, CATEGORY, or
other key string in a package space belonging to another organization.
* [C-0-3] Device implementers MUST NOT alter or extend any of the intent
-patterns used by the core apps listed in [section 3.2.3.1](#3_2_3_1_core_application_intents).
+patterns listed in [section 3.2.3.1](#3_2_3_1_common_application_intents).
* Device implementations MAY include intent patterns using namespaces clearly
and obviously associated with their own organization. This prohibition is
analogous to that specified for Java language classes in [section 3.6](#3_6_api_namespaces).
@@ -339,12 +335,15 @@
Device implementations:
-* [C-0-1] MUST broadcast the public broadcast intents in response to
- appropriate system events as described in the SDK documentation. Note that
- this requirement is not conflicting with section 3.5 as the limitation for
- background applications are also described in the SDK documentation.
+* [C-0-1] MUST broadcast the public broadcast intents listed [here](https://developer.android.com/about/versions/11/reference/broadcast-intents-30)
+in response to appropriate system events as described in the SDK documentation.
+Note that this requirement is not conflicting with section 3.5 as the
+limitation for background applications are also described in the SDK
+documentation. Also certain broadcast intents are conditional upon hardware
+support, if the device supports the necessary hardware they MUST broadcast the
+intents and provide the behavior inline with SDK documentation.
-#### 3.2.3.5\. Default App Settings
+#### 3.2.3.5\. Conditional Application Intents
Android includes settings that provide users an easy way to select their
default applications, for example for Home screen or SMS.
@@ -384,28 +383,168 @@
use to place outgoing calls. The AOSP implementation meets this requirement by
including a "Calling Accounts option" menu within the "Calls" settings menu.
-* [C-2-4] MUST allow [`android.telecom.CallRedirectionService`](
- https://developer.android.com/reference/android/telecom/CallRedirectionService) for an app
- that holds the [`android.app.role.CALL_REDIRECTION`](
- https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
- role.
-* [C-2-5] MUST provide the user affordance to choose an app
- that holds the [`android.app.role.CALL_REDIRECTION`](
- https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
- role.
+* [C-2-4] MUST allow [`android.telecom.CallRedirectionService`](https://developer.android.com/reference/android/telecom/CallRedirectionService)
+for an app that holds the [`android.app.role.CALL_REDIRECTION`](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
+role.
+* [C-2-5] MUST provide the user affordance to choose an app that holds the
+[`android.app.role.CALL_REDIRECTION`](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
+role.
+* [C-2-6] MUST honor the [android.intent.action.SENDTO](https://developer.android.com/reference/android/content/Intent#ACTION_SENDTO)
+and [android.intent.action.VIEW](https://developer.android.com/reference/android/content/Intent#ACTION_VIEW)
+intents and provide an activity to send/display SMS messages.
+* [C-SR] Are Strongly Recommended to honor [android.intent.action.ANSWER](https://developer.android.com/reference/android/content/Intent#ACTION_ANSWER),
+[android.intent.action.CALL](https://developer.android.com/reference/android/content/Intent#ACTION_CALL),
+[android.intent.action.CALL_BUTTON](https://developer.android.com/reference/android/content/Intent#ACTION_CALL_BUTTON),
+[android.intent.action.VIEW](https://developer.android.com/reference/android/content/Intent#ACTION_VIEW)
+& [android.intent.action.DIAL](https://developer.android.com/reference/android/content/Intent#ACTION_DIAL)
+intents with a preloaded dialer application which can handle these intents and
+provide fulfillment as described in the SDK.
If device implementations report `android.hardware.nfc.hce`, they:
* [C-3-1] MUST honor the [android.settings.NFC_PAYMENT_SETTINGS](
http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFC_PAYMENT_SETTINGS)
intent to show a default app settings menu for Tap and Pay.
+* [C-3-2] MUST honor [android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT](https://developer.android.com/reference/android/nfc/cardemulation/CardEmulation#ACTION_CHANGE_DEFAULT)
+intent to show an activity which opens a dialog to ask the user to change the
+default card emulation service for a certain category as described in the SDK.
+
+If device implementations report `android.hardware.nfc`, they:
+
+* [C-4-1] MUST honor these intents [android.nfc.action.NDEF_DISCOVERED](https://developer.android.com/reference/android/nfc/NfcAdapter#ACTION_NDEF_DISCOVERED),
+[android.nfc.action.TAG_DISCOVERED](https://developer.android.com/reference/android/nfc/NfcAdapter#ACTION_TAG_DISCOVERED)
+& [android.nfc.action.TECH_DISCOVERED](https://developer.android.com/reference/android/nfc/NfcAdapter#ACTION_TECH_DISCOVERED),
+to show an activity which fulfils developer expectations for these intents as
+described in the SDK.
If device implementations support the `VoiceInteractionService` and have more
than one application using this API installed at a time, they:
-* [C-4-1] MUST honor the [`android.settings.ACTION_VOICE_INPUT_SETTINGS`](
- https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS)
- intent to show a default app settings menu for voice input and assist.
+* [C-4-1] MUST honor the [`android.settings.ACTION_VOICE_INPUT_SETTINGS`](https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS)
+intent to show a default app settings menu for voice input and assist.
+
+If device implementations report `android.hardware.bluetooth`, they:
+
+* [C-5-1] MUST honor the [‘android.bluetooth.adapter.action.REQUEST_ENABLE’](https://developer.android.com/reference/kotlin/android/bluetooth/BluetoothAdapter#action_request_enable)
+intent and show a system activity to allow the user to turn on Bluetooth.
+* [C-5-2] MUST honor the
+[‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’](https://developer.android.com/reference/android/bluetooth/BluetoothAdapter#ACTION_REQUEST_DISCOVERABLE)
+intent and show a system activity that requests discoverable mode.
+
+If device implementations support the DND feature, they:
+
+* [C-6-1] MUST implement an activity that would respond to the intent
+[`ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS),
+which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity where
+the user can grant or deny the app access to DND policy configurations.
+
+If device implementations allow users to use third-party input methods on the
+device, they:
+
+* [C-7-1] MUST provide a user-accessible mechanism to add and configure
+third-party input methods in response to the
+[`android.settings.INPUT_METHOD_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_INPUT_METHOD_SETTINGS)
+intent.
+
+If device implementations support third-party accessibility services, they:
+
+* [C-8-1] MUST honor the [`android.settings.ACCESSIBILITY_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_ACCESSIBILITY_SETTINGS)
+intent to provide a user-accessible mechanism to enable and disable the
+third-party accessibility services alongside the preloaded accessibility
+services.
+
+If device implementations include support for Wi-Fi Easy Connect and expose the
+functionality to third-party apps, they:
+
+* [C-9-1] MUST implement the [Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI](https://developer.android.com/reference/android/provider/Settings.html#ACTION_PROCESS_WIFI_EASY_CONNECT_URI)
+Intent APIs as described in the SDK documentation.
+
+If device implementations provide the data saver mode, they:
+* [C-10-1] MUST provide a user interface in the settings, that handles the
+[`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](https://developer.android.com/reference/android/provider/Settings.html#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
+intent, allowing users to add applications to or remove applications from
+the allow list.
+
+If device implementations do not provide the data saver mode, they:
+
+* [C-11-1] MUST have an activity that handles the
+[`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
+intent but MAY implement it as a no-op.
+
+If device implementations declare the support for camera via
+`android.hardware.camera.any` they:
+
+* [C-12-1] MUST honor the [`android.media.action.STILL_IMAGE_CAMERA`](https://developer.android.com/reference/android/provider/MediaStore#INTENT_ACTION_STILL_IMAGE_CAMERA)
+and [`android.media.action.STILL_IMAGE_CAMERA_SECURE`](https://developer.android.com/reference/android/provider/MediaStore#INTENT_ACTION_STILL_IMAGE_CAMERA_SECURE)
+intent and launch the camera in still image mode as described in the SDK.
+* [C-12-2] MUST honor the [`android.media.action.VIDEO_CAMERA`](https://developer.android.com/reference/android/provider/MediaStore#INTENT_ACTION_VIDEO_CAMERA)
+intent to launch the camera in video mode as described in the SDK.
+* [C-12-3] MUST honor only allow preinstalled Android applications to handle
+the following intents [`MediaStore.ACTION_IMAGE_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE),
+[`MediaStore.ACTION_IMAGE_CAPTURE_SECURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE_SECURE),
+and [`MediaStore.ACTION_VIDEO_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_VIDEO_CAPTURE)
+as described in the [SDK document](https://developer.android.com/preview/behavior-changes-11?hl=zh-tw#media-capture).
+
+If device implementations report `android.software.device_admin`, they:
+
+* [C-13-1] MUST honor the intent [`android.app.action.ADD_DEVICE_ADMIN`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_ADD_DEVICE_ADMIN)
+to invoke a UI to bring the user through adding the device administrator to
+the system (or allowing them to reject it).
+
+* [C-13-2] MUST honor the intents
+[android.app.action.ADMIN_POLICY_COMPLIANCE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_ADMIN_POLICY_COMPLIANCE),
+[android.app.action.GET_PROVISIONING_MODE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_GET_PROVISIONING_MODE),
+[android.app.action.PROVISIONING_SUCCESSFUL](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_PROVISIONING_SUCCESSFUL),
+[android.app.action.PROVISION_MANAGED_DEVICE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_PROVISION_MANAGED_DEVICE),
+[android.app.action.PROVISION_MANAGED_PROFILE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_PROVISION_MANAGED_PROFILE),
+[android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_SET_NEW_PARENT_PROFILE_PASSWORD),
+[android.app.action.SET_NEW_PASSWORD](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_SET_NEW_PASSWORD)
+& [android.app.action.START_ENCRYPTION](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_START_ENCRYPTION)
+and have an activity to provide fulfillment for these intents as described
+in SDK [here](https://developer.android.com/reference/android/app/admin/DevicePolicyManager).
+
+If device implementations declare the [`android.software.autofill`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_AUTOFILL)
+feature flag, they:
+
+* [C-14-1] MUST fully implement the [`AutofillService`](https://developer.android.com/reference/android/service/autofill/AutofillService.html)
+and [`AutofillManager`](https://developer.android.com/reference/android/view/autofill/AutofillManager.html)
+APIs and honor the [android.settings.REQUEST_SET_AUTOFILL_SERVICE](https://developer.android.com/reference/android/provider/Settings.html#ACTION_REQUEST_SET_AUTOFILL_SERVICE)
+intent to show a default app settings menu to enable and disable autofill and
+change the default autofill service for the user.
+
+If device implementations include a pre-installed app or wish to allow
+third-party apps to access the usage statistics, they:
+
+* [C-SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant
+or revoke access to the usage stats in response to the
+[android.settings.ACTION_USAGE_ACCESS_SETTINGS](https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
+intent for apps that declare the `android.permission.PACKAGE_USAGE_STATS`
+permission.
+
+If device implementations intend to disallow any apps, including pre-installed
+apps, from accessing the usage statistics, they:
+
+* [C-15-1] MUST still have an activity that handles the
+[android.settings.ACTION_USAGE_ACCESS_SETTINGS](https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
+intent pattern but MUST implement it as a no-op, that is to have an equivalent
+behavior as when the user is declined for access.
+
+If device implementations report the feature `android.hardware.audio.output`,
+they:
+
+* [C-SR] Are Strongly Recommended to honor android.intent.action.TTS_SERVICE,
+android.speech.tts.engine.INSTALL_TTS_DATA &
+android.speech.tts.engine.GET_SAMPLE_TEXT intents have an activity to provide
+fulfillment for these intents as described in SDK [here](https://developer.android.com/reference/android/speech/tts/TextToSpeech.Engine).
+
+Android includes support for interactive screensavers, previously referred to
+as Dreams. Screen Savers allow users to interact with applications when a device
+connected to a power source is idle or docked in a desk dock.
+Device Implementations:
+
+* SHOULD include support for screen savers and provide a settings option for
+users to configure screen savers in response to the
+`android.settings.DREAM_SETTINGS` intent.
### 3.2.4\. Activities on secondary/multiple displays
diff --git a/3_software/3_5_api-behavioral-compatibility.md b/3_software/3_5_api-behavioral-compatibility.md
index 70004ed..fac707e 100644
--- a/3_software/3_5_api-behavioral-compatibility.md
+++ b/3_software/3_5_api-behavioral-compatibility.md
@@ -77,10 +77,11 @@
SHOULD use the source code available via the Android Open Source Project where
possible, rather than re-implement significant parts of the system.
-## 3.5.1\. Background Restriction
+## 3.5.1\. Application Restriction
-If device implementations implement the app restrictions that are included in
-AOSP or extend the app restrictions, they:
+If device implementations implement a proprietary mechanism to restrict apps and
+that mechanism is more restrictive than [the Rare App Standby Bucket](
+https://developer.android.com/topic/performance/power/power-details), they:
* [C-1-1] MUST provide user affordance where the user can see the list of
restricted apps.
@@ -97,7 +98,8 @@
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.
+automatically. Such information MUST be provided within 24 hours of when
+the restrictions are applied.
* [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.
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index fafb1b8..7265e3b 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -157,6 +157,26 @@
* MAY only manage the visibility and timing of when third-party apps can notify
users of notable events to mitigate safety issues such as driver distraction.
+Android 11 introduces support for conversation notifications, which are
+notifications that use [MessagingStyle](https://developer.android.com/reference/android/app/Notification.MessagingStyle.html)
+and provides a published [People](https://developer.android.com/reference/android/app/Person) Shortcut ID.
+
+Device implementations:
+
+* [C-SR] Are STRONGLY RECOMMENDED to group and display
+ [`conversation notifications`](https://developer.android.com/preview/features/conversations#api-notifications)
+ ahead of non conversation notifications with the exception of
+ ongoing foreground service notifications and [`importance:high`](https://developer.android.com/reference/android/app/NotificationManager#IMPORTANCE_HIGH)
+ notifications.
+
+If device implementations support [`conversation notifications`](https://developer.android.com/preview/features/conversations#api-notifications)
+and the app provides the required data for
+[`bubbles`](https://developer.android.com/guide/topics/ui/bubbles), they:
+
+* [C-SR] Are STRONGLY RECOMMENDED to display this conversation as a bubble.
+ The AOSP implementation meets these requirements with the default System UI,
+ Settings, and Launcher.
+
If device implementations support rich notifications, they:
* [C-2-1] MUST use the exact resources as
@@ -212,13 +232,7 @@
If device implementations support the DND feature, they:
-* [C-1-1] MUST implement an activity that would respond to the intent
- [ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS](
- https://developer.android.com/reference/android/provider/Settings.html#ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS),
- which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity
- where the user can grant or deny the app access to DND policy
- configurations.
-* [C-1-2] MUST, for when the device implementation has provided a means for the user
+* [C-1-1] MUST, for when the device implementation has provided a means for the user
to grant or deny third-party apps to access the DND policy configuration,
display [Automatic DND rules](
https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule%28android.app.AutomaticZenRule%29)
@@ -314,6 +328,9 @@
the [Material theme attributes](
http://developer.android.com/reference/android/R.style.html#Theme_Material)
or their assets exposed to applications.
+* [C-1-3] MUST use the [Roboto version 2.x](https://github.com/google/roboto)
+ fonts as the out-of-box Sans-serif font family for languages that Roboto
+ supports.
Android also includes a “Device Default” theme family as a set of defined styles
for application developers to use if they want to match the look and feel of the
@@ -408,22 +425,6 @@
* [C-1-1] MUST declare the platform feature android.software.input_methods and
support IME APIs as defined in the Android SDK documentation.
-* [C-1-2] MUST provide a user-accessible mechanism to add and configure
- third-party input methods in response to the
- android.settings.INPUT_METHOD_SETTINGS intent.
-
-If device implementations declare the [`android.software.autofill`](
-https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_AUTOFILL)
-feature flag, they:
-
-* [C-2-1] MUST fully implement the [`AutofillService`](
-https://developer.android.com/reference/android/service/autofill/AutofillService.html)
-and [`AutofillManager`](
-https://developer.android.com/reference/android/view/autofill/AutofillManager.html)
-APIs and honor the [`android.settings.REQUEST_SET_AUTOFILL_SERVICE`](
-https://developer.android.com/reference/android/provider/Settings.html#ACTION_REQUEST_SET_AUTOFILL_SERVICE)
-intent to show a default app settings menu to enable and disable autofill and
-change the default autofill service for the user.
### 3.8.10\. Lock Screen Media Control
@@ -436,13 +437,8 @@
### 3.8.11\. Screen savers (previously Dreams)
-Android includes support for [interactive screen savers](http://developer.android.com/reference/android/service/dreams/DreamService.html),
-previously referred to as Dreams. Screen savers allow users to interact with
-applications when a device connected to a power source is idle or docked in a
-desk dock. Android Watch devices MAY implement screen savers, but other types
-of device implementations SHOULD include support for screen savers and provide
-a settings option for users to configure screen savers in response to the
-`android.settings.DREAM_SETTINGS` intent.
+See [section 3.2.3.5](#3_2_3_5_conditional_application_intents) for settings
+intent to congfigure screen savers.
### 3.8.12\. Location
@@ -584,14 +580,12 @@
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.
+an area on the edge of the display that may not be functional for an application
+due to a display cutout or curved display on the edge(s).
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-5] MUST NOT have cutout(s) if the device's aspect ratio is 1.0(1:1).
* [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`](
@@ -600,3 +594,12 @@
* [C-1-4] MUST report correct values for all cutout metrics defined in the
[`DisplayCutout`](
https://developer.android.com/reference/android/view/DisplayCutout) API.
+
+### 3.8.16\. Device Controls
+
+Android includes [`ControlsProviderService`](https://developer.android.com/reference/android/service/controls/ControlsProviderService)
+and [`Control`](https://developer.android.com/reference/android/service/controls/Control)
+APIs to allow third-party applications to publish device controls for quick
+status and action for users.
+
+See Section [2_2_3](#2_2_3_software) for device-specific requirements.
\ 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 983b125..e8fd750 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -36,10 +36,15 @@
* [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 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.
+* [C-1-2] MUST require some affirmative action before or 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 but appropriate
+ disclosure notice (as referenced in AOSP) MUST be shown before device owner
+ provisioning is initiated. Also, the programmatic device owner consent
+ mechanism used (by enterprises) for device owner provisioning MUST NOT
+ interfere with the Out-Of-Box Experience for non-enterprise use.
+* [C-1-3] MUST NOT hard code the consent 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
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 27ae4f2..9e0b08f 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -63,3 +63,13 @@
harmful.
* SHOULD provide a user affordance to choose to uninstall or launch an
application on the warning dialog.
+
+* [C-0-8] MUST implement support for Incremental File System as documented
+ [here](https://source.android.com/devices/architecture/kernel/incfs).
+
+* [C-0-9] MUST support verifying .apk files using the
+ [APK Signature Scheme v4](https://source.android.com/security/apksigning/v4.html).
+
+* If device implementations are already launched on an earlier Android
+ version and cannot meet the requirements [C-0-8] and [C-0-9] through a
+ system software update, they MAY be exempted from these requirements.
diff --git a/5_multimedia/5_9_midi.md b/5_multimedia/5_9_midi.md
index ec13b0a..9a950a8 100644
--- a/5_multimedia/5_9_midi.md
+++ b/5_multimedia/5_9_midi.md
@@ -9,10 +9,12 @@
which they provide generic non-MIDI connectivity, where such transports are:
* USB host mode, [section 7.7](#7_7_USB)
- * USB peripheral mode, [section 7.7](#7_7_USB)
* MIDI over Bluetooth LE acting in central role, [section 7.4.3](#7_4_3_bluetooth)
* [C-1-2] MUST support the inter-app MIDI software transport
(virtual MIDI devices)
* [C-1-3] MUST include libamidi.so (native MIDI support)
+
+* SHOULD support MIDI over USB peripheral mode, [section 7.7](#7_7_USB)
+
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 802b984..33e6df1 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -9,8 +9,9 @@
commands provided in the AOSP, which can be used by app developers,
including [`dumpsys`](https://source.android.com/devices/input/diagnostics.html)
`cmd stats`
- * [C-SR] Are STRONGLY RECOMMENDED to support the shell command
- `cmd testharness`.
+ * [C-0-11] MUST support the shell command `cmd testharness`. Upgrading
+ device implementations from an earlier Android version without a
+ persistent data block MAY be exempted from C-0-11.
* [C-0-3] MUST NOT alter the format or the contents of device system
events (batterystats , diskstats, fingerprint, graphicsstats, netstats,
notification, procstats) logged via the dumpsys command.
@@ -48,12 +49,26 @@
* [C-0-5] MUST support secure adb. Android includes support for secure
adb. Secure adb enables adb on known authenticated hosts.
* [C-0-6] MUST provide a mechanism allowing adb to be connected from a
- host machine. For example:
+ host machine. Specifically:
- * Device implementations without a USB port supporting peripheral mode
- MUST implement adb via local-area network (such as Ethernet or Wi-Fi).
- * MUST provide drivers for Windows 7, 9 and 10, allowing developers to
- connect to the device using the adb protocol.
+ If device implementations without a USB port support peripheral mode, they:
+
+ * [C-3-1] MUST implement adb via local-area network (such as Ethernet
+ or Wi-Fi).
+ * [C-3-2] MUST provide drivers for Windows 7, 8 and 10, allowing
+ developers to connect to the device using the adb protocol.
+
+ If device implementations support adb connections to a host machine via
+ Wi-Fi, they:
+
+ * [C-4-1] MUST have the `AdbManager#isAdbWifiSupported()` method
+ return `true`.
+
+ If device implementations support adb connections to a host machine via
+ Wi-Fi and includes at least one camera, they:
+
+ * [C-5-1] MUST have the `AdbManager#isAdbWifiQrSupported()` method
+ return `true`.
* [**Dalvik Debug Monitor Service (ddms)**](http://developer.android.com/tools/debugging/ddms.html)
* [C-0-7] MUST support all ddms features as documented in the Android SDK.
@@ -83,15 +98,17 @@
* [C-SR] Are STRONGLY RECOMMENDED to provide, through the perfetto binary,
at least the data sources described in [the perfetto documentation](
https://developer.android.com/studio/command-line/perfetto).
-
+* [**Low Memory Killer**](https://source.android.com/devices/tech/perf/lmkd)
+ * [C-0-10] MUST write a `LMK_KILL_OCCURRED_FIELD_NUMBER` Atom to the
+ statsd log when an app is terminated by the [Low Memory Killer](
+ https://source.android.com/devices/tech/perf/lmkd).
* [**Test Harness Mode**](https://source.android.com/compatibility/cts/harness)
-
If device implementations support the shell command `cmd testharness` and
run `cmd testharness enable`, they:
-
* [C-2-1] MUST return `true` for
`ActivityManager.isRunningInUserTestHarness()`
- * [C-2-2] MUST implement Test Harness Mode as described in [harness mode documentation](
+ * [C-2-2] MUST implement Test Harness Mode as described in
+ [Test Harness Mode documentation](
https://source.android.com/compatibility/cts/harness).
If device implementations report the support of Vulkan 1.0 or higher via the
diff --git a/7_hardware-compatibility/7_10_haptics.md b/7_hardware-compatibility/7_10_haptics.md
new file mode 100644
index 0000000..e5ba689
--- /dev/null
+++ b/7_hardware-compatibility/7_10_haptics.md
@@ -0,0 +1,3 @@
+## 7.10\. Haptics
+
+See Section [2.2.1](#2_2_1_hardware) for device-specific requirements.
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index c470f95..ad9e3c6 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -55,14 +55,41 @@
* MAY have the Android-compatible display(s) with rounded corners.
-If device implementations support `UI_MODE_TYPE_NORMAL` and include the
+If device implementations support `UI_MODE_TYPE_NORMAL` and include
Android-compatible display(s) with rounded corners, they:
-* [C-1-1] MUST ensure that the radius of the rounded corners is less than or
-equal to 38 dp.
+* [C-1-1] MUST ensure that at least one of the following requirements
+ is met:
+ * The radius of the rounded corners is less than or equal to 38 dp.
+ * When a 15 dp by 15 dp box is anchored at each corner of the logical
+ display, at least one pixel of each box is visible on the screen.
+
* SHOULD include user affordance to switch to the display mode with the
rectangular corners.
+If device implementations include an Android-compatible display(s) that is
+foldable, or includes a folding hinge between multiple display panels and makes
+such display(s) available to render third-party apps, they:
+
+* [C-2-1] MUST implement the latest available stable version of the
+[extensions API](
+https://developer.android.com/jetpack/androidx/releases/window-extensions)
+or the stable version of [sidecar API](
+https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/window/window-sidecar/api/0.1.0-alpha01.txt)
+to be used by [Window Manager Jetpack](
+https://developer.android.com/jetpack/androidx/releases/window) library.
+
+If device implementations include an Android-compatible display(s) that is
+foldable, or includes a folding hinge between multiple display panels and if
+the hinge or fold crosses a fullscreen application window, they:
+
+* [C-3-1] MUST report the position, bounds and state of hinge or fold through
+ extensions or sidecar APIs to the application.
+
+For details on correctly implementing the sidecar or extension APIs refer
+to the public documentation of [Window Manager Jetpack](
+https://developer.android.com/jetpack/androidx/releases/window).
+
#### 7.1.1.2\. Screen Aspect Ratio
While there is no restriction to the aspect ratio of the physical display for
@@ -279,7 +306,13 @@
* SHOULD include support for Vulkan 1.1.
-If device implementations include support for Vulkan 1.0, they:
+The Vulkan dEQP tests are partitioned into a number of test lists, each with an
+associated date/version. These are in the Android source tree at
+`external/deqp/android/cts/master/vk-master-YYYY-MM-DD.txt`. A device that
+supports Vulkan at a self-reported level indicates that it can pass the dEQP
+tests in all test lists from this level and earlier.
+
+If device implementations include support for Vulkan 1.0 or higher, they:
* [C-1-1] MUST report the correct integer value with the
`android.hardware.vulkan.level` and `android.hardware.vulkan.version`
@@ -306,6 +339,13 @@
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.
+* [C-1-8] MUST report the maximum version of the Vulkan dEQP Tests
+ supported via the `android.software.vulkan.deqp.level` feature flag.
+* [C-1-9] MUST at least support version `132317953` (from Mar 1st, 2019) as
+ reported in the `android.software.vulkan.deqp.level` feature flag.
+* [C-1-10] MUST pass all Vulkan dEQP Tests in the test lists between
+ version `132317953` and the version specified in the
+ `android.software.vulkan.deqp.level` feature flag.
* [C-SR] Are STRONGLY RECOMMENDED to support the VK_KHR_driver_properties and
VK_GOOGLE_display_timing extensions.
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 66ae318..79a8827 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -186,7 +186,8 @@
(either mouse-like or touch).
* SHOULD support fully independently tracked pointers.
-If device implementations include a touchscreen (single-touch or better), they:
+If device implementations include a touchscreen (single-touch or better) on a
+primary Android-compatible display, they:
* [C-1-1] MUST report `TOUCHSCREEN_FINGER` for the [`Configuration.touchscreen`](https://developer.android.com/reference/android/content/res/Configuration.html#touchscreen)
API field.
@@ -194,18 +195,23 @@
`android.hardware.faketouch` feature flags.
If device implementations include a touchscreen that can track more than
-a single touch, they:
+a single touch on a primary Android-compatible display, they:
-* [C-2-1] MUST report the appropriate feature flags `android.hardware.touchscreen.multitouch`,
+* [C-2-1] MUST report the appropriate feature flags `android.hardware.touchscreen.multitouch`,
`android.hardware.touchscreen.multitouch.distinct`, `android.hardware.touchscreen.multitouch.jazzhand`
corresponding to the type of the specific touchscreen on the device.
-If device implementations do not include a touchscreen (and rely on a pointer
-device only) and meet the fake touch requirements in
+If device implementations rely on an external input device such as mouse or
+trackball (i.e. not directly touching the screen) for input on a primary
+Android-compatible display and meet the fake touch requirements in
[section 7.2.5](#7_2_5_fake_touch_input), they:
* [C-3-1] MUST NOT report any feature flag starting with
-`android.hardware.touchscreen` and MUST report only `android.hardware.faketouch`.
+`android.hardware.touchscreen`.
+* [C-3-2] MUST report only `android.hardware.faketouch`.
+* [C-3-3] MUST report `TOUCHSCREEN_NOTOUCH` for the
+[`Configuration.touchscreen`](https://developer.android.com/reference/android/content/res/Configuration.html#touchscreen)
+API field.
### 7.2.5\. Fake Touch Input
@@ -247,8 +253,6 @@
* [C-1-6] MUST support pointer down then allow users to quickly move the
object to a different position on the screen and then pointer up on the screen,
which allows users to fling an object on the screen.
-* [C-1-7] MUST report `TOUCHSCREEN_NOTOUCH` for the [`Configuration.touchscreen`](https://developer.android.com/reference/android/content/res/Configuration.html#touchscreen)
-API field.
If device implementations declare support for
`android.hardware.faketouch.multitouch.distinct`, they:
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 12fa21d..3c145c3 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -33,15 +33,6 @@
* [C-1-3] MUST report the first sensor sample within 400 milliseconds + 2 *
sample_time of the sensor being activated. It is acceptable for this sample to
have an accuracy of 0.
-* [SR] SHOULD [report the event time](
-http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp)
-in nanoseconds as defined in the Android SDK documentation, representing the
-time the event happened and synchronized with the
-SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are
-**STRONGLY RECOMMENDED** to meet these requirements so they will be able to
-upgrade to the future platform releases where this might become a REQUIRED
-component. The synchronization error SHOULD be below 100 milliseconds.
-
* [C-1-4] For any API indicated by the Android SDK documentation to be a
[continuous sensor](
https://source.android.com/devices/sensors/report-modes.html#continuous),
@@ -49,10 +40,17 @@
periodic data samples that SHOULD have a jitter below 3%,
where jitter is defined as the standard deviation of the difference of the
reported timestamp values between consecutive events.
-
* [C-1-5] MUST ensure that the sensor event stream
MUST NOT prevent the device CPU from entering a suspend state or waking up
from a suspend state.
+* [C-1-6] MUST [report the event time](
+http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp)
+in nanoseconds as defined in the Android SDK documentation, representing the
+time the event happened and synchronized with the
+SystemClock.elapsedRealtimeNano() clock.
+* [C-SR] Are STRONGLY RECOMMENDED to have timestamp synchronization error
+below 100 milliseconds, and SHOULD have timestamp synchronization error below 1
+millisecond.
* When several sensors are activated, the power consumption SHOULD NOT exceed
the sum of the individual sensor’s reported power consumption.
@@ -62,6 +60,13 @@
authoritative.
+If device implementations include a particular sensor type that has a
+corresponding API for third-party developers, they:
+
+* [C-1-6] MUST set a non-zero resolution for all sensors, and report the value
+ via the [`Sensor.getResolution()`](https://developer.android.com/reference/android/hardware/Sensor#getResolution%28%29)
+ API method.
+
Some sensor types are composite, meaning they can be derived from data provided
by one or more other sensors. (Examples include the orientation sensor and the
linear acceleration sensor.)
@@ -79,6 +84,30 @@
https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary).
+If device implementations include a particular sensor type that has a
+corresponding API for third-party developers and the sensor only reports one
+value, then device implementations:
+
+* [C-3-1] MUST set the resolution to 1 for the sensor and report the value
+ via the [`Sensor.getResolution()`](https://developer.android.com/reference/android/hardware/Sensor#getResolution%28%29)
+ API method.
+
+If device implementations include a particular sensor type which supports
+[SensorAdditionalInfo#TYPE_VEC3_CALIBRATION](https://developer.android.com/reference/android/hardware/SensorAdditionalInfo#TYPE_VEC3_CALIBRATION)
+and the sensor is exposed to third-party developers, they:
+
+* [C-4-1] MUST NOT include any fixed, factory-determined calibration
+ parameters in the data provided.
+
+If device implementations include a combination of 3-axis accelerometer, a
+3-axis gyroscope sensor, or a magnetometer sensor, they are:
+
+* [C-SR] STRONGLY RECOMMENDED to ensure the accelerometer, gyroscope and
+ magnetometer have a fixed relative position, such that if the device is
+ transformable (e.g. foldable), the sensor axes remain aligned and consistent
+ with the sensor coordinate system throughout all possible device
+ transformation states.
+
### 7.3.1\. Accelerometer
Device implementations:
@@ -168,10 +197,9 @@
samples collected over a period of at least 3 seconds at the fastest sampling
rate, no greater than 1.5 µT; SHOULD have a standard deviation no greater than
0.5 µT.
-* SHOULD implement `TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor.
-* [SR] Existing and new Android devices are STRONGLY RECOMMENDED to implement the
- `TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor.
-
+* [C-SR] Are STRONGLY RECOMMENDED to implement
+ [`TYPE_MAGNETIC_FIELD_UNCALIBRATED`](https://developer.android.com/reference/android/hardware/Sensor#STRING_TYPE_MAGNETIC_FIELD_UNCALIBRATED)
+ sensor.
If device implementations include a 3-axis magnetometer, an accelerometer
sensor, and a 3-axis gyroscope sensor, they:
@@ -186,7 +214,8 @@
`TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor, they:
* [C-3-1] MUST consume less than 10 mW.
-* SHOULD consume less than 3 mW when the sensor is registered for batch mode at 10 Hz.
+* SHOULD consume less than 3 mW when the sensor is registered for batch mode
+at 10 Hz.
### 7.3.3\. GPS
@@ -247,8 +276,7 @@
Device implementations:
-* [C-SR] Are STRONGLY RECOMMENDED to include a gyroscope sensor unless a
-3-axis accelerometer is also included.
+* [C-SR] Are STRONGLY RECOMMENDED to include a gyroscope sensor.
If device implementations include a 3-axis gyroscope, they:
@@ -271,8 +299,8 @@
when device is stationary at room temperature.
* SHOULD report events up to at least 200 Hz.
-If device implementations include a 3-axis gyroscope, an accelerometer sensor and a
-magnetometer sensor, they:
+If device implementations include a 3-axis gyroscope, an accelerometer sensor
+and a magnetometer sensor, they:
* [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
@@ -305,22 +333,19 @@
### 7.3.6\. Thermometer
-Device implementations:
-
-* MAY include an ambient thermometer (temperature sensor).
-* MAY but SHOULD NOT include a CPU temperature sensor.
-
If device implementations include an ambient thermometer (temperature sensor),
they:
-* [C-1-1] MUST be defined as `SENSOR_TYPE_AMBIENT_TEMPERATURE` and MUST
- measure the ambient (room/vehicle cabin) temperature from where the user
- is interacting with the device in degrees Celsius.
-* [C-1-2] MUST be defined as `SENSOR_TYPE_TEMPERATURE`.
-* [C-1-3] MUST measure the temperature of the device CPU.
-* [C-1-4] MUST NOT measure any other temperature.
+* [C-1-1] MUST define [`SENSOR_TYPE_AMBIENT_TEMPERATURE`](https://developer.android.com/reference/android/hardware/Sensor#TYPE_AMBIENT_TEMPERATURE)
+ for the ambient temperature sensor and the sensor MUST measure the ambient
+ (room/vehicle cabin) temperature from where the user is interacting with the
+ device in degrees Celsius.
-Note the `SENSOR_TYPE_TEMPERATURE` sensor type was deprecated in Android 4.0.
+If device implementations include a thermometer sensor that measures a
+temperature other than ambient temperature, such as CPU temperature, they:
+
+* [C-2-1] MUST NOT define [`SENSOR_TYPE_AMBIENT_TEMPERATURE`](https://developer.android.com/reference/android/hardware/Sensor#TYPE_AMBIENT_TEMPERATURE)
+ for the temperature sensor.
### 7.3.7\. Photometer
@@ -353,8 +378,9 @@
they:
* [C-2-1] MUST have a `TYPE_ACCELEROMETER` sensor which:
- * 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 range between at least -8g and +8g, and is
+ STRONGLY RECOMMENDED to 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; SHOULD
@@ -497,48 +523,81 @@
* SHOULD include a biometric sensor
-Biometric sensors can be classified as **Strong**, **Weak**, or **Convenience**
+Biometric sensors can be classified as **Class 3** (formerly **Strong**),
+**Class 2** (formerly **Weak**), or **Class 1** (formerly **Convenience**)
based on their spoof and imposter acceptance rates, and on the security of the
biometric pipeline. This classification determines the capabilities the
biometric sensor has to interface with the platform and with third-party
-applications. Sensors are classified as **Convenience** by default, and need
+applications. Sensors are classified as **Class 1** by default, and need
to meet additional requirements as detailed below if they wish to be classified
-as either **Weak** or **Strong**. Both **Weak** and **Strong** biometrics get
-additional capabilities as detailed below.
+as either **Class 2** or **Class 3**. Both **Class 2** and **Class 3**
+biometrics get additional capabilities as detailed below.
-
-To make a biometric sensor available to third-party applications, device
-implementations:
-
-* [C-0-1] MUST meet the requirements for **Strong** or **Weak** biometric as
- defined in this document.
-
-
-To allow access to keystore keys to third-party applications,
-device implementations:
-
-* [C-0-2] MUST meet the requirements for **Strong** as defined in this
- document.
-
-Additionally:
-
-* [C-0-3] MUST be paired with an explicit confirm action (e.g. a button press)
- if that **Strong** biometric is passive (e.g. face or iris where no
- explicit signal of the user's 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 device implementations wish to treat a biometric sensor as **Convenience**,
+If device implementations make a biometric sensor available to third-party
+applications via [android.hardware.biometrics.BiometricManager](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager),
+[android.hardware.biometrics.BiometricPrompt](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt),
+and [android.provider.Settings.ACTION_BIOMETRIC_ENROLL](https://developer.android.com/reference/android/provider/Settings#ACTION_BIOMETRIC_ENROLL),
they:
+* [C-4-1] MUST meet the requirements for **Class 3** or **Class 2** biometric
+ as defined in this document.
+* [C-4-2] MUST recognize and honor each parameter name defined as a constant
+ in the [Authenticators](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators)
+ class and any combinations thereof.
+ Conversely, MUST NOT honor or recognize integer constants passed to the
+ [canAuthenticate(int)](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate%28int%29)
+ and [setAllowedAuthenticators(int)](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setAllowedAuthenticators%28int%29)
+ methods other than those documented as public constants in
+ [Authenticators](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators)
+ and any combinations thereof.
+* [C-4-3] MUST implement the [ACTION_BIOMETRIC_ENROLL](https://developer.android.com/reference/android/provider/Settings#ACTION_BIOMETRIC_ENROLL)
+ action on devices that have either **Class 3** or **Class 2** biometrics.
+ This action MUST only present the enrollment entry points for **Class 3**
+ or **Class 2** biometrics.
+
+If device implementations support passive biometrics, they:
+
+* [C-5-1] MUST by default require an additional confirmation step
+ (e.g. a button press).
+* [C-SR] Are STRONGLY RECOMMENDED to have a setting to allow users to
+ override application preference and always require accompanying
+ confirmation step.
+* [C-SR] Are STRONGLY RECOMMENDED to have the confirm action 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.
+* [C-5-2] MUST additionally implement an implicit authentication flow
+ (without confirmation step) corresponding to
+ [setConfirmationRequired(boolean)](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setConfirmationRequired%28boolean%29),
+ which applications can set to utilize for sign-in flows.
+
+If device implementations have multiple biometric sensors, they:
+
+* [C-SR] Are STRONGLY RECOMMENDED to require only one biometric be confirmed
+ per authentication (e.g. if both fingerprint and face sensors are available
+ on the device, [onAuthenticationSucceeded](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.AuthenticationCallback.html#onAuthenticationSucceeded%28android.hardware.biometrics.BiometricPrompt.AuthenticationResult%29)
+ should be sent after any one of them is confirmed).
+
+In order for device implementations to allow access to keystore keys to
+third-party applications, they:
+
+* [C-6-1] MUST meet the requirements for **Class 3** as defined in this
+ section below.
+* [C-6-2] MUST present only **Class 3** biometrics when the authentication
+ requires [BIOMETRIC_STRONG](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators#BIOMETRIC_STRONG),
+ or the authentication is invoked with a
+ [CryptoObject](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.CryptoObject).
+
+If device implementations wish to treat a biometric sensor as **Class 1**
+(formerly **Convenience**), they:
+
* [C-1-1] MUST have a false acceptance rate less than 0.002%.
* [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%.
+ spoof and imposter acceptance rates are higher than 7% as measured by the
+ [Android Biometrics Test Protocols](https://source.android.com/security/biometric/measure).
* [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 ([`BIOMETRIC_ACQUIRED_GOOD`](
@@ -571,29 +630,33 @@
* 3 failed biometric authentication attempts.
* The idle timeout period and the failed authentication count is reset
after any successful confirmation of the device credentials.
+* [C-SR] Are STRONGLY RECOMMENDED to use the logic in the framework provided
+ by the Android Open Source Project to enforce constraints specified in
+ [C-1-7] and [C-1-8] for new devices.
* [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.
-If device implementations wish to treat a biometric sensor as **Weak**, they:
+If device implementations wish to treat a biometric sensor as **Class 2**
+(formerly **Weak**), they:
-* [C-2-1] MUST meet all requirements for **Convenience** above, except
- for [C-1-2].
-* [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%.
-* [C-2-3] MUST have a hardware-backed keystore implementation, and perform the
- biometric matching in an isolated execution environment outside Android user
- or kernel space, such as the Trusted Execution Environment (TEE), or on a
- chip with a secure channel to the isolated execution environment.
+* [C-2-1] MUST meet all requirements for **Class 1** above.
+* [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%
+ as measured by the [Android Biometrics Test Protocols](https://source.android.com/security/biometric/measure).
+* [C-2-3] MUST perform the
+ biometric matching in an isolated execution environment outside Android
+ user or kernel space, such as the Trusted Execution Environment (TEE), or
+ on a chip with a secure channel to the isolated execution environment.
* [C-2-4] MUST have all identifiable data encrypted and cryptographically
authenticated such that they cannot be acquired, read or altered outside of
the isolated execution environment or a chip with a secure channel to the
isolated execution environment as documented in the [implementation
guidelines](https://source.android.com/security/biometric#hal-implementation)
on the Android Open Source Project site.
-* [C-2-5] For camera based biometrics, while biometric based authentication or
- enrollment is happening:
+* [C-2-5] For camera based biometrics, while biometric based authentication
+ or enrollment is happening:
* MUST operate the camera in a mode that prevents camera frames from
being read or altered outside the isolated execution environment or a chip
with a secure channel to the isolated execution environment.
@@ -609,20 +672,27 @@
system or kernel compromise cannot allow data to be directly injected to
falsely authenticate as the user.
- If device implementations are already launched on an earlier Android version
- and cannot meet the requirement C-2-8 through a system software update, they
- MAY be exempted from the requirement.
+ If device implementations are already launched on an earlier Android
+ version and cannot meet the requirement C-2-8 through a system software
+ update, they MAY be exempted from the requirement.
-If device implementations wish to treat a biometric sensor as **Strong**, they:
+* [C-SR] Are STRONGLY RECOMMENDED to include liveness detection for all
+ biometric modalities and attention detection for Face biometrics.
-* [C-3-1] MUST meet all the requirements of **Weak** above. Upgrading
- devices from an earlier Android version is not exempted from C-2-7.
-* [C-3-2] MUST have a spoof and imposter acceptance rate not higher than 7%.
-* [C-3-3] MUST challenge the user for the recommended primary
+If device implementations wish to treat a biometric sensor as **Class 3**
+(formerly **Strong**), they:
+
+* [C-3-1] MUST meet all the requirements of **Class 2** above, except for
+ [C-1-7] and [C-1-8]. Upgrading devices from an earlier Android version
+ are not exempted from C-2-7.
+* [C-3-2] MUST have a hardware-backed keystore implementation.
+* [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%
+ as measured by the [Android Biometrics Test Protocols](https://source.android.com/security/biometric/measure).
+* [C-3-4] MUST challenge the user for the recommended primary
authentication (e.g. PIN, pattern, password) once every 72 hours
or less.
-## 7.3.12\. Pose Sensor
+### 7.3.12\. Pose Sensor
Device implementations:
@@ -634,3 +704,13 @@
https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_POSE_6DOF)
sensor.
* [C-1-2] MUST be more accurate than the rotation vector alone.
+
+### 7.3.13\. Hinge Angle Sensor
+
+If device implementations support a hinge angle sensor, they:
+
+* [C-1-1] MUST implement and report [`TYPE_HINGLE_ANGLE`](https://developer.android.com/reference/android/hardware/Sensor#STRING_TYPE_HINGE_ANGLE).
+* [C-1-2] MUST support at least two readings between 0 and 360 degrees
+ (inclusive i.e including 0 and 360 degrees).
+* [C-1-3] MUST return a [wakeup](https://developer.android.com/reference/android/hardware/Sensor.html#isWakeUpSensor%28%29)
+ sensor for [`getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)`](https://developer.android.com/reference/android/hardware/SensorManager#getDefaultSensor%28int%29).
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index af33139..f1aa803 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -312,10 +312,7 @@
If device implementations include support for Wi-Fi Easy Connect and expose the
functionality to third-party apps, they:
-* [C-1-1] MUST implement the [`Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI`](
- https://developer.android.com/reference/android/provider/Settings.html#ACTION_PROCESS_WIFI_EASY_CONNECT_URI)
- Intent APIs as described in the SDK documentation.
-* [C-1-2] MUST have the [WifiManager#isEasyConnectSupported\(\)](
+* [C-1-1] MUST have the [WifiManager#isEasyConnectSupported\(\)](
https://developer.android.com/reference/android/net/wifi/WifiManager.html#isEasyConnectSupported\(\))
method return `true`.
@@ -363,17 +360,16 @@
* [C-3-4] MUST report the correct value for
`BluetoothAdapter.isMultipleAdvertisementSupported()` to indicate
whether Low Energy Advertising is supported.
+* [C-3-5] MUST implement a Resolvable Private Address (RPA) timeout no longer
+ than 15 minutes and rotate the address at timeout to protect user privacy.
+ To prevent timing attacks, timeout intervals MUST also be randomized
+ between 5 and 15 minutes.
* SHOULD support offloading of the filtering logic to the bluetooth chipset
when implementing the [ScanFilter API](
https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html).
* SHOULD support offloading of the batched scanning to the bluetooth chipset.
* SHOULD support multi advertisement with at least 4 slots.
-
-* [SR] STRONGLY RECOMMENDED to implement a Resolvable Private Address (RPA)
-timeout no longer than 15 minutes and rotate the address at timeout to protect
-user privacy.
-
If device implementations support Bluetooth LE and use Bluetooth LE for
location scanning, they:
@@ -468,8 +464,9 @@
method. Note that this is not a standard Android feature and as such does not
appear as a constant in the `android.content.pm.PackageManager` class.
-### 7.4.5\. Minimum Network Capability
+### 7.4.5\. Networking protocols and APIs
+#### 7.4.5.1\. Minimum Network Capability
Device implementations:
* [C-0-1] MUST include support for one or more forms of
@@ -481,6 +478,11 @@
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.
+
+#### 7.4.5.2\. IPv6
+
+Device implementations:
+
* [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`
@@ -500,7 +502,7 @@
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.
+network and is visible as the source ip and port to internet (web) servers.
The required level of IPv6 support depends on the network type, as shown in
@@ -512,19 +514,53 @@
If device implementations support Ethernet, they:
-* [C-2-1] MUST support dual-stack operation on Ethernet.
+* [C-2-1] MUST support dual-stack and IPv6-only operation on
+ Ethernet.
If device implementations support Cellular data, they:
-* SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
-cellular.
+* [C-3-1] MUST support IPv6 operation (IPv6-only and possibly dual-stack) on
+ cellular.
If device implementations support more than one network type (e.g., Wi-Fi
and cellular data), they:
-* [C-3-1] MUST simultaneously meet the above requirements on each network
-when the device is simultaneously connected to more than one network type.
+* [C-4-1] MUST simultaneously meet the above requirements on each network
+ when the device is simultaneously connected to more than one network type.
+#### 7.4.5.3\. Captive Portals
+
+A captive portal refers to a network that requires sign-in in order to
+obtain internet access.
+
+
+If device implementations provide a complete implementation of the
+[`android.webkit.Webview API`](https://developer.android.com/reference/android/webkit/WebView.html),
+they:
+
+* [C-1-1] MUST provide a captive portal application to handle the intent
+ [`ACTION_CAPTIVE_PORTAL_SIGN_IN`](https://developer.android.com/reference/android/net/ConnectivityManager#ACTION_CAPTIVE_PORTAL_SIGN_IN)
+ and display the captive portal login page, by sending that intent, on
+ call to the System API
+ `ConnectivityManager#startCaptivePortalApp(Network, Bundle)`.
+* [C-1-2] MUST perform detection of captive portals and support login
+ through the captive portal application when the device is connected
+ to any network type, including cellular/mobile network, WiFi, Ethernet
+ or Bluetooth.
+* [C-1-3] MUST support logging in to captive portals using cleartext DNS
+ when the device is configured to use private DNS strict mode.
+* [C-1-4] MUST use encrypted DNS as per the SDK documentation for
+ [`android.net.LinkProperties.getPrivateDnsServerName`](https://developer.android.com/reference/android/net/LinkProperties.html#getPrivateDnsServerName%28%29)
+ and [`android.net.LinkProperties.isPrivateDnsActive`](https://developer.android.com/reference/android/net/LinkProperties#isPrivateDnsActive%28%29)
+ for all network traffic that is not explicitly communicating with the
+ captive portal.
+* [C-1-5] MUST ensure that, while the user is logging in to a captive
+ portal, the default network used by applications (as returned by
+ [`ConnectivityManager.getActiveNetwork`](https://developer.android.com/reference/android/net/ConnectivityManager#getActiveNetwork%28%29),
+ [`ConnectivityManager.registerDefaultNetworkCallback`](https://developer.android.com/reference/android/net/ConnectivityManager#registerDefaultNetworkCallback%28android.net.ConnectivityManager.NetworkCallback%29),
+ and used by default by Java networking APIs such as java.net.Socket,
+ and native APIs such as connect()) is any other available network
+ that provides internet access, if available.
### 7.4.6\. Sync Settings
@@ -546,11 +582,6 @@
* [C-1-1] MUST support all the APIs in the `ConnectivityManager`
class as described in the [SDK documentation](
https://developer.android.com/training/basics/network-ops/data-saver.html)
-* [C-1-2] MUST provide a user interface in the settings, that handles the
- [`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](
- https://developer.android.com/reference/android/provider/Settings.html#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
- intent, allowing users to add applications to or remove applications
- from the whitelist.
If device implementations do not provide the data saver mode, they:
@@ -559,15 +590,22 @@
https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus%28%29)
* [C-2-2] MUST NOT broadcast
`ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED`.
-* [C-2-3] MUST have an activity that handles the
-`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`
- intent but MAY implement it as a no-op.
### 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:
+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 third-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.
+* [C-1-1] MUST enumerate the available secure elements readers via
+ [`android.se.omapi.SEService.getReaders()`](https://developer.android.com/reference/android/se/omapi/SEService#getReaders%28%29) API.
+
+* [C-1-2] MUST declare the correct feature flags via
+ [`android.hardware.se.omapi.uicc`](
+ https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_SE_OMAPI_UICC)
+ for the device with UICC-based secure elements,
+ [`android.hardware.se.omapi.ese`](
+ https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_SE_OMAPI_ESE)
+ for the device with eSE-based secure elements and
+ [`android.hardware.se.omapi.sd`](
+ https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_SE_OMAPI_SD)
+ for the device with SD-based secure elements.
\ 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 3b1339f..2f7bad0 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -207,6 +207,11 @@
[`android.hardware.Camera`](https://developer.android.com/reference/android/hardware/Camera)
API also accessible via the [`android.hardware.camera2`](https://developer.android.com/reference/android/hardware/camera2/package-summary)
API.
+* [C-0-12] MUST ensure that the facial appearance is NOT altered, including
+ but not limited to altering facial geometry, facial skin tone, or facial
+ skin smoothening for any [`android.hardware.camera2`](https://developer.android.com/reference/android/hardware/camera2/package-summary)
+ or [`android.hardware.Camera`](https://developer.android.com/reference/android/hardware/Camera)
+ API.
* [C-SR] For devices with multiple RGB cameras facing in the same direction,
are STRONGLY RECOMMENDED to support a logical camera device that lists
capability
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index b3f4a41..4fb2645 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -24,30 +24,12 @@
* [C-0-3] MUST mount the application shared storage directly on the Linux path
`sdcard` or include a Linux symbolic link from `sdcard` to the actual mount
point.
-* [C-0-4] MUST enforce the `android.permission.WRITE_EXTERNAL_STORAGE`
- permission on this shared storage as documented in the SDK.
-* [C-0-5] MUST enable [scoped storage](
+* [C-0-4] MUST enable [scoped storage](
https://developer.android.com/privacy/scoped-storage) by default for all
- apps targeting API level 29 or above, except in the following situations:
- * when the app was installed before the device upgraded to API level 29,
- regardless of the target API of the app.
- * when the app has requested `android:requestLegacyExternalStorage="true"`
+ apps targeting API level 29 or above, except in the following situation:
+ * When the app has requested `android:requestLegacyExternalStorage="true"`
in their manifest.
- * when the app is granted the `android.permission.WRITE_MEDIA_STORAGE`
- permission.
-* [C-0-6] MUST enforce that apps with scoped storage enabled have no direct
- filesystem access to files outside of their application-specific
- directories, as returned by [`Context`](
- https://developer.android.com/reference/android/content/Context.html) API
- methods such as [`Context.getExternalFilesDirs()`](
- https://developer.android.com/reference/android/content/Context.html#getExternalFilesDirs%28java.lang.String%29),
- [`Context.getExternalCacheDirs()`](
- https://developer.android.com/reference/android/content/Context.html#getExternalCacheDirs%28%29),
- [`Context.getExternalMediaDirs()`](
- https://developer.android.com/reference/android/content/Context.html#getExternalMediaDirs%28%29),
- and
- [`Context.getObbDirs()`](https://developer.android.com/reference/android/content/Context.html#getObbDirs%28%29) methods.
-* [C-0-7] MUST redact location metadata, such as GPS Exif tags, stored in
+* [C-0-5] MUST redact location metadata, such as GPS Exif tags, stored in
media files when those files are accessed through `MediaStore`, except when
the calling app holds the `ACCESS_MEDIA_LOCATION` permission.
@@ -74,23 +56,6 @@
storage.
* MAY share the storage space with the application private data.
-If device implementations include multiple shared storage paths (such
-as both an SD card slot and shared internal storage), they:
-
-* [C-2-1] MUST allow only pre-installed and privileged Android
- applications with the `WRITE_MEDIA_STORAGE` permission to write to the
- secondary external storage, except when writing to their package-specific
- directories or within the `URI` returned by firing the
- `ACTION_OPEN_DOCUMENT_TREE` intent.
-* [C-2-2] MUST require that the direct access associated with the
- `android.permission.WRITE_MEDIA_STORAGE` permission is only given to
- user-visible apps when the `android.permission.WRITE_EXTERNAL_STORAGE`
- permission is also granted.
-* [SR] STRONGLY RECOMMENDED that pre-installed and privileged Android
- applications use public APIs such as `MediaStore` to interact with storage
- devices, instead of relying on the direct access granted by
- `android.permission.WRITE_MEDIA_STORAGE`.
-
If device implementations have a USB port with USB peripheral mode support,
they:
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 488d301..84eced9 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -1,8 +1,9 @@
## 8.3\. Power-Saving Modes
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:
+that are included in AOSP (e.g. App Standby Bucket, Doze) or extend the features
+that do not apply harder restrictions than [the Rare App Standby Bucket](
+https://developer.android.com/topic/performance/power/power-details), 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
@@ -26,6 +27,12 @@
* [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all
Apps that are exempted from App Standby and Doze power-saving modes.
+If device implementations extend power management features that are included
+in AOSP and that extension applies more stringent restrictions than
+[the Rare App Standby Bucket](
+https://developer.android.com/topic/performance/power/power-details), refer to
+[section 3.5.1](#3_5_api-behavioral-compatibility).
+
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).
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index cba1739..b3f6dea 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -70,6 +70,24 @@
Device implementations:
+* [C-0-3] MUST support cryptographically verifying file content against a
+ trusted key without reading the whole file.
+* [C-0-4] MUST NOT allow the read requests on a protected file to succeed
+ when the read content do not verify against a trusted key.
+* [C-0-5] MUST enable the above-described cryptographic file verification
+ protection for all files for the package that is installed
+ with trusted signature files as described [here](
+ https://developer.android.com/preview/security/features/apk-verity).
+
+If device implementations are already launched without the ability to verify
+file content against a trusted key on an earlier Android version and can not add
+support for this feature with a system software update, they MAY be exempted
+from the requirement. The upstream Android Open Source project provides a
+preferred implementation of this feature based on the Linux kernel [fs-verity](
+https://www.kernel.org/doc/html/latest/filesystems/fsverity.html) feature.
+
+Device implementations:
+
* [C-R] Are RECOMMENDED to support the [Android Protected Confirmation API](
https://developer.android.com/preview/features/security.html#user-confirmation).
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index fe42b8f..34cf539 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -49,7 +49,9 @@
* [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 timeout up to
- 15 seconds.
+ 15 seconds. Automotive devices, that lock the screen whenever the head unit
+ is turned off or the user is switched, MAY NOT have the Sleep timeout
+ configuration.
### 9.11.1\. Secure Lock Screen and Authentication
@@ -75,13 +77,6 @@
* [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).
-* [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).
If device implementations add or modify the authentication methods to unlock
the lock screen if based on a known secret and use a new authentication
@@ -113,7 +108,8 @@
method:
* [C-4-1] MUST meet all requirements described in [section
- 7.3.10](#7_3_10_biometric_sensors) for **Convenience**.
+ 7.3.10](#7_3_10_biometric_sensors) for **Class 1** (formerly
+ **Convenience**).
* [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
@@ -126,7 +122,8 @@
`KEYGUARD_DISABLE_FACE`, or `KEYGUARD_DISABLE_IRIS`).
If the biometric authentication methods do not meet the requirements
-for **Strong** as described in [section 7.3.10](#7_3_10_biometric_sensors):
+for **Class 3** (formerly **Strong**) 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()`](
@@ -134,9 +131,8 @@
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.
+ authentication (eg: PIN, pattern, password) as described in [C-1-7] and
+ [C-1-8] in [section 7.3.10](#7_3_10_biometric_sensors).
* [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.
@@ -187,6 +183,8 @@
* [C-7-5] MUST NOT store the encryption key or escrow token 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.
+ For Automotive devices, it is not allowed for the escrow token to be stored
+ on any part of the vehicle.
* [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
@@ -195,9 +193,8 @@
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.
+ authentication (eg: PIN, pattern, password) methods as described in
+ [C-1-7] and [C-1-8] in [section 7.3.10](#7_3_10_biometric_sensors).
* [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
constraints listed in C-8 below.
* [C-7-11] MUST NOT allow TrustAgents on primary personal devices
@@ -301,3 +298,40 @@
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.
+
+### 9.11.3\. Identity Credential
+
+The Identity Credential System is defined and achieved by implementing all
+APIs in the
+[`android.security.identity.*`](https://developer.android.com/reference/android/security/identity/package-summary)
+package. These APIs allows app developers to store and retrieve user identity
+documents. Device implementations:
+
+* [C-SR] are STRONGLY RECOMMENDED to implement the Identity Credential
+System.
+
+If device implementations implement the Identity Credential System, they:
+
+* [C-0-1] MUST return non-null for the [IdentityCredentialStore#getInstance()](
+ https://developer.android.com/reference/android/security/identity/IdentityCredentialStore#getInstance%28android.content.Context%29)
+ method.
+
+* [C-0-2] MUST implement the Identity Credential System (e.g. the
+ `android.security.identity.*` APIs) with code communicating with a trusted
+ application in an area that is securely isolated from the code running on
+ the kernel and above. Secure isolation MUST block all potential mechanisms
+ by which kernel or userspace code might access the internal state of the
+ isolated environment, including DMA.
+
+* [C-0-3] The cryptographic operations needed to implement the Identity
+ Credential System (e.g. the `android.security.identity.*` APIs) MUST be
+ performed entirely in the trusted application and private key material MUST
+ never leave the isolated execution environment unless specifically required
+ by higher-level APIs (e.g. the
+ [createEphemeralKeyPair()](https://developer.android.com/reference/android/security/identity/IdentityCredential#createEphemeralKeyPair%28%29)
+ method).
+
+* [C-0-4] The trusted application MUST be implemented in a way such that its
+ security properties are not affected (e.g. credential data is not released unless access
+ control conditions are satisfied, MACs can't be produced for arbitrary
+ data) even if Android is misbehaving or compromised.
diff --git a/9_security-model/9_16_app_data_migration.md b/9_security-model/9_16_app_data_migration.md
new file mode 100644
index 0000000..1d1fdf4
--- /dev/null
+++ b/9_security-model/9_16_app_data_migration.md
@@ -0,0 +1,23 @@
+## 9.16\. Application Data Migration
+
+If device implementations include a capability to migrate data from a device to
+another device and do not limit the application data it copies to what is
+configured by the application developer in the manifest via
+[android:fullBackupContent](https://developer.android.com/guide/topics/data/autobackup#IncludingFiles)
+attribute, they:
+
+* [C-1-1] MUST NOT initiate transfers of application data from
+ devices on which the user has not set a primary authentication as
+ described in [9.11.1 Secure Lock Screen and Authentication](
+ #9_11_1_secure_lock_screen_and_authentication).
+* [C-1-2] MUST securely confirm the primary authentication on the source
+ device and confirm with the user intent to copy the data on the source
+ device before any data is transferred.
+* [C-1-3] MUST use security key attestation to ensure that both the source
+ device and the target device in the device-to-device migration are
+ legitimate Android devices and have a locked bootloader.
+* [C-1-4] MUST only migrate application data to the same application on the
+ target device, with the same package name AND signing certificate.
+* [C-1-5] MUST show an indication that the source device has had data
+ migrated by a device-to-device data migration in the settings menu. A user
+ SHOULD NOT be able to remove this indication.
\ 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 ebb1927..b36e8ba 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -83,26 +83,16 @@
* [C-0-11] Apps holding a `softRestricted` permission MUST get only limited
access and MUST NOT gain full access until whitelisted as described in the
SDK, where full and limited access is defined for each `softRestricted`
- permission (for example, [`WRITE_EXTERNAL_STORAGE`](
- https://developer.android.com/reference/android/Manifest.permission.html#WRITE_EXTERNAL_STORAGE)
- and [`READ_EXTERNAL_STORAGE`](
+ permission (for example, [`READ_EXTERNAL_STORAGE`](
https://developer.android.com/reference/android/Manifest.permission#READ_EXTERNAL_STORAGE)).
-If device implementations include a pre-installed app or wish to allow
-third-party apps to access the usage statistics, they:
+If device implementations provide a user affordance to choose which apps can
+draw on top of other apps with an activity that handles the
+[`ACTION_MANAGE_OVERLAY_PERMISSION`](https://developer.android.com/reference/android/provider/Settings.html#ACTION_MANAGE_OVERLAY_PERMISSION)
+intent, they:
-* [SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant
- or revoke access to the usage stats in response to the
- [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
- https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
- intent for apps that declare the `android.permission.PACKAGE_USAGE_STATS`
- permission.
-
-If device implementations intend to disallow any apps, including pre-installed
-apps, from accessing the usage statistics, they:
-
-* [C-1-1] MUST still have an activity that handles the
- [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
- https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
- intent pattern but MUST implement it as a no-op, that is to have an
- equivalent behavior as when the user is declined for access.
+* [C-2-1] MUST ensure that all activities with intent filters for the
+ [`ACTION_MANAGE_OVERLAY_PERMISSION`](
+ https://developer.android.com/reference/android/provider/Settings.html#ACTION_MANAGE_OVERLAY_PERMISSION)
+ intent have the same UI screen, regardless of the initiating app or any
+ information it provides.
\ No newline at end of file
diff --git a/9_security-model/9_7_security-features.md b/9_security-model/9_7_security-features.md
index 83b03ed..49fa244 100644
--- a/9_security-model/9_7_security-features.md
+++ b/9_security-model/9_7_security-features.md
@@ -76,6 +76,15 @@
additional security-sensitive userspace components as explained in
[CFI](https://source.android.com/devices/tech/debug/cfi) and
[IntSan](https://source.android.com/devices/tech/debug/intsan).
+* [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel
+to prevent uses of uninitialized local variables (`CONFIG_INIT_STACK_ALL` or
+`CONFIG_INIT_STACK_ALL_ZERO`).
+Also, device implementations SHOULD NOT assume the value used by the compiler to
+initialize the locals.
+* [C-SR] Are STRONGLY RECOMMENDED to enable heap initialization in the kernel
+to prevent uses of uninitialized heap allocations
+(`CONFIG_INIT_ON_ALLOC_DEFAULT_ON`) and they SHOULD NOT assume the value used by
+the kernel to initialize those allocations.
If device implementations use a Linux kernel, they:
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index 425290f..b52a613 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -133,6 +133,10 @@
[`Content Capture`](
https://developer.android.com/reference/android/view/contentcapture/package-summary)
API or a similarly capable, proprietary API.
+* Any text or other data sent via the [`TextClassifier API`](https://developer.android.com/reference/android/view/textclassifier/TextClassifier)
+ to the System TextClassifier i.e to the system service to understand
+ the meaning of text, as well as generating predicted next actions based on
+ the text.
If device implementations capture the data above, they:
@@ -202,9 +206,87 @@
of Wi-Fi/Bluetooth scanning for determining location.
* [C-0-3] MUST ensure that the application using Emergency Location Bypass API
[LocationRequest.setLocationSettingsIgnored()] is a user initiated emergency
-session (e.g. dial 911 or text to 911).
+session (e.g. dial 911 or text to 911). For Automotive however, a vehicle MAY
+initiate an emergency session without active user interaction in the case
+a crash/accident is detected (e.g. to satisfy eCall requirements).
* [C-0-4] MUST preserve the Emergency Location Bypass API's ability to
bypass device location settings without changing the settings.
* [C-0-5] MUST schedule a notification that reminds the user after an app in
the background has accessed their location using the
[`ACCESS_BACKGROUND_LOCATION`] permission.
+
+### 9.8.9\. Installed apps
+
+Android apps targeting API level 30 or above cannot see details about other
+installed apps by default (see [Package visibility](
+https://developer.android.com/preview/privacy/package-visibility) in the Android
+SDK documentation).
+
+Device implementations:
+
+* [C-0-1] MUST NOT expose to any app targeting API level 30 or above details
+ about any other installed app, unless the app is already able to see details
+ about the other installed app through the managed APIs. This includes but is
+ not limited to details exposed by any custom APIs added by the device
+ implementer, or accessible via the filesystem.
+
+### 9.8.10\. Connectivity Bug Report
+
+If device implementations generate bug reports using System API
+`BUGREPORT_MODE_TELEPHONY` with BugreportManager, they:
+
+* [C-1-1] MUST obtain user consent every time the System API
+ `BUGREPORT_MODE_TELEPHONY` is called to generate a report and MUST NOT
+ prompt the user to consent to all future requests from the application.
+* [C-1-2] MUST display and obtain explicit user consent when the reports are
+ starting to be generated and MUST NOT return the generated report
+ to the requesting app without explicit user consent.
+* [C-1-3] MUST generate requested reports containing at least the following
+ information:
+ * TelephonyDebugService dump
+ * TelephonyRegistry dump
+ * WifiService dump
+ * ConnectivityService dump
+ * A dump of the calling package's CarrierService instance (if bound)
+ * Radio log buffer
+* [C-1-4] MUST NOT include the following in the generated reports:
+ * Any kind of information unrelated to connectivity debugging.
+ * Any kind of user-installed application traffic logs or detailed profiles
+ of user-installed applications/packages (UIDs are okay, package names
+ are not).
+* MAY include additional information that is not associated with any user
+ identity. (e.g. vendor logs).
+
+If device implementations include additional information (e.g vendor logs) in
+the bug report and that information has privacy/security/battery/storage/memory
+impact, they:
+
+* [C-SR] Are STRONGLY RECOMMENDED to have a developer setting defaulted to
+ disabled. The AOSP meets this by providing the
+ `Enable verbose vendor logging` option in developer settings to include
+ additional device-specific vendor logs in the bug reports.
+
+### 9.8.11\. Data blobs sharing
+
+Android, through [BlobStoreManager](
+https://developer.android.com/reference/android/app/blob/BlobStoreManager)
+allows apps to contribute data blobs to the System to be shared with a selected
+set of apps.
+
+If device implementations support shared data blobs as described in the
+[SDK documentation](https://developer.android.com/reference/android/app/blob/BlobStoreManager),
+they:
+
+ * [C-1-1] MUST NOT share data blobs belonging to apps beyond what they
+ intended to allow (i.e. the scope of default access and the other access
+ modes that can be specified using
+ [BlobStoreManager.session#allowPackageAccess()](
+ https://developer.android.com/reference/android/app/blob/BlobStoreManager.Session#allowPackageAccess%28java.lang.String%2C%2520byte%5B%5D%29),
+ [BlobStoreManager.session#allowSameSignatureAccess()](
+ https://developer.android.com/reference/android/app/blob/BlobStoreManager.Session#allowSameSignatureAccess%28%29),
+ or [BlobStoreManager.session#allowPublicAccess()](
+ https://developer.android.com/reference/android/app/blob/BlobStoreManager.Session#allowPublicAccess%28%29)
+ MUST NOT be modified). The AOSP reference implementation meets these
+ requirements.
+ * [C-1-2] MUST NOT send off device or share with other apps the secure hashes
+ of data blobs (which are used to control access).
\ No newline at end of file
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 55d6f19..cbf4de5 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -32,11 +32,12 @@
the user has completed the out-of-box setup experience.
* [C-0-3] MUST meet the above data storage encryption
requirement via implementing [File Based Encryption](
-https://source.android.com/security/encryption/file-based.html) (FBE).
+https://source.android.com/security/encryption/file-based.html) (FBE) and
+[Metadata Encryption](https://source.android.com/security/encryption/metadata).
-### 9.9.3\. File Based Encryption
+### 9.9.3\. Encryption Methods
-Encrypted devices:
+If device implementations are encrypted, they:
* [C-1-1] MUST boot up without challenging the user for credentials and
allow Direct Boot aware apps to access to the Device Encrypted (DE) storage
@@ -45,26 +46,39 @@
the user has unlocked the device by supplying their credentials
(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 either the user-supplied credentials or a registered escrow key.
-* [C-1-4] MUST use Verified Boot and ensure that DE keys are
-cryptographically bound to the device's hardware root of trust.
-* [C-1-5] MUST encrypt file contents using AES-256-XTS or
-Adiantum. AES-256-XTS refers to the Advanced Encryption Standard with a
-256-bit cipher key length, operated in XTS mode; the full length of the key
-is 512 bits. Adiantum refers to Adiantum-XChaCha12-AES, as specified at
-https://github.com/google/adiantum.
+* [C-1-13] MUST NOT offer any method to unlock the CE protected storage
+without either the user-supplied credentials, a registered escrow key or a
+resume on reboot implementation meeting the requirements in
+[section 9.9.4](#9_9_4_resume_on_reboot).
+* [C-1-4] MUST use Verified Boot.
+* [C-1-5] MUST encrypt file contents and filesystem metadata using
+AES-256-XTS or Adiantum. AES-256-XTS refers to the Advanced Encryption Standard
+with a 256-bit cipher key length, operated in XTS mode; the full length of the
+key is 512 bits. Adiantum refers to Adiantum-XChaCha12-AES, as specified at
+https://github.com/google/adiantum. Filesystem metadata is data such as file
+sizes, ownership, modes, and extended attributes (xattrs).
* [C-1-6] MUST encrypt file names using AES-256-CBC-CTS
or Adiantum.
-* [C-1-12] MUST use AES-256-XTS for file contents and AES-256-CBC-CTS for
-file names (instead of Adiantum) if the device has Advanced Encryption Standard
-(AES) instructions. AES instructions are ARMv8 Cryptography Extensions on
-ARM-based devices, or AES-NI on x86-based devices. If the device does not
-have AES instructions, the device MAY use Adiantum.
+* [C-1-12] If the device has Advanced Encryption Standard (AES)
+instructions (such as ARMv8 Cryptography Extensions on ARM-based devices, or
+AES-NI on x86-based devices) then the AES-based options above for file name,
+file contents, and filesystem metadata encryption MUST be used, not Adiantum.
+* [C-1-13] MUST use a cryptographically strong and non-reversible key
+derivation function (e.g. HKDF-SHA512) to derive any needed subkeys (e.g.
+per-file keys) from the CE and DE keys. "Cryptographically strong and
+non-reversible" means that the key derivation function has a security strength
+of at least 256 bits and behaves as a [pseudorandom function
+family](https://en.wikipedia.org/w/index.php?title=Pseudorandom_function_family&oldid=928163524)
+over its inputs.
+* [C-1-14] MUST NOT use the same File Based Encryption (FBE) keys or subkeys
+for different cryptographic purposes (e.g. for both encryption and key
+derivation, or for two different encryption algorithms).
-* The keys protecting CE and DE storage areas:
+* The keys protecting CE and DE storage areas and filesystem metadata:
* [C-1-7] MUST be cryptographically bound to a hardware-backed Keystore.
+ This keystore MUST be bound to Verified Boot and the device's hardware
+ root of trust.
* [C-1-8] CE keys MUST be bound to a user's lock screen credentials.
* [C-1-9] CE keys MUST be bound to a default passcode when the user has
not specified lock screen credentials.
@@ -72,12 +86,44 @@
key matches any other user's CE or DE keys.
* [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
modes.
-* [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 preinstalled essential apps (e.g. Alarm, Phone, Messenger)
Direct Boot aware.
The upstream Android Open Source project provides a preferred implementation of
-this feature based on the Linux kernel "fscrypt" encryption feature.
+File Based Encryption based on the Linux kernel "fscrypt" encryption feature,
+and of Metadata Encryption based on the Linux kernel "dm-default-key" feature.
+
+### 9.9.4\. Resume on Reboot
+
+Resume on Reboot allows unlocking the CE storage of all apps, including those
+that do not yet support Direct Boot, after a reboot initiated by an OTA. This
+feature enables users to receive notifications from installed apps after the
+reboot.
+
+An implementation of Resume-on-Reboot must continue to ensure that when a
+device falls into an attacker’s hands, it is extremely difficult for that
+attacker to recover the user’s CE-encrypted data, even if the device is powered
+on, CE storage is unlocked, and the user has unlocked the device after receiving
+an OTA. For insider attack resistance, we also assume the attacker gains access
+to broadcast cryptographic signing keys.
+
+Specifically:
+
+* [C-0-1] CE storage MUST NOT be readable even for the attacker who physically has
+the device and then has these capabilities and limitations:
+
+ * Can use the signing key of any vendor or company to sign arbitrary
+ messages.
+ * Can cause an OTA to be received by the device.
+ * Can modify the operation of any hardware (AP, flash etc) except as
+ detailed below, but such modification involves a delay of at least an
+ hour and a power cycle that destroys RAM contents.
+ * Cannot modify the operation of tamper-resistant hardware (eg Titan M).
+ * Cannot read the RAM of the live device.
+ * Cannot obtain the user’s credential (PIN, pattern, password) or
+ otherwise cause it to be entered.
+
+By way of example, a device implementation that implements and complies with all
+of the descriptions found [here](https://source.android.com/devices/tech/ota/resume-on-reboot)
+will be compliant with [C-0-1].
