Questa pagina è stata tradotta dall'API Cloud Translation.

Best practice per gli identificatori univoci

Questo documento fornisce indicazioni per selezionare gli identificatori appropriati per i tuoi in base al tuo caso d'uso.

Per una panoramica delle autorizzazioni Android, leggi l'articolo Autorizzazioni Panoramica. Per best practice specifiche per l'utilizzo delle autorizzazioni Android, consulta le best practice per le autorizzazioni app.

Best practice per l'uso degli identificatori Android

Per proteggere la privacy dei tuoi utenti, utilizza l'identificatore più restrittivo chesoddisfa il caso d'uso della tua app. In particolare, segui queste best practice:

Scegli identificatori reimpostabili dall'utente quando possibile. L'app può ottenere la maggior parte dei casi d'uso anche quando utilizza identificatori diversi dagli ID hardware non reimpostabili.
Evita di utilizzare identificatori hardware. Nella maggior parte dei casi, puoi evitare di usare identificatori hardware, come l'International Mobile Equipment Identity (IMEI), senza limitare la funzionalità richiesta.

Android 10 (livello API 29) aggiunge limitazioni per gli identificatori non reimpostabili, tra cui IMEI e numero di serie. Per poter accedere a questi identificatori, la tua app deve essere un'app di proprietà del dispositivo o del profilo, avere autorizzazioni speciali dell'operatore o disporre dell'autorizzazione privilegiata READ_PRIVILEGED_PHONE_STATE.
Utilizza un ID pubblicità solo per i casi d'uso di profilazione degli utenti o di annunci. Quando utilizzi un ID pubblicità, rispetta sempre le scelte degli utenti in merito al monitoraggio degli annunci. Se devi collegare l'identificatore pubblicità a informazioni che consentono l'identificazione personale, fallo solo con il consenso esplicito dell'utente.
Non eseguire il bridge delle reimpostazioni dell'ID pubblicità.
Utilizza un ID installazione Firebase (FID) o un GUID archiviato in privato, se possibile, per tutti gli altri casi d'uso, ad eccezione della prevenzione delle frodi relative ai pagamenti e della telefonia. Per la maggior parte dei casi d'uso non pubblicitari, un FID o un GUID dovrebbe essere sufficiente.
Utilizza le API appropriate per il tuo caso d'uso per ridurre al minimo il rischio per la privacy. Utilizza l'API DRM per la protezione dei contenuti di alto valore e API Play Integrity per la protezione dagli abusi. Le API Play Integrity sono il modo più semplice per determinare se un dispositivo è genuino senza incorrere in rischi per la privacy.

Le sezioni rimanenti di questa guida illustrano queste regole nel contesto dello sviluppo di app per Android.

Utilizzare gli ID pubblicità

L'ID pubblicità è un identificatore reimpostabile dall'utente ed è appropriato per gli annunci e casi d'uso specifici. Ci sono alcuni punti chiave da tenere a mente, ma quando usi questo strumento ID:

Rispetta sempre l'intenzione dell'utente di reimpostare l'ID pubblicità. Non collegare le reimpostazioni utente utilizzando un altro identificatore o un'altra impronta per collegare ID pubblicità successivi senza il consenso dell'utente. I contenuti degli sviluppatori di Google Play Le norme stabiliscono che seguenti:

"...se viene reimpostato, un nuovo identificatore pubblicità non deve essere collegato a un identificatore pubblicità precedente o dati derivanti da una precedente pubblicità senza l'esplicito consenso dell'utente."

Rispetta sempre l'indicatore Annunci personalizzati associato. Gli ID pubblicità sono configurabili in quanto gli utenti possono limitare la quantità di monitoraggio associata all'ID. Utilizza sempre il metodo AdvertisingIdClient.Info.isLimitAdTrackingEnabled() per assicurarti di non aggirare le preferenze degli utenti. Il Google Contenuti degli sviluppatori di Google Play Le norme stabiliscono che seguenti:

"…devi rispettare l'impostazione di disattivazione della pubblicità basata sugli interessi o della personalizzazione degli annunci configurata dall'utente. Se un utente ha attivato questa impostazione, non puoi utilizzare l'identificatore pubblicità per creare profili utente per per scopi pubblicitari o per il targeting degli utenti con pubblicità personalizzata. Le attività consentite includono pubblicità contestuale, quota limite, conversione monitoraggio, creazione di report e rilevamento di problemi di sicurezza e attività fraudolente."

