This document provides guidance for selecting appropriate identifiers for your
app based on your use case.

For a general look at Android permissions, see [Permissions
overview](https://developer.android.com/training/articles/user-data-overview). For specific best
practices for working with Android permissions, see [App permissions best
practices](https://developer.android.com/training/permissions/usage-notes).

## Best practices for working with Android identifiers

To protect the privacy of your users, use the most restrictive identifier that
satisfies your app's use case. In particular, follow these best practices:

1. ***Choose user-resettable identifiers whenever possible.*** Your app can achieve most of its use cases even when it uses identifiers other than non-resettable hardware IDs.
2. ***Avoid using hardware identifiers.*** In most use cases, you can avoid
   using hardware identifiers, such as International Mobile Equipment Identity
   (IMEI), without limiting required functionality.

   Android 10 (API level 29) adds restrictions for non-resettable identifiers,
   which include both IMEI and serial number. Your app must be a [device or
   profile owner
   app](https://source.android.com/devices/tech/admin/managed-profiles#device_administration),
   have [special carrier
   permissions](https://source.android.com/devices/tech/config/uicc), or have
   the `READ_PRIVILEGED_PHONE_STATE` privileged permission in order to access
   these identifiers.
3. ***Only use an Advertising ID for user profiling or ads use cases.*** When
   using an [Advertising ID](https://developers.google.com/android/reference/com/google/android/gms/ads/identifier/AdvertisingIdClient), always [respect users' selections regarding
   ad tracking](https://play.google.com/about/monetization-ads/ads/ad-id/). If
   you must connect the advertising identifier to personally-identifiable
   information, do so only with the [explicit consent of the
   user](https://support.google.com/googleplay/android-developer/answer/11150561).

4. ***Don't bridge Advertising ID resets.***

5. ***Use a Firebase installation ID (FID) or a privately stored GUID whenever
   possible for all other use cases, except for payment fraud prevention and
   telephony.*** For the vast majority of non-ads use cases, an FID or GUID
   should be sufficient.

6. ***Use APIs that are appropriate for your use case to minimize privacy
   risk.*** Use the [DRM API](https://source.android.com/devices/drm) for
   high-value content protection and the
   [Play Integrity APIs](https://developer.android.com/google/play/integrity/overview) for abuse protection.
   The Play Integrity APIs are the easiest way to determine whether a device is
   genuine without incurring privacy risk.

The remaining sections of this guide elaborate on these rules in the context of
developing Android apps.

## Work with advertising IDs

The Advertising ID is a user-resettable identifier and is appropriate for ads
use cases. There are some key points to bear in mind, however, when you use this
ID:

***Always respect the user's intention in resetting the advertising ID.***
Don't bridge user resets by using another identifier or fingerprint to link
subsequent Advertising IDs together without
the user's consent. The [Google Play Developer Content
Policy](https://play.google.com/about/developer-content-policy) states the
following:
> *"...if reset, a new advertising identifier must not be connected to a
> previous advertising identifier or data derived from a previous advertising
> identifier without the explicit consent of the user."*

***Always respect the associated Personalized Ads flag.*** Advertising IDs are
configurable in that users can limit the amount of tracking associated with the
ID. Always use the [`AdvertisingIdClient.Info.isLimitAdTrackingEnabled()`](https://developers.google.com/android/reference/com/google/android/gms/ads/identifier/AdvertisingIdClient.Info.html#isLimitAdTrackingEnabled())
method to ensure that you aren't circumventing your users' wishes. The [Google
Play Developer Content
Policy](https://play.google.com/about/developer-content-policy) states the
following:
> *"...you must abide by a user's 'Opt out of interest-based advertising' or
> 'Opt out of Ads Personalization' setting. If a user has enabled this setting,
> you may not use the advertising identifier for creating user profiles for
> advertising purposes or for targeting users with personalized advertising.
> Allowed activities include contextual advertising, frequency capping, conversion
> tracking, reporting and security and fraud detection."*
| **Note:** As part of Google Play services update in late 2021, the advertising ID will be removed when a user opts out of personalization using advertising ID in Android Settings. Any attempts to access the identifier will receive a string of zeros instead of the identifier. See [Play Console Help to learn more](https://support.google.com/googleplay/android-developer/answer/6048248?ref_topic=2364761).

***Be aware of any privacy or security policies associated with SDKs you use that are related to Advertising ID use.***
For example, if you pass `true` into the
[`enableAdvertisingIdCollection()`](https://developers.google.com/android/reference/com/google/android/gms/analytics/Tracker.html#enableAdvertisingIdCollection(boolean))
method from the Google Analytics SDK, make sure to review and adhere to all
applicable [Analytics SDK
policies](https://developers.google.com/analytics/devguides/collection/android/v4/policy).

Also, be aware that the [Google Play Developer Content
Policy](https://play.google.com/about/developer-content-policy.html) requires
that the Advertising ID "must not be connected to personally-identifiable
information or associated with any persistent device identifier (for example:
SSAID, MAC address, IMEI, etc.,)."

As an example, suppose you want to collect information to populate database
tables with the following columns:

|----------------|---------|----------------|-----------|
| TABLE-01                                           ||||
| `timestamp`    | `ad_id` | **account_id** | `clickid` |
| TABLE-02                                           ||||
| **account_id** | `name`  | `dob`          | `country` |

In this example, the `ad_id` column could be joined to PII via the `account_id`
column in both tables, which would be a violation of the [Google Play Developer
Content Policy](https://play.google.com/about/developer-content-policy), if you
didn't get explicit permission from your users.

Keep in mind that links between Advertiser ID and PII aren't always this
explicit. It's possible to have "quasi-identifiers" that appear in both PII and
Ad ID keyed tables, which also cause problems. For example, assume we change
TABLE-01 and TABLE-02 as follows:

|---------------|---------|--------------|---------------|--------|
| TABLE-01                                                    |||||
| **timestamp** | `ad_id` | `clickid`    | **dev_model**         ||
| TABLE-02                                                    |||||
| **timestamp** | `demo`  | `account_id` | **dev_model** | `name` |

In this case, with sufficiently rare click events, it's still possible to join
between the Advertiser ID TABLE-01 and the PII contained in TABLE-02 using the
timestamp of the event and the device model.

Although it's often difficult to guarantee that no such quasi-identifiers exist
in a dataset, you can prevent the most obvious join risks by generalizing
unique data where possible. In the preceding example, this would mean reducing
the accuracy of the timestamp so that multiple devices with the same model
appear for every timestamp.

Other solutions include the following:

- ***Not designing tables that explicitly link PII with Advertising IDs*** . In
  the first example above, this would mean not including the `account_id` column
  in TABLE-01.

- ***Segregating and monitoring access control lists for users or roles that have access to both the Advertising ID keyed data and PII***.
  By tightly controlling and auditing the ability to access both sources
  simultaneously (for example, by performing a join between tables), you reduce
  the risk of association between the Advertising ID and PII. Generally speaking,
  controlling access means doing the following:

  1. Keep access control lists (ACLs) for Advertiser ID keyed data and PII disjoint to minimize the number of individuals or roles that are in both ACLs.
  2. Implement access logging and auditing to detect and manage any exceptions to this rule.

For more information on working responsibly with Advertising IDs, see the
[`AdvertisingIdClient`](https://developers.google.com/android/reference/com/google/android/gms/ads/identifier/AdvertisingIdClient) API reference.

## Work with FIDs and GUIDs

The most straightforward solution to identifying an app instance running on a
device is to use a Firebase installation ID (FID), and this is the recommended
solution in the majority of non-ads use cases. Only the app instance for which
it was provisioned can access this identifier, and it's (relatively) easily
resettable because it only persists as long as the app is installed.

As a result, FIDs provide better privacy properties compared to
non-resettable, device-scoped hardware IDs. For more information, see the
[`firebase.installations`](https://firebase.google.com/docs/reference/android/com/google/firebase/installations/package-summary)
API reference.

In cases where an FID isn't practical, you can also use custom
globally-unique IDs (GUIDs) to uniquely identify an app instance. The simplest
way to do so is by generating your own GUID using the following code:  

### Kotlin

```kotlin
var uniqueID = UUID.randomUUID().toString()
```

### Java

```java
String uniqueID = UUID.randomUUID().toString();
```

Because the identifier is globally unique, it can be used to identify a specific
app instance. To avoid concerns related to linking the identifier across apps,
store GUIDs in internal storage instead of external (shared) storage. For more
information, see the [Data and file storage
overview](https://developer.android.com/guide/topics/data/data-storage) page.


## Don't work with MAC addresses

MAC addresses are globally unique, not user-resettable, and survive factory
resets. For these reasons, to protect user privacy, on Android versions 6 and
higher, access to MAC addresses is restricted to system apps. Third-party apps
can't access them.

### MAC address availability changes in Android 11

On apps targeting Android 11 and higher, MAC randomization for Passpoint
networks is per Passpoint profile, generating a unique MAC address based on the
following fields:

- Fully-qualified domain name (FQDN)
- Realm
- Credential, based on the credential used in the Passpoint profile:
  - User credential: user name
  - Certificate credential: cert and cert type
  - SIM credential: EAP type and IMSI

In addition, non-privileged apps can't access the device's MAC address; only
network interfaces with an IP address are visible. This impacts the
[`getifaddrs()`](https://android.googlesource.com/platform/bionic/+/master/libc/include/ifaddrs.h#83)
and
[`NetworkInterface.getHardwareAddress()`](https://developer.android.com/reference/java/net/NetworkInterface#getHardwareAddress())
methods, as well as sending `RTM_GETLINK` Netlink messages.

The following is a list of the ways that apps are affected by this change:

- `NetworkInterface.getHardwareAddress()` returns null for every interface.
- Apps cannot use the `bind()` function on `NETLINK_ROUTE` sockets.
- The `ip` command does not return information about interfaces.
- Apps cannot send `RTM_GETLINK` messages.

Note that most developers should use the higher-level APIs of
[`ConnectivityManager`](https://developer.android.com/reference/android/net/ConnectivityManager) rather than
lower-level APIs like
[`NetworkInterface`](https://developer.android.com/reference/java/net/NetworkInterface),
[`getifaddrs()`](https://android.googlesource.com/platform/bionic/+/master/libc/include/ifaddrs.h#83),
or Netlink sockets. For example, an app that needs up-to-date information on the
current routes can get this information by listening for network changes using [`ConnectivityManager.registerNetworkCallback()`](https://developer.android.com/reference/android/net/ConnectivityManager#registerNetworkCallback(android.net.NetworkRequest,%20android.net.ConnectivityManager.NetworkCallback))
and calling the network's associated
[`LinkProperties.getRoutes()`](https://developer.android.com/reference/android/net/LinkProperties#getRoutes()).

## Identifier characteristics

The Android OS offers a number of IDs with different behavior characteristics.
Which ID you should use depends on how the following characteristics work with
your use case. These characteristics also come with privacy implications,
however, so it's important to understand how these characteristics interact with
each other.

### Scope

Identifier scope explains which systems can access the identifier. Android
identifier scope generally comes in three flavors:

- *Single app*: The ID is internal to the app and not accessible to other apps.
- *Group of apps*: The ID is accessible to a pre-defined group of related apps.
- *Device*: The ID is accessible to all apps installed on the device.

The wider the scope granted to an identifier, the greater the risk of it being
used for tracking purposes. Conversely, if an identifier can only be accessed by
a single app instance, it cannot be used to track a device across transactions
in different apps.

### Resettability and persistence

Resettability and persistence define the lifespan of the identifier and explain
how it can be reset. Common reset triggers include: in-app resets, resets via
System Settings, resets on launch, and resets on installation. Android
identifiers can have varying lifespans, but the lifespan is usually related
to how the ID is reset:

- *Session-only*: A new ID is used every time the user restarts the app.
- *Install-reset*: A new ID is used every time user uninstalls and reinstalls the app.
- *FDR-reset*: A new ID is used every time the user factory-resets the device.
- *FDR-persistent*: The ID survives factory reset.

Resettability gives users the ability to create a new ID that is disassociated
from any existing profile information. The longer, and more reliably, an
identifier persists, such as one that persists across factory resets, the
greater the risk that the user may be subjected to long-term tracking. If the
identifier is reset upon app reinstall, this reduces the persistence and
provides a means for the ID to be reset, even if there is no explicit user
control to reset it from within the app or System Settings.

### Uniqueness

Uniqueness establishes the likelihood of collisions; that is, that identical
identifiers exist within the associated scope. At the highest level, a globally
unique identifier never has a collision, even on other devices or apps.
Otherwise, the level of uniqueness depends on the entropy of the identifier and
the source of randomness used to create it. For example, the chance of a
collision is much higher for random identifiers seeded with the calendar date of
installation (such as `2019-03-01`) than for identifiers seeded with the Unix
timestamp of installation (such as `1551414181`).

In general, user account identifiers can be considered unique. That is, each
device/account combination has a unique ID. On the other hand, the less unique
an identifier is within a population, the greater the privacy protection because
it's less useful for tracking an individual user.

### Integrity protection and non-repudiability

You can use an identifier that is difficult to spoof or replay to prove that the
associated device or account has certain properties. For example, you could
prove that the device isn't a virtual device used by a spammer.
Difficult-to-spoof identifiers also provide *non-repudiability*. If the device
signs a message with a secret key, it's difficult to claim that someone else's
device sent the message. Non-repudiability could be something a user wants, such
as when authenticating a payment, or it could be an undesirable property, such
as when they send a message they regret.

## Common use cases and the appropriate identifier to use

This section provides alternatives to using hardware IDs, such as IMEI. Using
hardware IDs is discouraged because the user cannot reset them, and they're
scoped to the device. In many cases, an app-scoped identifier would suffice.

### Accounts


#### Carrier status

*In this case, your app interacts with the device's phone and texting
functionality using a carrier account.*

**Recommended identifier to use:** IMEI, IMSI, and Line1

**Why this recommendation?**

Leveraging hardware identifiers is acceptable if it's required for
carrier-related functionality. For example, you could use these identifiers to
switch between cellular carriers or SIM slots, or to deliver SMS messages over
IP (for Line1) - SIM-based user accounts. For unprivileged apps, however, we
recommend using an account sign-in to retrieve user device information
server-side. One reason for this is that, in Android 6.0 (API level 23) and
higher, these identifiers can only be used via a runtime permission. Users might
toggle off this permission, so your app should handle these exceptions
gracefully.

#### Mobile subscription status

*In this case, you need to associate app functionality with certain mobile
service subscriptions on the device. For example, you may have a requirement to
verify access to certain premium app features based on the device's mobile
subscriptions via SIM.*

**Recommended identifier to use:** [Subscription ID
API](https://developer.android.com/reference/android/telephony/SubscriptionInfo#getSubscriptionId()) to
identify SIMs that are used on the device.

The Subscription ID provides an index value (starting at 1) for uniquely
identifying installed SIMs (including physical and electronic) used on the
device. Through this ID, your app can associate its functionality with various
subscription information for a given SIM. This value is stable for a given SIM
unless the device is factory reset. However, there may be cases where the same
SIM has a different Subscription ID on different devices or different SIMs have
the same ID on different devices.
| **Note:** Access to this ID requires the [`READ_PHONE_STATE`](https://developer.android.com/reference/android/Manifest.permission#READ_PHONE_STATE) permission.

**Why this recommendation?**

Some apps may be currently using the [ICC
ID](https://developer.android.com/reference/android/telephony/SubscriptionInfo#getIccId%28%29) for this
purpose. Because the ICC ID is globally unique and non-resettable, the access
has been restricted to apps with the `READ_PRIVILEGED_PHONE_STATE`
permission since Android 10. Beginning with Android 11, Android further
restricted access to the ICCID through the
[`getIccId()`](https://developer.android.com/reference/android/telephony/SubscriptionInfo#getIccId%28%29)
API, regardless of the app's target API level. Affected apps should migrate to
use the Subscription ID instead.

#### Single sign-on

*In this case, your app offers a single sign-on experience, allowing users to
associate an existing account with your organization.*

**Recommended identifier to use:** Account manager-compatible accounts, such as
[Google Account Linking](https://developers.google.com/identity/account-linking)

**Why this recommendation?**

Google Account Linking allows users to associate a user's existing Google
account with your app, providing seamless and more secure access to your
organization's products and services. Additionally, you can
[define custom OAuth scopes](https://developers.google.com/identity/protocols/oauth2/native-app#identify-access-scopes)
to share only necessary data, increasing user trust by clearly defining how
their data is used.

### Ads

#### Targeting

*In this case, your app builds a profile of a user's interests, to show them
more relevant ads.*

**Recommended identifier to use:** If your app uses an ID for ads and uploads or
publishes to Google Play, that ID must be the Advertising ID.

**Why this recommendation?**

This is an ads-related use case which might require an ID that is available
across your organization's different apps, so using an Advertising ID is the
most appropriate solution. Use of the Advertising ID is mandatory for
advertising use cases, per the
[Google Play Developer Content Policy](https://play.google.com/about/developer-content-policy),
because the user can reset it.

Regardless of whether you share user data in your app, if you collect and use it
for ads purposes, you need to declare the ads purposes in the
[Data safety section](https://support.google.com/googleplay/android-developer/answer/10787469)
of the **App content** page in the Play Console.

#### Measurement

*In this case, your app creates a profile of a user based on their behavior
across your organization's apps on the same device.*

**Recommended identifier to use:** Advertising ID or Play install referrer APIs

**Why this recommendation?**

This is an ads-related use case which might require an ID that is available
across your organization's different apps, so using an Advertising ID is the
most appropriate solution. If you use an ID for advertising use cases, that ID
must be the Advertising ID because the user can reset it. Learn more in the
[Google Play Developer Content Policy](https://play.google.com/about/developer-content-policy).


#### Conversions

*In this case, you're tracking conversions to detect if your marketing strategy
is successful.*

**Recommended identifier to use:** Advertising ID or Play install referrer APIs

**Why this recommendation?**

This is an ads-related use case which might require an ID that is available
across your organization's different apps, so using an Advertising ID is the
most appropriate solution. Use of the Advertising ID is mandatory for
advertising use cases, per the
[Google Play Developer Content Policy](https://play.google.com/about/developer-content-policy),
because the user can reset it.

#### Remarketing

*In this case, your app shows ads based on a user's previous interests.*

**Recommended identifier to use:** Advertising ID

**Why this recommendation?**

This is an ads-related use case which might require an ID that is available
across your organization's different apps, so using an Advertising ID is the
most appropriate solution. Use of the Advertising ID is mandatory for
advertising use cases, per the
[Google Play Developer Content Policy](https://play.google.com/about/developer-content-policy),
because the user can reset it.

### App analytics

*In this case, your app evaluates a user's behavior to help you determine the
following:*

- *Which of your organization's other products or apps might be suitable for the
  user.*
- *How to keep users interested in using your app.*
- *Measure usage statistics and analytics for signed-out or anonymous users.*

Possible solutions include:

- **App set ID:** An App Set ID allows you to analyze a user's behavior across multiple apps that your organization owns, as long as you don't use user data for advertising purposes. If you're targeting devices powered by Google Play services, we recommend that you use App Set ID.
- **Firebase ID (FID):** An FID is scoped to the app that creates it, which prevents the identifier from being used to track users across apps. It is also easily resettable, as the user can clear app data or reinstall the app. The process of creating a FID is straightforward; see the Firebase installations guide.

### App development

#### Crash reporting

*In this case, your app collects data regarding when and why it crashes on a
user's devices.*

**Recommended identifier to use:** FID or App set ID

**Why this recommendation?**

An FID is scoped to the app that creates it, which prevents the identifier from
being used to track users across apps. It is also easily resettable, as the user
can clear app data or reinstall the app. The process of creating a FID is
straightforward; see the
[Firebase installations guide](https://firebase.google.com/docs/projects/manage-installations).
An App Set ID allows you to analyze a user's behavior across multiple apps that
your organization owns, as long as you don't use user data for advertising
purposes.

#### Performance reporting

In this case, your app collects performance metrics, such as load times and
battery usage, to help improve your app's quality.

**Recommended identifier to use:**
[Firebase Performance Monitoring](https://firebase.google.com/products/performance)

**Why this recommendation?**

Firebase Performance Monitoring helps you focus on the metrics that matter most
to you, and to test the impact of a recent change in your app.

### App testing

In this case, your app evaluates a user's experience with your app for testing
or debugging purposes.

**Recommended identifier to use:** FID or App set ID

**Why this recommendation?**

An FID is scoped to the app that creates it, which prevents the identifier from
being used to track users across apps. It is also easily resettable, as the user
can clear app data or reinstall the app. The process of creating a FID is
straightforward; see the
[Firebase installations guide](https://firebase.google.com/docs/projects/manage-installations).
An App Set ID allows you to analyze a user's behavior across multiple apps that
your organization owns, as long as you don't use user data for advertising
purposes.

### Cross-device installation

*In this case, your app needs to identify the correct instance of the app when
it's installed on multiple devices for the same user.*

**Recommended identifier to use:** FID or GUID

**Why this recommendation?**

An FID is designed explicitly for this purpose; its scope is limited to the
app so that it cannot be used to track users across different apps, and it's
reset upon app reinstall. In the rare cases where an FID is
insufficient, you can also use a GUID.

### Security

#### Abuse detection

*In this case, you are trying to detect multiple fake devices attacking your
backend services.*

**Recommended identifier to use:** The Google Play Integrity API integrity token

**Why this recommendation?**

To verify that a request comes from a genuine Android device---rather than an
emulator or other code spoofing another device---use the
[Google Play Integrity API](https://developer.android.com/google/play/integrity/overview).

#### Ad fraud

*In this case, your app checks that a user's impressions and actions in your app
are genuine and verifiable.*

**Recommended identifier to use:** Advertising ID

**Why this recommendation?**

Use of the Advertising ID is mandatory for advertising use cases, per the
[Google Play Developer Content Policy](https://play.google.com/about/developer-content-policy),
because the user can reset it.


#### Digital rights management (DRM)

*In this case, your app wants to protect fraudulent access to intellectual
property or paid content.*

**Recommended identifier to use:** Using an FID or GUID forces the user to
reinstall the app in order to circumvent the content limits, which is a
sufficient burden to deter most people. If this isn't sufficient protection,
Android provides a [DRM API](https://source.android.com/devices/drm), which can
be used to limit access to content, includes a per-APK identifier, the
Widevine ID.


### User preferences

*In this case, your app saves per-device user state on your app's, particularly
for users who aren't signed in. You might transfer this state to another app
that's signed with the same key on the same device.*

**Recommended identifier to use:** FID or GUID

**Why this recommendation?**

Persisting information through reinstalls isn't recommended because users may
want to reset their preferences by reinstalling the app.