Best practice per gli identificatori univoci

Questo documento fornisce indicazioni per la selezione degli 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, vedi 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 che soddisfi il caso d'uso della tua app. In particolare, segui queste best practice:

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

2. Evita di utilizzare identificatori hardware. Nella maggior parte dei casi d'uso, puoi evitare di utilizzare identificatori hardware, come l'International Mobile Equipment Identity (IMEI), senza limitare le funzionalità richieste.

   Android 10 (livello API 29) aggiunge limitazioni per gli identificatori non ripristinabili, che includono sia l'IMEI che il numero di serie. La tua app deve essere un'app proprietaria del dispositivo o del profilo, disporre di autorizzazioni speciali dell'operatore o dell'autorizzazione privilegiata READ_PRIVILEGED_PHONE_STATE per accedere a questi identificatori.

3. Utilizza un ID pubblicità solo per la profilazione degli utenti o i casi d'uso degli 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 dell'ID pubblicità.

5. Utilizza un ID installazione Firebase (FID) o un GUID archiviato privatamente ogni volta possibile per tutti gli altri casi d'uso, ad eccezione della prevenzione delle frodi nei pagamenti e della telefonia. Per la stragrande maggioranza dei casi d'uso non correlati agli annunci, un FID o un GUID dovrebbe essere sufficiente.

6. Utilizza API adatte al 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 dagli abusi. Le API Play Integrity sono il modo più semplice per determinare se un dispositivo è originale senza incorrere in rischi per la privacy.

Le sezioni rimanenti di questa guida approfondiscono 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, devi tenere presente alcuni punti chiave:

Rispettare 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 collegare gli ID pubblicità successivi senza il consenso dell'utente. Le Norme relative ai contenuti per gli sviluppatori di Google Play stabiliscono 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".

Rispettare sempre il flag 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 i desideri dei tuoi utenti. Le Norme relative ai contenuti per gli sviluppatori di Google Play affermano 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 conto di eventuali norme sulla privacy o sulla sicurezza associate agli SDK che utilizzi e che riguardano l'uso dell'ID pubblicità. Ad esempio, se passi true al metodo enableAdvertisingIdCollection() dell'SDK Google Analytics, assicurati di esaminare 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 deve essere collegato a informazioni che consentono l'identificazione personale o associato ad alcun identificatore del dispositivo persistente (ad esempio: SSAID, indirizzo MAC, IMEI e così via)".

Ad esempio, supponiamo di voler raccogliere informazioni per compilare tabelle di database con le seguenti colonne:

In questo esempio, la colonna ad_id potrebbe essere unita alle informazioni di identificazione personale 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 dagli utenti.

Tieni presente che i collegamenti tra l'ID inserzionista e i dati personali non sono sempre così espliciti. È possibile avere "quasi-identificatori" che compaiono sia nelle tabelle con chiave PII sia in quelle con ID pubblicità, il che causa anche problemi. Ad esempio, supponiamo di modificare TABLE-01 e TABLE-02 nel seguente modo:

In questo caso, con eventi di clic sufficientemente rari, è comunque possibile eseguire il join tra l'ID inserzionista TABLE-01 e i dati PII contenuti in TABLE-02 utilizzando il timestamp dell'evento e il modello del dispositivo.

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

Altre soluzioni includono:

• Non progettare tabelle che collegano esplicitamente le PII agli ID pubblicità. Nel primo esempio riportato sopra, ciò significa non includere la colonna account_id in TABLE-01.

