Questa pagina è stata tradotta dall'API Cloud Translation.

Best practice per gli identificatori univoci

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

Per una panoramica generale delle autorizzazioni Android, consulta la Panoramica delle autorizzazioni. Per best practice specifiche per l'utilizzo delle autorizzazioni Android, consulta Best practice relative alle autorizzazioni app.

Best practice per l'uso degli identificatori Android

Per proteggere la privacy dei tuoi 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, ove possibile. La tua app può raggiungere la maggior parte dei casi d'uso anche quando utilizza identificatori diversi dagli ID hardware non reimpostabili.
Evita di utilizzare identificatori di hardware. Nella maggior parte dei casi d'uso, è possibile evitare di utilizzare identificatori hardware, come IMEI (International Mobile Equipment Identity), senza limitare la funzionalità richiesta.

Android 10 (livello API 29) aggiunge limitazioni per gli identificatori non reimpostabili, che includono sia il codice IMEI sia il numero di serie. Per poter accedere a questi identificatori, la tua app deve essere un'app del proprietario del dispositivo o del profilo, deve disporre di autorizzazioni speciali dell'operatore o dell'autorizzazione con privilegi READ_PRIVILEGED_PHONE_STATE.
Utilizza un ID pubblicità solo per i casi d'uso degli annunci o della profilazione degli utenti. Quando utilizzi un ID pubblicità, rispetta sempre le selezioni 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 le reimpostazioni degli ID pubblicità.
Utilizza un ID di installazione Firebase (FID) o un GUID archiviato privatamente, ove possibile per tutti gli altri casi d'uso, ad eccezione della telefonia e della prevenzione di attività fraudolente nei pagamenti. Per la maggior parte dei casi d'uso non pubblicitari, dovrebbe essere sufficiente un FID o un GUID.
Utilizza API appropriate per il tuo caso d'uso per ridurre al minimo i rischi 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 correre rischi per la privacy.

Le altre sezioni di questa guida trattano 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. Quando utilizzi questo ID, devi però tenere a mente alcuni punti chiave:

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 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, un nuovo identificatore pubblicità non deve essere collegato a un identificatore pubblicità precedente o a dati derivati da un identificatore pubblicità precedente senza il consenso esplicito 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 eludere le intenzioni 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 degli utenti per scopi pubblicitari o per eseguire il targeting degli utenti con pubblicità personalizzata. Sono ammesse, ad esempio, pubblicità contestuale, quota limite, monitoraggio delle conversioni, generazione di report e rilevamento di problemi di sicurezza e di attività fraudolente."

Devi conoscere le norme sulla privacy o sulla sicurezza associate agli SDK che usi e relativi all'uso dell'ID pubblicità. Ad esempio, se trasmetti true al metodo enableAdvertisingIdCollection() dall'SDK di Google Analytics, assicurati di leggere e rispettare tutte le norme relative all'SDK di 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 a un identificatore del dispositivo persistente (ad esempio: SSAID, indirizzo MAC, IMEI e così via).".

Ad esempio, supponi di voler raccogliere informazioni per completare le tabelle di database con le seguenti colonne:

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

In questo esempio, la colonna ad_id potrebbe essere unita alle PII tramite la colonna account_id in entrambe le tabelle, il che comporterebbe una violazione delle Norme relative ai contenuti per gli sviluppatori di Google Play se non avessi ricevuto un'autorizzazione esplicita dagli utenti.

Tieni presente che i collegamenti tra l'ID inserzionista e le PII non sono sempre questo esplicito. È possibile che gli "quasi-identificatori" vengano visualizzati in entrambe le tabelle con chiave PII e ID annuncio, il che causa anche problemi. Ad esempio, supponiamo di modificare TABLE-01 e TABLE-02 come segue:

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

In questo caso, con eventi di clic sufficientemente rari, è comunque possibile eseguire l'unione tra l'ID inserzionista TABLE-01 e le PII contenute in TABLE-02 usando 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 join più evidenti generalizzando 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 PII con ID pubblicità. Nel primo esempio riportato sopra, ciò significa non includere la colonna account_id in TABLE-01.
Segregazione e monitoraggio degli elenchi di controllo dell'accesso per utenti o ruoli che hanno accesso sia ai dati chiave dell'ID pubblicità che alle PII. Controllando e verificando rigorosamente la possibilità di accedere a entrambe le origini contemporaneamente (ad esempio, eseguendo un join tra tabelle), riduci il rischio di associazione tra l'ID pubblicità e le PII. In linea di massima, controllare l'accesso significa fare quanto segue:
1. Mantieni separati gli elenchi di controllo dell'accesso (ACL) per i dati con chiave dell'ID inserzionista e le PII per ridurre al minimo il numero di utenti o ruoli che si trovano in entrambi gli ACL.
2. Implementa il logging e il controllo degli accessi per rilevare e gestire eventuali eccezioni a questa regola.

