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 generale delle autorizzazioni Android, vedi Panoramica delle autorizzazioni. Per best practice specifiche per l'utilizzo delle autorizzazioni Android, consulta le best practice per le autorizzazioni app.

Best practice per lavorare con gli 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:

1. Scegli identificatori reimpostabili dall'utente, se possibile. L'app può ottenere la maggior parte dei casi d'uso anche quando utilizza identificatori diversi dagli ID hardware non reimpostabili.

2. Evita di utilizzare identificatori hardware. Nella maggior parte dei casi, puoi evitare di utilizzare 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.

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 eseguire il bridge delle reimpostazioni dell'ID pubblicità.

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

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 correre 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 i casi d'uso degli annunci. Tuttavia, quando utilizzi questo ID, tieni presente alcuni punti chiave:

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. Le Norme relative ai contenuti per gli sviluppatori di Google Play prevedono quanto segue:

"…in caso di reimpostazione, il nuovo identificatore pubblicità non deve essere collegato a un identificatore pubblicità precedente o a dati derivanti da un identificatore pubblicità precedente 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. Le Norme relative ai contenuti per gli sviluppatori di Google Play prevedono quanto segue:

"…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 degli utenti per scopi pubblicitari o per eseguire il targeting degli utenti con pubblicità personalizzata. Sono ammessi, ad esempio, pubblicità contestuale, quota limite, monitoraggio delle conversioni, creazione di report e rilevamento di problemi di sicurezza e di 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 le tabelle del database con le seguenti colonne:

In questo esempio, la colonna ad_id potrebbe essere unita alle PII tramite la colonna account_id in entrambe le tabelle, il che costituirebbe una violazione delle Norme relative ai contenuti per gli sviluppatori di Google Play, se non hai ottenuto l'autorizzazione esplicita degli 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 modificare TABLE-01 e TABLE-02 come segue:

In questo caso, con eventi di clic sufficientemente rari, è comunque possibile eseguire l'unione tra la TABELLA-01 dell'ID inserzionista e le PII contenute nella TABELLA-02 utilizzando il timestamp dell'evento e il modello di 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 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 tabelle), riduci il rischio di associazione tra l'ID pubblicità e le PII. In generale, controllare l'accesso significa:

  1. Mantieni disgiunti gli elenchi di controllo dell'accesso (ACL) per i dati con chiave ID inserzionista e le PII per ridurre al minimo il numero di persone o ruoli presenti in entrambi gli 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.

Lavorare con FID e GUID

La soluzione più semplice per identificare un'istanza di app in esecuzione su un dispositivo è utilizzare un ID installazione Firebase (FID). Si tratta della soluzione consigliata nella maggior parte dei casi d'uso non pubblicitari. Solo l'istanza dell'app per la quale è stato eseguito il provisioning può accedere a questo identificatore ed è (relativamente) facile da reimpostare perché persiste solo finché l'app è installata.

Di conseguenza, gli FID offrono 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 dell'app. Il modo più semplice per farlo è generare il tuo GUID utilizzando il seguente codice:

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, memorizza i GUID nello spazio di archiviazione interno anziché in quello esterno (condiviso). 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à 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)
• Realm
• Autenticazione, in base alle credenziali utilizzate nel profilo Passpoint:
  • Credenziale utente: nome utente
  • Credenziale del certificato: cert e tipo di certificato
  • Scheda 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 sui metodi getifaddrs() e NetworkInterface.getHardwareAddress() nonché sull'invio di messaggi RTM_GETLINK Netlink.

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

• NetworkInterface.getHardwareAddress() restituisce null 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 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 di comportamento diverse. L'ID da utilizzare dipende dal modo in cui le seguenti caratteristiche funzionano con 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 indica quali sistemi possono accedere all'identificatore. L'ambito identificativo Android è generalmente 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.

Ripristino e persistenza

La reimpostazione e la persistenza definiscono la durata dell'identificatore e spiegano come può essere reimpostato. Gli attivatori di reimpostazione più comuni sono: reimpostazione in-app, reimpostazione tramite Impostazioni di sistema, reimpostazione all'avvio e reimpostazione all'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-ripristino: 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 l'identificatore viene reimpostato al momento della reinstallazione dell'app, la persistenza viene ridotta e viene fornito un mezzo per reimpostare l'ID, anche se non esiste un controllo esplicito da parte dell'utente per reimpostarlo dall'app o dalle Impostazioni di sistema.

Unicità

L'unicità stabilisce la probabilità di collisioni, ovvero che esistono identificatori identici nell'ambito associato. A livello più alto, un identificatore unico 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. In altre parole, ogni combinazione di 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 falsificare o riprodurre per dimostrare che il dispositivo o l'account associato ha determinate proprietà. Ad esempio, potresti dimostrare che il dispositivo non è un dispositivo virtuale utilizzato da uno spammer. Gli identificatori difficili da falsificare offrono anche non ripudio. 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. 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 versioni successive, questi identificatori possono essere utilizzati solo tramite un'autorizzazione di runtime. Gli utenti potrebbero disattivare questa autorizzazione, pertanto la tua app deve gestire queste eccezioni in modo corretto.

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 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: API Subscription ID per identificare le SIM utilizzate sul dispositivo.

L'ID abbonamento fornisce un valore di indice (a partire da 1) per identificare in modo univoco le SIM installate (incluse quelle fisiche ed elettroniche) utilizzate sul 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, in alcuni casi la stessa SIM potrebbe avere un ID abbonamento diverso su dispositivi diversi o SIM diverse avere 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 целевой для приложения. Per le app interessate è necessario 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 il collegamento dell'Account Google

Perché questo consiglio?

Il collegamento dell'Account Google consente agli utenti di associare il loro Account Google esistente alla tua app, offrendo un accesso semplice e più sicuro ai prodotti e ai 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?

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 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 i 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, monitori le conversioni per rilevare se la tua strategia di marketing è efficace.

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

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.

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 della tua organizzazione potrebbero essere adatti all'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.

Ecco alcune possibili soluzioni:

• 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, può essere facilmente reimpostato, poiché l'utente può cancellare i dati dell'app o reinstallarla. La procedura di creazione di un FID è semplice; consulta la guida alle installazioni di Firebase.

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?

L'ambito di un FID è limitato all'app che lo crea, il che impedisce l'utilizzo dell'identificatore 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 per te e a testare l'impatto di una modifica recente nella tua 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?

L'ambito di un FID è limitato all'app che lo crea, il che impedisce l'utilizzo dell'identificatore 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.

Installazione cross-device

In questo caso, l'app deve identificare l'istanza corretta quando è 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 non sia sufficiente, puoi utilizzare anche 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, 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, ai sensi delle Norme relative ai contenuti per gli sviluppatori di Google Play, poiché 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 utilizzare: l'utilizzo di un FID o GUID costringe l'utente a reinstallare l'app per aggirare i limiti di contenuti, un onere sufficiente per 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.