Tieni presente le norme sulla privacy o sulla sicurezza associate agli SDK che utilizzi e relative all'utilizzo dell'ID pubblicità. Ad esempio, se passi true al metodo enableAdvertisingIdCollection() dell'SDK Google Analytics, assicurati di rivedere e rispettare tutte le norme dell'SDK Analytics applicabili.

Inoltre, tieni presente che le Norme relative ai contenuti per gli sviluppatori di Google Play richiedono che l'ID pubblicità "non sia collegato a informazioni che consentono l'identificazione personale o associato a un identificatore del dispositivo persistente (ad esempio SSAID, indirizzo MAC, IMEI e così via)".

Ad esempio, supponiamo che tu voglia raccogliere informazioni per compilare il database con le seguenti colonne:

TABELLA-01
`timestamp`	`ad_id`	`account_id`	`clickid`
TABELLA-02
`account_id`	`name`	`dob`	`country`

In questo esempio, la colonna ad_id potrebbe essere unita alle PII tramite account_id in entrambe le tabelle, il che costituirebbe una violazione delle Norme relative ai contenuti, se non hanno ricevuto l'autorizzazione esplicita dagli utenti.

Tieni presente che i link tra ID inserzionista e PII non sono sempre così espliciti. È possibile che vengano visualizzati "quasi-identificatori" sia nelle tabelle con chiave PII sia nelle tabelle con chiave ID annuncio, che causano anche problemi. Ad esempio, supponiamo di cambiare TABLE-01 e TABLE-02 come segue:

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

In questo caso, se gli eventi di clic sono sufficientemente rari, è comunque possibile partecipare tra l'ID inserzionista TABLE-01 e le PII contenute in TABLE-02 utilizzando il timestamp dell'evento e il modello del dispositivo.

Sebbene sia spesso difficile garantire che questi quasi-identificatori non esistano in un set di dati, puoi prevenire i rischi di join più evidenti generalizzando ove possibile. Nell'esempio precedente, ciò significherebbe ridurre la precisione del timestamp in modo che più dispositivi con lo stesso modello vengano visualizzati per ogni timestamp.

Altre soluzioni includono:

Non progettare tabelle che colleghino esplicitamente le PII agli ID pubblicità. Nel primo esempio riportato sopra, ciò significa non includere la colonna account_id nella TABELLA-01.
Separazione e monitoraggio degli elenchi di controllo dell'accesso per gli utenti o i ruoli che hanno accesso sia ai dati con chiave ID pubblicità sia alle PII. Controllando e verificando attentamente la possibilità di accedere contemporaneamente a entrambe le origini (ad esempio, eseguendo un join tra le tabelle), riduci il rischio di associazione tra l'ID pubblicità e le PII. In generale, controllare l'accesso significa:
1. Mantieni gli elenchi di controllo dell'accesso (ACL) per i dati con chiave e le PII dell'ID inserzionista separati per minimizzare il numero di individui o ruoli che rientrano ACL.
2. Implementa il logging e il controllo degli accessi per rilevare e gestire eventuali eccezioni a questa regola.

Per ulteriori informazioni sull'utilizzo responsabile degli ID pubblicità, consulta la documentazione di riferimento dell'API AdvertisingIdClient.

Utilizzo di FID e GUID

La soluzione più semplice per identificare un'istanza di app in esecuzione su un dispositivo è utilizzare un ID installazione Firebase (FID) e si tratta del metodo consigliato nella maggior parte dei casi d'uso non pubblicitari. Solo l'istanza dell'app per cui di cui è stato eseguito il provisioning può accedere a questo identificatore ed è (relativamente) facilmente reimpostabile perché persiste solo finché l'app è installata.

Di conseguenza, gli FID forniscono proprietà della privacy migliori rispetto agli ID hardware basati sul dispositivo e non reimpostabili. Per ulteriori informazioni, consulta il riferimento all'API firebase.installations.

Nei casi in cui un FID non sia pratico, puoi anche utilizzare ID personalizzati (GUID) univoci a livello globale per identificare in modo univoco un'istanza di app. Il modo più semplice per farlo è generare il tuo GUID utilizzando il seguente codice:

KotlinJava

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

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

Poiché l'identificatore è univoco a livello globale, può essere utilizzato per identificare una specifica istanza dell'app. Per evitare problemi relativi al collegamento dell'identificatore tra le app, archiviare i GUID nella memoria interna anziché nell'archiviazione esterna (condivisa). Per ulteriori informazioni, consulta la pagina Panoramica dell'archiviazione di dati e file.