Per ulteriori informazioni su un utilizzo responsabile con gli ID pubblicità, consulta il riferimento dell'API AdvertisingIdClient.

Utilizzare FID e GUID

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

Di conseguenza, i FID offrono proprietà di privacy migliori rispetto agli ID hardware con ambito dispositivo non reimpostabili. Per saperne di più, consulta il riferimento dell'API firebase.installations.

Nei casi in cui un FID non sia pratico, puoi anche utilizzare ID univoci a livello globale (GUID) personalizzati per identificare in modo univoco un'istanza di 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 una specifica istanza di app. Per evitare problemi correlati al collegamento dell'identificatore tra app, archivia i GUID nell'unità di archiviazione interna anziché nello spazio di archiviazione esterno (condiviso). Per ulteriori informazioni, consulta la pagina Panoramica dell'archiviazione di dati e file.

Non funziona con gli indirizzi MAC

Gli indirizzi MAC sono univoci a livello globale, non sono reimpostabili dall'utente e sono soggetti al 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.

Cambiamenti relativi alla disponibilità degli indirizzi MAC in Android 11

Nelle app che hanno come target Android 11 e versioni successive, la randomizzazione MAC per le reti Passpoint avviene per profilo Passpoint, che genera un indirizzo MAC univoco in base ai seguenti campi:

Nome di dominio completo (FQDN)
Area di autenticazione
Credenziale, basata su quella utilizzata nel profilo Passpoint:
- Credenziali utente: nome utente
- Credenziale del certificato: tipo di certificato e di certificato
- Credenziali SIM: tipo EAP e IMSI

Inoltre, le app senza privilegi 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 di RTM_GETLINK.

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

NetworkInterface.getHardwareAddress() restituisce un valore 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 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 socket Netlink. Ad esempio, un'app che ha bisogno di informazioni aggiornate sulle route correnti può ottenere queste informazioni ascoltando le modifiche della rete utilizzando ConnectivityManager.registerNetworkCallback() e chiamando la rete LinkProperties.getRoutes() associata alla rete.

Caratteristiche dell'identificatore

Il sistema operativo Android offre una serie di ID con differenti caratteristiche di comportamento. L'ID da utilizzare dipende dall'interazione tra le seguenti caratteristiche e il tuo caso d'uso. Tuttavia, queste caratteristiche hanno anche implicazioni in termini di privacy, quindi è importante capire in che modo queste caratteristiche interagiscono tra loro.

Ambito

L'ambito dell'identificatore spiega quali sistemi possono accedere all'identificatore. L'ambito degli identificatori Android in genere è 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 il monitoraggio. Al contrario, se un identificatore è accessibile solo da una singola istanza di app, non può essere utilizzato per monitorare un dispositivo per più transazioni in app diverse.

Reimpostabilità e persistenza

Reimpostabilità e persistenza definiscono la durata dell'identificatore e spiegano come può essere reimpostato. I trigger di reimpostazione comuni includono: reimpostazioni in-app o tramite Impostazioni di sistema, reimpostazioni all'avvio e al momento dell'installazione. Gli identificatori Android possono avere durata variabile, ma in genere questa è correlata al modo in cui l'ID viene reimpostato:

Solo 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.
Persistent FDR: l'ID non viene ripristinato ai dati di fabbrica.

La reimpostabilità offre agli utenti la possibilità di creare un nuovo ID dissociato da tutte le informazioni del profilo esistenti. Più a lungo e in modo più affidabile un identificatore persiste, ad esempio uno che persiste anche dopo il ripristino dei dati di fabbrica, maggiore è il rischio che l'utente sia soggetto al monitoraggio a lungo termine. Se l'identificatore viene reimpostato al momento della reinstallazione dell'app, questo riduce la persistenza e fornisce 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'univocità stabilisce la probabilità di conflitti, ovvero che identificatori identici esistono all'interno dell'ambito associato. Al livello più generale, un identificatore univoco a livello globale non ha mai collisione, neanche su altri dispositivi o app. In caso contrario, il livello di univocità dipende dall'entropia dell'identificatore e dall'origine di casualità utilizzata per crearlo. Ad esempio, la possibilità di una collisione è molto più elevata per gli identificatori casuali che hanno origine con la data di calendario dell'installazione (come 2019-03-01) rispetto agli identificatori per i quali è stato inviato il timestamp Unix di installazione (come 1551414181).

In generale, gli identificatori dell'account utente possono essere considerati univoci. In altre parole, ogni combinazione di dispositivo/account ha un ID univoco. Invece, meno un identificatore è univoco all'interno di una popolazione, maggiore è la protezione della privacy, in quanto è meno utile per il monitoraggio di un singolo utente.

Protezione dell'integrità e non ripudibilità

