Docs: Final cleanup for CDD source.
- Fix rowspan in table in section 2.1.
- Put markdown links on a single line.
- Escape parentheses in URLs.
- Fix some internal links with dashes instead of underscores.
- Replace tabs with spaces.
- Other misc. cleanup.
Bug: 32070486
Change-Id: Ie44202b5a0bfe7133505880a0a9c74f08a9bac1f
diff --git a/10_software-compatibility-testing/10_1_compatibility_test_suite.md b/10_software-compatibility-testing/10_1_compatibility_test_suite.md
index dc45335..5dba74d 100644
--- a/10_software-compatibility-testing/10_1_compatibility_test_suite.md
+++ b/10_software-compatibility-testing/10_1_compatibility_test_suite.md
@@ -1,12 +1,12 @@
## 10.1\. Compatibility Test Suite
-Device implementations MUST pass the [Android Compatibility Test Suite
-(CTS)](http://source.android.com/compatibility/index.html) available from the
-Android Open Source Project, using the final shipping software on the device.
-Additionally, device implementers SHOULD use the reference implementation in
-the Android Open Source tree as much as possible, and MUST ensure compatibility
-in cases of ambiguity in CTS and for any reimplementations of parts of the
-reference source code.
+Device implementations MUST pass the
+[Android Compatibility Test Suite (CTS)](http://source.android.com/compatibility/index.html)
+available from the Android Open Source Project, using the final shipping
+software on the device. Additionally, device implementers SHOULD use the
+reference implementation in the Android Open Source tree as much as possible,
+and MUST ensure compatibility in cases of ambiguity in CTS and for any
+reimplementations of parts of the reference source code.
The CTS is designed to be run on an actual device. Like any software, the CTS
may itself contain bugs. The CTS will be versioned independently of this
diff --git a/13_contact-us/13_0_intro.md b/13_contact-us/13_0_intro.md
index 0332715..5eb1094 100644
--- a/13_contact-us/13_0_intro.md
+++ b/13_contact-us/13_0_intro.md
@@ -1,6 +1,5 @@
# 13\. Contact Us
-You can join the [android-compatibility
-forum](https://groups.google.com/forum/#!forum/android-compatibility) and ask
-for clarifications or bring up any issues that you think the document does not
+You can join the [android-compatibility forum](https://groups.google.com/forum/#!forum/android-compatibility)
+and ask for clarifications or bring up any issues that you think the document does not
cover.
diff --git a/2_device-types/2_1_device-configurations.md b/2_device-types/2_1_device-configurations.md
index a44309b..3bf6dc1 100644
--- a/2_device-types/2_1_device-configurations.md
+++ b/2_device-types/2_1_device-configurations.md
@@ -63,7 +63,7 @@
<td></td>
</tr>
<tr>
- <td rowspan="5">Connectivity</td>
+ <td rowspan="6">Connectivity</td>
<td>Wi-Fi</td>
<td><a href="#7_4_2_ieee_802.11">7.4.2. IEEE 802.11</a></td>
<td>SHOULD</td>
@@ -101,7 +101,7 @@
</tr>
<tr>
<td>Cellular radio</td>
- <td><a href="#7_4_5_minimum-network-capability">
+ <td><a href="#7_4_5_minimum_network_capability">
7.4.5. Minimum Network Capability</a></td>
<td></td>
<td></td>
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 0f7a484..0c9ad6c 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -81,7 +81,7 @@
Android Television device implementations are STRONGLY RECOMMENDED to support
TV recording. If the TV input supports recording, the EPG MAY provide a way to
-[record a program](https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord())
+[record a program](https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29)
if the recording of such a program is not
[prohibited](https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED).
Device implementations SHOULD provide a user interface to play recorded programs.
diff --git a/3_software/3_1_managed-api-compatibility.md b/3_software/3_1_managed-api-compatibility.md
index fde3dca..f35836c 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -5,9 +5,8 @@
set of Android platform interfaces exposed to applications running in the
managed runtime environment. 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.
+exposed by the [Android SDK](http://developer.android.com/reference/packages.html)
+or any API decorated with the “@SystemApi” marker in the upstream Android source code.
Device implementations MUST support/preserve all classes, methods, and
associated elements marked by the TestApi annotation (@TestApi).
@@ -18,14 +17,14 @@
This Compatibility Definition permits some types of hardware for which Android
includes APIs to be omitted by device implementations. In such cases, the APIs
-MUST still be present and behave in a reasonable way. See [section
-7](#7_hardware_compatibility) for specific requirements for this scenario.
+MUST still be present and behave in a reasonable way. 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. 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.
+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.
\ No newline at end of file
+at least version 1.
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 419096a..d7d117e 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -1,28 +1,26 @@
## 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.
+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
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).
+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. 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.
+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. 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>
@@ -117,15 +115,15 @@
<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>
- $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
- <p>For example:</p>
- <p class="small">acme/myproduct/<br>
- 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>
+ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
+ <p>For example:</p>
+<p class="small">acme/myproduct/<br>
+ 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>
@@ -250,8 +248,7 @@
#### 3.2.3.2\. Intent Resolution
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
+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; device implementers MUST NOT attach special privileges to system
applications' use of these intent patterns, or prevent third-party applications
@@ -270,15 +267,13 @@
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:
+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:
* 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
+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.
* MUST attempt validation of the intent filters during the installation of
the application and set all successfully validated UIR intent filters as
@@ -309,10 +304,10 @@
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. 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
+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
@@ -345,8 +340,7 @@
[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 the device
implementation reports android.hardware.nfc.hce.
-* MUST honor the [`android.telecom.action.CHANGE_DEFAULT_DIALER`]
-(https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER)
+* 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 the
device implementation reports `android.hardware.telephony`.
* MUST honor the [android.settings.ACTION_VOICE_INPUT_SETTINGS](https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS)
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 3d4883e..038dda5 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -108,10 +108,10 @@
* MUST implement an activity where the user can grant or deny the app access
to DND policy configurations in response to the intent [ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS](https://developer.android.com/reference/android/provider/Settings.html#ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS).
-* MUST display [Automatic DND rules](https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule(android.app.AutomaticZenRule))
+* MUST 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.
* 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(int, int, int, int)).
+ values passed along the [`NotificationManager.Policy`](https://developer.android.com/reference/android/app/NotificationManager.Policy.html#NotificationManager.Policy%28int, int, int, int%29).
### 3.8.4\. Search
@@ -208,7 +208,8 @@
### 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)
+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.
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index b6ccb7e..d1cfb00 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -55,7 +55,7 @@
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(android.content.ComponentName, java.lang.CharSequence).
+ [`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
@@ -117,5 +117,5 @@
* 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(android.content.ComponentName)">getParentProfileInstance</a>..
+ <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#getParentProfileInstance%28android.content.ComponentName%29">getParentProfileInstance</a>.
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 1185450..6edd734 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -1,13 +1,12 @@
# 4\. Application Packaging Compatibility
Device implementations MUST install and run Android “.apk” files as generated
-by the “aapt” tool included in the [official Android
-SDK](http://developer.android.com/tools/help/index.html). For this reason device
-implementations SHOULD use the reference implementation’s package management
-system.
+by the “aapt” tool included in the [official Android SDK](http://developer.android.com/tools/help/index.html).
+For this reason device implementations SHOULD use the reference implementation’s
+package management system.
-The package manager MUST support verifying “.apk” files using the [APK Signature
-Scheme v2](https://source.android.com/security/apksigning/v2.html).
+The package manager MUST support verifying “.apk” files using the
+[APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html).
Devices implementations MUST NOT extend either the
[.apk](http://developer.android.com/guide/components/fundamentals.html),
@@ -22,4 +21,4 @@
permission. The only exceptions are the system package verifier app handling
[PACKAGE_NEEDS_VERIFICATION](https://developer.android.com/reference/android/content/Intent.html#ACTION_PACKAGE_NEEDS_VERIFICATION)
intent and the storage manager app handling [ACTION_MANAGE_STORAGE](https://developer.android.com/reference/android/os/storage/StorageManager.html#ACTION_MANAGE_STORAGE)
-intent.
\ No newline at end of file
+intent.
diff --git a/5_multimedia/5_2_video-encoding.md b/5_multimedia/5_2_video-encoding.md
index c19a23a..f115f40 100644
--- a/5_multimedia/5_2_video-encoding.md
+++ b/5_multimedia/5_2_video-encoding.md
@@ -28,7 +28,7 @@
### 5.2.2\. H-264
-Android device implementations with H.264 codec support&emdash;
+Android device implementations with H.264 codec support:
* MUST support Baseline Profile Level 3.<br>
However, support for ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock
@@ -77,7 +77,7 @@
### 5.2.3\. VP8
-Android device implementations with VP8 codec support MUST support the SD video
+Android device implementations with VP8 codec support MUST support the SD video
encoding profiles and SHOULD support the following HD (High Definition) video encoding profiles.
<table>
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 9a5bec5..48cc645 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -19,8 +19,7 @@
### 5.5.2\. Audio Effects
-Android provides an [API for audio
-effects](http://developer.android.com/reference/android/media/audiofx/AudioEffect.html)
+Android provides an [API for audio effects](http://developer.android.com/reference/android/media/audiofx/AudioEffect.html)
for device implementations. Device implementations that declare the feature
android.hardware.audio.output:
diff --git a/5_multimedia/5_7_network-protocols.md b/5_multimedia/5_7_network-protocols.md
index 70b9b49..409d38d 100644
--- a/5_multimedia/5_7_network-protocols.md
+++ b/5_multimedia/5_7_network-protocols.md
@@ -1,16 +1,14 @@
## 5.7\. Network Protocols
-Devices MUST support the [media network
-protocols](http://developer.android.com/guide/appendix/media-formats.html) for
-audio and video playback as specified in the Android SDK documentation.
+Devices MUST support the [media network protocols](http://developer.android.com/guide/appendix/media-formats.html)
+for audio and video playback as specified in the Android SDK documentation.
Specifically, devices MUST support the following media network protocols:
* HTTP(S) progressive streaming <br>
All required codecs and container formats in [section 5.1](#5_1_media_codecs) MUST
be supported over HTTP(S)
-* [HTTP Live Streaming draft protocol, Version 7
- ](http://tools.ietf.org/html/draft-pantos-http-live-streaming-07)<br>
+* [HTTP Live Streaming draft protocol, Version 7 ](http://tools.ietf.org/html/draft-pantos-http-live-streaming-07)<br>
The following media segment formats MUST be supported:
<table>
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 8ce161f..b412570 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -16,7 +16,7 @@
* [**Dalvik Debug Monitor Service (ddms)**](http://developer.android.com/tools/debugging/ddms.html)
* Device implementations MUST support all ddms features as documented in the Android SDK.
* As ddms uses adb, support for ddms SHOULD be inactive by default, but MUST be supported whenever the user has activated the Android Debug Bridge, as above.
-* [**Monkey**](http://developer.android.com/tools/help/monkey.html). Device
+* [**Monkey**](http://developer.android.com/tools/help/monkey.html) Device
implementations MUST include the Monkey framework, and make it available for
applications to use.
* [**SysTrace**](http://developer.android.com/tools/help/systrace.html)
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 67f5882..ddd0cfd 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -2,8 +2,7 @@
Android includes facilities that automatically adjust application assets and UI
layouts appropriately for the device to ensure that third-party applications
-run well on a [variety of hardware
-configurations](http://developer.android.com/guide/practices/screens_support.html).
+run well on a [variety of hardware configurations](http://developer.android.com/guide/practices/screens_support.html).
Devices MUST properly implement these APIs and behaviors, as detailed in this
section.
@@ -34,8 +33,7 @@
The Android UI framework supports a variety of different screen sizes, and
allows applications to query the device screen size (aka “screen layout") via
android.content.res.Configuration.screenLayout with the SCREENLAYOUT_SIZE_MASK.
-Device implementations MUST report the correct [screen
-size](http://developer.android.com/guide/practices/screens_support.html) as
+Device implementations MUST report the correct [screen size](http://developer.android.com/guide/practices/screens_support.html) as
defined in the Android SDK documentation and determined by the upstream Android
platform. Specifically, device implementations MUST report the correct screen
size according to the following logical density-independent pixel (dp) screen
@@ -162,9 +160,8 @@
Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodied and
detailed in the Android SDK documentations. Device implementations SHOULD
support OpenGL ES 3.0, 3.1, or 3.2 on devices capable of supporting it. Device
-implementations MUST also support [Android
-RenderScript](http://developer.android.com/guide/topics/renderscript/), as
-detailed in the Android SDK documentation.
+implementations MUST also support [Android RenderScript](http://developer.android.com/guide/topics/renderscript/),
+as detailed in the Android SDK documentation.
Device implementations MUST also correctly identify themselves as supporting
OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1, or OpenGL 3.2\. That is:
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index ae76674..c6ffb72 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -156,8 +156,7 @@
corresponding to the type of the specific touchscreen on the device.
Android includes support for a variety of touchscreens, touch pads, and fake
-touch input devices. [Touchscreen based device
-implementations](http://source.android.com/devices/tech/input/touch-devices.html)
+touch input devices. [Touchscreen-based device implementations](http://source.android.com/devices/tech/input/touch-devices.html)
are associated with a display such that the user has the impression of directly
manipulating items on screen. Since the user is directly touching the screen,
the system does not require any additional affordances to indicate the objects
@@ -188,9 +187,8 @@
Device implementations that declare support for android.hardware.faketouch:
-* MUST report the [absolute X and Y screen
-positions](http://developer.android.com/reference/android/view/MotionEvent.html)of
-the pointer location and display a visual pointer on the screen.
+* MUST report the [absolute X and Y screen positions](http://developer.android.com/reference/android/view/MotionEvent.html)
+of the pointer location and display a visual pointer on the screen.
* MUST report touch event with the action code that specifies the state change
that occurs on the pointer [going down or up on the
screen](http://developer.android.com/reference/android/view/MotionEvent.html).
@@ -198,9 +196,8 @@
users to emulate tap on an object on the screen.
* MUST support pointer down, pointer up, pointer down then pointer up in the
same place on an object on the screen within a time threshold, which allows
-users to [emulate double
-tap](http://developer.android.com/reference/android/view/MotionEvent.html) on an
-object on the screen.
+users to [emulate double tap](http://developer.android.com/reference/android/view/MotionEvent.html)
+on an object on the screen.
* MUST support pointer down on an arbitrary point on the screen, pointer move
to any other arbitrary point on the screen, followed by a pointer up, which
allows users to emulate a touch drag.
@@ -360,6 +357,5 @@
* **Search affordance**. Device implementations MUST fire KEYCODE_SEARCH when
the user invokes voice search either on the physical or software-based remote.
-* **Navigation**. All Android Television remotes MUST include [Back, Home, and
-Select buttons and support for D-pad
-events](http://developer.android.com/reference/android/view/KeyEvent.html).
+* **Navigation**. All Android Television remotes MUST include
+[Back, Home, and Select buttons and support for D-pad events](http://developer.android.com/reference/android/view/KeyEvent.html).
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 8826a12..ae52633 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -18,12 +18,10 @@
true or false as appropriate when applications attempt to register listeners,
not calling sensor listeners when the corresponding sensors are not present;
etc.).
-* MUST [report all sensor
-measurements](http://developer.android.com/reference/android/hardware/SensorEvent.html)
+* MUST [report all sensor measurements](http://developer.android.com/reference/android/hardware/SensorEvent.html)
using the relevant International System of Units (metric) values for each
sensor type as defined in the Android SDK documentation.
-* SHOULD [report the event
-time](http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp)
+* 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
@@ -47,14 +45,12 @@
by one or more other sensors. (Examples include the orientation sensor and the
linear acceleration sensor.) Device implementations SHOULD implement these
sensor types, when they include the prerequisite physical sensors as described
-in [sensor
-types](https://source.android.com/devices/sensors/sensor-types.html). If a
+in [sensor types](https://source.android.com/devices/sensors/sensor-types.html). If a
device implementation includes a composite sensor it MUST implement the sensor
-as described in the Android Open Source documentation on [composite
-sensors](https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary).
+as described in the Android Open Source documentation on
+[composite sensors](https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary).
-Some Android sensors support a [“continuous” trigger
-mode](https://source.android.com/devices/sensors/report-modes.html#continuous),
+Some Android sensors support a [“continuous” trigger mode](https://source.android.com/devices/sensors/report-modes.html#continuous),
which returns data continuously. For any API indicated by the Android SDK
documentation to be a continuous sensor, device implementations MUST
continuously provide periodic data samples that SHOULD have a jitter below 3%,
@@ -75,14 +71,13 @@
RECOMMENDED to include this sensor. If a device implementation does include a
3-axis accelerometer, it:
-* MUST implement and report [TYPE_ACCELEROMETER
-sensor](http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER).
+* MUST implement and report
+[TYPE_ACCELEROMETER sensor](http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER).
* MUST be able to report events up to a frequency of at least 50 Hz for
Android Watch devices as such devices have a stricter power constraint and 100
Hz for all other device types.
* SHOULD report events up to at least 200 Hz.
-* MUST comply with the [Android sensor coordinate
-system](http://developer.android.com/reference/android/hardware/SensorEvent.html)
+* MUST comply with the [Android sensor coordinate system](http://developer.android.com/reference/android/hardware/SensorEvent.html)
as detailed in the Android APIs. Android Automotive implementations MUST comply
with the Android [car sensor coordinate system](http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
* MUST be capable of measuring from freefall up to four times the gravity
@@ -120,8 +115,7 @@
STRONGLY RECOMMENDED to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.
* MUST be able to report events up to a frequency of at least 10 Hz and
SHOULD report events up to at least 50 Hz.
-* MUST comply with the [Android sensor coordinate
-system](http://developer.android.com/reference/android/hardware/SensorEvent.html)
+* MUST comply with the [Android sensor coordinate system](http://developer.android.com/reference/android/hardware/SensorEvent.html)
as detailed in the Android APIs.
* MUST be capable of measuring between -900 µT and +900 µT on each axis
before saturating.
@@ -378,8 +372,8 @@
corresponding API for third-party developers, it:
* MUST declare support for the android.hardware.fingerprint feature.
-* MUST fully implement the [corresponding
-API](https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html)
+* MUST fully implement the
+[corresponding API](https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html)
as described in the Android SDK documentation.
* MUST have a false acceptance rate not higher than 0.002%.
* Is STRONGLY RECOMMENDED to have a false rejection rate of less than 10%, as
@@ -394,8 +388,8 @@
a secure channel to the TEE.
* MUST have all identifiable fingerprint data encrypted and cryptographically
authenticated such that they cannot be acquired, read or altered outside of the
-Trusted Execution Environment (TEE) as documented in the [implementation
-guidelines](https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
+Trusted Execution Environment (TEE) as documented in the
+[implementation guidelines](https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
on the Android Open Source Project site.
* MUST prevent adding a fingerprint without first establishing a chain of
trust by having the user confirm existing or add a new device credential
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 3e1f583..4ddedb4 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -30,9 +30,9 @@
'BlockedNumberProvider' without any interaction with apps. The only exception
is when number blocking is temporarily lifted as described in the SDK
documentation.
-* MUST NOT write to the [platform call log provider] (http://developer.android.com/reference/android/provider/CallLog.html)
+* MUST NOT write to the [platform call log provider](http://developer.android.com/reference/android/provider/CallLog.html)
for a blocked call.
-* MUST NOT write to the [Telephony provider] (http://developer.android.com/reference/android/provider/Telephony.html)
+* MUST NOT write to the [Telephony provider](http://developer.android.com/reference/android/provider/Telephony.html)
for a blocked message.
* MUST implement a blocked numbers management UI, which is opened with the
intent returned by TelecomManager.createManageBlockedNumbersIntent() method.
@@ -52,8 +52,7 @@
Android API and:
* MUST report the hardware feature flag android.hardware.wifi.
-* MUST implement the [multicast
-API](http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
+* MUST implement the [multicast API](http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
as described in the SDK documentation.
* MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets
(224.0.0.251) at any time of operation including:
@@ -65,8 +64,8 @@
Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi
peer-to-peer). If a device implementation does include support for Wi-Fi
-Direct, it MUST implement the [corresponding Android
-API](http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html)
+Direct, it MUST implement the
+[corresponding Android API](http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html)
as described in the SDK documentation. If a device implementation includes
support for Wi-Fi Direct, then it:
@@ -77,8 +76,7 @@
#### 7.4.2.2\. Wi-Fi Tunneled Direct Link Setup
Device implementations SHOULD include support for [Wi-Fi
-Tunneled Direct Link Setup
-(TDLS)](http://developer.android.com/reference/android/net/wifi/WifiManager.html)
+Tunneled Direct Link Setup (TDLS)](http://developer.android.com/reference/android/net/wifi/WifiManager.html)
as described in the Android SDK Documentation. If a device
implementation does include support for TDLS and TDLS is enabled by the
WiFiManager API, the device:
@@ -100,13 +98,13 @@
Device implementations that support `android.hardware.vr.high_performance` feature MUST
support Bluetooth 4.2 and Bluetooth LE Data Length Extension.
-Android includes support for [Bluetooth and Bluetooth Low
-Energy](http://developer.android.com/reference/android/bluetooth/package-summary.html)
-. Device implementations that include support for Bluetooth and Bluetooth Low
+Android includes support for
+[Bluetooth and Bluetooth Low Energy](http://developer.android.com/reference/android/bluetooth/package-summary.html).
+Device implementations that include support for Bluetooth and Bluetooth Low
Energy MUST declare the relevant platform features (android.hardware.bluetooth
-and android.hardware.bluetooth_le respectively) and implement the platform
-APIs. Device implementations SHOULD implement relevant Bluetooth profiles such
-as A2DP, AVCP, OBEX, etc. as appropriate for the device.
+and android.hardware.bluetooth_le respectively) and implement the platform APIs.
+Device implementations SHOULD implement relevant Bluetooth profiles such as
+A2DP, AVCP, OBEX, etc. as appropriate for the device.
Android Automotive implementations SHOULD support Message Access Profile (MAP).
Android Automotive implementations MUST support the following Bluetooth
@@ -127,8 +125,7 @@
timeout no longer than 15 minutes and rotate the address at timeout to protect
user privacy.
* 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),
+when implementing the [ScanFilter API](https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html),
and MUST report the correct value of where the filtering logic is implemented
whenever queried via the
android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method.
@@ -146,8 +143,7 @@
hardware and plans to make it available to third-party apps, then it:
* MUST report the android.hardware.nfc feature from the
-[android.content.pm.PackageManager.hasSystemFeature()
-method](http://developer.android.com/reference/android/content/pm/PackageManager.html).
+[android.content.pm.PackageManager.hasSystemFeature() method](http://developer.android.com/reference/android/content/pm/PackageManager.html).
* MUST be capable of reading and writing NDEF messages via the following NFC
standards:
* MUST be capable of acting as an NFC Forum reader/writer (as defined by
@@ -168,8 +164,7 @@
the future platform releases.
* NfcV (ISO 15693)
* SHOULD be capable of reading the barcode and URL (if encoded) of
-[Thinfilm NFC
-Barcode](http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html)
+[Thinfilm NFC Barcode](http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html)
products.
* MUST be capable of transmitting and receiving data via the following
peer-to-peer standards and protocols:
@@ -179,35 +174,32 @@
* [NDEF Push Protocol](http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf)
* SNEP 1.0 (defined by the NFC Forum)
* MUST include support for [Android Beam](http://developer.android.com/guide/topics/connectivity/nfc/nfc.html).
- * MUST implement the SNEP default server. Valid NDEF messages
+ * MUST implement the SNEP default server. Valid NDEF messages
received by the default SNEP server MUST be dispatched to applications using
the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in
settings MUST NOT disable dispatch of incoming NDEF message.
- * MUST honor the android.settings.NFCSHARING_SETTINGS intent to show
-[NFC sharing
-settings](http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS).
- * MUST implement the NPP server. Messages received by the NPP server
+ * MUST honor the android.settings.NFCSHARING_SETTINGS intent to show
+[NFC sharing settings](http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS).
+ * MUST implement the NPP server. Messages received by the NPP server
MUST be processed the same way as the SNEP default server.
- * MUST implement a SNEP client and attempt to send outbound P2P NDEF
+ * MUST implement a SNEP client and attempt to send outbound P2P NDEF
to the default SNEP server when Android Beam is enabled. If no default SNEP
server is found then the client MUST attempt to send to an NPP server.
- * MUST allow foreground activities to set the outbound P2P NDEF
+ * MUST allow foreground activities to set the outbound P2P NDEF
message using android.nfc.NfcAdapter.setNdefPushMessage, and
android.nfc.NfcAdapter.setNdefPushMessageCallback, and
android.nfc.NfcAdapter.enableForegroundNdefPush.
- * SHOULD use a gesture or on-screen confirmation, such as 'Touch to
+ * SHOULD use a gesture or on-screen confirmation, such as 'Touch to
Beam', before sending outbound P2P NDEF messages.
- * SHOULD enable Android Beam by default and MUST be able to send and
+ * SHOULD enable Android Beam by default and MUST be able to send and
receive using Android Beam, even when another proprietary NFC P2p mode is
turned on.
- * MUST support NFC Connection handover to Bluetooth when the device
+ * MUST support NFC Connection handover to Bluetooth when the device
supports Bluetooth Object Push Profile. Device implementations MUST support
connection handover to Bluetooth when using
-android.nfc.NfcAdapter.setBeamPushUris, by implementing the “[Connection
-Handover version
-1.2](http://members.nfc-forum.org/specs/spec_list/#conn_handover)” and
-“[Bluetooth Secure Simple Pairing Using NFC version
-1.0](http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf)”
+android.nfc.NfcAdapter.setBeamPushUris, by implementing the
+“[Connection Handover version 1.2](http://members.nfc-forum.org/specs/spec_list/#conn_handover)” and
+“[Bluetooth Secure Simple Pairing Using NFC version 1.0](http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf)”
specs from the NFC Forum. Such an implementation MUST implement the handover
LLCP service with service name “urn:nfc:sn:handover” for exchanging the
handover request/select records over NFC, and it MUST use the Bluetooth Object
@@ -333,7 +325,7 @@
Conversely if a device implementation does not provide the data saver mode, it:
* MUST return the value `RESTRICT_BACKGROUND_STATUS_DISABLED` for
- [`ConnectivityManager.getRestrictBackgroundStatus()`](https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus())
+ [`ConnectivityManager.getRestrictBackgroundStatus()`](https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus%28%29)
* MUST not broadcast `ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED`
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index fe963bf..6da8503 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -144,15 +144,14 @@
the android.hardware.camera2 API, device implementations MUST report the proper
level of support with the
[android.info.supportedHardwareLevel](https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL)
-property as described in the Android SDK and report the appropriate [framework
-feature flags](http://source.android.com/devices/camera/versioning.html).
+property as described in the Android SDK and report the appropriate
+[framework feature flags](http://source.android.com/devices/camera/versioning.html).
Device implementations MUST also declare its Individual camera capabilities of
android.hardware.camera2 via the android.request.availableCapabilities property
-and declare the appropriate [feature
-flags](http://source.android.com/devices/camera/versioning.html); a device must
-define the feature flag if any of its attached camera devices supports the
-feature.
+and declare the appropriate [feature flags](http://source.android.com/devices/camera/versioning.html);
+a device must define the feature flag if any of its attached camera devices
+supports the feature.
Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent
whenever a new picture is taken by the camera and the entry of the picture has
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index 5a45e07..3367e11 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -76,8 +76,7 @@
least 4GB of non-volatile storage for application private data so they will be
able to upgrade to the future platform releases.
-The Android APIs include a [Download
-Manager](http://developer.android.com/reference/android/app/DownloadManager.html)
+The Android APIs include a [Download Manager](http://developer.android.com/reference/android/app/DownloadManager.html)
that applications MAY use to download data files. The device implementation of
the Download Manager MUST be capable of downloading individual files of at
least 100MB in size to the default “cache” location.
@@ -135,15 +134,15 @@
Protocol to satisfy this requirement. If the device implementation supports
Media Transfer Protocol, it:
-* SHOULD be compatible with the reference Android MTP host, [Android File
-Transfer](http://www.android.com/filetransfer).
+* SHOULD be compatible with the reference Android MTP host,
+[Android File Transfer](http://www.android.com/filetransfer).
* SHOULD report a USB device class of 0x00.
* SHOULD report a USB interface name of 'MTP'.
### 7.6.3\. Adoptable Storage
-Device implementations are STRONGLY RECOMMENDED to implement [adoptable
-storage](http://source.android.com/devices/storage/adoptable.html) if the
+Device implementations are STRONGLY RECOMMENDED to implement
+[adoptable storage](http://source.android.com/devices/storage/adoptable.html) if the
removable storage device port is in a long-term stable location, such as within
the battery compartment or other protective cover.
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index a426ded..94f084d 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -28,14 +28,12 @@
implementing the AOA specification:
* MUST declare support for the hardware feature
[android.hardware.usb.accessory](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
- * MUST implement the [USB audio
- class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)as
- documented in the Android SDK documentation.
+ * MUST implement the [USB audio class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
+ as documented in the Android SDK documentation.
* The USB mass storage class MUST include the string "android" at the end
of the interface description `iInterface` string of the USB mass storage
* It SHOULD implement support to draw 1.5 A current during HS chirp and
- traffic as specified in the [USB Battery Charging specification, revision
- 1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
+ traffic as specified in the [USB Battery Charging specification, revision 1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
Existing and new Android devices are **STRONGLY RECOMMENDED to meet these
requirements** so they will be able to upgrade to the future platform
releases.
@@ -63,8 +61,8 @@
* MAY use a non-standard port form factor, but if so MUST ship with a cable or
cables adapting the port to a standard type-A or type-C USB port.
* MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables adapting the port to a standard type-A or type-C USB port.
-* is **STRONGLY RECOMMENDED** to implement the [USB audio
- class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
+* is **STRONGLY RECOMMENDED** to implement the
+ [USB audio class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
as documented in the Android SDK documentation.
* MUST implement the Android USB host API as documented in the Android SDK,
and MUST declare support for the hardware feature
@@ -85,4 +83,4 @@
specification (section 4.5.1.3.3).
* SHOULD, if the Dual Role Port functionality is supported, implement the
Try.\* model that is most appropriate for the device form factor. For
- example a handheld device SHOULD implement the Try.SNK model.
\ No newline at end of file
+ example a handheld device SHOULD implement the Try.SNK model.
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 137d5eb..6d7b102 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -48,12 +48,12 @@
#### 7.8.2.1\. Analog Audio Ports
-In order to be compatible with the [headsets and other audio
-accessories](http://source.android.com/accessories/headset-spec.html) using the
-3.5mm audio plug across the Android ecosystem, if a device implementation
-includes one or more analog audio ports, at least one of the audio port(s)
-SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4
-conductor 3.5mm audio jack, it:
+In order to be compatible with the
+[headsets and other audio accessories](http://source.android.com/accessories/headset-spec.html)
+using the 3.5mm audio plug across the Android ecosystem, if a device
+implementation includes one or more analog audio ports, at least one of the
+audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device
+implementation has a 4 conductor 3.5mm audio jack, it:
* MUST support audio playback to stereo headphones and stereo headsets with a
microphone, and SHOULD support audio recording from stereo headsets with a
@@ -83,7 +83,7 @@
Near-Ultrasound audio is the 18.5 kHz to 20 kHz band. Device implementations
MUST correctly report the support of near-ultrasound audio capability via the
-[AudioManager.getProperty](http://developer.android.com/reference/android/media/AudioManager.html#getProperty(java.lang.String))
+[AudioManager.getProperty](http://developer.android.com/reference/android/media/AudioManager.html#getProperty%28java.lang.String%29)
API as follows:
* If
diff --git a/8_performance-and-power/8_4_power-consumption-accounting.md b/8_performance-and-power/8_4_power-consumption-accounting.md
index ac49384..e8384a8 100644
--- a/8_performance-and-power/8_4_power-consumption-accounting.md
+++ b/8_performance-and-power/8_4_power-consumption-accounting.md
@@ -6,8 +6,8 @@
* MUST be able to track hardware component power usage and attribute that
power usage to specific applications. Specifically, implementations:
- * MUST provide a per-component power profile that defines the [current
-consumption value](http://source.android.com/devices/tech/power/values.html)
+ * MUST provide a per-component power profile that defines the
+[current consumption value](http://source.android.com/devices/tech/power/values.html)
for each hardware component and the approximate battery drain caused by the
components over time as documented in the Android Open Source Project site.
* MUST report all power consumption values in milliampere hours (mAh).
@@ -16,8 +16,8 @@
* MUST report CPU power consumption per each process's UID. The Android
Open Source Project meets the requirement through the `uid_cputime` kernel
module implementation.
-* MUST make this power usage available via the [`adb shell dumpsys
-batterystats`](http://source.android.com/devices/tech/power/batterystats.html)
+* MUST make this power usage available via the
+[`adb shell dumpsys batterystats`](http://source.android.com/devices/tech/power/batterystats.html)
shell command to the app developer.
* MUST honor the
[android.intent.action.POWER_USAGE_SUMMARY](http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY)
diff --git a/8_performance-and-power/8_5_consistent-performance.md b/8_performance-and-power/8_5_consistent-performance.md
index 89edf96..4eb4fe6 100644
--- a/8_performance-and-power/8_5_consistent-performance.md
+++ b/8_performance-and-power/8_5_consistent-performance.md
@@ -9,19 +9,18 @@
Device implementations SHOULD support Sustained Performance Mode which can
provide the top foreground application a consistent level of performance for a
prolonged amount of time when requested through the
-[`Window.setSustainedPerformanceMode()`]
-(https://developer.android.com/reference/android/view/Window.html#setSustainedPerformanceMode(boolean))
+[`Window.setSustainedPerformanceMode()`](https://developer.android.com/reference/android/view/Window.html#setSustainedPerformanceMode%28boolean%29)
API method. A Device implementation MUST report the support of Sustained
Performance Mode accurately through the
-[`PowerManager.isSustainedPerformanceModeSupported()`]
-(https://developer.android.com/reference/android/os/PowerManager.html#isSustainedPerformanceModeSupported())
+[`PowerManager.isSustainedPerformanceModeSupported()`](https://developer.android.com/reference/android/os/PowerManager.html#isSustainedPerformanceModeSupported%28%29)
API method.
Device implementations with two or more CPU cores SHOULD provide at least one exclusive core that
can be reserved by the top foreground application. If provided, implementations MUST meet the
following requirements:
- * Implementations MUST report through the [`Process.getExclusiveCores()`](https://developer.android.com/reference/android/os/Process.html#getExclusiveCores())
+ * Implementations MUST report through the
+ [`Process.getExclusiveCores()`](https://developer.android.com/reference/android/os/Process.html#getExclusiveCores%28%29)
API method the id numbers of the exclusive cores that can be reserved by the top foreground
application.
* Device implementations MUST not allow any user space processes except the device drivers used
@@ -29,5 +28,6 @@
as necessary.
If a device implementation does not support an exclusive core, it MUST return an
-empty list through the [`Process.getExclusiveCores()`](https://developer.android.com/reference/android/os/Process.html#getExclusiveCores())
-API method.
\ No newline at end of file
+empty list through the
+[`Process.getExclusiveCores()`](https://developer.android.com/reference/android/os/Process.html#getExclusiveCores%28%29)
+API method.
diff --git a/9_security-model/9_0_intro.md b/9_security-model/9_0_intro.md
index e6105bf..c7fbcae 100644
--- a/9_security-model/9_0_intro.md
+++ b/9_security-model/9_0_intro.md
@@ -1,8 +1,8 @@
# 9\. Security Model Compatibility
Device implementations MUST implement a security model consistent with the
-Android platform security model as defined in [Security and Permissions
-reference document](http://developer.android.com/guide/topics/security/permissions.html)
+Android platform security model as defined in
+[Security and Permissions reference document](http://developer.android.com/guide/topics/security/permissions.html)
in the APIs in the Android developer documentation. Device implementations MUST
support installation of self-signed applications without requiring any
additional permissions/certificates from any third parties/authorities.
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index ef15bb0..8cb497b 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -1,10 +1,9 @@
## 9.11\. Keys and Credentials
-The [Android Keystore
-System](https://developer.android.com/training/articles/keystore.html) allows
+The [Android Keystore System](https://developer.android.com/training/articles/keystore.html) allows
app developers to store cryptographic keys in a container and use them in
-cryptographic operations through the [KeyChain
-API](https://developer.android.com/reference/android/security/KeyChain.html) or
+cryptographic operations through the
+[KeyChain API](https://developer.android.com/reference/android/security/KeyChain.html) or
the [Keystore API](https://developer.android.com/reference/java/security/KeyStore.html).
All Android device implementations MUST meet the following requirements:
@@ -42,7 +41,8 @@
* MUST not replace any of the existing authentication methods (PIN,
pattern, password) implemented and provided in AOSP.
* MUST be disabled when the Device Policy Controller (DPC) application
- has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality\(android.content.ComponentName,%20int\))
+ has set the password quality policy via the
+ [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
method with a more restrictive quality constant than `PASSWORD_QUALITY_SOMETHING`.
* The authenticaion method, if based on a physical token or the location,
MUST NOT be treated as a secure lock screen unless it meets all following
@@ -53,8 +53,8 @@
* It MUST be disabled and only allow the primary authentication to
unlock the screen when the Device Policy Controller (DPC) application
has set the policy with either the
- [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setKeyguardDisabledFeatures\(android.content.ComponentName,%20int\))
- method or the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality\(android.content.ComponentName,%20int\))
+ [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
+ method or the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
method with a more restrictive quality constant than
`PASSWORD_QUALITY_UNSPECIFIED`.
* The authentication method, if based on biometrics, MUST NOT be treated as a
@@ -65,29 +65,29 @@
* It MUST be disabled and only allow the primary authentication to
unlock the screen when the Device Policy Controller (DPC) application
has set the keguard feature policy by calling the method
- [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setKeyguardDisabledFeatures\(android.content.ComponentName,%20int\)).
+ [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29).
* It MUST have a false acceptance rate that is equal or stronger than
what is required for a fingerprint sensor as described in
section 7.3.10, or otherwise MUST be disabled and only allow the
primary authentication to unlock the screen when the Device Policy
Controller (DPC) application has set the password quality policy
- via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality\(android.content.ComponentName,%20int\))
+ via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
method with a more restrictive quality constant than
`PASSWORD_QUALITY_BIOMETRIC_WEAK`.
* If the authentication method can not be treated as a secure lock screen,
it:
- * MUST return `false` for both the [`KeyguardManager.isKeyguardSecure()`](http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure\(\))
- and the [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure\(\))
+ * MUST return `false` for both the [`KeyguardManager.isKeyguardSecure()`](http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29)
+ and the [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29)
methods.
* MUST be disabled when the Device Policy Controller (DPC) application
- has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality\(android.content.ComponentName,%20int\))
+ has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
method with a more restrictive quality constant than `PASSWORD_QUALITY_UNSPECIFIED`.
- * MUST NOT reset the password expiration timers set by [`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout\(android.content.ComponentName,%20long\)).
- * MUST NOT authenticate access to keystores if the application has called\
- [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired\(boolean\)).
+ * MUST NOT reset the password expiration timers set by [`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
+ * MUST NOT authenticate access to keystores if the application has called
+ [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
* If the authentication method is based on a physical token, the location,
or biometrics that has higher false acceptance rate than what is required
for fingerprint sensors as described in section 7.3.10, then it:
- * MUST NOT reset the password expiration timers set by [`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout\(android.content.ComponentName,%20long\)).
+ * MUST NOT reset the password expiration timers set by [`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
* MUST NOT authenticate access to keystores if the application has called
- [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired\(boolean\)).
+ [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
diff --git a/9_security-model/9_12_data-deletion.md b/9_security-model/9_12_data-deletion.md
index 2419cd4..92a6c47 100644
--- a/9_security-model/9_12_data-deletion.md
+++ b/9_security-model/9_12_data-deletion.md
@@ -9,7 +9,6 @@
All user-generated data MUST be deleted. This MUST satisfy relevant industry
standards for data deletion such as NIST SP800-88\. This MUST be used for the
implementation of the wipeData() API (part of the Android Device Administration
-API) described in [section 3.9 Device
-Administration](#3_9_device_administration).
+API) described in [section 3.9 Device Administration](#3_9_device_administration).
Devices MAY provide a fast data wipe that conducts a logical data erase.
diff --git a/9_security-model/9_13_safe-mode.md b/9_security-model/9_13_safe-mode.md
index 408012d..7e246ab 100644
--- a/9_security-model/9_13_safe-mode.md
+++ b/9_security-model/9_13_safe-mode.md
@@ -19,4 +19,4 @@
flag as true.
* Device implementations MUST provide the user the capability to uninstall
- any third-party apps within Safe Mode.
\ No newline at end of file
+ any third-party apps within Safe Mode.
diff --git a/9_security-model/9_14_automotive-system-isolation.md b/9_security-model/9_14_automotive-system-isolation.md
index aa14b29..ec79074 100644
--- a/9_security-model/9_14_automotive-system-isolation.md
+++ b/9_security-model/9_14_automotive-system-isolation.md
@@ -1,13 +1,12 @@
## 9.14\. Automotive Vehicle System Isolation
Android Automotive devices are expected to exchange data with critical vehicle
-subsystems, e.g., by using the [vehicle
-HAL](http://source.android.com/devices/automotive.html) to send and receive
-messages over vehicle networks such as CAN bus. Android Automotive device
-implementations MUST implement security features below the Android framework
-layers to prevent malicious or unintentional interaction between the Android
-framework or third-party apps and vehicle subsystems. These security features
-are as follows:
+subsystems, e.g., by using the [vehicle HAL](http://source.android.com/devices/automotive.html)
+to send and receive messages over vehicle networks such as CAN bus. Android
+Automotive device implementations MUST implement security features below the
+Android framework layers to prevent malicious or unintentional interaction
+between the Android framework or third-party apps and vehicle subsystems. These
+security features are as follows:
* Gatekeeping messages from Android framework vehicle subsystems, e.g.,
whitelisting permitted message types and message sources.
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index a6a6d63..20dacfd 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -1,7 +1,7 @@
## 9.1\. Permissions
-Device implementations MUST support the [Android permissions
-model](http://developer.android.com/guide/topics/security/permissions.html) as
+Device implementations MUST support the
+[Android permissions model](http://developer.android.com/guide/topics/security/permissions.html) as
defined in the Android developer documentation. Specifically, implementations
MUST enforce each permission defined as described in the SDK documentation; no
permissions may be omitted, altered, or ignored. Implementations MAY add
diff --git a/9_security-model/9_2_uid-and-process-isolation.md b/9_security-model/9_2_uid-and-process-isolation.md
index 388f2b0..6c584ce 100644
--- a/9_security-model/9_2_uid-and-process-isolation.md
+++ b/9_security-model/9_2_uid-and-process-isolation.md
@@ -4,5 +4,5 @@
which each application runs as a unique Unixstyle UID and in a separate
process. Device implementations MUST support running multiple applications as
the same Linux user ID, provided that the applications are properly signed and
-constructed, as defined in the [Security and Permissions
-reference](http://developer.android.com/guide/topics/security/permissions.html).
+constructed, as defined in the
+[Security and Permissions reference](http://developer.android.com/guide/topics/security/permissions.html).
diff --git a/9_security-model/9_3_filesystem-permissions.md b/9_security-model/9_3_filesystem-permissions.md
index 07788f6..c7e46dc 100644
--- a/9_security-model/9_3_filesystem-permissions.md
+++ b/9_security-model/9_3_filesystem-permissions.md
@@ -1,5 +1,5 @@
## 9.3\. Filesystem Permissions
Device implementations MUST support the Android file access permissions model
-as defined in the [Security and Permissions
-reference](http://developer.android.com/guide/topics/security/permissions.html).
+as defined in the
+[Security and Permissions reference](http://developer.android.com/guide/topics/security/permissions.html).
diff --git a/9_security-model/9_4_alternate-execution-environments.md b/9_security-model/9_4_alternate-execution-environments.md
index dcc4dcd..728db59 100644
--- a/9_security-model/9_4_alternate-execution-environments.md
+++ b/9_security-model/9_4_alternate-execution-environments.md
@@ -7,8 +7,8 @@
applications, as described in this section.
Alternate runtimes MUST themselves be Android applications, and abide by the
-standard Android security model, as described elsewhere in [section
-9](#9_security_model_compatibility).
+standard Android security model, as described elsewhere in
+[section 9](#9_security_model_compatibility).
Alternate runtimes MUST NOT be granted access to resources protected by
permissions not requested in the runtime’s AndroidManifest.xml file via the
diff --git a/9_security-model/9_5_multi-user-support.md b/9_security-model/9_5_multi-user-support.md
index a392990..8a816a9 100644
--- a/9_security-model/9_5_multi-user-support.md
+++ b/9_security-model/9_5_multi-user-support.md
@@ -6,8 +6,7 @@
</div>
-Android includes [support for multiple
-users](http://developer.android.com/reference/android/os/UserManager.html) and
+Android includes [support for multiple users](http://developer.android.com/reference/android/os/UserManager.html) and
provides support for full user isolation. Device implementations MAY enable
multiple users, but when enabled MUST meet the following requirements related
to [multi-user support](http://source.android.com/devices/storage/traditional.html):
@@ -26,9 +25,8 @@
but MUST align with the AOSP implementation of controls to enable /disable
other users from accessing the voice calls and SMS.
* Device implementations MUST, for each user, implement a security model
-consistent with the Android platform security model as defined in [Security and
-Permissions reference
-document](http://developer.android.com/guide/topics/security/permissions.html)
+consistent with the Android platform security model as defined in
+[Security and Permissions reference document](http://developer.android.com/guide/topics/security/permissions.html)
in the APIs.
* Each user instance on an Android device MUST have separate and isolated
external storage directories. Device implementations MAY store multiple users'
@@ -42,6 +40,6 @@
only to the system. As this will make the media unreadable by a host PC, device
implementations will be required to switch to MTP or a similar system to
provide host PCs with access to the current user’s data. Accordingly, device
-implementations MAY but SHOULD NOT enable multi-user if they use [removable
-media](http://developer.android.com/reference/android/os/Environment.html) for
+implementations MAY but SHOULD NOT enable multi-user if they use
+[removable media](http://developer.android.com/reference/android/os/Environment.html) for
primary external storage.
diff --git a/9_security-model/9_6_premium-sms-warning.md b/9_security-model/9_6_premium-sms-warning.md
index 9be8fbf..f34abd1 100644
--- a/9_security-model/9_6_premium-sms-warning.md
+++ b/9_security-model/9_6_premium-sms-warning.md
@@ -1,9 +1,9 @@
## 9.6\. Premium SMS Warning
-Android includes support for warning users of any outgoing [premium SMS
-message](http://en.wikipedia.org/wiki/Short_code). Premium SMS messages are
-text messages sent to a service registered with a carrier that may incur a
-charge to the user. Device implementations that declare support for
+Android includes support for warning users of any outgoing
+[premium SMS message](http://en.wikipedia.org/wiki/Short_code). Premium SMS
+messages are text messages sent to a service registered with a carrier that may
+incur a charge to the user. Device implementations that declare support for
android.hardware.telephony MUST warn users before sending a SMS message to
numbers identified by regular expressions defined in /data/misc/sms/codes.xml
file in the device. The upstream Android Open Source Project provides an
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 86c0fe7..b20c427 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -25,10 +25,10 @@
### 9.9.1\. Direct Boot
-All devices MUST implement the [Direct Boot
-mode](http://developer.android.com/preview/features/direct-boot.html) APIs even
+All devices MUST implement the
+[Direct Boot mode](http://developer.android.com/preview/features/direct-boot.html) APIs even
if they do not support Storage Encryption. In particular, the
-LOCKED_BOOT_COMPLETED(https://developer.android.com/reference/android/content/Intent.html#LOCKED_BOOT_COMPLETED)
+[LOCKED_BOOT_COMPLETED](https://developer.android.com/reference/android/content/Intent.html#LOCKED_BOOT_COMPLETED)
and
[ACTION_USER_UNLOCKED](https://developer.android.com/reference/android/content/Intent.html#ACTION_USER_UNLOCKED)
Intents must still be broadcast to signal Direct Boot aware applications that
