Best practice per gli identificatori univoci

Questo documento fornisce indicazioni per la selezione di identificatori appropriati per la tua app in base al tuo caso d'uso.

Per una panoramica delle autorizzazioni Android, leggi l'articolo Autorizzazioni Panoramica. Per ottenere pratiche per l'uso delle autorizzazioni Android, consulta Best practice sulle autorizzazioni app pratiche.

Best practice per lavorare con gli identificatori Android

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

  1. Scegli identificatori reimpostabili dall'utente quando possibile. La tua app può raggiungere la maggior parte dei casi d'uso anche quando usa identificatori diversi da e non reimpostabili.
  2. 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. L'app deve essere un dispositivo o proprietario del profilo app, hai un operatore speciale autorizzazioni o avere l'autorizzazione privilegiata READ_PRIVILEGED_PHONE_STATE per accedere questi identificatori.

  3. 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.

  4. Non collegare le reimpostazioni degli ID pubblicità.

  5. Utilizza un ID di installazione Firebase (FID) o un GUID memorizzato privatamente possibile per tutti gli altri casi d'uso, ad eccezione della prevenzione delle frodi di pagamento e telefonia. Per la maggior parte dei casi d'uso non pubblicitari, un FID o un GUID dovrebbe essere sufficiente.

  6. 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 di contenuti di alto valore e le API Play Integrity per la protezione da 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.

Utilizza gli ID pubblicità

L'ID pubblicità è un identificatore reimpostabile dall'utente ed è appropriato per i casi d'uso degli annunci. 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 degli utenti utilizzando un altro identificatore o un'altra impronta per il collegamento gli 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 il flag degli 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 impostata dall'utente o "Disattiva Personalizzazione annunci" dell'ambientazione. Se un utente ha attivato questa impostazione, non puoi utilizzare l'identificatore pubblicità per creare profili degli utenti per scopi pubblicitari o per eseguire 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."

Rispetta le norme sulla privacy o sulla sicurezza associate agli SDK che usi e relative all'utilizzo degli 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:

TABLE-01
timestamp ad_id account_id clickid
TABLE-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:

TABLE-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 non esistano quasi identificatori di questo tipo in un set di dati, puoi evitare i rischi di unione più evidenti generalizzando i dati univoci, se possibile. Nell'esempio precedente, ciò significherebbe ridurre la precisione del timestamp in modo che più dispositivi con lo stesso modello compaiono per ogni timestamp.

Altre soluzioni includono:

  • Non progettare tabelle che colleghino esplicitamente le PII agli ID pubblicità. Nella nel primo esempio riportato sopra, ciò significa che la colonna account_id non viene inclusa nella tabella TABLE-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 fare quanto segue:

    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 dell'accesso 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 firebase.installations Riferimento API.

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

Kotlin

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

Java

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. App di terze parti non possono accedervi.

Modifiche alla disponibilità dell'indirizzo MAC in Android 11

Nelle app destinate ad Android 11 e versioni successive, la randomizzazione dell'indirizzo MAC per le reti Passpoint avviene in base al profilo Passpoint, generando un indirizzo MAC univoco in base ai seguenti campi:

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

Inoltre, le app senza privilegi non possono accedere all'indirizzo MAC del dispositivo. 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() sui 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 ha bisogno di informazioni aggiornate sui percorsi correnti può ottenerle ascoltando le modifiche alla rete utilizzando ConnectivityManager.registerNetworkCallback() e chiamando il LinkProperties.getRoutes() associato alla rete.

Caratteristiche degli identificatori

Il sistema operativo Android offre una serie di ID con caratteristiche comportamentali diverse. L'ID da utilizzare dipende dal funzionamento delle seguenti caratteristiche il tuo caso d'uso. Tuttavia, queste caratteristiche comportano anche implicazioni per la privacy, pertanto è importante capire in che modo interagiscono tra loro.

Ambito

L'ambito dell'identificatore spiega 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 assegnato a un identificatore, maggiore è il rischio che venga utilizzati 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