Puoi utilizzare un identificatore difficile da replicare o riprodurre per dimostrare che il dispositivo o l'account associato dispone di determinate proprietà. Ad esempio, potresti dimostrare che il dispositivo non è un dispositivo virtuale utilizzato da uno spammer. Gli identificatori difficili da spoofing forniscono anche gli identificatori non ripudibili. Se il dispositivo firma un messaggio con una chiave segreta, è difficile dichiarare che il messaggio è stato inviato dal dispositivo di qualcun altro. Potrebbe essere qualcosa che l'utente vuole, ad esempio al momento dell'autenticazione di un pagamento, o una proprietà indesiderata, ad esempio quando invia un messaggio di cui si penti.

Casi d'uso comuni e identificatore appropriato da utilizzare

Questa sezione fornisce alternative all'utilizzo degli ID hardware, ad esempio il codice IMEI. Si sconsiglia l'utilizzo degli ID hardware perché l'utente non può reimpostarli e hanno come ambito il dispositivo. In molti casi, sarebbe sufficiente un identificatore basato sulle app.

Account

Stato corriere

In questo caso, la tua app interagisce con lo smartphone e la funzionalità di invio di messaggi del dispositivo utilizzando l'account di un operatore.

Identificatore consigliato per l'uso: IMEI, IMSI e Line1

Perché questo consiglio?

L'utilizzo degli identificatori hardware è accettabile se è richiesto per le funzionalità relative all'operatore. Ad esempio, puoi utilizzare questi identificatori per passare da un operatore di telefonia mobile all'altro o per recapitare messaggi SMS tramite IP (per la linea 1), con gli account utente basati su SIM. Tuttavia, per le app senza privilegi consigliamo di utilizzare un accesso all'account per recuperare le informazioni del dispositivo 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, quindi la tua app dovrebbe gestire queste eccezioni con grazia.

Stato abbonamento dispositivo mobile

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

Identificatore consigliato da usare: l'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, l'app può associare la sua funzionalità a vari dati dell'abbonamento di 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 oppure SIM differenti hanno lo stesso ID su dispositivi diversi.

Perché questo consiglio?

Alcune app potrebbero utilizzare l'ID ICC per 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 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. Per utilizzare l'ID abbonamento, è necessario eseguire la migrazione delle app interessate.

Single Sign-On

In questo caso, la tua app offre un'esperienza Single Sign-On, che consente agli utenti di associare un account esistente alla tua organizzazione.

Identificatore consigliato da utilizzare: account compatibili con l'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 alla tua app, fornendo un accesso continuo 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.

Google Ads

Targeting

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

Identificatore consigliato da usare: se l'app utilizza un ID per gli annunci e i caricamenti o le pubblicazioni su Google Play, questo ID deve essere l'ID pubblicità.

Perché questo consiglio?

Si tratta di un caso d'uso relativo agli annunci che potrebbe richiedere un ID disponibile nelle diverse app della tua organizzazione, per cui l'uso 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, perché l'utente può reimpostarlo.

Indipendentemente dal fatto che tu condivida dati utente nella tua app, se li raccogli e li utilizzi per scopi pubblicitari, devi dichiarare le finalità relative agli annunci 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 dell'organizzazione sullo stesso dispositivo.

Identificatore consigliato da utilizzare:ID pubblicità o API del referrer per l'installazione di Google Play

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, per cui l'uso 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 l'efficacia della strategia di marketing.

Identificatore consigliato da utilizzare:ID pubblicità o API del referrer per l'installazione di Google Play

Perché questo consiglio?

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?

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 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 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 i dati utente non vengano utilizzati 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, impedendo così l'utilizzo dell'identificatore per monitorare gli utenti tra le app. È inoltre facilmente reimpostabile, in quanto l'utente può cancellare i dati o reinstallare l'app. Il processo di creazione di un FID è semplice; consulta la guida all'installazione 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: FID o ID set di app

Perché questo consiglio?

Un FID ha come ambito l'app che lo crea, impedendo così 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. La procedura di creazione di un FID è semplice; consulta la guida all'installazione 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 non utilizzi i dati utente per scopi pubblicitari.

Report sul rendimento

In questo caso, la tua app raccoglie metriche sulle prestazioni, 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 consente di concentrarti sulle metriche più importanti per la tua attività e di 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 l'app a scopo di test o di debug.

Identificatore consigliato: FID o ID set di app

Perché questo consiglio?

Installazione cross-device

In questo caso, la tua 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 in modo da non poter essere usato per monitorare gli utenti in diverse app e viene reimpostato al momento della reinstallazione dell'app. Nei rari casi in cui un FID sia sufficiente, puoi utilizzare anche un GUID.

Sicurezza

Rilevamento di comportamenti illeciti

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

Identificatore consigliato da usare: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 dispositivo per lo spoofing del codice, 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 secondo le 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 GUID costringe l'utente a reinstallare l'app per aggirare i limiti di 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, include un identificatore per APK, ovvero l'ID Widevine.

Preferenze utente

In questo caso, la tua app salva lo stato dell'utente in base al 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?

Non è consigliabile non salvare le informazioni tramite le reinstallazioni perché gli utenti potrebbero voler reimpostare le loro preferenze reinstallando l'app.