Non funzionano con gli indirizzi MAC

Gli indirizzi MAC sono univoci a livello globale, non possono essere reimpostati dall'utente e rimangono invariati anche dopo il ripristino dei dati di fabbrica. Per questi motivi, per proteggere la privacy degli utenti, nelle versioni di Android 6 e superiori l'accesso agli indirizzi MAC è limitato alle app di sistema. Le app di terze parti non possono accedervi.

Modifiche alla disponibilità degli indirizzi MAC in Android 11

Nelle app che hanno come target Android 11 e versioni successive, la randomizzazione degli indirizzi MAC per Passpoint reti è per profilo Passpoint, generando un indirizzo MAC univoco in base al seguenti campi:

Nome di dominio completo (FQDN)
Area di autenticazione
Autenticazione, in base alle credenziali utilizzate nel profilo Passpoint:
- Credenziali utente: nome utente
- Credenziale del certificato: cert e tipo di certificato
- Credenziale SIM: tipo EAP e IMSI

Inoltre, le app non privilegiate non possono accedere all'indirizzo MAC del dispositivo; sono visibili solo le interfacce di rete con un indirizzo IP. Ciò influisce sulle getifaddrs() e NetworkInterface.getHardwareAddress() oltre a inviare messaggi Netlink RTM_GETLINK.

Di seguito è riportato un elenco dei modi in cui le app sono interessate da questa modifica:

NetworkInterface.getHardwareAddress() restituisce un valore nullo per ogni interfaccia.
Le app non possono utilizzare la funzione bind() sulle socket NETLINK_ROUTE.
Il comando ip non restituisce informazioni sulle interfacce.
Le app non possono inviare messaggi RTM_GETLINK.

Tieni presente che la maggior parte degli sviluppatori dovrebbe utilizzare le API di livello superiore di ConnectivityManager anziché le API di livello inferiore come NetworkInterface, getifaddrs() o le socket Netlink. Ad esempio, un'app che necessita di informazioni aggiornate sulla le route attuali possono ottenere queste informazioni ascoltando i cambiamenti di rete utilizzando ConnectivityManager.registerNetworkCallback() e chiamando i dati associati alla rete LinkProperties.getRoutes().

Caratteristiche degli identificatori

Il sistema operativo Android offre una serie di ID con caratteristiche di comportamento diverse. L'ID da utilizzare dipende dal funzionamento delle seguenti caratteristiche con il tuo caso d'uso. Queste caratteristiche hanno anche implicazioni sulla privacy, perciò è importante capire in che modo queste caratteristiche interagiscono tra loro.

Ambito

L'ambito dell'identificatore indica quali sistemi possono accedere all'identificatore. Android l'ambito degli identificatori è in genere disponibile in tre versioni:

App singola: l'ID è interno all'app e non è accessibile ad altre app.
Gruppo di app: l'ID è accessibile a un gruppo predefinito di app correlate.
Dispositivo: l'ID è accessibile a tutte le app installate sul dispositivo.

Più ampio è l'ambito concesso a un identificatore, maggiore è il rischio che venga utilizzato per scopi di monitoraggio. Al contrario, se un identificatore è accessibile solo da una singola istanza dell'app, non può essere utilizzato per monitorare un dispositivo nelle transazioni in app diverse.

Resettabilità e persistenza

Resettabilità e persistenza definiscono la durata dell'identificatore e spiegano come può essere reimpostato. Gli attivatori di reimpostazione più comuni includono: reimpostazioni in-app, ripristini tramite Impostazioni di sistema, ripristini all'avvio e ripristini al momento dell'installazione. Gli identificatori Android possono avere durate diverse, ma in genere sono correlate al modo in cui l'ID viene reimpostato:

Solo per la sessione: viene utilizzato un nuovo ID ogni volta che l'utente riavvia l'app.
Installazione-reimpostazione: viene utilizzato un nuovo ID ogni volta che l'utente disinstalla e reinstalla l'app.
Ripristino dei dati di fabbrica: viene utilizzato un nuovo ID ogni volta che l'utente ripristina i dati di fabbrica del dispositivo.
FDR-persistent: l'ID persiste dopo il ripristino dei dati di fabbrica.

