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

upload android base code part4

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

2
android/compatibility/cdd/3_software/3_0_intro.md Normal file
View file

@ -0,0 +1,2 @@
# 3\. Software

38
android/compatibility/cdd/3_software/3_10_accessibility.md Normal file
View file

@ -0,0 +1,38 @@
## 3.10\. Accessibility
Android provides an accessibility layer that helps users with disabilities to
navigate their devices more easily. In addition, Android provides platform APIs
that enable accessibility service implementations to receive callbacks for user
and system events and generate alternate feedback mechanisms, such as
text-to-speech, haptic feedback, and trackball/d-pad navigation.
If device implementations support third-party accessibility services, they:
* [C-1-1] MUST provide an implementation of the Android accessibility
framework as described in the [accessibility APIs](
http://developer.android.com/reference/android/view/accessibility/package-summary.html)
SDK documentation.
* [C-1-2] MUST generate accessibility events and deliver the appropriate
`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 preloaded 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`](
https://developer.android.com/reference/android/accessibilityservice/AccessibilityServiceInfo.html#FLAG%5FREQUEST%5FACCESSIBILITY%5FBUTTON)
. Note that for device implementations with no system navigation bar, this
requirement is not applicable, but device implementations SHOULD provide a
user affordance to control these accessibility services.
If device implementations include preloaded accessibility services, they:
* [C-2-1] MUST implement these preloaded accessibility services as [Direct Boot aware]
(https://developer.android.com/reference/android/content/pm/ComponentInfo.html#directBootAware)
apps when the data storage is encrypted with File Based Encryption (FBE).
* SHOULD provide a mechanism in the out-of-box setup flow for users to enable
relevant accessibility services, as well as options to adjust the font size,
display size and magnification gestures.

18
android/compatibility/cdd/3_software/3_11_text-to-speech.md Normal file
View file

@ -0,0 +1,18 @@
## 3.11\. Text-to-Speech
Android includes APIs that allow applications to make use of text-to-speech
(TTS) services and allows service providers to provide implementations of TTS
services.
If device implementations reporting the feature android.hardware.audio.output,
they:
* [C-1-1] MUST support the [Android TTS framework](
http://developer.android.com/reference/android/speech/tts/package-summary.html)
APIs.
If device implementations support installation of third-party TTS engines, they:
* [C-2-1] MUST provide user affordance to allow the user to select a TTS
engine for use at system level.

105
android/compatibility/cdd/3_software/3_12_tv-input-framework.md Normal file
View file

@ -0,0 +1,105 @@
## 3.12\. TV Input Framework
The [Android Television Input Framework (TIF)](
http://source.android.com/devices/tv/index.html) simplifies the delivery of live
content to Android Television devices. TIF provides a standard API to create
input modules that control Android Television devices.
* [T-0-1] Android Television device implementations MUST support TV Input
Framework.
If device implementations support TIF, they:
* [C-1-1] MUST declare the platform feature `android.software.live_tv`.
* [C-1-2] MUST preload a TV application (TV App) and meet all requirements
described in [section 3.12.1](#3_12_tv-input-framework).
### 3.12.1\. TV App
If device implementations support TIF:
* [C-1-1] The TV App MUST provide facilities to install and use [TV Channels](
http://developer.android.com/reference/android/media/tv/TvContract.Channels.html)
and meet the following requirements:
The TV app that is required for Android device implementations declaring the
`android.software.live_tv` feature flag, MUST meet the following requirements:
* Device implementations SHOULD allow third-party TIF-based inputs
([third-party inputs](
https://source.android.com/devices/tv/index.html#third-party_input_example))
to be installed and managed.
* Device implementations MAY provide visual separation between pre-installed
[TIF-based inputs](
https://source.android.com/devices/tv/index.html#tv_inputs)
(installed inputs) and third-party inputs.
* Device implementations SHOULD NOT display the third-party inputs more than a
single navigation action away from the TV App (i.e. expanding a list of
third-party inputs from the TV App).
The Android Open Source Project provides an implementation of the TV App that
meets the above requirements.
#### 3.12.1.1\. Electronic Program Guide
If device implementations support TIF, they:
* [C-1-1] MUST show an informational and
interactive overlay, which MUST include an electronic program guide (EPG)
generated from the values in the [TvContract.Programs](
https://developer.android.com/reference/android/media/tv/TvContract.Programs.html)
fields.
* [C-1-2] On channel change, device implementations MUST display EPG data for
the currently playing program.
* [SR] The EPG is STRONGLY RECOMMENDED to display installed inputs and
third-party inputs with equal prominence. The EPG SHOULD NOT display the
third-party inputs more than a single navigation action away from the
installed inputs on the EPG.
* The EPG SHOULD display information from all installed inputs and third-party
inputs.
* The EPG MAY provide visual separation between the installed inputs and
third-party inputs.
#### 3.12.1.2\. Navigation
If device implementations support TIF, they:
* [C-1-1] MUST allow navigation for the following functions via
the D-pad, Back, and Home keys on the Android Television device’s input
device(s) (i.e. remote control, remote control application, or game controller):
* Changing TV channels
* Opening EPG
* Configuring and tuning to third-party TIF-based inputs (if those inputs are supported)
* Opening Settings menu
* SHOULD pass key events to HDMI inputs through CEC.
#### 3.12.1.3\. TV input app linking
Android Television device implementations SHOULD support
[TV input app linking](http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI),
which allows all inputs to provide activity links from the current activity to
another activity (i.e. a link from live programming to related content). The TV
App SHOULD show TV input app linking when it is provided.
#### 3.12.1.4\. Time shifting
If device implementations support TIF, they:
* [SR] STRONGLY RECOMMENDED to support time shifting, which allows the user
to pause and resume live content.
* SHOULD provide the user a way to pause and resume the currently playing
program, if time shifting for that program [is available](
https://developer.android.com/reference/android/media/tv/TvInputManager.html#TIME_SHIFT_STATUS_AVAILABLE).
#### 3.12.1.5\. TV recording
If device implementations support TIF, they:
* [SR] STRONGLY RECOMMENDED to support TV recording.
* If the TV input supports recording and the recording of a program is not
[prohibited](
https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED),
the EPG MAY provide a way to [record a program](
https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29).

15
android/compatibility/cdd/3_software/3_13_quick-settings.md Normal file
View file

@ -0,0 +1,15 @@
## 3.13\. Quick Settings
Android provides a Quick Settings UI component that allows quick access to
frequently used or urgently needed actions.
If device implementations include a Quick Settings UI component, they:
* [C-1-1] MUST allow the user to add or remove the tiles provided through the
[`quicksettings`](
https://developer.android.com/reference/android/service/quicksettings/package-summary.html)
APIs from a third-party app.
* [C-1-2] MUST NOT automatically add a tile from a third-party app directly
to the Quick Settings.
* [C-1-3] MUST display all the user-added tiles from third-party apps
alongside the system-provided quick setting tiles.

19
android/compatibility/cdd/3_software/3_14_vehicle-ui-apis.md Normal file
View file

@ -0,0 +1,19 @@
## 3.14\. Media UI
If device implementations include the UI framework that supports third-party
apps that depend on [`MediaBrowser`](
http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
and [`MediaSession`](
http://developer.android.com/reference/android/media/session/MediaSession.html)
, they:
* [C-1-1] MUST display [MediaItem](
http://developer.android.com/reference/android/media/browse/MediaBrowser.MediaItem.html)
icons and notification icons unaltered.
* [C-1-2] MUST display those items as described by MediaSession, e.g.,
metadata, icons, imagery.
* [C-1-3] MUST show app title.
* [C-1-4] MUST have drawer to present [MediaBrowser](
http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
hierarchy.

17
android/compatibility/cdd/3_software/3_15_instant-apps.md Normal file
View file

@ -0,0 +1,17 @@
## 3.15\. Instant Apps
Device implementations MUST satisfy the following requirements:
* [C-0-1] Instant Apps MUST only be granted permissions that have the
[`android:protectionLevel`](https://developer.android.com/guide/topics/manifest/permission-element.html#plevel)
set to `"ephemeral"`.
* [C-0-2] Instant Apps MUST NOT interact with installed apps via [implicit intents](https://developer.android.com/reference/android/content/Intent.html)
unless one of the following is true:
* The component's intent pattern filter is exposed and has CATEGORY_BROWSABLE
* The action is one of ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
* The target is explicitly exposed with [android:visibleToInstantApps](https://developer.android.com/reference/android/R.attr.html#visibleToInstantApps)
* [C-0-3] Instant Apps MUST NOT interact explicitly with installed apps unless the
component is exposed via android:visibleToInstantApps.
* [C-0-4] IInstalled Apps MUST NOT see details about Instant Apps on the
device unless the Instant App explicitly connects to the
installed application.

17
android/compatibility/cdd/3_software/3_16_companion_device_pairing.md Normal file
View file

@ -0,0 +1,17 @@
## 3.16\. Companion Device Pairing
Android includes support for companion device pairing to more effectively manage
association with companion devices and provides the [`CompanionDeviceManager`
](https://developer.android.com/reference/android/companion/CompanionDeviceManager.html)
API for apps to access this feature.
If device implementations support the companion device pairing feature, they:
* [C-1-1] MUST declare the feature flag [`FEATURE_COMPANION_DEVICE_SETUP`
](https://developer.android.com/reference/android/content/pm/PackageManager.html?#FEATURE_COMPANION_DEVICE_SETUP)
.
* [C-1-2] MUST ensure the APIs in the [`android.companion`
](https://developer.android.com/reference/android/companion/package-summary.html)
package is fully implemented.
* [C-1-3] MUST provide user affordances for the user to select/confirm a companion
device is present and operational.

35
android/compatibility/cdd/3_software/3_1_managed-api-compatibility.md Normal file
View file

@ -0,0 +1,35 @@
## 3.1\. Managed API Compatibility
The managed Dalvik bytecode execution environment is the primary vehicle for
Android applications. The Android application programming interface (API) is the
set of Android platform interfaces exposed to applications running in the
managed runtime environment.
* [C-0-1] Device implementations MUST provide complete implementations,
including all documented behaviors, of any documented API exposed by the
[Android SDK](http://developer.android.com/reference/packages.html)
or any API decorated with the “@SystemApi” marker in the upstream Android
source code.
* [C-0-2] Device implementations MUST support/preserve all classes,
methods, and associated elements marked by the TestApi annotation (@TestApi).
* [C-0-3] Device implementations MUST NOT omit any managed APIs, alter
API interfaces or signatures, deviate from the documented behavior, or include
no-ops, except where specifically allowed by this Compatibility Definition.
* [C-0-4] Device implementations MUST still keep the APIs present and behave
in a reasonable way, even when some hardware features for which Android
includes APIs are omitted. See [section 7](#7_hardware_compatibility)
for specific requirements for this scenario.
## 3.1.1\. Android Extensions
Android includes the support of extending the managed APIs while keeping the
same API level version.
* [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.

436
android/compatibility/cdd/3_software/3_2_soft-api-compatibility.md Normal file
View file

@ -0,0 +1,436 @@
## 3.2\. Soft API Compatibility
In addition to the managed APIs from [section 3.1](#3_1_managed_api_compatibility),
Android also includes a significant runtime-only “soft” API, in the form of such
things as intents, permissions, and similar aspects of Android applications that
cannot be enforced at application compile time.
### 3.2.1\. Permissions
* [C-0-1] Device implementers MUST support and enforce all permission
constants as documented by the [Permission reference page](http://developer.android.com/reference/android/Manifest.permission.html).
Note that [section 9](#9_security_model_compatibility) lists additional
requirements related to the Android security model.
### 3.2.2\. Build Parameters
The Android APIs include a number of constants on the
[android.os.Build class](http://developer.android.com/reference/android/os/Build.html)
that are intended to describe the current device.
* [C-0-1] To provide consistent, meaningful values across device
implementations, the table below includes additional restrictions on the formats
of these values to which device implementations MUST conform.
<table>
<tr>
<th>Parameter</th>
<th>Details</th>
</tr>
<tr>
<td>VERSION.RELEASE</td>
<td>The version of the currently-executing Android system, in human-readable
format. This field MUST have one of the string values defined in
<a href="http://source.android.com/compatibility/ANDROID_VERSION/versions.html">ANDROID_VERSION</a>.</td>
</tr>
<tr>
<td>VERSION.SDK</td>
<td>The version of the currently-executing Android system, in a format
accessible to third-party application code. For Android ANDROID_VERSION,
this field MUST have the integer value ANDROID_VERSION_INT.</td>
</tr>
<tr>
<td>VERSION.SDK_INT</td>
<td>The version of the currently-executing Android system, in a format
accessible to third-party application code. For Android ANDROID_VERSION,
this field MUST have the integer value ANDROID_VERSION_INT.</td>
</tr>
<tr>
<td>VERSION.INCREMENTAL</td>
<td>A value chosen by the device implementer designating the specific build
of the currently-executing Android system, in human-readable format. This
value MUST NOT be reused for different builds made available to end users. A
typical use of this field is to indicate which build number or
source-control change identifier was used to generate the build. There are
no requirements on the specific format of this field, except that it MUST
NOT be null or the empty string ("").</td>
</tr>
<tr>
<td>BOARD</td>
<td>A value chosen by the device implementer identifying the specific
internal hardware used by the device, in human-readable format. A possible
use of this field is to indicate the specific revision of the board powering
the device. The value of this field MUST be encodable as 7-bit ASCII and
match the regular expression &ldquo;^[a-zA-Z0-9_-]+$&rdquo;.</td>
</tr>
<tr>
<td>BRAND</td>
<td>A value reflecting the brand name associated with the device as known to
the end users. MUST be in human-readable format and SHOULD represent the
manufacturer of the device or the company brand under which the device is
marketed. The value of this field MUST be encodable as 7-bit ASCII and match
the regular expression &ldquo;^[a-zA-Z0-9_-]+$&rdquo;.</td>
</tr>
<tr>
<td>SUPPORTED_ABIS</td>
<td>The name of the instruction set (CPU type + ABI convention) of native
code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API
Compatibility</a>.</td>
</tr>
<tr>
<td>SUPPORTED_32_BIT_ABIS</td>
<td>The name of the instruction set (CPU type + ABI convention) of native
code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API
Compatibility</a>.</td>
</tr>
<tr>
<td>SUPPORTED_64_BIT_ABIS</td>
<td>The name of the second instruction set (CPU type + ABI convention) of
native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native
API Compatibility</a>.</td>
</tr>
<tr>
<td>CPU_ABI</td>
<td>The name of the instruction set (CPU type + ABI convention) of native
code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API
Compatibility</a>.</td>
</tr>
<tr>
<td>CPU_ABI2</td>
<td>The name of the second instruction set (CPU type + ABI convention) of
native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native
API Compatibility</a>.</td>
</tr>
<tr>
<td>DEVICE</td>
<td>A value chosen by the device implementer containing the development name
or code name identifying the configuration of the hardware features and
industrial design of the device. The value of this field MUST be encodable
as 7-bit ASCII and match the regular expression
&ldquo;^[a-zA-Z0-9_-]+$&rdquo;. This device name MUST NOT change during the
lifetime of the product.</td>
</tr>
<tr>
<td>FINGERPRINT</td>
<td>A string that uniquely identifies this build. It SHOULD be reasonably
human-readable. It MUST follow this template:
<p class="small">$(BRAND)/$(PRODUCT)/<br>
&nbsp;&nbsp;&nbsp;&nbsp;$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
<p>For example:</p>
<p class="small">acme/myproduct/<br>
&nbsp;&nbsp;&nbsp;&nbsp;mydevice:ANDROID_VERSION/LMYXX/3359:userdebug/test-keys</p>
<p>The fingerprint MUST NOT include whitespace characters. If other fields
included in the template above have whitespace characters, they MUST be
replaced in the build fingerprint with another character, such as the
underscore ("_") character. The value of this field MUST be encodable as
7-bit ASCII.</p></td>
</tr>
<tr>
<td>HARDWARE</td>
<td>The name of the hardware (from the kernel command line or /proc). It
SHOULD be reasonably human-readable. The value of this field MUST be
encodable as 7-bit ASCII and match the regular expression
&ldquo;^[a-zA-Z0-9_-]+$&rdquo;.</td>
</tr>
<tr>
<td>HOST</td>
<td>A string that uniquely identifies the host the build was built on, in
human-readable format. There are no requirements on the specific format of
this field, except that it MUST NOT be null or the empty string ("").</td>
</tr>
<tr>
<td>ID</td>
<td>An identifier chosen by the device implementer to refer to a specific
release, in human-readable format. This field can be the same as
android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value sufficiently
meaningful for end users to distinguish between software builds. The value
of this field MUST be encodable as 7-bit ASCII and match the regular
expression &ldquo;^[a-zA-Z0-9._-]+$&rdquo;.</td>
</tr>
<tr>
<td>MANUFACTURER</td>
<td>The trade name of the Original Equipment Manufacturer (OEM) of the
product. There are no requirements on the specific format of this field,
except that it MUST NOT be null or the empty string (""). This field
MUST NOT change during the lifetime of the product.</td>
</tr>
<tr>
<td>MODEL</td>
<td>A value chosen by the device implementer containing the name of the
device as known to the end user. This SHOULD be the same name under which
the device is marketed and sold to end users. There are no requirements on
the specific format of this field, except that it MUST NOT be null or the
empty string (""). This field MUST NOT change during the
lifetime of the product.</td>
</tr>
<tr>
<td>PRODUCT</td>
<td>A value chosen by the device implementer containing the development name
or code name of the specific product (SKU) that MUST be unique within the
same brand. MUST be human-readable, but is not necessarily intended for view
by end users. The value of this field MUST be encodable as 7-bit ASCII and
match the regular expression &ldquo;^[a-zA-Z0-9_-]+$&rdquo;. This product
name MUST NOT change during the lifetime of the product.</td>
</tr>
<tr>
<td>SERIAL</td>
<td>A hardware serial number, which MUST be available and unique across
devices with the same MODEL and MANUFACTURER. The value of this field MUST
be encodable as 7-bit ASCII and match the regular expression
&ldquo;^([a-zA-Z0-9]{6,20})$&rdquo;.</td>
</tr>
<tr>
<td>TAGS</td>
<td>A comma-separated list of tags chosen by the device implementer that
further distinguishes the build. This field MUST have one of the values
corresponding to the three typical Android platform signing configurations:
release-keys, dev-keys, test-keys.</td>
</tr>
<tr>
<td>TIME</td>
<td>A value representing the timestamp of when the build occurred.</td>
</tr>
<tr>
<td>TYPE</td>
<td>A value chosen by the device implementer specifying the runtime
configuration of the build. This field MUST have one of the values
corresponding to the three typical Android runtime configurations: user,
userdebug, or eng.</td>
</tr>
<tr>
<td>USER</td>
<td>A name or user ID of the user (or automated user) that generated the
build. There are no requirements on the specific format of this field,
except that it MUST NOT be null or the empty string ("").</td>
</tr>
<tr>
<td>SECURITY_PATCH</td>
<td>A value indicating the security patch level of a build. It MUST signify
that the build is not in any way vulnerable to any of the issues described
up through the designated Android Public Security Bulletin. It MUST be in
the format [YYYY-MM-DD], matching a defined string documented in the
<a href="source.android.com/security/bulletin"> Android Public Security
Bulletin</a> or in the <a href="http://source.android.com/security/advisory">
Android Security Advisory</a>, for example "2015-11-01".</td>
</tr>
<tr>
<td>BASE_OS</td>
<td>A value representing the FINGERPRINT parameter of the build that is
otherwise identical to this build except for the patches provided in the
Android Public Security Bulletin. It MUST report the correct value and if
such a build does not exist, report an empty string ("").</td>
</tr>
<tr>
<td><a href="https://developer.android.com/reference/android/os/Build.html#BOOTLOADER">BOOTLOADER</a></td>
<td> A value chosen by the device implementer identifying the specific
internal bootloader version used in the device, in human-readable format.
The value of this field MUST be encodable as 7-bit ASCII and match the
regular expression &ldquo;^[a-zA-Z0-9._-]+$&rdquo;.</td>
</tr>
<tr>
<td><a href="https://developer.android.com/reference/android/os/Build.html#getRadioVersion()">getRadioVersion()</a></td>
<td> MUST (be or return) a value chosen by the device implementer
identifying the specific internal radio/modem version used in the device,
in human-readable format. If a device does not have any internal
radio/modem it MUST return NULL. The value of this field MUST be
encodable as 7-bit ASCII and match the regular expression
&ldquo;^[a-zA-Z0-9._-,]+$&rdquo;.</td>
</tr>
</table>
### 3.2.3\. Intent Compatibility
#### 3.2.3.1\. Core 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.
* [C-0-1] Device implementations MUST include these application, service
components, or at least a handler, for all the public intent filter patterns
defined by the the following core Android applications in AOSP:
* Desk Clock
* Browser
* Calendar
* Contacts
* Gallery
* GlobalSearch
* Launcher
* Music
* Settings
#### 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)
to be overridden by third-party applications. The upstream Android open source
implementation allows this by default.
* [C-0-2] Dvice implementers MUST NOT attach special privileges to system
applications' use of these intent patterns, or prevent third-party applications
from binding to and assuming control of these patterns. This prohibition
specifically includes but is not limited to disabling the “Chooser” user
interface that allows the user to select between multiple applications that all
handle the same intent pattern.
* [C-0-3] Device implementations MUST provide a user interface for users to
modify the default activity for intents.
* However, device implementations MAY provide default activities for specific
URI patterns (e.g. http://play.google.com) when the default activity provides a
more specific attribute for the data URI. For example, an intent filter pattern
specifying the data URI “http://www.android.com” is more specific than the
browser's core intent pattern for “http://”.
Android also includes a mechanism for third-party apps to declare an
authoritative default [app linking behavior](https://developer.android.com/training/app-links)
for certain types of web URI intents. When such authoritative declarations are
defined in an app's intent filter patterns, device implementations:
* [C-0-4] MUST attempt to validate any intent filters by performing the
validation steps defined in the [Digital Asset Links specification](https://developers.google.com/digital-asset-links)
as implemented by the Package Manager in the upstream Android Open Source
Project.
* [C-0-5] MUST attempt validation of the intent filters during the installation of
the application and set all successfully validated UIR intent filters as
default app handlers for their UIRs.
* MAY set specific URI intent filters as default app handlers for their URIs,
if they are successfully verified but other candidate URI filters fail
verification. If a device implementation does this, it MUST provide the
user appropriate per-URI pattern overrides in the settings menu.
* MUST provide the user with per-app App Links controls in Settings as
follows:
* [C-0-6] The user MUST be able to override holistically the default app
links behavior for an app to be: always open, always ask, or never open,
which must apply to all candidate URI intent filters equally.
* [C-0-7] The user MUST be able to see a list of the candidate URI intent
filters.
* The device implementation MAY provide the user with the ability to
override specific candidate URI intent filters that were successfully
verified, on a per-intent filter basis.
* [C-0-8] The device implementation MUST provide users with the ability to
view and override specific candidate URI intent filters if the device
implementation lets some candidate URI intent filters succeed
verification while some others can fail.
#### 3.2.3.3\. Intent Namespaces
* [C-0-1] Device implementations MUST NOT include any Android component that
honors any new intent or broadcast intent patterns using an ACTION, CATEGORY, or
other key string in the android.* or com.android.* namespace.
* [C-0-2] Device implementers MUST NOT include any Android components that
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).
* 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).
#### 3.2.3.4\. Broadcast Intents
Third-party applications rely on the platform to broadcast certain intents to
notify them of changes in the hardware or software environment.
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.
#### 3.2.3.5\. Default App Settings
Android includes settings that provide users an easy way to select their
default applications, for example for Home screen or SMS.
Where it makes sense, device implementations MUST provide a similar settings
menu and be compatible with the intent filter pattern and API methods described
in the SDK documentation as below.
If device implementations report `android.software.home_screen`, they:
* [C-1-1] MUST honor the [android.settings.HOME_SETTINGS](
http://developer.android.com/reference/android/provider/Settings.html#ACTION_HOME_SETTINGS)
intent to show a default app settings menu for Home Screen.
If device implementations report `android.hardware.telephony`, they:
* [C-2-1] MUST provide a settings menu that will call the
[android.provider.Telephony.ACTION_CHANGE_DEFAULT](
http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html)
intent to show a dialog to change the default SMS application.
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.
If device implementations report `android.hardware.telephony`, they:
* [C-4-1] MUST honor the [android.telecom.action.CHANGE_DEFAULT_DIALER](
https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER)
intent to show a dialog to allow the user to change the default Phone
application.
If device implementations support the VoiceInteractionService, they:
* [C-5-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.
### 3.2.4\. Activities on secondary displays
If device implementations allow launching normal [Android Activities](
https://developer.android.com/reference/android/app/Activity.html) on secondary
displays, they:
* [C-1-1] MUST set the `android.software.activities_on_secondary_displays`
feature flag.
* [C-1-2] MUST guarantee API compatibility similar to an activity running on
the primary display.
* [C-1-3] MUST land the new activity on the same display as the activity that
launched it, when the new activity is launched without specifying a target
display via the [`ActivityOptions.setLaunchDisplayId()`](
https://developer.android.com/reference/android/app/ActivityOptions.html#setLaunchDisplayId%28int%29)
API.
* [C-1-4] MUST destory all activities, when a display with the
[`Display.FLAG_PRIVATE`](http://developer.android.com/reference/android/view/Display.html#FLAG_PRIVATE)
flag is removed.
* [C-1-5] MUST resize accordingly all activities on a [`VirtualDisplay`](
https://developer.android.com/reference/android/hardware/display/VirtualDisplay.html)
if the display itself is resized.
* MAY show an IME (input method editor, a user control that enables users to
enter text) on the primary display, when a text input field becomes focused
on a secondary display.
* SHOULD implement the input focus on the secondary display independently of
the primary display, when touch or key inputs are supported.
* SHOULD have [`android.content.res.Configuration`](
https://developer.android.com/reference/android/content/res/Configuration.html)
which corresponds to that display in order to be displayed, operate
correctly, and maintain compatibility if an activity is launched on
secondary display.
If device implementations allow launching normal [Android Activities](
https://developer.android.com/reference/android/app/Activity.html) on secondary
displays and primary and secondary displays have different
[android.util.DisplayMetrics](https://developer.android.com/reference/android/util/DisplayMetrics.html):
* [C-2-1] Non-resizeable activities (that have `resizeableActivity=false` in
`AndroidManifest.xml`) and apps targeting API level 23 or lower MUST NOT be
allowed on secondary displays.
If device implementations allow launching normal [Android Activities](
https://developer.android.com/reference/android/app/Activity.html) on secondary
displays and a secondary display has the [android.view.Display.FLAG_PRIVATE](
https://developer.android.com/reference/android/view/Display.html#FLAG_PRIVATE)
flag:
* [C-3-1] Only the owner of that display, system, and activities that are
already on that display MUST be able to launch to it. Everyone can launch to
a display that has [android.view.Display.FLAG_PUBLIC](https://developer.android.com/reference/android/view/Display.html#FLAG_PUBLIC)
flag.

120
android/compatibility/cdd/3_software/3_3_native-api-compatibility.md Normal file
View file

@ -0,0 +1,120 @@
## 3.3\. Native API Compatibility
Device implementers are:
Native code compatibility is challenging. For this reason,
device implementers are:
* [SR] STRONGLY RECOMMENDED to use the implementations of the libraries
listed below from the upstream Android Open Source Project.
### 3.3.1\. Application Binary Interfaces
Managed Dalvik bytecode can call into native code provided in the application
`.apk` file as an ELF `.so` file compiled for the appropriate device hardware
architecture. As native code is highly dependent on the underlying processor
technology, Android defines a number of Application Binary Interfaces (ABIs) in
the Android NDK.
Device implementations:
* [C-0-1] MUST be compatible with one or more defined ABIs and implement
compatibility with the Android NDK.
* [C-0-2] MUST include support for code running in the managed environment to
call into native code, using the standard Java Native Interface (JNI)
semantics.
* [C-0-3] MUST be source-compatible (i.e. header-compatible) and
binary-compatible (for the ABI) with each required library in the list
below.
* [C-0-4] MUST support the equivalent 32-bit ABI if any 64-bit ABI is
supported.
* [C-0-5] MUST accurately report the native Application Binary Interface
(ABI) supported by the device, via the `android.os.Build.SUPPORTED_ABIS`,
`android.os.Build.SUPPORTED_32_BIT_ABIS`, and
`android.os.Build.SUPPORTED_64_BIT_ABIS` parameters, each a comma separated
list of ABIs ordered from the most to the least preferred one.
* [C-0-6] MUST report, via the above parameters, only those ABIs documented
and described in the latest version of the
[Android NDK ABI Management documentation](
https://developer.android.com/ndk/guides/abis.html), and MUST include
support for the [Advanced SIMD](
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html)
(a.k.a. NEON) extension.
* [C-0-7] MUST make all the following libraries, providing native APIs,
available to apps that include native code:
* libaaudio.so (AAudio native audio support)
* libandroid.so (native Android activity support)
* libc (C library)
* libcamera2ndk.so
* libdl (dynamic linker)
* libEGL.so (native OpenGL surface management)
* libGLESv1\_CM.so (OpenGL ES 1.x)
* libGLESv2.so (OpenGL ES 2.0)
* libGLESv3.so (OpenGL ES 3.x)
* libicui18n.so
* libicuuc.so
* libjnigraphics.so
* liblog (Android logging)
* libmediandk.so (native media APIs support)
* libm (math library)
* libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
* libOpenSLES.so (OpenSL ES 1.0.1 audio support)
* libRS.so
* libstdc++ (Minimal support for C++)
* libvulkan.so (Vulkan)
* libz (Zlib compression)
* JNI interface
* [C-0-8] MUST NOT add or remove the public functions for the native libraries
listed above.
* [C-0-9] MUST list additional non-AOSP libraries exposed directly to
third-party apps in `/vendor/etc/public.libraries.txt`.
* [C-0-10] MUST NOT expose any other native libraries, implemented and
provided in AOSP as system libraries, to third-party apps targeting API
level 24 or higher as they are reserved.
* [C-0-11] MUST export all the OpenGL ES 3.1 and [Android Extension Pack](
http://developer.android.com/guide/topics/graphics/opengl.html#aep)
function symbols, as defined in the NDK, through the `libGLESv3.so` library.
Note that while all the symbols MUST be present, section 7.1.4.1 describes
in more detail the requirements for when the full implementation of each
corresponding functions are expected.
* [C-0-12] MUST export function symbols for the core Vulkan 1.0 function
symobls, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
`VK_KHR_swapchain`, `VK_KHR_maintenance1`, and
`VK_KHR_get_physical_device_properties2` extensions through the
`libvulkan.so` library. Note that while all the symbols MUST be present,
section 7.1.4.2 describes in more detail the requirements for when the full
implementation of each corresponding functions are expected.
* SHOULD be built using the source code and header files available in the
upstream Android Open Source Project
Note that future releases of the Android NDK may introduce support for
additional ABIs.
### 3.3.2. 32-bit ARM Native Code Compatibility
If device implementations are 64-bit ARM devices, then:
* [C-1-1] Although the ARMv8 architecture deprecates several CPU operations,
including some operations used in existing native code, the following
deprecated operations MUST remain available to 32-bit native ARM code,
either through native CPU support or through software emulation:
* SWP and SWPB instructions
* SETEND instruction
* CP15ISB, CP15DSB, and CP15DMB barrier operations
If device implementations include a 32-bit ARM ABI, they:
* [C-2-1] MUST include the following lines in `/proc/cpuinfo` when it is read
by 32-bit ARM applications to ensure compatibility with applications built
using legacy versions of Android NDK.
* `Features: `, followed by a list of any optional ARMv7 CPU features
supported by the device.
* `CPU architecture: `, followed by an integer describing the device's
highest supported ARM architecture (e.g., "8" for ARMv8 devices).
* SHOULD not alter `/proc/cpuinfo` when read by 64-bit ARM or non-ARM
applications.

63
android/compatibility/cdd/3_software/3_4_web-compatibility.md Normal file
View file

@ -0,0 +1,63 @@
## 3.4\. Web Compatibility
### 3.4.1\. WebView Compatibility
If device implementations provide a complete implementation of the
`android.webkit.Webview` API, they:
* [C-1-1] MUST report `android.software.webview`.
* [C-1-2] MUST use the [Chromium](http://www.chromium.org/) Project build
from the upstream Android Open Source Project on the Android
ANDROID_VERSION branch for the implementation of the
[`android.webkit.WebView`](
http://developer.android.com/reference/android/webkit/WebView.html)
API.
* [C-1-3] The user agent string reported by the WebView MUST be in this format:
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile
Safari/537.36
* The value of the $(VERSION) string MUST be the same as the value for
android.os.Build.VERSION.RELEASE.
* The value of the $(MODEL) string MUST be the same as the value for
android.os.Build.MODEL.
* The value of the $(BUILD) string MUST be the same as the value for
android.os.Build.ID.
* The value of the $(CHROMIUM_VER) string MUST be the version of Chromium
in the upstream Android Open Source Project.
* Device implementations MAY omit Mobile in the user agent string.
* The WebView component SHOULD include support for as many HTML5 features as
possible and if it supports the feature SHOULD conform to the
[HTML5 specification](http://html.spec.whatwg.org/multipage/).
### 3.4.2\. Browser Compatibility
If device implementations include a standalone Browser application for general
web browsing, they:
* [C-1-1] MUST support each of these APIs associated with
HTML5:
* [application cache/offline operation](
http://www.w3.org/html/wg/drafts/html/master/browsers.html#offline)
* [&lt;video&gt; tag](
http://www.w3.org/html/wg/drafts/html/master/semantics.html#video)
* [geolocation](http://www.w3.org/TR/geolocation-API/)
* [C-1-2] MUST support the HTML5/W3C [webstorage API](
http://www.w3.org/TR/webstorage/) and SHOULD support the HTML5/W3C
[IndexedDB API](http://www.w3.org/TR/IndexedDB/). Note that as the web
development standards bodies are transitioning to favor IndexedDB over
webstorage, IndexedDB is expected to become a required component in a
future version of Android.
* MAY ship a custom user agent string in the standalone Browser application.
* SHOULD implement support for as much of [HTML5](
http://html.spec.whatwg.org/multipage/) as possible on the standalone
Browser application (whether based on the upstream WebKit Browser
application or a third-party replacement).
However, If device implementations do not include a standalone Browser
application, they:
* [C-2-1] MUST still support the public intent patterns as described in
[section 3.2.3.1](#3_2_3_1_core_application_intents).

49
android/compatibility/cdd/3_software/3_5_api-behavioral-compatibility.md Normal file
View file

@ -0,0 +1,49 @@
## 3.5\. API Behavioral Compatibility
The behaviors of each of the API types (managed, soft, native, and web) must be
consistent with the preferred implementation of the upstream
[Android Open Source Project](http://source.android.com/). Some specific areas
of compatibility are:
* [C-0-1] Devices MUST NOT change the behavior or semantics of a
standard intent.
* [C-0-2] Devices MUST NOT alter the lifecycle or lifecycle semantics of
a particular type of system component (such as Service, Activity, ContentProvider, etc.).
* [C-0-3] Devices MUST NOT change the semantics of a standard permission.
* Devices MUST NOT alter the limitations enforced on background applications.
More specifically, for background apps:
* [C-0-4] they MUST stop executing callbacks that are registered by the
app to receive outputs from the [`GnssMeasurement`](
https://developer.android.com/reference/android/location/GnssMeasurement.html)
and [`GnssNavigationMessage`](
https://developer.android.com/reference/android/location/GnssNavigationMessage.html).
* [C-0-5] they MUST rate-limit the frequency of updates that are
provided to the app through the [`LocationManager`](
https://developer.android.com/reference/android/location/LocationManager.html)
API class or the [`WifiManager.startScan()`](
https://developer.android.com/reference/android/net/wifi/WifiManager.html#startScan%28%29)
method.
* [C-0-6] if the app is targeting API level 25 or higher, they MUST NOT
allow to register broadcast receivers for the implicit broadcasts of
standard Android intents in the app's manifest, unless the broadcast
intent requires a `"signature"` or `"signatureOrSystem"`
[`protectionLevel`](
https://developer.android.com/guide/topics/manifest/permission-element.html#plevel)
permission or are on the [exemption list](
https://developer.android.com/preview/features/background-broadcasts.html)
.
* [C-0-7] if the app is targeting API level 25 or higher, they MUST stop
the app's background services, just as if the app had called the
services'[`stopSelf()`](
https://developer.android.com/reference/android/app/Service.html#stopSelf%28%29)
method, unless the app is placed on a temporary whitelist to handle a
task that's visible to the user.
* [C-0-8] if the app is targeting API level 25 or higher, they MUST
release the wakelocks the app holds.
The above list is not comprehensive. The Compatibility Test Suite (CTS) tests
significant portions of the platform for behavioral compatibility, but not all.
It is the responsibility of the implementer to ensure behavioral compatibility
with the Android Open Source Project. For this reason, device implementers
SHOULD use the source code available via the Android Open Source Project where
possible, rather than re-implement significant parts of the system.

52
android/compatibility/cdd/3_software/3_6_api-namespaces.md Normal file
View file

@ -0,0 +1,52 @@
## 3.6\. API Namespaces
Android follows the package and class namespace conventions defined by the Java
programming language. To ensure compatibility with third-party applications,
device implementers MUST NOT make any prohibited modifications (see below) to
these package namespaces:
* `java.*`
* `javax.*`
* `sun.*`
* `android.*`
* `com.android.*`
That is, they:
* [C-0-1] MUST NOT modify the publicly exposed APIs on the Android platform
by changing any method or class signatures, or by removing classes or class
fields.
* [C-0-2] MUST NOT add any publicly exposed elements (such as classes or
interfaces, or fields or methods to existing classes or interfaces) or Test
or System APIs to the APIs in the above namespaces. A “publicly exposed
element” is any construct that is not decorated with the “@hide” marker as
used in the upstream Android source code.
Device implementers MAY modify the underlying implementation of the APIs, but
such modifications:
* [C-0-3] MUST NOT impact the stated behavior and Java-language signature of
any publicly exposed APIs.
* [C-0-4] MUST NOT be advertised or otherwise exposed to developers.
However, device implementers MAY add custom APIs outside the standard Android
namespace, but the custom APIs:
* [C-0-5] MUST NOT be in a namespace owned by or referring to another
organization. For instance, device implementers MUST NOT add APIs to the
`com.google.*` or similar namespace: only Google may do so. Similarly,
Google MUST NOT add APIs to other companies' namespaces.
* [C-0-6] MUST be packaged in an Android shared library so that only apps
that explicitly use them (via the &lt;uses-library&gt; mechanism) are
affected by the increased memory usage of such APIs.
If a device implementer proposes to improve one of the package namespaces above
(such as by adding useful new functionality to an existing API, or adding a new
API), the implementer SHOULD visit [source.android.com](
http://source.android.com/) and begin the process for contributing changes and
code, according to the information on that site.
Note that the restrictions above correspond to standard conventions for naming
APIs in the Java programming language; this section simply aims to reinforce
those conventions and make them binding through inclusion in this Compatibility
Definition.

218
android/compatibility/cdd/3_software/3_7_runtime-compatibility.md Normal file
View file

@ -0,0 +1,218 @@
## 3.7\. Runtime Compatibility
Device implementations:
* [C-0-1] MUST support the full Dalvik Executable (DEX) format
and [Dalvik bytecode specification and semantics](https://android.googlesource.com/platform/dalvik/).
* [C-0-2] MUST configure Dalvik runtimes to allocate memory in
accordance with the upstream Android platform, and as specified by
the following table. (See [section 7.1.1](#7_1_1_screen_configuration) for
screen size and screen density definitions.)
* SHOULD use Android RunTime (ART), the reference upstream
implementation of the Dalvik Executable Format, and the reference
implementation’s package management system.
* SHOULD run fuzz tests under various modes of execution
and target architectures to assure the stability of the runtime. Refer to
[JFuzz](https://android.googlesource.com/platform/art/+/master/tools/dexfuzz/)
and [DexFuzz](https://android.googlesource.com/platform/art/+/master/tools/dexfuzz/)
in the Android Open Source Project website.
Note that memory values specified below are considered minimum values and
device implementations MAY allocate more memory per application.
<table>
<tr>
<th>Screen Layout</th>
<th>Screen Density</th>
<th>Minimum Application Memory</th>
</tr>
<tr>
<td rowspan="12">Android Watch</td>
<td>120 dpi (ldpi)</td>
<td rowspan="3">32MB</td>
</tr>
<tr>
<td>160 dpi (mdpi)</td>
</tr>
<tr>
<td>213 dpi (tvdpi)</td>
</tr>
<tr>
<td>240 dpi (hdpi)</td>
<td rowspan="2">36MB</td>
</tr>
<tr>
<td>280 dpi (280dpi)</td>
</tr>
<tr>
<td>320 dpi (xhdpi)</td>
<td rowspan="2">48MB</td>
</tr>
<tr>
<td>360 dpi (360dpi)</td>
</tr>
<tr>
<td>400 dpi (400dpi)</td>
<td>56MB</td>
</tr>
<tr>
<td>420 dpi (420dpi)</td>
<td>64MB</td>
</tr>
<tr>
<td>480 dpi (xxhdpi)</td>
<td>88MB</td>
</tr>
<tr>
<td>560 dpi (560dpi)</td>
<td>112MB</td>
</tr>
<tr>
<td>640 dpi (xxxhdpi)</td>
<td>154MB</td>
</tr>
<tr>
<td rowspan="12">small/normal</td>
<td>120 dpi (ldpi)</td>
<td rowspan="2">32MB</td>
</tr>
<tr>
<td>160 dpi (mdpi)</td>
</tr>
<tr>
<td>213 dpi (tvdpi)</td>
<td rowspan="3">48MB</td>
</tr>
<tr>
<td>240 dpi (hdpi)</td>
</tr>
<tr>
<td>280 dpi (280dpi)</td>
</tr>
<tr>
<td>320 dpi (xhdpi)</td>
<td rowspan="2">80MB</td>
</tr>
<tr>
<td>360 dpi (360dpi)</td>
</tr>
<tr>
<td>400 dpi (400dpi)</td>
<td>96MB</td>
</tr>
<tr>
<td>420 dpi (420dpi)</td>
<td>112MB</td>
</tr>
<tr>
<td>480 dpi (xxhdpi)</td>
<td>128MB</td>
</tr>
<tr>
<td>560 dpi (560dpi)</td>
<td>192MB</td>
</tr>
<tr>
<td>640 dpi (xxxhdpi)</td>
<td>256MB</td>
</tr>
<tr>
<td rowspan="12">large</td>
<td>120 dpi (ldpi)</td>
<td>32MB</td>
</tr>
<tr>
<td>160 dpi (mdpi)</td>
<td>48MB</td>
</tr>
<tr>
<td>213 dpi (tvdpi)</td>
<td rowspan="2">80MB</td>
</tr>
<tr>
<td>240 dpi (hdpi)</td>
</tr>
<tr>
<td>280 dpi (280dpi)</td>
<td>96MB</td>
</tr>
<tr>
<td>320 dpi (xhdpi)</td>
<td>128MB</td>
</tr>
<tr>
<td>360 dpi (360dpi)</td>
<td>160MB</td>
</tr>
<tr>
<td>400 dpi (400dpi)</td>
<td>192MB</td>
</tr>
<tr>
<td>420 dpi (420dpi)</td>
<td>228MB</td>
</tr>
<tr>
<td>480 dpi (xxhdpi)</td>
<td>256MB</td>
</tr>
<tr>
<td>560 dpi (560dpi)</td>
<td>384MB</td>
</tr>
<tr>
<td>640 dpi (xxxhdpi)</td>
<td>512MB</td>
</tr>
<tr>
<td rowspan="12">xlarge</td>
<td>120 dpi (ldpi)</td>
<td>48MB</td>
</tr>
<tr>
<td>160 dpi (mdpi)</td>
<td>80MB</td>
</tr>
<tr>
<td>213 dpi (tvdpi)</td>
<td rowspan="2">96MB</td>
</tr>
<tr>
<td>240 dpi (hdpi)</td>
</tr>
<tr>
<td>280 dpi (280dpi)</td>
<td>144MB</td>
</tr>
<tr>
<td>320 dpi (xhdpi)</td>
<td>192MB</td>
</tr>
<tr>
<td>360 dpi (360dpi)</td>
<td>240MB</td>
</tr>
<tr>
<td>400 dpi (400dpi)</td>
<td>288MB</td>
</tr>
<tr>
<td>420 dpi (420dpi)</td>
<td>336MB</td>
</tr>
<tr>
<td>480 dpi (xxhdpi)</td>
<td>384MB</td>
</tr>
<tr>
<td>560 dpi (560dpi)</td>
<td>576MB</td>
</tr>
<tr>
<td>640 dpi (xxxhdpi)</td>
<td>768MB</td>
</tr>
</table>

522
android/compatibility/cdd/3_software/3_8_user-interface-compatibility.md Normal file
View file

@ -0,0 +1,522 @@
## 3.8\. User Interface Compatibility
### 3.8.1\. Launcher (Home Screen)
Android includes a launcher application (home screen) and support for
third-party applications to replace the device launcher (home screen).
If device implementations allow third-party applications to replace the device home screen, they:
* [C-1-1] MUST declare the platform feature `android.software.home_screen`.
* [C-1-2] MUST return the [`AdaptiveIconDrawable`](
https://developer.android.com/reference/android/graphics/drawable/AdaptiveIconDrawable.html)
object when the third party application use `<adaptive-icon>` tag to provide
their icon, and the [`PackageManager`](
https://developer.android.com/reference/android/content/pm/PackageManager.html)
methods to retrieve icons are called.
If device implementations include a default launcher that supports in-app pinning of shortcuts and
widgets, they:
* [C-2-1] MUST report `true` for
[`ShortcutManager.isRequestPinShortcutSupported()`](
https://developer.android.com/reference/android/content/pm/ShortcutManager.html#isRequestPinShortcutSupported%28%29)
and [`AppWidgetManager.html.isRequestPinAppWidgetSupported()`](
https://developer.android.com/reference/android/appwidget/AppWidgetManager.html#isRequestPinAppWidgetSupported%28%29).
* [C-2-2] MUST have user affordance asking the user before adding a shortcut requested
by apps via the [`ShortcutManager.requestPinShortcut()`](
https://developer.android.com/reference/android/content/pm/ShortcutManager.html#requestPinShortcut%28android.content.pm.ShortcutInfo, android.content.IntentSender%29)
and the [`AppWidgetManager.requestPinAddWidget()`](
https://developer.android.com/reference/android/appwidget/AppWidgetManager.html#requestPinAppWidget%28android.content.ComponentName,android.os.Bundle, android.app.PendingIntent%29)
API method.
Conversely, if device implementations do not support in-app pinning, they:
* [C-3-1] MUST report `false` for
[`ShortcutManager.isRequestPinShortcutSupported()`](
https://developer.android.com/reference/android/content/pm/ShortcutManager.html#isRequestPinShortcutSupported%28%29)
and [`AppWidgetManager.html#isRequestPinAppWidgetSupported()`](
https://developer.android.com/reference/android/appwidget/AppWidgetManager.html#isRequestPinAppWidgetSupported%28%29).
If device implementations implement a default launcher that provides quick access to the additional
shortcuts provided by third-party apps through the [ShortcutManager](
https://developer.android.com/reference/android/content/pm/ShortcutManager.html) API, they:
* [C-4-1] MUST support all documented shortcut features (e.g. static and
dynamic shortcuts, pinning shortcuts) and fully implement the APIs of the
[`ShortcutManager`](
https://developer.android.com/reference/android/content/pm/ShortcutManager.html)
API class.
If device implementations include a default launcher app that shows badges for
the app icons, they:
* [C-5-1] MUST respect the [`NotificationChannel.setShowBadge()`](
https://developer.android.com/reference/android/app/NotificationChannel.html#setShowBadge%28boolean%29)
API method.
In other words, show a visual affordance associated with the app icon if the
value is set as `true`, and do not show any app icon badging scheme when all
of the app's notification channels have set the value as `false`.
* MAY override the app icon badges with their proprietary badging scheme when
third-party applications indicate support of the proprietary badging scheme
through the use of proprietary APIs, but SHOULD use the resources and values
provided through the notification badges APIs described in [the SDK](
https://developer.android.com/preview/features/notification-badges.html)
, such as the [`Notification.Builder.setNumber()`](
http://developer.android.com/reference/android/app/Notification.Builder.html#setNumber%28int%29)
and the [`Notification.Builder.setBadgeIconType()`](
http://developer.android.com/reference/android/app/Notification.Builder.html#setBadgeIconType%28int%29)
API.
### 3.8.2\. Widgets
Android supports third-party app widgets by defining a component type and
corresponding API and lifecycle that allows applications to expose an
[“AppWidget”](http://developer.android.com/guide/practices/ui_guidelines/widget_design.html)
to the end user.
If device implementations support third-party app widgets, they:
* [C-1-1] MUST declare support for platform feature android.software.app_widgets.
* [C-1-2] MUST include built-in support for AppWidgets and expose
user interface affordances to add, configure, view, and remove AppWidgets
directly within the Launcher.
* [C-1-3] MUST be capable of rendering widgets that are 4 x 4
in the standard grid size. See the [App Widget Design
Guidelines](http://developer.android.com/guide/practices/ui_guidelines/widget_design.html)
in the Android SDK documentation for details.
* MAY support application widgets on the lock screen.
### 3.8.3\. Notifications
Android includes [`Notification`](
https://developer.android.com/reference/android/app/Notification.html) and
[`NotificationManager`](
https://developer.android.com/reference/android/app/NotificationManager.html)
APIs that allow third-party app developers to notify users of notable events and
attract users' attention using the hardware components (e.g. sound, vibration
and light) and software features (e.g. notification shade, system bar) of the
device.
#### 3.8.3.1\. Presentation of Notifications
If device implementations allow third party apps to [notify users of notable events](
http://developer.android.com/guide/topics/ui/notifiers/notifications.html), they:
* [C-1-1] MUST support notifications that use hardware features, as described in
the SDK documentation, and to the extent possible with the device implementation
hardware. For instance, if a device implementation includes a vibrator, it MUST
correctly implement the vibration APIs. If a device implementation lacks
hardware, the corresponding APIs MUST be implemented as no-ops. This behavior is
further detailed in [section 7](#7_hardware_compatibility).
* [C-1-2] MUST correctly render all [resources](
https://developer.android.com/guide/topics/resources/available-resources.html)
(icons, animation files etc.) provided for in the APIs, or in the
Status/System Bar [icon style guide](
http://developer.android.com/design/style/iconography.html), although they
MAY provide an alternative user experience for notifications than that
provided by the reference Android Open Source implementation.
* [C-1-3] MUST honor and implement properly the behaviors described for
[the APIs](
https://developer.android.com/guide/topics/ui/notifiers/notifications.html#Managing)
to update, remove and group notifications.
* [C-1-4] MUST provide the full behavior of the [NotificationChannel](
https://developer.android.com/reference/android/app/NotificationChannel.html)
API documented in the SDK.
* [C-1-5] MUST provide a user affordance to block and modify a certain
third-party app's notification per each channel and app package level.
* [C-1-6] MUST also provide a user affordance to display deleted notification
channels.
* SHOULD support rich notifications.
* SHOULD present some higher priority notifications as heads-up notifications.
* SHOULD have user affordance to snooze notifications.
* 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.
If device implementations support rich notifications, they:
* [C-2-1] MUST use the exact resources as
provided through the [`Notification.Style`](
https://developer.android.com/reference/android/app/Notification.Style.html)
API class and its subclasses for the presented resource elements.
* SHOULD present each and every resource element (e.g.
icon, title and summary text) defined in the [`Notification.Style`](
https://developer.android.com/reference/android/app/Notification.Style.html)
API class and its subclasses.
If device impelementations support heads-up notifications: they:
* [C-3-1] MUST use the heads-up notification view and resources
as described in the [`Notification.Builder`](
https://developer.android.com/reference/android/app/Notification.Builder.html)
API class when heads-up notifications are presented.
#### 3.8.3.2\. Notification Listener Service
Android includes the [`NotificationListenerService`](
https://developer.android.com/reference/android/service/notification/NotificationListenerService.html)
APIs that allow apps (once explicitly enabled by the user) to receive a copy of
all notifications as they are posted or updated.
Device implementations:
* [C-0-1] MUST correctly and promptly update notifications in their entirety to all
such installed and user-enabled listener services, including any and all
metadata attached to the Notification object.
* [C-0-2] MUST respect the [`snoozeNotification()`](
https://developer.android.com/reference/android/service/notification/NotificationListenerService.html#snoozeNotification%28java.lang.String, long%29)
API call, and dismiss the notification and make a callback after the snooze
duration that is set in the API call.
If device implementations have a user affordance to snooze notifications, they:
* [C-1-1] MUST reflect the snoozed notification status properly
through the standard APIs such as
[`NotificationListenerService.getSnoozedNotifications()`](
https://developer.android.com/reference/android/service/notification/NotificationListenerService.html#getSnoozedNotifications%28%29).
* [C-1-2] MUST make this user affordance available to snooze notifications
from each installed third-party app's, unless they are from
persistent/foreground services.
#### 3.8.3.3\. DND (Do not Disturb)
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
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)
created by applications alongside the user-created and pre-defined rules.
* [C-1-3] MUST honor the [`suppressedVisualEffects`](https://developer.android.com/reference/android/app/NotificationManager.Policy.html#suppressedVisualEffects)
values passed along the [`NotificationManager.Policy`](https://developer.android.com/reference/android/app/NotificationManager.Policy.html#NotificationManager.Policy%28int, int, int, int%29)
and if an app has set any of the SUPPRESSED_EFFECT_SCREEN_OFF or
SUPPRESSED_EFFECT_SCREEN_ON flags, it SHOULD indicate to the user that the
visual effects are suppressed in the DND settings menu.
### 3.8.4\. Search
Android includes APIs that allow developers to
[incorporate search](http://developer.android.com/reference/android/app/SearchManager.html)
into their applications and expose their application’s data into the global
system search. Generally speaking, this functionality consists of a single,
system-wide user interface that allows users to enter queries, displays
suggestions as users type, and displays results. The Android APIs allow
developers to reuse this interface to provide search within their own apps and
allow developers to supply results to the common global search user interface.
* Android device implementations SHOULD include global search, a single, shared,
system-wide search user interface capable of real-time suggestions in response
to user input.
If device implementations implement the global search interface, they:
* [C-1-1] MUST implement the APIs that allow third-party applications to add
suggestions to the search box when it is run in global search mode.
If no third-party applications are installed that make use of the global search:
* The default behavior SHOULD be to display web search engine results and
suggestions.
Android also includes the [Assist APIs](
https://developer.android.com/reference/android/app/assist/package-summary.html)
to allow applications to elect how much information of the current context is
shared with the assistant on the device.
If device implementations support the Assist action, they:
* [C-2-1] MUST indicate clearly to the end user when the context is shared, by
either:
* Each time the assist app accesses the context, displaying a white
light around the edges of the screen that meet or exceed the duration and
brightness of the Android Open Source Project implementation.
* For the preinstalled assist app, providing a user affordance less
than two navigations away from
[the default voice input and assistant app settings menu](#3_2_3_5_default_app_settings),
and only sharing the context when the assist app is explicitly invoked by
the user through a hotword or assist navigation key input.
* [C-2-2] The designated interaction to launch the assist app as described
in [section 7.2.3](#7_2_3_navigation_keys) MUST launch the user-selected
assist app, in other words the app that implements `VoiceInteractionService`,
or an activity handling the `ACTION_ASSIST` intent.
* [SR] STRONGLY RECOMMENDED to use long press on `HOME` key as this designated
interaction.
### 3.8.5\. Alerts and Toasts
Applications can use the [`Toast`](
http://developer.android.com/reference/android/widget/Toast.html)
API to display short non-modal strings to the end user that disappear after a
brief period of time, and use the [`TYPE_APPLICATION_OVERLAY`](
http://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#TYPE_APPLICATION_OVERLAY)
window type API to display alert windows as an overlay over other apps.
If device implementations include a screen or video output, they:
* [C-1-1] MUST provide a user affordance to block an app from displaying alert
windows that use the [`TYPE_APPLICATION_OVERLAY`](
http://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#TYPE_APPLICATION_OVERLAY)
. The AOSP implementation meets this requirement by having controls in the notification shade.
* [C-1-2] MUST honor the Toast API and display Toasts from applications to end users in some highly
visible manner.
### 3.8.6\. Themes
Android provides “themes” as a mechanism for applications to apply styles across
an entire Activity or application.
Android includes a “Holo” and "Material" theme family as a set of defined styles
for application developers to use if they want to match the
[Holo theme look and feel](http://developer.android.com/guide/topics/ui/themes.html)
as defined by the Android SDK.
If device implementations include a screen or video output, they:
* [C-1-1] MUST NOT alter any of the [Holo theme attributes](
http://developer.android.com/reference/android/R.style.html) exposed to
applications.
* [C-1-2] MUST support the “Material” theme family and MUST NOT alter any of
the [Material theme attributes](
http://developer.android.com/reference/android/R.style.html#Theme_Material)
or their assets exposed to applications.
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
device theme as defined by the device implementer.
* Device implementations MAY modify the [Device Default theme attributes](
http://developer.android.com/reference/android/R.style.html) exposed to
applications.
Android supports a variant theme with translucent system bars, which allows
application developers to fill the area behind the status and navigation bar
with their app content. To enable a consistent developer experience in this
configuration, it is important the status bar icon style is maintained across
different device implementations.
If device implementations include a system status bar, they:
* [C-2-1] MUST use white for system status icons (such as signal strength and
battery level) and notifications issued by the system, unless the icon is
indicating a problematic status or an app requests a light status bar using
the SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag.
* [C-2-2] Android device implementations MUST change the color of the system
status icons to black (for details, refer to [R.style](
http://developer.android.com/reference/android/R.style.html)) when an app
requests a light status bar.
### 3.8.7\. Live Wallpapers
Android defines a component type and corresponding API and lifecycle that allows
applications to expose one or more
[“Live Wallpapers”](http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html)
to the end user. Live wallpapers are animations, patterns, or similar images
with limited input capabilities that display as a wallpaper, behind other
applications.
Hardware is considered capable of reliably running live wallpapers if it can run
all live wallpapers, with no limitations on functionality, at a reasonable frame
rate with no adverse effects on other applications. If limitations in the
hardware cause wallpapers and/or applications to crash, malfunction, consume
excessive CPU or battery power, or run at unacceptably low frame rates, the
hardware is considered incapable of running live wallpaper. As an example, some
live wallpapers may use an OpenGL 2.0 or 3.x context to render their content.
Live wallpaper will not run reliably on hardware that does not support multiple
OpenGL contexts because the live wallpaper use of an OpenGL context may conflict
with other applications that also use an OpenGL context.
* Device implementations capable of running live wallpapers reliably as described
above SHOULD implement live wallpapers.
If device implementations implement live wallpapers, they:
* [C-1-1] MUST report the platform feature flag android.software.live_wallpaper.
### 3.8.8\. Activity Switching
The upstream Android source code includes the
[overview screen](https://developer.android.com/guide/components/activities/recents.html), a
system-level user interface for task switching and displaying recently accessed
activities and tasks using a thumbnail image of the application’s graphical
state at the moment the user last left the application.
Device implementations
including the recents function navigation key as detailed in
[section 7.2.3](#7_2_3_navigation_keys) MAY alter the interface.
If device implementations including the recents function navigation key as detailed in
[section 7.2.3](#7_2_3_navigation_keys) alter the interface, they:
* [C-1-1] MUST support at least up to 20 displayed activities.
* SHOULD at least display the title of 4 activities at a time.
* [C-1-2] MUST implement the [screen pinning behavior](http://developer.android.com/about/versions/android-5.0.html#ScreenPinning)
and provide the user with a settings menu to toggle the feature.
* SHOULD display highlight color, icon, screen title in recents.
* SHOULD display a closing affordance ("x") but MAY delay this until user interacts with screens.
* SHOULD implement a shortcut to switch easily to the previous activity
* SHOULD trigger the fast-switch action between the two most recently used
apps, when the recents function key is tapped twice.
* SHOULD trigger the split-screen multiwindow-mode, if supported, when the
recents functions key is long pressed.
* MAY display affiliated recents as a group that moves together.
* [SR] Device implementations are STRONGLY RECOMMENDED to use the upstream Android user
interface (or a similar thumbnail-based interface) for the overview screen.
### 3.8.9\. Input Management
Android includes support for
[Input Management](http://developer.android.com/guide/topics/text/creating-input-method.html)
and support for third-party input method editors.
If device implementations allow users to use third-party input methods on the
device, they:
* [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
The Remote Control Client API is deprecated from Android 5.0 in favor of the
[Media Notification Template](http://developer.android.com/reference/android/app/Notification.MediaStyle.html)
that allows media applications to integrate with playback controls that are
displayed on the lock screen.
### 3.8.11\. Screen savers (previously Dreams)
Android includes support for [interactivescreensavers](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 toconfigure screen savers in response to the
`android.settings.DREAM_SETTINGS` intent.
### 3.8.12\. Location
If device implementations include a hardware sensor (e.g. GPS) that is capable
of providing the location coordinates:
* [C-1-1] [location modes](
http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE)
MUST be displayed in the Location menu within Settings.
### 3.8.13\. Unicode and Font
Android includes support for the emoji characters defined in
[Unicode 10.0](http://www.unicode.org/versions/Unicode10.0.0/).
If device implementations include a screen or video output, they:
* [C-1-1] MUST be capable of rendering these emoji characters in color glyph.
* [C-1-2] MUST include support for:
* Roboto 2 font with different weights—sans-serif-thin, sans-serif-light,
sans-serif-medium, sans-serif-black, sans-serif-condensed,
sans-serif-condensed-light for the languages available on the device.
* Full Unicode 7.0 coverage of Latin, Greek, and Cyrillic, including the
Latin Extended A, B, C, and D ranges, and all glyphs in the currency
symbols block of Unicode 7.0.
* SHOULD support the skin tone and diverse family emojis as specified in the
[Unicode Technical Report #51](http://unicode.org/reports/tr51).
If device implementations include an IME, they:
* SHOULD provide an input method to the user for these emoji characters.
### 3.8.14\. Multi-windows
If device implementations have the capability to display multiple activities at
the same time, they:
* [C-1-1] MUST implement such multi-window mode(s) in accordance with the
application behaviors and APIs described in the Android SDK
[multi-window mode support documentation](
https://developer.android.com/guide/topics/ui/multi-window.html) and meet
the following requirements:
* [C-1-2] Applications can indicate whether they are capable of operating in
multi-window mode in the `AndroidManifest.xml` file, either explicitly via
setting the [`android:resizeableActivity`](https://developer.android.com/reference/android/R.attr.html#resizeableActivity)
attribute to `true` or implicitly by having the targetSdkVersion > 24. Apps that
explicitly set this attribute to `false` in their manifest MUST NOT be
launched in multi-window mode. Older apps with targetSdkVersion < 24 that
did not set this `android:resizeableActivity` attribute MAY be launched in
multi-window mode, but the system MUST provide warning that the app may not
work as expected in multi-window mode.
* [C-1-3] MUST NOT offer split-screen or freeform mode if
the screen height < 440 dp and the the screen width < 440 dp.
* Device implementations with screen size `xlarge` SHOULD support freeform
mode.
If device implementations support multi-window mode(s), and the split screen
mode, they:
* [C-2-1] MUST preload a [resizeable](
https://developer.android.com/guide/topics/ui/multi-window.html#configuring)
launcher as the default.
* [C-2-2] MUST crop the docked activity of a split-screen multi-window but
SHOULD show some content of it, if the Launcher app is the focused window.
* [C-2-3] MUST honor the declared [`AndroidManifestLayout_minWidth`](
https://developer.android.com/reference/android/R.styleable.html#AndroidManifestLayout_minWidth)
and [`AndroidManifestLayout_minHeight`](
https://developer.android.com/reference/android/R.styleable.html#AndroidManifestLayout_minHeight)
values of the third-party launcher application and not override these values
in the course of showing some content of the docked activity.
If device implementations support multi-window mode(s) and Picture-in-Picture
multi-window mode, they:
* [C-3-1] MUST launch activities in picture-in-picture multi-window mode
when the app is:
* Targeting API level 26 or higher and declares
[`android:supportsPictureInPicture`](https://developer.android.com/reference/android/R.attr.html#supportsPictureInPicture)
* Targeting API level 25 or lower and declares both [`android:resizeableActivity`](https://developer.android.com/reference/android/R.attr.html#resizeableActivity)
and [`android:supportsPictureInPicture`](https://developer.android.com/reference/android/R.attr.html#supportsPictureInPicture).
* [C-3-2] MUST expose the actions in their SystemUI as
specified by the current PIP activity through the [`setActions()`](
https://developer.android.com/reference/android/app/PictureInPictureParams.Builder.html#setActions%28java.util.List<android.app.RemoteAction>%29)
API.
* [C-3-3] MUST support aspect ratios greater than or equal to
1:2.39 and less than or equal to 2.39:1, as specified by the PIP activity through
the [`setAspectRatio()`](
https://developer.android.com/reference/android/app/PictureInPictureParams.Builder.html#setAspectRatio%28android.util.Rational%29)
API.
* [C-3-4] MUST use [`KeyEvent.KEYCODE_WINDOW`](
https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_WINDOW)
to control the PIP window; if PIP mode is not implemented, the key MUST be
available to the foreground activity.
* [C-3-5] MUST provide a user affordance to block an app from displaying in
PIP mode; the AOSP implementation meets this requirement by having
controls in the notification shade.
* [C-3-6] MUST allocate minimum width and height of 108 dp for the PIP window
and minimum width of 240 dp and height of 135 dp for the PIP window when the
`Configuration.uiMode` is configured as [`UI_MODE_TYPE_TELEVISION`](
https://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_TELEVISION)

146
android/compatibility/cdd/3_software/3_9_device-administration.md Normal file
View file

@ -0,0 +1,146 @@
## 3.9\. Device Administration
Android includes features that allow security-aware applications to perform
device administration functions at the system level, such as enforcing password
policies or performing remote wipe, through the
[Android Device Administration API](http://developer.android.com/guide/topics/admin/device-admin.html)].
If device implementations implement the full range of [device administration](
http://developer.android.com/guide/topics/admin/device-admin.html)
policies defined in the Android SDK documentation, they:
* [C-1-1] MUST declare `android.software.device_admin`.
* [C-1-2] MUST support device owner provisioning as described in
[section 3.9.1](#3_9_1_device_provisioning) and
[section 3.9.1.1](#3_9_1_1_device_owner_provisioning).
* [C-1-3] MUST declare the support of manged profiles via the
`android.software.managed_users` feature flag, except for when the device is
configured so that it would [report](
http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
itself as a low RAM device or so that it allocate internal (non-removable)
storage as shared storage.
### 3.9.1 Device Provisioning
#### 3.9.1.1 Device owner provisioning
If device implementations declare `android.software.device_admin`, they:
* [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a
[Device Owner app](
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp%28java.lang.String%29)
as described below:.
* when the device implementation has no user data is configured yet, it:
* [C-1-3] MUST report `true` for [`DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#isProvisioningAllowed\(java.lang.String\)).
* [C-1-4] MUST enroll the DPC application as the Device Owner app in
response to the intent action [`android.app.action.PROVISION_MANAGED_DEVICE`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE).
* [C-1-5] MUST enroll the DPC application as the Device Owner app if the
device declares Near-Field Communications (NFC) support via the feature
flag `android.hardware.nfc` and receives an NFC message containing a
record with MIME type [`MIME_TYPE_PROVISIONING_NFC`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#MIME_TYPE_PROVISIONING_NFC).
* When the device implementation has user data, it:
* [C-1-6] MUST report `false` for the [`DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#isProvisioningAllowed\(java.lang.String\)).
* [C-1-7] MUST not enroll any DPC application as the Device Owner App
any more.
* [C-1-2] MUST NOT set an application (including pre-installed app) as the
Device Owner app without explicit consent or action from the user or the
administrator of the device.
If device implementations declare `android.software.device_admin`, but also
include a proprietary Device Owner management solution and provide a mechanism
to promote an application configured in their solution as a "Device Owner
equivalent" to the standard "Device Owner" as recognized by the standard Android
[DevicePolicyManager](
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html)
APIs, they:
* [C-2-1] MUST have a process in place to verify that the specific app
being promoted belongs to a legitimate enterprise device management
solution and it has been already configured in the proprietary solution
to have the rights equivalent as a "Device Owner".
* [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the
flow initiated by [`android.app.action.PROVISION_MANAGED_DEVICE`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE)
prior to enrolling the DPC application as "Device Owner".
* MAY have user data on the device prior to enrolling the DPC application
as "Device Owner".
#### 3.9.1.2 Managed profile provisioning
If device implementations declare `android.software.managed_users`, they:
* [C-1-1] MUST implement the [APIs](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE)
allowing a Device Policy Controller (DPC) application to become the
[owner of a new Managed Profile](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp%28java.lang.String%29).
* [C-1-2] The managed profile provisioning process (the flow initiated by
[android.app.action.PROVISION_MANAGED_PROFILE](
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE))
users experience MUST align with the AOSP implementation.
* [C-1-3] MUST provide the following user affordances within the Settings to
indicate to the user when a particular system function has been disabled by
the Device Policy Controller (DPC):
* A consistent icon or other user affordance (for example the upstream
AOSP info icon) to represent when a particular setting is restricted by
a Device Admin.
* A short explanation message, as provided by the Device Admin via the
[`setShortSupportMessage`](
https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage%28android.content.ComponentName, java.lang.CharSequence%29).
* The DPC application’s icon.
## 3.9.2 Managed Profile Support
If device implementations declare `android.software.managed_users`, they:
* [C-1-1] MUST support managed profiles via the `android.app.admin.DevicePolicyManager`
APIs.
* [C-1-2] MUST allow one and only [one managed profile to be created](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE).
* [C-1-3] MUST use an icon badge (similar to the AOSP upstream work badge) to
represent the managed applications and widgets and other badged UI elements
like Recents &amp; Notifications.
* [C-1-4] MUST display a notification icon (similar to the AOSP upstream work
badge) to indicate when user is within a managed profile application.
* [C-1-5] MUST display a toast indicating that the user is in the managed
profile if and when the device wakes up (ACTION_USER_PRESENT) and the
foreground application is within the managed profile.
* [C-1-6] Where a managed profile exists, MUST show a visual affordance in the
Intent 'Chooser' to allow the user to forward the intent from the managed
profile to the primary user or vice versa, if enabled by the Device Policy
Controller.
* [C-1-7] Where a managed profile exists, MUST expose the following user
affordances for both the primary user and the managed profile:
* Separate accounting for battery, location, mobile data and storage usage
for the primary user and managed profile.
* Independent management of VPN Applications installed within the primary
user or managed profile.
* Independent management of applications installed within the primary user
or managed profile.
* Independent management of accounts within the primary user or managed
profile.
* [C-1-8] MUST ensure the preinstalled dialer, contacts and messaging
applications can search for and look up caller information from the managed
profile (if one exists) alongside those from the primary profile, if the
Device Policy Controller permits it.
* [C-1-9] MUST ensure that it satisfies all the security requirements
applicable for a device with multiple users enabled
(see[section 9.5](#9_5_multi-user_support)), even though the managed profile
is not counted as another user in addition to the primary user.
* [C-1-10] MUST support the ability to specify a separate lock screen meeting
the following requirements to grant access to apps running in a managed
profile.
* Device implementations MUST honor the
[`DevicePolicyManager.ACTION_SET_NEW_PASSWORD`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_SET_NEW_PASSWORD)
intent and show an interface to configure a separate lock screen
credential for the managed profile.
* The lock screen credentials of the managed profile MUST use the same
credential storage and management mechanisms as the parent profile,
as documented on the
[Android Open Source Project Site](http://source.android.com/security/authentication/index.html)
* The DPC [password policies](https://developer.android.com/guide/topics/admin/device-admin.html#pwd)
MUST apply to only the managed profile's lock screen credentials unless
called upon the `DevicePolicyManager` instance returned by
<a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#getParentProfileInstance%28android.content.ComponentName%29">getParentProfileInstance</a>.
* When contacts from the managed profile are displayed
in the preinstalled call log, in-call UI, in-progress and missed-call
notifications, contacts and messaging apps they SHOULD be badged with the
same badge used to indicate managed profile applications.