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, consulta Panoramica delle autorizzazioni. Per best practice specifiche per l'utilizzo delle autorizzazioni Android, consulta Best practice per le autorizzazioni app.
Best practice per l'utilizzo degli identificatori Android
Per proteggere la privacy degli utenti, utilizza l'identificatore più restrittivo che soddisfa il caso d'uso della tua app. In particolare, segui queste best practice:
- Scegli identificatori reimpostabili dall'utente, se possibile. La tua app può soddisfare la maggior parte dei suoi casi d'uso anche quando utilizza identificatori diversi dagli ID hardware non reimpostabili.
Evita di utilizzare identificatori hardware. Nella maggior parte dei casi d'uso, puoi evitare di utilizzare identificatori hardware, come l'IMEI (International Mobile Equipment Identity), senza limitare le funzionalità richieste.
Android 10 (livello API 29) aggiunge limitazioni per gli identificatori non reimpostabili, che includono sia l'IMEI sia il numero di serie. Per accedere a questi identificatori, la tua app deve essere un'app proprietaria del dispositivo o del profilo, disporre di autorizzazioni speciali dell'operatore o dell'autorizzazione con privilegi
READ_PRIVILEGED_PHONE_STATE.Utilizza un ID pubblicità solo per la profilazione degli utenti o per i casi d'uso degli annunci. Quando utilizzi un ID pubblicità, rispetta sempre le scelte degli utenti relative 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 collegare i reset dell'ID pubblicità.
Utilizza un ID installazione di Firebase (FID) o un GUID archiviato privatamente, se 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.
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 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.
Utilizza 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:
Rispetta sempre l'intenzione dell'utente di reimpostare l'ID pubblicità. Non aggirare le reimpostazioni degli utenti utilizzando un altro identificatore o fingerprint per collegare tra loro 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."
Rispetta sempre il flag associato agli annunci personalizzati. Gli ID pubblicità sono configurabili, nel senso che 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 stabiliscono 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 utente 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."
Assicurati di conoscere 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() dall'SDK Analytics, assicurati di esaminare e rispettare tutte le norme relative all'SDK Analytics applicabili.
Inoltre, tieni presente che le Norme relative ai contenuti per gli sviluppatori di Google Play richiedono che l'ID pubblicità "non venga collegato a informazioni che consentono l'identificazione personale o associato a un identificatore persistente del dispositivo (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:
| 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 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 collegamenti tra l'ID inserzionista e le PII non sono sempre così espliciti. È possibile avere "quasi-identificatori" che compaiono sia nelle tabelle con chiave PII sia in quelle con chiave ID annuncio, il che causa anche problemi. Ad esempio, supponiamo di modificare 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, con eventi di clic sufficientemente rari, è comunque possibile unire l'ID inserzionista della TABELLA-01 e le PII contenute nella TABELLA-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 join più evidenti generalizzando i dati univoci, ove possibile. Nell'esempio precedente, ciò significherebbe ridurre l'accuratezza del timestamp in modo che vengano visualizzati più dispositivi con lo stesso modello 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_idin TABLE-01.Separare e monitorare gli 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 a entrambe le origini contemporaneamente (ad esempio, eseguendo un join tra le tabelle), riduci il rischio di associazione tra l'ID pubblicità e le PII. In generale, il controllo dell'accesso prevede quanto segue:
- Mantieni gli elenchi di controllo dell'accesso (ACL) per i dati con chiave ID inserzionista e le PII separati per ridurre al minimo il numero di persone o ruoli presenti in entrambi gli ACL.
- Implementa il logging e l'auditing degli accessi per rilevare e gestire eventuali eccezioni a questa regola.
Per saperne di più su come utilizzare in modo responsabile gli ID pubblicità, consulta il riferimento API AdvertisingIdClient.
Utilizza FID e GUID
La soluzione più semplice per identificare un'istanza dell'app in esecuzione su un dispositivo è utilizzare un ID installazione Firebase (FID), che è 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) facile da reimpostare perché persiste solo finché l'app è installata.
Di conseguenza, gli ID famiglia offrono proprietà di privacy migliori rispetto agli ID hardware non reimpostabili con ambito dispositivo. Per saperne di più, consulta il riferimento API firebase.installations.
Nei casi in cui un FID non sia pratico, puoi anche utilizzare ID univoci globali (GUID) personalizzati per identificare in modo univoco un'istanza dell'app. Il modo più semplice per farlo è 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 un'istanza di app specifica. Per evitare problemi relativi al collegamento dell'identificatore tra le app, archivia i GUID nello spazio di archiviazione interno anziché in quello esterno (condiviso). Per saperne di più, consulta la pagina Panoramica dell'archiviazione di dati e file.
Non funzionano con gli indirizzi MAC
Gli indirizzi MAC sono globalmente univoci, non reimpostabili dall'utente e persistono anche dopo il ripristino dei dati di fabbrica. Per questi motivi, per proteggere la privacy degli utenti, su Android 6 e versioni successive 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 destinate ad Android 11 e versioni successive, la randomizzazione 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 alle credenziali 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 Netlink RTM_GETLINK.
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 socketNETLINK_ROUTE. - Il comando
ipnon restituisce informazioni sulle interfacce. - Le app non possono inviare messaggi
RTM_GETLINK.
Tieni presente che la maggior parte degli sviluppatori deve 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 sulle route attuali può ottenerle ascoltando le modifiche alla rete utilizzando ConnectivityManager.registerNetworkCallback() e chiamando l'oggetto 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 da come le seguenti caratteristiche funzionano con il tuo caso d'uso. Tuttavia, queste caratteristiche hanno anche implicazioni per la privacy, quindi è importante capire come interagiscono tra loro.
Ambito
L'ambito dell'identificatore spiega quali sistemi possono accedere all'identificatore. In genere, l'ambito degli identificatori Android è di tre tipi:
- 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 un'unica istanza dell'app, non può essere utilizzato per monitorare un dispositivo tra transazioni in app diverse.
Possibilità di reimpostazione e persistenza
La reimpostabilità e la persistenza definiscono la durata dell'identificatore e spiegano come può essere reimpostato. I trigger di reimpostazione comuni includono: reimpostazioni in-app, reimpostazioni tramite le impostazioni di sistema, reimpostazioni all'avvio e reimpostazioni all'installazione. Gli identificatori Android possono avere durate diverse, ma in genere la durata è correlata alla modalità di reimpostazione dell'ID:
- Solo per la sessione: viene utilizzato un nuovo ID ogni volta che l'utente riavvia l'app.
- Reimpostazione dell'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.
- Persistente al ripristino dei dati di fabbrica: l'ID viene mantenuto dopo il ripristino dei dati di fabbrica.
La possibilità di reimpostazione consente agli utenti di creare un nuovo ID scollegato da qualsiasi informazione del profilo esistente. Più a lungo e in modo più affidabile persiste un identificatore, ad esempio uno che persiste anche dopo il ripristino dei dati di fabbrica, maggiore è il rischio che l'utente possa essere soggetto 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 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ù elevata per gli identificatori casuali con seed basato sulla data di installazione del calendario (ad esempio 2019-03-01) rispetto agli identificatori con seed basato sul timestamp Unix dell'installazione (ad esempio 1551414181).
In generale, gli identificatori degli account utente possono essere considerati univoci. In altre parole, ogni combinazione dispositivo/account ha un ID univoco. D'altra parte, meno un identificatore è univoco all'interno di una popolazione, maggiore è la protezione della privacy, perché è meno utile per monitorare un singolo utente.
Protezione dell'integrità e non ripudiabilità
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 il non ripudio. Se il dispositivo firma un messaggio con una chiave segreta, è difficile sostenere che il messaggio sia stato inviato dal dispositivo di un'altra persona. La non ripudiabilità potrebbe essere una caratteristica desiderata da un utente, ad esempio durante l'autenticazione di un pagamento, o potrebbe essere una proprietà indesiderata, 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 di 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 è sufficiente.
Account
Stato del corriere
In questo caso, l'app interagisce con le funzionalità di chiamata e invio di 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 le funzionalità relative all'operatore. Ad esempio, potresti utilizzare questi identificatori per passare da un operatore di telefonia mobile o da uno slot SIM all'altro oppure per inviare SMS tramite IP (per Line1) - account utente basati su SIM. Per le app senza privilegi, tuttavia, ti 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 corretto.
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'esigenza di verificare l'accesso a determinate funzionalità premium dell'app in base agli abbonamenti 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 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 esserci 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?
Alcune app potrebbero attualmente utilizzare l'ID ICC a questo scopo. Poiché l'ID ICC è univoco a livello globale e non reimpostabile, 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 limitato ulteriormente 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 (SSO)
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 l'account manager, ad esempio il collegamento dell'Account Google
Perché questo consiglio?
Il collegamento dell'Account Google consente agli utenti di associare il proprio Account Google esistente alla tua app, fornendo un accesso più sicuro e senza interruzioni 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?
Si tratta di 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 alle Norme relative ai contenuti di Google Play per gli sviluppatori, 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:ID pubblicità o API Play Install Referrer
Perché questo consiglio?
Si tratta di un caso d'uso relativo 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, monitori le conversioni per rilevare se la tua strategia di marketing è efficace.
Identificatore consigliato da utilizzare:ID pubblicità o API 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, 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 alle Norme relative ai contenuti di Google Play per gli sviluppatori, 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, 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 alle Norme relative ai contenuti di Google Play per gli sviluppatori, perché l'utente può reimpostarlo.
Analisi dell'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 la tua app.
- Misurare le statistiche sull'utilizzo e l'analisi per gli utenti disconnessi o anonimi.
Le possibili soluzioni includono:
- 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 per scopi pubblicitari. Se scegli come target dispositivi con Google Play Services, ti consigliamo di utilizzare l'ID set di app.
- ID Firebase (FID): un FID ha come ambito l'app che lo crea, il che impedisce l'utilizzo dell'identificatore per monitorare gli utenti nelle app. Inoltre, è facilmente reimpostabile, in quanto l'utente può cancellare i dati dell'app o reinstallarla. Il processo 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 relativi a quando e perché si arresta in modo anomalo 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 l'utilizzo dell'identificatore per monitorare gli utenti nelle varie app. Inoltre, è facilmente reimpostabile, in quanto l'utente può cancellare i dati dell'app o reinstallarla. Il processo 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 per scopi pubblicitari.
Creazione di 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?
Un FID ha come ambito l'app che lo crea, il che impedisce l'utilizzo dell'identificatore per monitorare gli utenti nelle varie app. Inoltre, è facilmente reimpostabile, in quanto l'utente può cancellare i dati dell'app o reinstallarla. Il processo 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 per scopi pubblicitari.
Installazione cross-device
In questo caso, l'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, quindi non può essere utilizzato per monitorare gli utenti in diverse app e viene reimpostato alla reinstallazione dell'app. Nei rari casi in cui un FID non è 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 Play Integrity di Google Play
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 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 di Google Play per gli sviluppatori, perché l'utente può reimpostarlo.
Digital Rights Management (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 di un GUID costringe l'utente a reinstallare l'app per aggirare i limiti dei contenuti, il che è 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, l'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 proprie preferenze reinstallando l'app.