La reimpostazione consente agli utenti di creare un nuovo ID disaccoppiato da qualsiasi informazione del profilo esistente. Maggiore è la durata e l'affidabilità di un identificatore, ad esempio uno che persiste anche dopo i ripristini dei dati di fabbrica, maggiore è il rischio che l'utente possa essere sottoposto a monitoraggio a lungo termine. Se viene reimpostato alla reinstallazione dell'app, riducendo così la persistenza fornisce un mezzo per la reimpostazione dell'ID, anche se non esiste un utente esplicito per reimpostarla dall'app o dalle Impostazioni di sistema.

Unicità

L'unicità stabilisce la probabilità di collisioni, ovvero l'esistenza di identificatori identici nell'ambito associato. A livello più alto, un identificatore univoco a livello mondiale non ha mai collisioni, nemmeno su altri dispositivi o app. In caso contrario, il livello di unicità dipende dall'entropia dell'identificatore e dalla fonte di casualità utilizzata per crearlo. Ad esempio, la possibilità che la collisione è molto più elevata per gli identificatori casuali con data di calendario (ad esempio 2019-03-01) che per gli identificatori seed with the Unix timestamp dell'installazione (ad esempio 1551414181).

In generale, gli identificatori degli account utente possono essere considerati univoci. Vale a dire che ogni la combinazione dispositivo/account ha un ID univoco. D'altra parte, meno un identificativo è univoco all'interno di una popolazione, maggiore è la protezione della privacy perché è meno utile per monitorare un singolo utente.

Protezione dell'integrità e non ripudibilità

Puoi utilizzare un identificatore difficile da spoofing o replicare per dimostrare che dispositivo o account associato ha determinate proprietà. Ad esempio, potresti dimostrare che il dispositivo non è un dispositivo virtuale utilizzato da uno spammer. Anche gli identificatori difficili da falsificare offrono non riproducibilità. Se il dispositivo firma un messaggio con una chiave segreta, è difficile affermare che il messaggio sia stato inviato dal dispositivo di qualcun altro. La non ripudio potrebbe essere qualcosa che un utente vuole, ad esempio quando autentica un pagamento, oppure potrebbe essere una proprietà indesiderata, ad esempio quando invia un messaggio di cui si pente.

Casi d'uso comuni e l'identificatore appropriato da utilizzare

Questa sezione fornisce alternative all'utilizzo degli ID hardware, come l'IMEI. Utilizzo Gli ID hardware sono sconsigliati perché l'utente non può reimpostarli limitato all'ambito del dispositivo. In molti casi, un identificatore basato sulle app sarà sufficiente.

Account

Stato dell'operatore

In questo caso, la tua app interagisce con lo smartphone del dispositivo e invia messaggi usando l'account di un operatore.

Identificatore consigliato da utilizzare:IMEI, IMSI e Line1

Perché questo consiglio?

L'utilizzo di identificatori hardware è accettabile se richiesto per funzionalità correlate all'operatore. Ad esempio, puoi utilizzare questi identificatori per cambiare operatore di telefonia cellulare o slot SIM oppure per inviare messaggi SMS tramite IP (per Line1) - account utente basati su SIM. Per le app senza privilegi, tuttavia, consigliamo di utilizzare un accesso all'account per recuperare le informazioni sul dispositivo dell'utente sul lato server. Uno dei motivi è che, in Android 6.0 (livello API 23) e versioni successive, questi identificatori possono essere utilizzati solo tramite un'autorizzazione di runtime. Gli utenti potrebbero disattiva questa autorizzazione, in modo che la tua app possa gestire queste eccezioni con eleganza.

Stato dell'abbonamento mobile

In questo caso, devi associare la funzionalità dell'app a determinate abbonamenti al servizio sul dispositivo. Ad esempio, potresti avere l'obbligo di verificare l'accesso a determinate funzionalità dell'app premium in base agli abbonamenti di telefonia mobile del dispositivo tramite SIM.

Identificatore consigliato da utilizzare: ID sottoscrizione API per identificare le SIM utilizzate sul dispositivo.

L'ID sottoscrizione fornisce un valore di indice (a partire da 1) per identificare le SIM installate (incluse quelle fisiche ed elettroniche) utilizzate dispositivo. Tramite questo ID, l'app può associare la sua funzionalità a varie informazioni sull'abbonamento per una determinata SIM. Questo valore è stabile per una determinata SIM a meno che non vengano ripristinati i dati di fabbrica del dispositivo. Tuttavia, possono verificarsi casi in cui La SIM ha un ID abbonamento diverso su dispositivi diversi oppure SIM diverse hanno lo stesso ID su dispositivi diversi.