• Separazione e monitoraggio degli elenchi di controllo dell'accesso per utenti o ruoli che hanno accesso sia ai dati basati sull'ID pubblicità sia alle PII. Controllando e verificando attentamente la possibilità di accedere contemporaneamente a entrambe le origini (ad esempio eseguendo un'unione tra tabelle), riduci il rischio di associazione tra l'ID pubblicità e i dati personali. In generale, controllare l'accesso significa:

  1. Mantieni disgiunti gli elenchi di controllo dell'accesso (ACL) per i dati basati sull'ID inserzionista e le PII per ridurre al minimo il numero di persone o ruoli presenti in entrambi gli ACL.
  2. Implementa la registrazione e l'audit degli accessi per rilevare e gestire eventuali eccezioni a questa regola.

Per ulteriori informazioni sull'utilizzo responsabile degli ID pubblicità, consulta il riferimento API AdvertisingIdClient.

Utilizzare gli ID funzionalità e i GUID

La soluzione più semplice per identificare un'istanza dell'app in esecuzione su un dispositivo è utilizzare un ID installazione Firebase (FID). Questa è la soluzione consigliata nella maggior parte dei casi d'uso non correlati agli annunci. Solo l'istanza dell'app per cui è stato eseguito il provisioning può accedere a questo identificatore, che è (relativamente) facilmente reimpostabile perché persiste solo finché l'app è installata.

Di conseguenza, gli ID pubblicità forniscono migliori proprietà di privacy rispetto agli ID hardware non reimpostabili e con ambito dispositivo. Per ulteriori informazioni, consulta il riferimento API firebase.installations.

Nei casi in cui un FID non è pratico, puoi anche utilizzare ID univoci a livello globale (GUID) personalizzati per identificare in modo univoco un'istanza dell'app. Il modo più semplice per farlo è generare un GUID personalizzato 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 un'istanza specifica dell'app. Per evitare problemi relativi al collegamento dell'identificatore tra le app, memorizza i GUID nella memoria interna anziché in quella esterna (condivisa). Per ulteriori informazioni, consulta la pagina Panoramica dell'archiviazione di dati e file.

Non funziona con gli indirizzi MAC

Gli indirizzi MAC sono globalmente univoci, non reimpostabili dall'utente e rimangono invariati dopo il ripristino dei dati di fabbrica. Per questi motivi, per proteggere la privacy degli utenti, nelle versioni di Android 6 e successive, 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 per profilo Passpoint, generando un indirizzo MAC univoco in base ai seguenti campi:

• Nome di dominio completo (FQDN)
• Realm
• Credenziali, in base a quelle utilizzate nel profilo Passpoint:
  • Credenziale utente: nome utente
  • Credenziale del certificato: certificato 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 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() sui socket NETLINK_ROUTE.
• Il comando ip non restituisce informazioni sulle interfacce.
• Le app non possono inviare messaggi di RTM_GETLINK.

Tieni presente che la maggior parte degli sviluppatori dovrebbe utilizzare le API di livello superiore di ConnectivityManager anziché API di livello inferiore come NetworkInterface, getifaddrs() o socket Netlink. Ad esempio, un'app che ha bisogno di informazioni aggiornate sugli itinerari attuali può ottenerle ascoltando le modifiche alla rete utilizzando ConnectivityManager.registerNetworkCallback() e chiamando l'LinkProperties.getRoutes() associato alla rete.

Caratteristiche dell'identificatore

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. Queste caratteristiche hanno anche implicazioni per la privacy, pertanto è importante capire come interagiscono tra loro.

Ambito

L'ambito dell'identificatore spiega a quali sistemi può accedere. L'ambito dell'identificatore Android è generalmente di tre tipi:

• Singola app: 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 a fini di monitoraggio. Al contrario, se un identificatore è accessibile solo da una singola istanza dell'app, non può essere utilizzato per monitorare un dispositivo in diverse transazioni in app diverse.

Reimpostabilità e persistenza

La resettabilità e la persistenza definiscono la durata dell'identificatore e spiegano come può essere reimpostato. I trigger di ripristino comuni includono: ripristini in-app, ripristini tramite Impostazioni di sistema, ripristini all'avvio e ripristini all'installazione. Gli identificatori Android possono avere durate diverse, ma la durata è in genere correlata al modo in cui viene reimpostato l'ID:

• Solo sessione: viene utilizzato un nuovo ID ogni volta che l'utente riavvia l'app.
• Reimpostazione installazione: 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 sopravvive al ripristino dei dati di fabbrica.

La reimpostazione consente agli utenti di creare un nuovo ID dissociato da qualsiasi informazione del profilo esistente. Più a lungo e in modo più affidabile persiste un identificatore, ad esempio uno che persiste dopo i ripristini dei dati di fabbrica, maggiore è il rischio che l'utente possa essere sottoposto a un 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 utente esplicito per reimpostarlo dall'app o dalle impostazioni di sistema.

Unicità

L'unicità stabilisce la probabilità di collisioni, ovvero che esistano identificatori identici nell'ambito associato. Al livello più alto, un identificatore univoco a livello globale non ha mai una collisione, 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 una collisione è molto più alta per gli identificatori casuali inizializzati con la data di installazione (ad esempio 2019-03-01) rispetto a quelli inizializzati con il timestamp Unix dell'installazione (ad esempio 1551414181).

In generale, gli identificatori degli account utente possono essere considerati unici. ovvero ogni combinazione dispositivo/account ha un ID univoco. D'altra parte, meno unico è un identificatore 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 forniscono anche non ripudio. Se il dispositivo firma un messaggio con una chiave segreta, è difficile sostenere che il messaggio sia stato inviato dal dispositivo di qualcun altro. La non ripudiabilità potrebbe essere qualcosa che un utente desidera, ad esempio quando autentica un pagamento, oppure potrebbe essere una proprietà indesiderabile, ad esempio quando invia un messaggio di cui si pente.

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, un identificatore con ambito app sarebbe sufficiente.

Conti

Stato dell'operatore

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

Identificatore consigliato da utilizzare: IMEI, IMSI e Line1

Perché questo consiglio?

L'utilizzo degli identificatori hardware è accettabile se necessario per funzionalità correlate all'operatore. Ad esempio, potresti utilizzare questi identificatori per passare da un operatore di telefonia mobile all'altro o da uno slot SIM all'altro oppure per inviare messaggi SMS tramite IP (per Line1) - account utente basati su SIM. Per le app senza privilegi, tuttavia, consigliamo di utilizzare l'accesso all'account per recuperare le informazioni sul dispositivo dell'utente 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, quindi la tua app deve gestire queste eccezioni in modo appropriato.

Stato dell'abbonamento mobile

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

Identificatore consigliato da utilizzare: ID abbonamento API 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 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, potrebbero verificarsi casi in cui la stessa SIM ha un ID abbonamento diverso su dispositivi diversi o SIM diverse hanno lo stesso ID su dispositivi diversi.

Perché questo consiglio?

Attualmente, alcune app potrebbero utilizzare l'ID ICC a questo scopo. Poiché l'ICC ID è univoco a livello globale e non ripristinabile, l'accesso è stato limitato alle app con l'autorizzazione READ_PRIVILEGED_PHONE_STATE a partire da Android 10. A partire da Android 11, Android ha ulteriormente limitato l'accesso all'ICCID tramite l'API getIccId(), indipendentemente dal livello API target dell'app. 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 Single Sign-On, consentendo agli utenti di associare un account esistente alla tua organizzazione.

Identificatore consigliato da utilizzare: account compatibili con Account Manager, ad esempio collegamento dell'Account Google

Perché questo consiglio?

Il collegamento dell'Account Google consente agli utenti di associare un Account Google esistente alla tua app, fornendo un accesso più sicuro e senza interruzioni ai prodotti e 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, l'ID deve essere l'ID pubblicità.

Perché questo consiglio?

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

Indipendentemente dal fatto che tu condivida o meno i dati utente nella tua app, se li raccogli e li utilizzi per scopi pubblicitari, devi dichiarare questi scopi 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: API ID pubblicità o Play Install Referrer

Perché questo consiglio?

Si tratta di un caso d'uso correlato agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, quindi l'utilizzo di un ID pubblicità è la soluzione più appropriata. Se utilizzi un ID per casi d'uso pubblicitari, 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 ha successo.

Identificatore consigliato da utilizzare: API ID pubblicità o Play Install Referrer

Perché questo consiglio?

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

Remarketing

In questo caso, la tua app mostra 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 correlato agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, quindi l'utilizzo di un ID pubblicità è la soluzione più appropriata. L'utilizzo dell'ID pubblicità è obbligatorio per i casi d'uso pubblicitari, in base alle 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 della tua organizzazione potrebbero essere adatti all'utente.
• Come mantenere vivo l'interesse degli utenti per l'utilizzo della tua app.
• Misura le statistiche di utilizzo e Analytics per gli utenti che hanno eseguito la disconnessione o anonimi.

Ecco alcune possibili soluzioni:

• ID set di app:un ID set di app ti consente di analizzare il comportamento di un utente in più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente a scopi pubblicitari. Se scegli come target dispositivi che utilizzano 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 che l'identificatore venga utilizzato per monitorare gli utenti nelle app. È anche facilmente ripristinabile, in quanto 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, la tua app raccoglie dati relativi a 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 è limitato all'app che lo crea, il che impedisce che l'identificatore venga utilizzato per monitorare gli utenti nelle app. Inoltre, è facilmente ripristinabile, in quanto 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. Un ID set di app ti consente di analizzare il comportamento di un utente in più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente a fini pubblicitari.

Report sul rendimento

In questo caso, la tua 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 recente modifica nella tua app.

Test delle app

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

Identificatore consigliato da utilizzare:FID o ID set di app

Perché questo consiglio?

Un FID è limitato all'app che lo crea, il che impedisce che l'identificatore venga utilizzato per monitorare gli utenti nelle app. Inoltre, è facilmente ripristinabile, in quanto 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. Un ID set di app ti consente di analizzare il comportamento di un utente in più app di proprietà della tua organizzazione, a condizione che tu non utilizzi i dati utente a fini pubblicitari.

Installazione cross-device

In questo caso, la tua app deve identificare l'istanza corretta dell'app 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 in diverse app e viene reimpostato in caso di reinstallazione dell'app. Nei rari casi in cui un FID non è sufficiente, puoi utilizzare anche un GUID.

Sicurezza

Rilevamento di abusi

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 verifica 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 alle Norme relative ai contenuti per gli sviluppatori di Google Play, perché l'utente può reimpostarlo.

DRM (Digital Rights Management)

In questo caso, la tua app vuole proteggere l'accesso fraudolento a proprietà intellettuale o 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 dei contenuti, il che è un onere 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 dell'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?

Il mantenimento delle informazioni durante le reinstallazioni non è consigliato perché gli utenti potrebbero voler reimpostare le proprie preferenze reinstallando l'app.