Docs: updating runtime perms content to fix link
changing to strong and em tags, removing MUST
Bug: 27834736
Change-Id: I45aa1773b7b63cc7ac25ef88511ffe70b0a249d4
diff --git a/src/devices/tech/config/runtime_perms.jd b/src/devices/tech/config/runtime_perms.jd
index ef54b78..b9b57c5 100644
--- a/src/devices/tech/config/runtime_perms.jd
+++ b/src/devices/tech/config/runtime_perms.jd
@@ -24,63 +24,139 @@
</div>
</div>
-<p>The Android 6.0 release presents a new application permission model aimed at making permissions more understandable, useful, and secure for users. The model moves Android applications that require dangerous permissions (see <a href="#affected-permissions">Affected permissions</a>) from an <i>install</i> time permission model to <i>runtime</i> permission model:</p>
+<p>The Android 6.0 application permission model is designed to make permissions
+more understandable, useful, and secure for users. The model moves Android
+applications that require dangerous permissions (see
+<a href="#affected-permissions">Affected permissions</a>) from an
+<em>install</em> time permission model to <em>runtime</em> permission model:</p>
<ul>
-<li><strong>Install Time Permissions</strong> (<i>Android 5.1 and earlier</i>). Users grant dangerous permissions to an app when installing or updating the app. OEMs/carriers can pre-install apps with pre-granted permissions without notifying the user. </li>
-<li><strong>Runtime Permissions</strong> (Android <i>6.0 and later</i>). Users grant dangerous permissions to an app when the app is running. Applications decide when to request permissions (such as when the app launches or the user accesses a specific feature), but must allow the user to grant/deny application access to specific permission groups. OEMs/carriers can pre-install apps but cannot pre-grant permissions (see <a href="#creating-exceptions">Creating exceptions</a>). </li>
+<li><strong>Install Time Permissions</strong> (<em>Android 5.1 and earlier</em>).
+Users grant dangerous permissions to an app when installing or updating the app.
+OEMs/carriers can pre-install apps with pre-granted permissions without
+notifying the user.</li>
+<li><strong>Runtime Permissions</strong> (Android <em>6.0 and later</em>). Users
+grant dangerous permissions to an app when the app is running. Applications
+decide when to request permissions (such as when the app launches or the user
+accesses a specific feature), but must allow the user to grant/deny application
+access to specific permission groups. OEMs/carriers can pre-install apps but
+cannot pre-grant permissions (see <a href="#creating-exceptions">Creating
+exceptions</a>).</li>
</ul>
-<p>The move to runtime permissions provides users additional context and visibility into the permissions that applications are seeking or have been granted. The new model also encourages developers to help users understand why applications require the requested permissions and to provide greater transparency about the benefits and hazards of granting or denying permissions. Users can revoke application permissions using the Apps menu in Settings.</p>
+<p>Runtime permissions provide users additional context and visibility into the
+permissions applications are seeking or have been granted. The runtime model
+also encourages developers to help users understand why applications require the
+requested permissions and to provide greater transparency about the benefits and
+hazards of granting or denying permissions.</p>
+<p>Users can revoke application permissions using the Apps menu in Settings.</p>
<h2 id="affected-permissions">Affected permissions</h2>
-<p>The Android 6.0 release requires only dangerous permissions to use a runtime permissions model. Dangerous permissions are higher-risk permissions (such as <code>READ_CALENDAR</code>) that grant requesting applications access to private user data or control over the device that can negatively impact the user. To view a list of dangerous permissions, run the command: <code>adb shell pm list permissions -g -d</code> .</p>
+<p>Android 6.0 requires only dangerous permissions to use a runtime permissions
+model. Dangerous permissions are higher-risk permissions (such as
+<code>READ_CALENDAR</code>) that grant requesting applications access to private
+user data or control over the device that can negatively impact the user. To
+view a list of dangerous permissions, run the command: <code>adb shell pm list
+permissions -g -d</code> .</p>
-<p>This release does not change the behavior of normal permissions (all non-dangerous permissions including normal, system, and signature permissions). Normal permissions are lower-risk permissions (such as <code>SET_WALLPAPER</code>) that grant requesting applications access to isolated application-level features with minimal risk to other applications, the system, or the user. As in Android 5.1 and earlier releases, the system automatically grants normal permissions to a requesting application at installation and does not prompt the user for approval. For details on permissions, refer to <a href="http://developer.android.com/guide/topics/manifest/permission-element.html"><permission> element documentation</a>.</p>
+<p>Android 6.0 does not change the behavior of normal permissions (all
+non-dangerous permissions including normal, system, and signature permissions).
+Normal permissions are lower-risk permissions (such as
+<code>SET_WALLPAPER</code>) that grant requesting applications access to
+isolated application-level features with minimal risk to other applications, the
+system, or the user. As in Android 5.1 and earlier releases, the system
+automatically grants normal permissions to a requesting application at
+installation and does not prompt the user for approval. For details on
+permissions, refer to
+<a href="http://developer.android.com/guide/topics/manifest/permission-element.html"><permission>
+element documentation</a>.</p>
<h2 id="requirements">Requirements</h2>
-<p>The runtime permission model applies to all applications, including pre-installed apps and apps delivered to the device as part of the setup process. Application software requirements include: </p>
+<p>The runtime permission model applies to all applications, including
+pre-installed apps and apps delivered to the device as part of the setup
+process. Application software requirements include:</p>
<ul>
-<li>Runtime permission model must be consistent across all devices running Android 6.0. Enforced by Android Compatibility Test Suite (CTS) tests.</li>
-<li>Apps must prompt users to grant application permissions at runtime. For details, see Updating Applications.Limited exceptions may be granted to default applications and handlers that provide basic device functionality determined to be fundamental to the expected operation of the device (i.e. the device's default Dialer app for handling ACTION_CALL may have Phone permission access). For details, see <a href="#creating-exceptions">Creating exceptions</a>.</li>
-<li>Pre-loaded apps with "dangerous permission" MUST target API level 23 and the AOSP permission model of Android 6.0 should be maintained (i.e. the UI flow during an app installation should not deviate from the AOSP implementation of PackageInstaller, users can even revoke the dangerous permissions of pre-installed apps etc.).</li>
-<li>Headless applications must use an activity to request permissions or share a UID with another application that has the necessary permissions. For details, see <a href="#headless-apps">Headless applications</a>.</li>
+<li>Runtime permission model must be consistent across all devices running
+Android 6.0. Enforced by Android Compatibility Test Suite (CTS) tests.</li>
+<li>Apps must prompt users to grant application permissions at runtime. For
+details, see <a href="#updating-apps">Updating applications</a>. Limited
+exceptions may be granted to default applications and handlers that provide
+basic device functionality fundamental to the expected operation of the device
+(i.e. the device's default Dialer app for handling <code>ACTION_CALL</code> may
+have Phone permission access). For details, see
+<a href="#creating-exceptions">Creating exceptions</a>.</li>
+<li>Pre-loaded apps with "dangerous permission" must target API level 23 and
+maintain the runtime permission model (i.e. the UI flow during app installation
+should not deviate from the AOSP implementation of PackageInstaller, users can
+revoke dangerous permissions of pre-installed apps, etc.).</li>
+<li>Headless applications must use an activity to request permissions or share a
+UID with another application that has the necessary permissions. For details,
+see <a href="#headless-apps">Headless applications</a>.</li>
</ul>
<h2 id="permissions-migration">Permissions migration</h2>
-<p>Permissions granted to applications on Android 5.x remain granted after updating to Android 6.0, but users can revoke those permissions at any time.</p>
+<p>Permissions granted to applications on Android 5.x remain granted after
+updating to Android 6.0, but users can revoke those permissions at any time.</p>
<h2 id="integration">Integration</h2>
-<p>When integrating the Android 6.0 application runtime permissions model, you must update pre-installed applications to work with the new model. You can also define exceptions for apps that are the default handlers/providers for core functionality, define custom permissions, and customize the theme used in the PackageInstaller.</p>
+<p>When integrating the Android 6.0 application runtime permissions model, you
+must update pre-installed applications to work with the new model. You can also
+define exceptions for apps that are the default handlers/providers for core
+functionality, define custom permissions, and customize the theme used in the
+PackageInstaller.</p>
<h3 id="updating-apps">Updating applications</h3>
-<p>Applications on the system image and pre-installed applications are not automatically pre-granted permissions. We encourage you to work with pre-installed app developers (OEM, Carrier, and third party) to make the required app modifications using the <a href="https://developer.android.com/preview/features/runtime-permissions.html">guidelines</a> posted on the developer portal. Specifically, you must ensure that pre-installed applications are modified to avoid crashes and other issues when users revoke permissions.</p>
+<p>Applications on the system image and pre-installed applications are not
+automatically pre-granted permissions. We encourage you to work with
+pre-installed app developers (OEM, Carrier, and third party) to make the
+required app modifications using
+<a href="https://developer.android.com/training/permissions/index.html">developer
+guidelines</a>. Specifically, you must ensure that pre-installed applications
+are modified to avoid crashes and other issues when users revoke permissions.</p>
<h4 id="preloaded-apps">Pre-loaded applications</h4>
-<p>Pre-loaded apps that use dangerous permissions MUST target API level 23 and maintain the Android 6.0 AOSP permission model (i.e. the UI flow during an app installation should not deviate from the AOSP implementation of PackageInstaller, users can even revoke the dangerous permissions of pre-installed apps etc.).</p>
+<p>Pre-loaded apps that use dangerous permissions must target API level 23 and
+maintain the Android 6.0 AOSP permission model (i.e. the UI flow during an app
+installation should not deviate from the AOSP implementation of
+PackageInstaller, users can even revoke the dangerous permissions of
+pre-installed apps, etc.).</p>
<h4 id="headless-apps">Headless applications</h4>
-<p>Only activities can request permissions; services cannot directly request permissions. </p>
+<p>Only activities can request permissions; services cannot directly request
+permissions.</p>
<ul>
-<li>In Android 5.1 and earlier releases, headless applications can request permissions when installed or pre-installed without the use of an activity.</li>
-<li>In Android 6.0, headless applications must use one of the following methods to request permissions:<ul>
+<li>In Android 5.1 and earlier releases, headless applications can request
+permissions when installed or pre-installed without the use of an activity.</li>
+<li>In Android 6.0, headless applications must use one of the following methods
+to request permissions:<ul>
<li>Add an activity to request permissions (preferred method).</li>
-<li>Share a UID with another application that has the necessary permissions. Use this method only when you need the platform to handle multiple APKs as a single application.</li>
+<li>Share a UID with another application that has the necessary permissions. Use
+this method only when you need the platform to handle multiple APKs as a single
+application.</li>
</ul></li>
</ul>
-<p>The goal is to avoid confusing users with permission requests that appear out of context.</p>
+<p>The goal is to avoid confusing users with permission requests that appear out
+of context.</p>
<h3 id="customizing-package-install">Customizing PackageInstaller</h3>
-<p>If desired, you can customize the Permissions UI <b>theme</b> by updating the default device themes (<code>Theme.DeviceDefault.Settings</code> and <code>Theme.DeviceDefault.Light.Dialog.NoActionBar</code>) used by PackageInstaller. However, because consistency is critical for app developers, you cannot customize the placement, position, and rules of when the Permissions UI appears.</p>
-<p>To include <b>strings</b> for additional languages, contribute the strings to AOSP.</p>
+<p>If desired, you can customize the Permissions UI <strong>theme</strong> by
+updating the default device themes (<code>Theme.DeviceDefault.Settings</code>
+and <code>Theme.DeviceDefault.Light.Dialog.NoActionBar</code>) used by
+PackageInstaller. However, because consistency is critical for app developers,
+you cannot customize the placement, position, and rules of when the Permissions
+UI appears.</p>
+<p>To include <strong>strings</strong> for additional languages, contribute the
+strings to AOSP.</p>
<h3 id="creating-exceptions">Creating exceptions</h3>
-<p>You can pre-grant permissions to applications that are default handlers or providers for core OS functionality using the <code>DefaultPermissionGrantPolicy.java</code> in PackageManager. Examples:</p>
+<p>You can pre-grant permissions to applications that are default handlers or
+providers for core OS functionality using the
+<code>DefaultPermissionGrantPolicy.java</code> in PackageManager. Examples:</p>
<code>
<p>ACTION_CALL (Dialer) Default</p>
@@ -94,14 +170,23 @@
</code>
<h3 id="defining-custom-perms">Defining custom permissions</h3>
-<p>You can define custom permissions and groups as <i>normal</i> or <i>dangerous</i> and add OEM/Carrier-specific permissions to existing permissions groups, just as you could in Android 5.x and earlier releases.</p>
+<p>You can define custom permissions and groups as <em>normal</em> or
+<em>dangerous</em> and add OEM/Carrier-specific permissions to existing
+permissions groups, just as you could in Android 5.x and earlier releases.</p>
-<p>In the Android 6.0 release, if you add a new dangerous permission, it must be handled in the same way as other dangerous permissions (requested during app runtime and revocable by users). Specifically: </p>
+<p>In Android 6.0, if you add a new dangerous permission, it must be handled in
+the same way as other dangerous permissions (requested during app runtime and
+revocable by users). Specifically:</p>
<ul>
-<li>You can add new permissions to a current group, but you cannot modify the AOSP mapping of dangerous permissions and dangerous permissions group (e.g. you cannot remove a permission from a group and assign to other group).</li>
-<li>You can add new permission groups in applications installed on the device, but you cannot add new permissions groups in the platform manifest.</li>
+<li>You can add new permissions to a current group, but you cannot modify the
+AOSP mapping of dangerous permissions and dangerous permissions group (e.g. you
+cannot remove a permission from a group and assign to other group).</li>
+<li>You can add new permission groups in applications installed on the device,
+but you cannot add new permissions groups in the platform manifest.</li>
</ul>
<h2 id="testing-perms">Testing permissions</h2>
-<p>The Android 6.0 release includes new Compatibility Test Suite (CTS) tests that verify individual permissions are mapped to the correct Groups. Passing these tests is a requirement for Android 6.0 CTS compatibility.</p>
\ No newline at end of file
+<p>Android 6.0 includes Compatibility Test Suite (CTS) tests that verify
+individual permissions are mapped to the correct Groups. Passing these tests is
+a requirement for Android 6.0 CTS compatibility.</p>
\ No newline at end of file