Perché questo consiglio?

Alcune app potrebbero attualmente utilizzare l'ID ICC per questo scopo. Poiché l'ID ICC è univoco a livello globale e non può essere reimpostato, l'accesso è stato limitato alle app con l'autorizzazione READ_PRIVILEGED_PHONE_STATE da Android 10. A partire da Android 11, anche Android accesso limitato all'ICCID tramite getIccId() all'API, indipendentemente dal livello API target dell'app. La migrazione delle app interessate deve essere eseguita in ma usare l'ID abbonamento.

Single Sign-On

In questo caso, la tua app offre un'esperienza di accesso singolo, consentendo agli utenti di associare un account esistente alla tua organizzazione.

Identificatore consigliato da utilizzare: account compatibili con gli account manager, ad esempio Collegamento dell'Account Google

Perché questo consiglio?

Il collegamento dell'Account Google consente agli utenti di associare l'account Google esistente di un utente account con la tua app, fornendo un accesso semplice e più sicuro al tuo i prodotti e i servizi della tua organizzazione. Inoltre, puoi definire ambiti OAuth personalizzati per condividere solo i dati necessari, aumentando la fiducia degli utenti definendo chiaramente come vengono utilizzati i loro dati.

Annunci

Targeting

In questo caso, la tua app crea un profilo degli interessi di un utente per mostrargli annunci più pertinenti.

Identificatore consigliato da utilizzare: se la tua app utilizza un ID per gli annunci e viene caricata o pubblicata su Google Play, questo ID deve essere l'ID pubblicità.

Perché questo consiglio?

Si tratta di un caso d'uso relativo agli annunci che potrebbe richiedere un ID disponibile tra le diverse app dell'organizzazione. L'utilizzo di un ID pubblicità è la soluzione più appropriata. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, in base Norme relative ai contenuti per gli sviluppatori di Google Play, perché l'utente può reimpostarlo.

Che tu voglia condividere o meno i dati utente nella tua app, se li raccogli e li utilizzi a fini pubblicitari, devi dichiarare le finalità pubblicitarie nel Sezione Sicurezza dei dati della pagina Contenuti app in Play Console.

Misurazione

In questo caso, la tua app crea il profilo di un utente in base al suo comportamento tra le app della tua organizzazione sullo stesso dispositivo.

Identificatore consigliato da utilizzare: ID pubblicità o API referrer di installazioni di Google Play

Perché questo consiglio?

Questo è un caso d'uso correlato agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, pertanto l'utilizzo di un ID pubblicità è la soluzione più appropriata. Se utilizzi un ID per casi d'uso pubblicitari, questo ID deve essere l'ID pubblicità perché l'utente può reimpostarlo. Scopri di più nelle Norme relative ai contenuti per gli sviluppatori di Google Play.

Conversioni

In questo caso, stai monitorando le conversioni per capire se la tua strategia di marketing ha successo.

Identificatore consigliato da utilizzare: ID pubblicità o API referrer di installazioni di Google Play

Perché questo consiglio?

Remarketing

In questo caso, la tua app mostra annunci basati sugli interessi precedenti dell'utente.

Identificatore consigliato da utilizzare:ID pubblicità

Perché questo consiglio?

Questo è un caso d'uso correlato agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, pertanto l'utilizzo di un ID pubblicità è la soluzione più appropriata. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, in base Norme relative ai contenuti per gli sviluppatori di Google Play, perché l'utente può reimpostarlo.

Analisi dati delle app

In questo caso, la tua app valuta il comportamento di un utente per aiutarti a determinare quanto segue:

Quali altri prodotti o app dell'organizzazione potrebbero essere adatti al utente.
Come mantenere gli utenti interessati a utilizzare la tua app.
Misurare statistiche e analisi sull'utilizzo per gli utenti anonimi o che non hanno eseguito l'accesso.

Le possibili soluzioni sono:

ID set di app: un ID set di app ti consente di analizzare il comportamento di un utente su Più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente per scopi pubblicitari. Se scegli come target i dispositivi con i servizi Google Play, ti consigliamo di utilizzare l'ID set di app.
ID Firebase (FID): un FID è limitato all'app che lo crea, il che impedisce l'utilizzo dell'identificatore per monitorare gli utenti nelle app. È inoltre possibile facilmente reimpostabili, in quanto l'utente può cancellare i dati dell'app o reinstallarla. La il processo di creazione di un FID è semplice; vedi le installazioni di Firebase guida.