La reimpostazione e la 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 reimpostabilità offre agli utenti la possibilità di creare un nuovo ID disassociato da qualsiasi informazione esistente del profilo. 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 probabilità di collisione è molto più elevata per gli identificatori casuali inizializzati con la data di calendario dell'installazione (ad esempio 2019-03-01) rispetto agli identificatori inizializzati con il timestamp Unix 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 ripudio

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 riproducibilità potrebbe essere qualcosa che un utente desidera, ad esempio ad esempio quando si autentica un pagamento, o potrebbe trattarsi di una proprietà indesiderata, come quando inviano un messaggio di cui si penti.

Casi d'uso comuni e identificatore appropriato da utilizzare

Questa sezione fornisce alternative all'utilizzo degli ID hardware, come l'IMEI. L'utilizzo degli ID hardware è sconsigliato perché l'utente non può reimpostarli e sono limitati al dispositivo. In molti casi, è sufficiente un identificatore basato sull'app.

Account

Stato dell'operatore

In questo caso, l'app interagisce con la funzionalità di chiamate e messaggi del dispositivo utilizzando un account dell'operatore.

Identificatore consigliato da utilizzare: IMEI, IMSI e Line1

Perché questo consiglio?

L'utilizzo di identificatori hardware è accettabile se è necessario per la funzionalità correlata 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 questi identificatori possono essere usati soltanto 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 determinati abbonamenti ai servizi di telefonia mobile sul dispositivo. Ad esempio, potresti avere la necessità di Verificare l'accesso ad alcune funzionalità premium dell'app in base al dispositivo mobile abbonamenti tramite SIM.

Identificatore consigliato da utilizzare: API Subscription ID 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, la tua app può associare le sue 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, Android ha ulteriormente ограничен доступ к ICCID через API getIccId(), независимо от уровня API целевой для приложения. Le app interessate devono eseguire la migrazione per utilizzare 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 annunci e caricamenti oppure vengono pubblicati su Google Play, questo ID deve essere l'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, ai sensi delle Norme relative ai contenuti per gli sviluppatori di Google Play, poiché l'utente può reimpostarlo.

Indipendentemente dal fatto che tu condivida i dati utente nella tua app, se li raccogli e li utilizzi per finalità pubblicitarie, devi dichiarare le finalità pubblicitarie nella sezione Sicurezza dei dati della pagina Contenuti app in Play Console.

Misurazione

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

Identificatore consigliato da utilizzare: ID pubblicità o API referrer delle installazioni di 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 delle installazioni di 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. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, ai sensi delle Norme relative ai contenuti per gli sviluppatori di Google Play, poiché l'utente può reimpostarlo.

Remarketing

In questo caso, la tua app mostra gli annunci in base agli interessi precedenti di un utente.

Identificatore consigliato da utilizzare: 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.

Analisi dati delle app

In questo caso, la tua app valuta il comportamento dell'utente per aiutarti a determinare il seguenti:

  • Quali altri prodotti o app dell'organizzazione potrebbero essere adatti al utente.
  • Come mantenere gli utenti interessati a utilizzare la tua app.
  • Misura le statistiche e le 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 dispositivi con tecnologia Google Play ti consigliamo di usare l'ID set di app.
  • ID Firebase (FID): un FID ha come ambito l'app che lo crea, che impedisce che l'identificatore venga utilizzato 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, l'app raccoglie dati su quando e perché si arresta in modo anomalo sui dispositivi di un utente.

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 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?

Il FID è progettato esplicitamente per questo scopo. il suo ambito è limitato app in modo che non possa essere utilizzata per monitorare gli utenti in diverse app. alla reinstallazione dell'app. Nei rari casi in cui un FID non sia sufficiente, puoi utilizzare anche un GUID.

Sicurezza

Rilevamento di abusi

In questo caso, state cercando di rilevare più dispositivi falsi che attaccano i vostri e i 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, la tua app controlla che le impressioni e le azioni di un utente nella tua app siano autentiche 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, in grado di essere utilizzato per limitare l'accesso ai contenuti, include un identificatore per ogni APK, 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. Puoi trasferire questo stato a un'altra app firmato con la stessa chiave sullo stesso dispositivo.

Identificatore consigliato da utilizzare: FID o GUID

Perché questo consiglio?

Non è consigliabile conservare informazioni persistenti tramite le reinstallazioni perché gli utenti potrebbero vogliono reimpostare le loro preferenze reinstallando l'app.