Cette page a été traduite par l'API Cloud Translation.

Bonnes pratiques pour les identifiants uniques

Ce document explique comment sélectionner les identifiants appropriés pour votre application en fonction de votre cas d'utilisation.

Pour en savoir plus sur les autorisations Android, consultez la section Présentation des autorisations. Pour connaître les bonnes pratiques d'utilisation des autorisations Android, consultez Bonnes pratiques pour les autorisations d'applications.

Bonnes pratiques d'utilisation des identifiants Android

Pour protéger la confidentialité de vos utilisateurs, utilisez l'identifiant le plus restrictif adapté au cas d'utilisation de votre application. Suivez tout particulièrement les bonnes pratiques suivantes:

Dans la mesure du possible, choisissez des identifiants réinitialisables par l'utilisateur. Votre application peut atteindre la plupart de ses cas d'utilisation, même lorsqu'elle se sert d'identifiants autres que les ID matériels non réinitialisables.
Évitez d'utiliser des identifiants matériels. Dans la plupart des cas d'utilisation, vous pouvez éviter d'utiliser des identifiants matériels, tels que l'identifiant international de l'équipement mobile (IMEI), sans limiter les fonctionnalités requises.

Android 10 (niveau d'API 29) ajoute des restrictions pour les identifiants non réinitialisables, y compris le code IMEI et le numéro de série. Votre application doit être une application de propriétaire d'appareil ou de profil, doit disposer d'autorisations spéciales de l'opérateur ou disposer de l'autorisation privilégiée READ_PRIVILEGED_PHONE_STATE pour accéder à ces identifiants.
N'utilisez un identifiant publicitaire que pour le profilage des utilisateurs ou pour des cas d'utilisation d'annonces. Lorsque vous utilisez un identifiant publicitaire, respectez toujours les choix des utilisateurs concernant le suivi des annonces. Si vous devez associer l'identifiant publicitaire à des informations permettant d'identifier personnellement l'utilisateur, faites-le uniquement avec le consentement explicite de l'utilisateur.
N'associez pas les réinitialisations d'identifiants publicitaires.
Dans la mesure du possible, utilisez un ID d'installation Firebase (FID) ou un GUID stocké de manière privée pour tous les autres cas d'utilisation, à l'exception de la prévention des fraudes au paiement et de la téléphonie. Pour la grande majorité des cas d'utilisation autres que les annonces, un FID ou un GUID devrait suffire.
Utilisez des API adaptées à votre cas d'utilisation pour minimiser les risques liés à la confidentialité. Utilisez l'API DRM pour la protection des contenus à forte valeur ajoutée et les API Play Integrity pour la protection contre les abus. Les API Play Integrity sont le moyen le plus simple de déterminer si un appareil est authentique sans risque pour la confidentialité.

Les autres sections de ce guide détaillent ces règles dans le contexte du développement d'applications Android.

Utiliser des identifiants publicitaires

L'identifiant publicitaire est un identifiant réinitialisable par l'utilisateur qui convient aux cas d'utilisation publicitaires. Lorsque vous utilisez cet ID, vous devez toutefois tenir compte des points clés suivants:

Respectez toujours l'intention de l'utilisateur de réinitialiser l'identifiant publicitaire. N'associez pas les réinitialisations des utilisateurs à l'aide d'un autre identifiant ou d'une autre empreinte digitale pour associer les identifiants publicitaires suivants sans l'autorisation de l'utilisateur. Le Règlement relatif au contenu Google Play pour les développeurs stipule les éléments suivants:

"...s'il est réinitialisé, un nouvel identifiant publicitaire ne doit pas être associé à un identifiant publicitaire précédent ni à des données qui en sont dérivées sans le consentement explicite de l'utilisateur."

Respectez toujours l'indicateur d'annonces personnalisées associé. Les identifiants publicitaires sont configurables dans la mesure où les utilisateurs peuvent limiter le niveau de suivi qui leur est associé. Utilisez toujours la méthode AdvertisingIdClient.Info.isLimitAdTrackingEnabled() pour vous assurer de ne pas contourner les souhaits de vos utilisateurs. Le Règlement relatif au contenu Google Play pour les développeurs stipule les éléments suivants:

"...vous devez respecter le paramètre "Désactiver les annonces par centres d'intérêt" ou "Désactiver la personnalisation des annonces" défini par l'utilisateur. Si un utilisateur a activé ce paramètre, vous ne pouvez pas utiliser l'identifiant publicitaire pour créer des profils utilisateur à des fins publicitaires ou pour cibler des utilisateurs avec de la publicité personnalisée. Les activités autorisées incluent la publicité contextuelle, la limitation de la fréquence d'exposition, le suivi des conversions, la création de rapports, la sécurité et la détection des fraudes."

Prenez connaissance des règles de confidentialité ou de sécurité associées aux SDK que vous utilisez et qui sont liées à l'utilisation des identifiants publicitaires. Par exemple, si vous transmettez true à la méthode enableAdvertisingIdCollection() à partir du SDK Google Analytics, veillez à consulter et à respecter toutes les Règles du SDK Analytics applicables.

Sachez également que le Règlement relatif au contenu Google Play pour les développeurs exige que l'identifiant publicitaire ne soit associé à aucune information permettant d'identifier personnellement l'utilisateur ni à un identifiant permanent de l'appareil (par exemple, SSAID, adresse MAC, code IMEI, etc.).

Par exemple, supposons que vous souhaitiez collecter des informations pour renseigner les tables de la base de données avec les colonnes suivantes:

TABLEAU 01
`timestamp`	`ad_id`	`account_id`	`clickid`
TABLEAU 02
`account_id`	`name`	`dob`	`country`

Dans cet exemple, la colonne ad_id peut être jointe aux informations permettant d'identifier personnellement l'utilisateur via la colonne account_id des deux tables, ce qui enfreint le Règlement relatif au contenu Google Play pour les développeurs si vous n'avez pas obtenu l'autorisation explicite de vos utilisateurs.

N'oubliez pas que les liens entre la référence annonceur et les informations permettant d'identifier personnellement l'utilisateur ne sont pas toujours aussi explicites. Il est possible que des "quasi-identifiants" apparaissent à la fois dans les tableaux contenant des informations permettant d'identifier personnellement l'utilisateur et des identifiants d'annonce, ce qui pose également des problèmes. Par exemple, supposons que nous modifions TABLE-01 et TABLE-02 comme suit:

TABLEAU 01
`timestamp`	`ad_id`	`clickid`	`dev_model`
TABLEAU 02
`timestamp`	`demo`	`account_id`	`dev_model`	`name`

Dans ce cas, avec des événements de clic suffisamment rares, il est toujours possible de joindre la référence annonceur TABLE-01 aux informations permettant d'identifier personnellement l'utilisateur contenues dans le tableau TABLE-02 en utilisant l'horodatage de l'événement et le modèle d'appareil.

Bien qu'il soit souvent difficile de garantir l'absence de ces quasi-identifiants dans un ensemble de données, vous pouvez éviter les risques de jointure les plus évidents en généralisant des données uniques lorsque cela est possible. Dans l'exemple précédent, cela impliquerait de réduire la précision de l'horodatage afin que plusieurs appareils avec le même modèle apparaissent pour chaque horodatage.

Voici d'autres solutions possibles:

Ne pas concevoir de tables qui associent explicitement des informations permettant d'identifier personnellement l'utilisateur avec des identifiants publicitaires. Dans le premier exemple ci-dessus, cela signifierait que la colonne account_id n'est pas incluse dans la table TABLE-01.
Séparer et surveiller des listes de contrôle d'accès pour les utilisateurs ou les rôles qui ont accès à la fois aux données contenant des identifiants publicitaires et aux informations permettant d'identifier personnellement l'utilisateur En contrôlant et en auditant étroitement la capacité à accéder simultanément aux deux sources (par exemple, en effectuant une jointure entre les tables), vous réduisez le risque d'association entre l'identifiant publicitaire et les informations permettant d'identifier personnellement l'utilisateur. De manière générale, contrôler les accès implique d'effectuer les opérations suivantes:
1. Conservez les listes de contrôle d'accès (LCA) pour les données associées aux références annonceur et les informations permettant d'identifier personnellement l'utilisateur afin de réduire le nombre d'utilisateurs ou de rôles figurant dans les deux LCA.
2. Mettez en œuvre la journalisation et l'audit des accès pour détecter et gérer les exceptions à cette règle.

Pour en savoir plus sur la manière de travailler de manière responsable avec les identifiants publicitaires, consultez la documentation de référence de l'API AdvertisingIdClient.

Utiliser les FID et les GUID

La solution la plus simple pour identifier une instance d'application exécutée sur un appareil consiste à utiliser un ID d'installation Firebase (FID). Cette solution est recommandée dans la plupart des cas d'utilisation autres que les annonces. Seule l'instance d'application pour laquelle elle a été provisionnée peut accéder à cet identifiant. Il est (relativement) facile à réinitialiser, car elle ne persiste que tant que l'application est installée.

Par conséquent, les FID offrent de meilleures propriétés de confidentialité que les ID matériels de portée appareil non réinitialisables. Pour en savoir plus, consultez la documentation de référence de l'API firebase.installations.

Dans les cas où un FID n'est pas pratique, vous pouvez également utiliser des ID uniques globaux (GUID) personnalisés pour identifier de manière unique une instance d'application. Pour ce faire, le moyen le plus simple consiste à générer votre propre GUID à l'aide du code suivant:

Kotlin

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

Java

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

Étant donné que l'identifiant est unique, il peut être utilisé pour identifier une instance d'application spécifique. Pour éviter les problèmes liés à l'association de l'identifiant entre les applications, stockez les GUID dans la mémoire de stockage interne plutôt que dans un espace de stockage externe (partagé). Pour en savoir plus, consultez la page Présentation du stockage de données et de fichiers.

Les adresses MAC ne sont pas compatibles

Les adresses MAC sont uniques au niveau mondial, ne peuvent pas être réinitialisées par l'utilisateur et survivent aux réinitialisations. Pour ces raisons, afin de protéger la confidentialité des utilisateurs, sur Android 6 ou version ultérieure, l'accès aux adresses MAC est limité aux applications système. Les applications tierces ne peuvent pas y accéder.

Changements de la disponibilité des adresses MAC sous Android 11

Dans les applications ciblant Android 11 ou version ultérieure, la randomisation MAC pour les réseaux Passpoint est effectuée par profil Passpoint, ce qui génère une adresse MAC unique en fonction des champs suivants:

Nom de domaine complet
Domaine
Identifiants, en fonction de ceux utilisés dans le profil Passpoint :
- Identifiants utilisateur: nom d'utilisateur
- Identifiants du certificat: certificat et type de certificat
- Identifiants SIM: type EAP et IMSI

De plus, les applications non privilégiées ne peuvent pas accéder à l'adresse MAC de l'appareil. Seules les interfaces réseau avec une adresse IP sont visibles. Cela affecte les méthodes getifaddrs() et NetworkInterface.getHardwareAddress(), ainsi que l'envoi de messages Netlink RTM_GETLINK.

Voici la liste des conséquences de ce changement pour les applications:

NetworkInterface.getHardwareAddress() renvoie une valeur nulle pour chaque interface.
Les applications ne peuvent pas utiliser la fonction bind() sur les sockets NETLINK_ROUTE.
La commande ip ne renvoie pas d'informations sur les interfaces.
Les applications ne peuvent pas envoyer de messages RTM_GETLINK.

Notez que la plupart des développeurs doivent utiliser les API de niveau supérieur de ConnectivityManager plutôt que les API de niveau inférieur telles que les sockets NetworkInterface, getifaddrs() ou Netlink. Par exemple, une application qui a besoin d'informations à jour sur les routes actuelles peut obtenir ces informations en écoutant les modifications du réseau à l'aide de ConnectivityManager.registerNetworkCallback() et en appelant le LinkProperties.getRoutes() associé au réseau.

Caractéristiques des identifiants

L'OS Android propose un certain nombre d'ID avec des caractéristiques de comportement différentes. L'ID à utiliser dépend de la façon dont les caractéristiques suivantes fonctionnent avec votre cas d'utilisation. Toutefois, ces caractéristiques ont également des implications en termes de confidentialité. Il est donc important de comprendre comment ces caractéristiques interagissent les unes avec les autres.

Champ d'application

Le champ d'application de l'identifiant explique quels systèmes peuvent accéder à l'identifiant. Le champ d'application des identifiants Android se présente généralement sous trois formes:

Application unique: l'identifiant est interne à l'application et n'est pas accessible aux autres applications.
Groupe d'applications: un groupe prédéfini d'applications associées peut accéder à l'ID.
Appareil: toutes les applications installées sur l'appareil ont accès à l'ID.

Plus le champ d'application accordé à un identifiant est large, plus il risque d'être utilisé à des fins de suivi. À l'inverse, si un identifiant n'est accessible que par une seule instance d'application, il ne peut pas être utilisé pour suivre un appareil pour les transactions effectuées dans différentes applications.

Réinitialisabilité et persistance

La réinitialisation et la persistance définissent la durée de vie de l'identifiant et expliquent comment celui-ci peut être réinitialisé. Les déclencheurs courants de réinitialisation incluent les réinitialisations dans l'application, les réinitialisations via les paramètres système, les réinitialisations au lancement et les réinitialisations à l'installation. Les identifiants Android peuvent avoir des durées de vie variables, mais celle-ci est généralement liée à la façon dont l'ID est réinitialisé:

Session uniquement: un nouvel identifiant est utilisé chaque fois que l'utilisateur redémarre l'application.
Install-reset: un nouvel ID est utilisé chaque fois que l'utilisateur désinstalle et réinstalle l'application.
Rétablir la configuration d'usine: un nouvel ID est utilisé chaque fois que l'utilisateur rétablit la configuration d'usine de l'appareil.
FDR-persistent: l'ID survit au rétablissement de la configuration d'usine.

La réinitialisation permet aux utilisateurs de créer un ID qui est dissocié des informations de profil existantes. Plus un identifiant persiste et de manière plus fiable (par exemple, s'il persiste en cas de rétablissement de la configuration d'usine), plus le risque que l'utilisateur fasse l'objet d'un suivi à long terme est élevé. Si l'identifiant est réinitialisé lors de la réinstallation de l'application, cela réduit la persistance et permet de le réinitialiser, même s'il n'existe aucune commande utilisateur explicite permettant de le réinitialiser depuis l'application ou les paramètres système.

unicité

L'unicité établit la probabilité de conflits, c'est-à-dire que des identifiants identiques existent dans le champ d'application associé. Au niveau le plus élevé, un identifiant global unique ne présente jamais de conflit, même sur d'autres appareils ou applications. Sinon, le niveau d'unicité dépend de l'entropie de l'identifiant et de la source du caractère aléatoire utilisée pour le créer. Par exemple, le risque de collision est beaucoup plus élevé pour les identifiants aléatoires renseignés avec la date du calendrier d'installation (tels que 2019-03-01) que pour les identifiants contenant l'horodatage d'installation Unix (tels que 1551414181).

En général, les identifiants de compte utilisateur peuvent être considérés comme uniques. Autrement dit, chaque combinaison appareil/compte possède un identifiant unique. En revanche, plus un identifiant est unique au sein d'une population, plus la protection de la confidentialité est importante, car il est moins utile pour suivre un utilisateur individuel.

Protection de l'intégrité et non-répudiabilité

Vous pouvez utiliser un identifiant difficile à falsifier ou à répéter pour prouver que l'appareil ou le compte associé possède certaines propriétés. Par exemple, vous pouvez prouver que l'appareil n'est pas un appareil virtuel utilisé par un spammeur. Les identifiants difficiles à falsifier permettent également de non-répudiabilité. Si l'appareil signe un message avec une clé secrète, il est difficile de prétendre que l'appareil d'une autre personne a envoyé le message. La non-répudiabilité peut être souhaitable pour un utilisateur, par exemple lors de l'authentification d'un paiement, ou une propriété indésirable, comme lorsqu'il envoie un message qu'il regrette.

Cas d'utilisation courants et identifiant approprié

Cette section propose des alternatives à l'utilisation d'ID matériels, tels que le code IMEI. Nous vous déconseillons d'utiliser des ID matériels, car l'utilisateur ne peut pas les réinitialiser, car ils sont limités à l'appareil. Dans de nombreux cas, un identifiant défini au niveau de l'application suffit.

Comptes

État du transporteur

Dans ce cas, votre application interagit avec le téléphone et la fonctionnalité d'envoi de messages de l'appareil à l'aide d'un compte d'opérateur.

Identifiant recommandé à utiliser:IMEI, IMSI et Line1

Pourquoi cette recommandation ?

L'utilisation d'identifiants matériels est acceptable si cela est nécessaire pour les fonctionnalités liées à l'opérateur. Par exemple, vous pouvez utiliser ces identifiants pour changer d'opérateur de téléphonie mobile ou d'emplacement pour carte SIM, ou pour envoyer des SMS via IP (pour la ligne 1) - comptes utilisateur basés sur une carte SIM. Toutefois, pour les applications non privilégiées, nous vous recommandons d'utiliser une connexion avec un compte pour récupérer les informations sur l'appareil de l'utilisateur côté serveur. En effet, sous Android 6.0 (niveau d'API 23) ou version ultérieure, ces identifiants ne peuvent être utilisés que via une autorisation d'exécution. Les utilisateurs peuvent désactiver cette autorisation. Votre application doit donc gérer ces exceptions correctement.

État de l'abonnement mobile

Dans ce cas, vous devez associer les fonctionnalités de l'application à certains abonnements à des services mobiles sur l'appareil. Par exemple, vous pouvez être tenu de vérifier l'accès à certaines fonctionnalités d'applications premium en fonction des abonnements mobiles de l'appareil via une carte SIM.

Identifiant recommandé à utiliser:API Subscription ID pour identifier les cartes SIM utilisées sur l'appareil.

L'ID d'abonnement fournit une valeur d'indice (commençant à 1) pour identifier de manière unique les SIM installées (y compris physiques et électroniques) utilisées sur l'appareil. Grâce à cet ID, votre application peut associer sa fonctionnalité à diverses informations d'abonnement pour une carte SIM donnée. Cette valeur est stable pour une carte SIM donnée, sauf si la configuration d'usine de l'appareil est rétablie. Toutefois, il peut arriver que la même carte SIM ait un ID d'abonnement différent sur différents appareils, ou que différentes cartes SIM aient le même ID sur différents appareils.

Pourquoi cette recommandation ?

Certaines applications utilisent peut-être actuellement l'ID ICC à cette fin. Comme l'ID ICC est unique et non réinitialisable, l'accès a été limité aux applications disposant de l'autorisation READ_PRIVILEGED_PHONE_STATE depuis Android 10. À partir d'Android 11, Android a restreint l'accès à l'ICCID via l'API getIccId(), quel que soit le niveau d'API cible de l'application. Les applications concernées doivent migrer pour utiliser l'ID d'abonnement à la place.

Authentification unique

Dans ce cas, votre application offre une expérience d'authentification unique, ce qui permet aux utilisateurs d'associer un compte existant à votre organisation.

Identifiant recommandé à utiliser:comptes compatibles avec le responsable de compte (par exemple, Association de comptes Google)

Pourquoi cette recommandation ?

L'association du compte Google permet aux utilisateurs d'associer le compte Google existant d'un utilisateur à votre application, afin de bénéficier d'un accès fluide et plus sécurisé aux produits et services de votre organisation. De plus, vous pouvez définir des champs d'application OAuth personnalisés pour ne partager que les données nécessaires, ce qui améliore la confiance des utilisateurs en définissant clairement la manière dont leurs données sont utilisées.

Google Ads

Ciblage

Dans ce cas, votre application crée un profil des centres d'intérêt de l'utilisateur afin de lui présenter des annonces plus pertinentes.

Identifiant recommandé à utiliser:si votre application utilise un identifiant pour les annonces, les importations ou les publications sur Google Play, cet identifiant doit être l'identifiant publicitaire.

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un identifiant disponible dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire est donc la solution la plus appropriée. L'utilisation de l'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaires, conformément au Règlement relatif au contenu Google Play pour les développeurs, car l'utilisateur peut le réinitialiser.

Que vous partagiez ou non des données utilisateur dans votre application, si vous les collectez et les utilisez à des fins publicitaires, vous devez déclarer les finalités des annonces dans la section Sécurité des données de la page Contenu de l'application dans la Play Console.

de mesure

Dans ce cas, votre application crée le profil d'un utilisateur en fonction de son comportement dans les applications de votre organisation sur le même appareil.

Identifiant recommandé à utiliser:API d'identifiant publicitaire ou de provenance des installations Play

Pourquoi cette recommandation ?

Il s'agit d'un cas d'utilisation lié aux annonces qui peut nécessiter un identifiant disponible dans les différentes applications de votre organisation. L'utilisation d'un identifiant publicitaire est donc la solution la plus appropriée. Si vous utilisez un identifiant pour des cas d'utilisation publicitaires, il doit correspondre à l'identifiant publicitaire, car l'utilisateur peut le réinitialiser. Pour en savoir plus, consultez le Règlement relatif au contenu de Google Play pour les développeurs.

Conversions

Dans ce cas, vous suivez les conversions pour détecter si votre stratégie marketing est efficace.

Identifiant recommandé à utiliser:API d'identifiant publicitaire ou de provenance des installations Play

Pourquoi cette recommandation ?

Remarketing

Dans ce cas, votre application diffuse des annonces en fonction des centres d'intérêt antérieurs de l'utilisateur.

Identifiant recommandé à utiliser:identifiant publicitaire

Pourquoi cette recommandation ?

Solution d'analyse d'applications

Dans ce cas, votre application évalue le comportement d'un utilisateur pour vous aider à déterminer les éléments suivants:

Quels autres produits ou applications de votre organisation pourraient convenir à l'utilisateur ?
Comment entretenir l'intérêt des utilisateurs pour votre application ?
Mesurez les statistiques d'utilisation et les données analytiques des utilisateurs non connectés ou anonymes.

Voici les solutions possibles:

ID du groupe d'applications:un ID du groupe d'applications vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications appartenant à votre organisation, à condition que vous n'utilisiez pas de données utilisateur à des fins publicitaires. Si vous ciblez des appareils optimisés par les services Google Play, nous vous recommandons d'utiliser l'ID du groupe d'applications.
ID Firebase (FID) : un FID est limité à l'application qui le crée, ce qui empêche l'utilisation de l'identifiant pour suivre les utilisateurs dans les applications. Il est également facile à réinitialiser, car l'utilisateur peut effacer les données de l'application ou la réinstaller. Le processus de création d'un FID est simple. Consultez le guide d'installation de Firebase.

Développement d'application

Rapports d'erreur

Dans ce cas, votre application collecte des données indiquant quand et pourquoi elle plante sur les appareils d'un utilisateur.

Identifiant recommandé à utiliser:FID ou ID du groupe d'applications

Pourquoi cette recommandation ?

Un FID est limité à l'application qui le crée, ce qui empêche l'utilisation de l'identifiant pour suivre les utilisateurs dans les applications. Il est également facile à réinitialiser, car l'utilisateur peut effacer les données de l'application ou réinstaller l'application. Le processus de création d'un FID est simple. Consultez le guide d'installation de Firebase. Un ID d'ensemble d'applications vous permet d'analyser le comportement d'un utilisateur dans plusieurs applications appartenant à votre organisation, à condition que vous n'utilisiez pas les données utilisateur à des fins publicitaires.

Rapports sur les performances

Dans ce cas, votre application collecte des métriques de performances, telles que les temps de chargement et l'utilisation de la batterie, pour vous aider à améliorer la qualité de votre application.

Identifiant recommandé à utiliser:Firebase Performance Monitoring

Pourquoi cette recommandation ?

Firebase Performance Monitoring vous aide à vous concentrer sur les métriques qui comptent le plus pour vous et à tester l'impact d'une modification récente dans votre application.

Test d'applications

Dans ce cas, votre application évalue l'expérience utilisateur avec votre application à des fins de test ou de débogage.

Identifiant recommandé à utiliser:FID ou ID du groupe d'applications

Pourquoi cette recommandation ?

Installation inter-appareil

Dans ce cas, votre application doit identifier la bonne instance de l'application lorsqu'elle est installée sur plusieurs appareils pour le même utilisateur.

Identifiant recommandé à utiliser:FID ou GUID

Pourquoi cette recommandation ?

Un FID est conçu explicitement à cette fin. Son champ d'application est limité à l'application. Il ne peut donc pas être utilisé pour suivre les utilisateurs dans différentes applications, et il est réinitialisé lors de la réinstallation de l'application. Dans les rares cas où un FID est insuffisant, vous pouvez également utiliser un GUID.

Sécurité

Détection des abus

Dans le cas présent, vous essayez de détecter plusieurs faux appareils qui attaquent vos services de backend.

Identifiant recommandé à utiliser:le jeton d'intégrité de l'API Google Play Integrity

Pourquoi cette recommandation ?

Pour vérifier qu'une requête provient d'un appareil Android authentique, et non d'un émulateur ou d'un autre code usurpant l'identité d'un autre appareil, utilisez l'API Google Play Integrity.

Fraude publicitaire

Dans ce cas, votre application vérifie que les impressions et les actions d'un utilisateur dans votre application sont authentiques et vérifiables.

Identifiant recommandé à utiliser:identifiant publicitaire

Pourquoi cette recommandation ?

L'utilisation de l'identifiant publicitaire est obligatoire pour les cas d'utilisation publicitaires, conformément au Règlement relatif au contenu Google Play pour les développeurs, car l'utilisateur peut le réinitialiser.

Gestion des droits numériques (DRM)

Dans ce cas, votre application souhaite protéger tout accès frauduleux à la propriété intellectuelle ou à des contenus payants.

Identifiant recommandé à utiliser:l'utilisation d'un FID ou d'un GUID oblige l'utilisateur à réinstaller l'application afin de contourner les limites de contenu, ce qui constitue une charge suffisante pour dissuader la plupart des utilisateurs. Si cette protection n'est pas suffisante, Android fournit une API DRM, qui peut être utilisée pour limiter l'accès au contenu, et inclut un identifiant par APK, l'ID Widevine.

Préférences utilisateur

Dans ce cas, votre application enregistre l'état utilisateur par appareil dans votre application, en particulier pour les utilisateurs qui ne sont pas connectés. Vous pouvez transférer cet état vers une autre application signée avec la même clé sur le même appareil.

Identifiant recommandé à utiliser:FID ou GUID

Pourquoi cette recommandation ?

Il n'est pas recommandé de conserver les informations lors des réinstallations, car les utilisateurs peuvent vouloir réinitialiser leurs préférences en réinstallant l'application.