Sviluppo di app

Report sugli arresti anomali

In questo caso, la tua app raccoglie dati relativi a quando e perché ha arresti anomali su una sui dispositivi degli utenti.

Identificatore consigliato da utilizzare: FID o ID set di app

Perché questo consiglio?

Un FID ha come ambito l'app che lo crea, il che impedisce all'identificatore di utilizzati per monitorare gli utenti nelle app. Inoltre, può essere reimpostato facilmente, poiché l'utente può cancellare i dati dell'app o reinstallarla. La procedura di creazione di un FID diretto; vedi il Guida all'installazione di Firebase. Un ID set di app ti consente di analizzare il comportamento di un utente su più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente per scopi pubblicitari.

Report sul rendimento

In questo caso, l'app raccoglie metriche sul rendimento, come i tempi di caricamento e l'utilizzo della batteria, per contribuire a migliorare la qualità dell'app.

Identificatore consigliato da utilizzare: Firebase Performance Monitoring

Perché questo consiglio?

Firebase Performance Monitoring ti aiuta a concentrarti sulle metriche più importanti e per verificare l'impatto di una modifica recente all'interno dell'app.

Test delle app

In questo caso, la tua app valuta l'esperienza di un utente con la tua app a scopo di test o debug.

Identificatore consigliato da utilizzare:FID o ID set di app

Perché questo consiglio?

Un FID ha come ambito l'app che lo crea, il che impedisce all'identificatore di utilizzati per monitorare gli utenti nelle app. Inoltre, può essere reimpostato facilmente, poiché l'utente può cancellare i dati dell'app o reinstallarla. La procedura per creare un FID è semplice; consulta la guida alle installazioni di Firebase. Un ID set di app ti consente di analizzare il comportamento di un utente su più app che proprietà dell'organizzazione, purché non vengano utilizzati dati utente a scopi pubblicitari scopi.

Installazione cross-device

In questo caso, l'app deve identificarne l'istanza corretta quando Viene installata su più dispositivi per lo stesso utente.

Identificatore consigliato da utilizzare: FID o GUID

Perché questo consiglio?

Un FID è progettato esplicitamente per questo scopo; il suo ambito è limitato all'app, pertanto non può essere utilizzato per monitorare gli utenti su app diverse e viene reimpostato al momento della reinstallazione dell'app. Nei rari casi in cui un FID viene insufficiente, puoi anche usare un GUID.

Sicurezza

Rilevamento di comportamenti illeciti

In questo caso, stai cercando di rilevare più dispositivi falsi che attaccano i tuoi servizi di backend.

Identificatore consigliato da utilizzare: il token di integrità dell'API Google Play Integrity

Perché questo consiglio?

Per verificare che una richiesta provenga da un dispositivo Android originale, anziché da un emulatore o da un altro codice che simula un altro dispositivo, utilizza l'API Google Play Integrity.

Frode pubblicitaria

In questo caso, l'app controlla che le impressioni e le azioni di un utente siano autentici e verificabili.

Identificatore consigliato da utilizzare: ID pubblicità

Perché questo consiglio?

L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, in base al Norme relative ai contenuti per gli sviluppatori di Google Play, perché l'utente può reimpostarlo.

Gestione dei diritti digitali (DRM)

In questo caso, la tua app vuole proteggere l'accesso fraudolento alla proprietà intellettuale o ai contenuti a pagamento.

Identificatore consigliato da usare:l'utilizzo di un FID o un GUID obbliga l'utente a reinstallare l'app per aggirare i limiti di contenuti, un'operazione che un carico sufficiente a scoraggiare la maggior parte delle persone. Se questa protezione non è sufficiente, Android fornisce un'API DRM, che può essere utilizzata per limitare l'accesso ai contenuti, e include un identificatore per APK, l'ID Widevine.

Preferenze utente

In questo caso, la tua app salva lo stato utente per dispositivo, in particolare per gli utenti che non hanno eseguito l'accesso. Potresti trasferire questo stato a un'altra app firmata con la stessa chiave sullo stesso dispositivo.

Identificatore consigliato da utilizzare: FID o GUID

Perché questo consiglio?

La persistenza delle informazioni tramite le reinstallazioni non è consigliata perché gli utenti potrebbero voler reimpostare le preferenze reinstallando l'app.