Doc change: edits to permissions and ids guidelines.

  If the device is running Android 6.0 (API level 23) and the app's <a href=

  "{@docRoot}guide/topics/manifest/uses-sdk-element.html#target"

  ><code>targetSdkVersion</code></a> is 23 or higher, the following system

  behavior applies when you app requests a dangerous permission:

  behavior applies when your app requests a dangerous permission:

</p>

<ul>

<p>

  For a general look at Android permissions, please see <a href=

  "{@docRoot}training/articles/user-data-overview.html">Permissions

  and User Privacy</a>. For specific best practices for

  and User Data</a>. For specific best practices for

  working with Android permissions, please see <a href=

  "{@docRoot}training/articles/user-data-permissions.html">Best Practices for

  App Permissions</a>.

<p>

  In general, user account identifiers can be considered unique (i.e., each

  device/account combo has a unique ID). On the other hand, the less the unique

  device/account combo has a unique ID). On the other hand, the less unique

  an identifier is within a population (e.g. of devices), the greater the

  privacy protection because it's less useful for tracking an individual user.

</p>

</p>

<p>

  <strong>We Recommend</strong>: IMEI, IMSI, and Line1.

  <strong>We Recommend</strong>: IMEI, IMSI, and Line1 (requires <code>PHONE</code>

  permission group in Android 6.0 (API level 23) and higher).

</p>

<p>

page.title=Permissions and User Privacy

page.title=Permissions and User Data

page.metaDescription=An overview of permissions on Android and how to manage them.

page.tags="user data","permissions","identifiers"

page.image=images/cards/card-user_2x.png

  at the group level and a <em><strong>single permission group</strong></em>

  corresponds to <em><strong>several permission declarations</strong></em> in

  the app manifest; for example, the SMS group includes both the

  <code>READ_SMS</code> and the <code>WRITE_SMS</code> declarations.

  <code>READ_SMS</code> and the <code>RECEIVE_SMS</code> declarations.

</p>

  a request to grant permission for the whole group rather than the specific

  API call. For example, if you request the <code>MANAGE_ACOUNTS</code>

  permission, the user will be asked to grant access to the <em>Identity</em>

  group which is composed of the <code>GET_ACCOUNTS</code>,

  group (in API level 22 and lower), which is composed of the <code>GET_ACCOUNTS</code>,

  <code>READ_PROFILE</code>, and <code>WRITE_PROFILE</code> permissions, and

  all their associated methods.

</p>

<p>

  For a more general look at Android permissions, please see <a href=

  "{@docRoot}training/articles/user-data-overview.html">Permissions

  and User Privacy</a>. For details on how to work with permissions in your code,

  and User Data</a>. For details on how to work with permissions in your code,

  see <a href="{@docRoot}training/permissions/index.html">Working with System Permissions</a>.

  For best practices for working with unique identifiers, please see <a href=

  "{@docRoot}training/articles/user-data-ids.html">Best Practices for

</p>

<p>

  <em><strong>Increased situational context</strong></em>: Users are be

  <em><strong>Increased situational context</strong></em>: Users are

  prompted at runtime, in the context of your app, for permission to access the

  functionality covered by those permission groups. Users are be more sensitive to

  functionality covered by those permission groups. Users are more sensitive to

  the context in which the permission is requested, and if there’s a mismatch

  between what you are requesting and the purpose of your app, it's even

  more important to provide detailed explanation to the user as to why you’re

        <a href="<?cs var:toroot ?>training/articles/user-data-overview.html"

           description=

           "Overview of app permissions on Android and how they affect your users."

          >Permissions and User Privacy</a>

          >Permissions and User Data</a>

      </li>

      <li>

        <a href="<?cs var:toroot ?>training/articles/user-data-permissions.html"