Prácticas recomendadas para identificadores únicos

En este documento, encontrarás orientación sobre cómo seleccionar los identificadores adecuados para tu app según tu caso de uso.

Para obtener un panorama general sobre los permisos de Android, consulta la Descripción general de permisos. Si quieres obtener las prácticas recomendadas específicas para trabajar con permisos de Android, consulta Prácticas recomendadas sobre permisos de apps.

Recomendaciones para trabajar con identificadores de Android

Para proteger la privacidad de los usuarios, usa el identificador más restrictivo que cumpla con el caso de uso de tu app. En particular, sigue estas prácticas recomendadas:

  1. Elige identificadores que el usuario pueda restablecer siempre que sea posible. Tu app puede lograr la mayoría de sus casos de uso, incluso cuando usa identificadores que no sean IDs de hardware que no se pueden restablecer.
  2. Evita usar identificadores de hardware. En la mayoría de los casos de uso, puedes evitar el uso de identificadores de hardware, como la Identidad Internacional de Equipos Móviles (IMEI), sin limitar la funcionalidad requerida.

    Android 10 (nivel de API 29) agrega restricciones para identificadores que no se pueden restablecer, como el IMEI y el número de serie. Tu app debe ser una app de propietario del perfil o del dispositivo, tener permisos especiales de proveedor o tener el permiso con privilegios READ_PRIVILEGED_PHONE_STATE para acceder a estos identificadores.

  3. Solo usa un ID de publicidad para casos prácticos de anuncios o generación de perfiles. Cuando uses un ID de publicidad, siempre respeta las selecciones de los usuarios respecto del seguimiento de anuncios. Si debes conectar el identificador de publicidad a información de identificación personal, hazlo solo con el consentimiento explícito del usuario.

  4. No compartas los restablecimientos de los IDs de publicidad.

  5. Usa un ID de instalación de Firebase (FID) o un GUID almacenado de forma privada siempre que sea posible para todos los demás casos de uso, excepto para la prevención de pagos fraudulentos y la telefonía. Para la gran mayoría de los casos de uso que no incluyan anuncios, un FID o un GUID debería ser suficiente.

  6. Usa las APIs que sean apropiadas para tu caso de uso a fin de minimizar los riesgos de privacidad. Usa la API de DRM para proteger contenido de alto valor y las APIs de Play Integrity para protegerlo contra abusos. Las APIs de Play Integrity son la forma más fácil de determinar si un dispositivo es genuino sin incurrir en riesgos de privacidad.

En las secciones restantes de esta guía, se abordan estas reglas en mayor profundidad en el contexto del desarrollo de apps para Android.

Cómo trabajar con los ID de publicidad

El ID de publicidad es un identificador que el usuario puede restablecer y es adecuado para casos de uso de anuncios. Sin embargo, debes tener en cuenta algunos puntos clave cuando uses este ID:

Respeta siempre la intención del usuario que restablece un ID de publicidad. No conectes los restablecimientos del usuario con otro identificador o huella digital para vincular los IDs de publicidad posteriores sin el consentimiento del usuario. La Política de contenido para desarrolladores de Google Play establece lo siguiente:

"...si se realiza un restablecimiento, un nuevo identificador de publicidad no debe estar conectado a un identificador de publicidad anterior ni a datos derivados de un identificador de publicidad previo sin el consentimiento explícito del usuario".

Respeta siempre el indicador de anuncios personalizados asociado. Los IDs de publicidad se pueden configurar en el sentido de que los usuarios pueden limitar la cantidad de seguimiento asociada con el ID. Usa siempre el método AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para asegurarte de no eludir los deseos de los usuarios. La Política de Contenido para Desarrolladores de Google Play establece lo siguiente:

"...se debe respetar lo que haya seleccionado el usuario en las opciones "Inhabilitar publicidad basada en intereses" o "Cancelar Personalización de anuncios". Si un usuario habilitó esta configuración, no podrás usar el identificador de publicidad para crear perfiles de usuario con fines publicitarios ni para segmentar usuarios con publicidad personalizada. Las actividades permitidas incluyen la publicidad contextual, la limitación de frecuencia, el seguimiento de conversiones, los informes y la seguridad, y la detección de fraudes".

Ten en cuenta todas las políticas de privacidad o seguridad asociadas con los SDK que uses y que estén relacionadas con el uso de ID de publicidad. Por ejemplo, si pasas true al método enableAdvertisingIdCollection() desde el SDK de Google Analytics, asegúrate de revisar todas las políticas del SDK de Analytics aplicables y cumplir con ellas.

Además, ten en cuenta que la Política de Contenido para Desarrolladores de Google Play establece que el ID de publicidad "no debe conectarse a información de identificación personal ni asociarse con ningún identificador de dispositivo persistente (por ejemplo: SSAID, dirección MAC, IMEI, etc.)".

A modo de ejemplo, supongamos que deseas recopilar información para completar tablas de base de datos con las siguientes columnas:

TABLA-01
timestamp ad_id account_id clickid
TABLA-02
account_id name dob country

En este ejemplo, la columna ad_id podría vincularse a PII a través de la columna account_id en ambas tablas, lo que supondría el incumplimiento de la Política de Contenido para Desarrolladores de Google Play si no obtuviste el permiso explícito de tus usuarios.

Ten en cuenta que los vínculos entre el ID del anunciante y la PII no siempre son tan explícitos. Es posible que haya "cuasi identificadores" que aparecen en las tablas de PII y de ID de anuncio con clave, lo que también causa problemas. Por ejemplo, supongamos que cambiamos la TABLA-01 y la TABLA-02 de la siguiente manera:

TABLA-01
timestamp ad_id clickid dev_model
TABLA-02
timestamp demo account_id dev_model name

En este caso, con eventos de clic lo suficientemente infrecuentes, aún es posible unirse entre la TABLA-01 de ID del anunciante y la PII contenida en la TABLA-02 con la marca de tiempo del evento y el modelo de dispositivo.

Aunque suele ser difícil garantizar que no existan tales cuasi identificadores en un conjunto de datos, puedes evitar los riesgos de unión más obvios si generalizas los datos únicos siempre que sea posible. En el ejemplo anterior, esto significaría reducir la precisión de la marca de tiempo para que aparecieran varios dispositivos con el mismo modelo en cada marca de tiempo.

A continuación, se muestran soluciones alternativas:

  • No diseñes tablas que vinculen explícitamente la PII con los ID de publicidad. En el primer ejemplo anterior, esto significaría no incluir la columna account_id en la TABLA-01.

  • Segregar y supervisar las listas de control de acceso de usuarios o roles que tienen acceso tanto a los datos con clave de ID de publicidad como a la PII. Si controlas y auditas de forma estricta la capacidad de acceder a ambas fuentes de forma simultánea (por ejemplo, mediante una unión entre las tablas), reduces el riesgo de asociación entre el ID de publicidad y la PII. En términos generales, para controlar el acceso, debes hacer lo siguiente:

    1. Mantén las listas de control de acceso (LCA) para la PII y los datos del ID del anunciante inconexos a fin de minimizar la cantidad de personas o funciones que están en ambas LCA.
    2. Implementar registros de acceso y auditorías para detectar y administrar las excepciones a esta regla.

Para obtener más información sobre cómo trabajar de manera responsable con los IDs de publicidad, consulta la referencia de la API de AdvertisingIdClient.

Cómo trabajar con FID y GUID

La solución más directa para identificar una instancia de app que se ejecuta en un dispositivo es usar un ID de instalación de Firebase (FID), y esta es la solución recomendada en la mayoría de los casos de uso que no incluyen anuncios. Solo la instancia de app para la que se aprovisionó puede acceder a este identificador, y es (relativamente) fácil de restablecer, ya que solo persiste mientras la app esté instalada.

Como resultado, los FID proporcionan mejores propiedades de privacidad en comparación con los IDs de hardware específicos del dispositivo que no se pueden restablecer. Si deseas obtener más información, consulta la referencia de la API de firebase.installations.

En los casos en que un FID no resulta práctico, también puedes usar IDs únicos globales (GUID) personalizados para identificar una instancia de app de forma única. La forma más sencilla de hacerlo es generar tu propio GUID con el siguiente código:

Kotlin

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

Java

String uniqueID = UUID.randomUUID().toString();

Debido a que el identificador es único a nivel global, se puede usar para identificar una instancia específica de la app. Para evitar problemas relacionados con la vinculación del identificador entre apps, almacena los GUID en el almacenamiento interno en lugar de en el externo (compartido). Para obtener más información, consulta la página Descripción general del almacenamiento de datos y archivos.

No trabajes con direcciones MAC

Las direcciones MAC son únicas a nivel global, el usuario no puede restablecer y permanecen vigentes después de los restablecimientos de la configuración de fábrica. Por estos motivos, para proteger la privacidad del usuario, en Android 6 y versiones posteriores, el acceso a las direcciones MAC está restringido a las apps del sistema. Las apps de terceros no tienen acceso a ellas.

Cambios en la disponibilidad de direcciones MAC en Android 11

En las apps orientadas a Android 11 y versiones posteriores, la aleatorización de MAC para las redes de Passpoint se realiza por perfil de Passpoint y esto genera una dirección MAC única basada en los siguientes campos:

  • Nombre de dominio completamente calificado (FQDN)
  • Dominio
  • Credencial, basada en la que se usó en el perfil de Passpoint:
    • Credencial de usuario: nombre de usuario
    • Credencial de certificado: certificado y tipo de certificado
    • Credencial de SIM: Tipo de EAP e IMSI

Además, las apps sin privilegios no pueden acceder a la dirección MAC del dispositivo; solo son visibles las interfaces de red con una dirección IP. Esto afecta a los métodos getifaddrs() y NetworkInterface.getHardwareAddress(), además del envío de mensajes RTM_GETLINK de Netlink.

La siguiente es una lista de los efectos de este cambio en las apps:

  • NetworkInterface.getHardwareAddress() muestra un valor nulo para cada interfaz.
  • Las apps no pueden usar la función bind() en los sockets NETLINK_ROUTE.
  • El comando ip no muestra información sobre las interfaces.
  • Las apps no pueden enviar mensajes RTM_GETLINK.

Ten en cuenta que la mayoría de los desarrolladores deben usar las APIs de nivel superior de ConnectivityManager en lugar de APIs de nivel inferior como NetworkInterface, getifaddrs() o sockets de Netlink. Por ejemplo, una app que necesita información actualizada sobre las rutas actuales puede obtenerla escuchando los cambios de red mediante ConnectivityManager.registerNetworkCallback() y llamando al LinkProperties.getRoutes() asociado de la red.

Características de los identificadores

El SO Android ofrece varios ID con diferentes características de comportamiento. El ID que debes usar depende del funcionamiento de las siguientes características con tu caso de uso. Sin embargo, estas características también tienen implicaciones en la privacidad, por lo que es importante comprender cómo interactúan entre sí.

Alcance

El ámbito del identificador explica los sistemas que pueden acceder al identificador. Por lo general, el alcance del identificador de Android tiene tres variantes:

  • Una sola app: El ID reside en la app, y otras apps no pueden acceder a él.
  • Grupo de apps: Un grupo predefinido de apps relacionadas puede acceder al ID.
  • Dispositivo: Todas las apps instaladas en el dispositivo pueden acceder al ID.

Cuanto más amplio sea el alcance otorgado a un identificador, mayor será el riesgo de que se use con fines de seguimiento. Por el contrario, si una sola instancia de app puede acceder al identificador, este no se podrá usar para realizar el seguimiento de un dispositivo en transacciones de diferentes apps.

Capacidad de restablecimiento y persistencia

La capacidad de restablecimiento y la persistencia definen la vida útil del identificador y explican cómo se puede restablecer. Entre los activadores de restablecimiento más comunes, se incluyen los restablecimientos dentro de la app, los restablecimientos mediante la configuración del sistema, los restablecimientos durante el inicio y los restablecimientos durante la instalación. La vida útil de los identificadores de Android puede variar, pero generalmente se relaciona con la forma en que se restablece el ID:

  • Solo por sesión: Se usa un ID nuevo cada vez que se reinicia la app.
  • Restablecimiento en instalación: Se usa un ID nuevo cada vez que el usuario desinstala y reinstala la app.
  • Restablecimiento de la configuración de fábrica: Se usa un ID nuevo cada vez que el usuario restablece la configuración de fábrica del dispositivo.
  • Conservación tras restablecimiento de la configuración de fábrica: El ID se mantiene después de restablecer la configuración de fábrica.

La capacidad de restablecimiento brinda a los usuarios la capacidad de crear un ID nuevo que no esté asociado a ninguna información de perfil existente. Cuanto más tiempo y más confiable persista un identificador, como uno que persiste después de los restablecimientos de la configuración de fábrica, mayor será el riesgo de que el usuario pueda estar sujeto a un seguimiento a largo plazo. Si se restablece el identificador después de reinstalar la app, se reduce la persistencia y se proporciona un medio para que se restablezca el ID, incluso si no hay un control explícito del usuario para restablecerlo desde la app o la Configuración del sistema.

Exclusividad

La exclusividad establece la probabilidad de colisiones, es decir, de que existan identificadores idénticos dentro del alcance asociado. En el nivel más alto, un identificador único global nunca sufre una colisión, ni siquiera en otros dispositivos o apps. De lo contrario, el nivel de exclusividad depende de la entropía del identificador y la fuente de aleatoriedad usada para crearlo. Por ejemplo, la probabilidad de una colisión es mucho mayor para identificadores aleatorios propagados con la fecha calendario de instalación (como 2019-03-01) que con los identificadores propagados con la marca de tiempo de instalación de Unix (como 1551414181).

En general, los identificadores de cuenta de usuario se pueden considerar únicos. Es decir, cada combinación de dispositivo y cuenta tiene un ID único. Por otro lado, cuanto menos único sea un identificador en una población, mayor será la protección de la privacidad, ya que es menos útil para el seguimiento de un usuario individual.

Protección de la integridad y carácter no repudiable

Puedes usar un identificador que sea difícil de falsificar o reproducir para demostrar que la cuenta o el dispositivo asociado tienen determinadas propiedades. Por ejemplo, podrías demostrar que el dispositivo no es un dispositivo virtual utilizado por un generador de spam. Los identificadores difíciles de falsificar también conllevan un carácter no repudiable. Si el dispositivo firma un mensaje con una clave secreta, es difícil afirmar que el dispositivo de otra persona lo envió. El carácter no repudiable podría ser algo que un usuario desea, como cuando se autentica un pago, o podría ser una propiedad no deseada, como cuando envía un mensaje del que se arrepiente.

Casos prácticos y el identificador adecuado que debe usarse

En esta sección, se proporcionan alternativas para evitar el uso de los ID de hardware, como el IMEI. No se recomienda usarlos, ya que el usuario no puede restablecerlos y su alcance es determinado por el dispositivo. En muchos casos, un identificador que funcione en el ámbito de la app sería suficiente.

Cuentas

Estado del proveedor

En este caso, tu app interactúa con el teléfono y la funcionalidad de mensajes de texto del dispositivo mediante una cuenta del proveedor.

Identificador recomendado para usar: IMEI, IMSI y Line1

¿Por qué se brinda esta recomendación?

El uso de identificadores de hardware es aceptable si se requieren para la funcionalidad relacionada con el proveedor. Por ejemplo, puedes usar estos identificadores para alternar entre proveedores de telefonía celular o ranuras de SIM, o para entregar mensajes SMS por IP (para Line1), cuentas de usuario basadas en SIM. Sin embargo, en el caso de las apps sin privilegios, recomendamos el uso de un acceso a una cuenta para recuperar la información del dispositivo del usuario en el servidor. Un motivo es que, en Android 6.0 (nivel de API 23) y versiones posteriores, estos identificadores solo se pueden usar mediante un permiso de tiempo de ejecución. Los usuarios pueden desactivar este permiso, por lo que tu app debería manejar estas excepciones con fluidez.

Estado de la suscripción para dispositivos móviles

En este caso, debes asociar las funciones de la app con ciertas suscripciones a servicios para dispositivos móviles en el dispositivo. Por ejemplo, es posible que debas verificar el acceso a ciertas funciones premium de apps según las suscripciones para dispositivos móviles del dispositivo mediante SIM.

Identificador recomendado para usar: API de Subscription ID para identificar las SIM que se usan en el dispositivo.

El ID de suscripción proporciona un valor de índice (a partir de 1) para identificar de forma única las SIM instaladas (incluidas las físicas y electrónicas) que se usan en el dispositivo. Mediante este ID, tu app puede asociar su funcionalidad con varias opciones de información de suscripción para una SIM determinada. Este valor es estable para una SIM determinada, a menos que se restablezca la configuración de fábrica del dispositivo. Sin embargo, puede haber casos en los que la misma SIM tenga un ID de suscripción diferente en dispositivos distintos, o bien SIM diferentes tengan el mismo ID en dispositivos distintos.

¿Por qué se brinda esta recomendación?

Es posible que algunas apps usen actualmente el ID de ICC para este propósito. Debido a que el ID de ICC es único a nivel global y no se puede restablecer, el acceso se restringió a apps con el permiso READ_PRIVILEGED_PHONE_STATE desde Android 10. A partir de Android 11, Android restringió aún más el acceso al ICCID mediante la API de getIccId(), independientemente del nivel de API objetivo de la app. En su lugar, se deben migrar las apps afectadas para usar el ID de suscripción.

Inicio de sesión único

En este caso, la app ofrece una experiencia de inicio de sesión único, lo que permite a los usuarios asociar una cuenta existente con tu organización.

Identificador recomendado para usar: Cuentas compatibles con el administrador de cuentas, como la vinculación de Cuentas de Google.

¿Por qué se brinda esta recomendación?

La vinculación de Cuentas de Google permite a los usuarios asociar su Cuenta de Google con tu app, lo que proporciona un acceso fluido y más seguro a los productos y servicios de tu organización. Además, puedes definir alcances personalizados de OAuth para compartir solo los datos necesarios, lo que aumenta la confianza de los usuarios mediante la definición clara de cómo se usan sus datos.

Anuncios

Segmentación

En este caso, tu app crea un perfil de los intereses del usuario para mostrarle anuncios más relevantes.

Identificador recomendado para usar: Si tu app usa un ID para anuncios, cargas o publicaciones en Google Play, ese ID debe ser el ID de publicidad.

¿Por qué se brinda esta recomendación?

Este es un caso de uso relacionado con anuncios que puede requerir un ID que esté disponible en las diferentes apps de tu organización, por lo que usar un ID de publicidad es la solución más adecuada. El uso del ID de publicidad es obligatorio para los casos de uso de publicidad, según la Política de Contenido para Desarrolladores de Google Play, ya que el usuario puede restablecerlo.

Independientemente de si compartes datos del usuario en tu app, si los recopilas y usas con fines publicitarios, debes declararlo en la sección de Seguridad de los datos de la página Contenido de la app en Play Console.

Medición

En este caso, tu app crea el perfil de un usuario según su comportamiento en las apps de la organización en el mismo dispositivo.

Identificador recomendado para usar: ID de publicidad o APIs de referencia de instalación de Play

¿Por qué se brinda esta recomendación?

Este es un caso de uso relacionado con anuncios que puede requerir un ID que esté disponible en las diferentes apps de tu organización, por lo que usar un ID de publicidad es la solución más adecuada. Si usas un ID para casos de uso de publicidad, ese ID debe ser el ID de publicidad porque el usuario puede restablecerlo. Obtén más información en la Política de Contenido para Desarrolladores de Google Play.

Conversiones

En este caso, se realiza un seguimiento de las conversiones para detectar si tu estrategia de marketing es exitosa.

Identificador recomendado para usar: ID de publicidad o APIs de referencia de instalación de Play

¿Por qué se brinda esta recomendación?

Este es un caso de uso relacionado con anuncios que puede requerir un ID que esté disponible en las diferentes apps de tu organización, por lo que usar un ID de publicidad es la solución más adecuada. El uso del ID de publicidad es obligatorio para los casos de uso de publicidad, según la Política de Contenido para Desarrolladores de Google Play, ya que el usuario puede restablecerlo.

Remarketing

En este caso, la app muestra anuncios en función de los intereses anteriores del usuario.

Identificador recomendado para usar: ID de publicidad

¿Por qué se brinda esta recomendación?

Este es un caso de uso relacionado con anuncios que puede requerir un ID que esté disponible en las diferentes apps de tu organización, por lo que usar un ID de publicidad es la solución más adecuada. El uso del ID de publicidad es obligatorio para los casos de uso de publicidad, según la Política de Contenido para Desarrolladores de Google Play, ya que el usuario puede restablecerlo.

Estadísticas de aplicaciones

En este caso, tu app evalúa el comportamiento del usuario para ayudarte a determinar lo siguiente:

  • ¿Cuál de los otros productos o apps de tu organización podría ser adecuado para el usuario?
  • Cómo mantener el interés de los usuarios por usar tu app
  • Mide las estadísticas y los análisis de uso de los usuarios anónimos o que salieron de sus cuentas.

Entre las posibles soluciones, se incluyen las siguientes:

  • ID del conjunto de apps: Un ID del conjunto de apps te permite analizar el comportamiento de un usuario en varias apps que pertenecen a tu organización, siempre que no uses los datos del usuario con fines publicitarios. Si orientas tus anuncios a dispositivos con la tecnología de los Servicios de Google Play, te recomendamos que uses el ID del conjunto de apps.
  • ID de Firebase (FID): Un FID se limita a la app que lo crea, lo que evita que el identificador se use para hacer un seguimiento de los usuarios en las apps. También se puede restablecer con facilidad, ya que el usuario puede borrar los datos de la app o reinstalar la app. El proceso de creación de un FID es sencillo; consulta la guía de instalación de Firebase.

Desarrollo de apps

Informes de fallas

En este caso, tu app recopila datos que indican cuándo y por qué falla en los dispositivos de un usuario.

Identificador recomendado para usar: FID o ID del conjunto de apps

¿Por qué se brinda esta recomendación?

Un FID se limita a la app que lo crea, lo que evita que el identificador se use para hacer un seguimiento de los usuarios en las apps. También se puede restablecer con facilidad, ya que el usuario puede borrar los datos de la app o reinstalarla. El proceso de creación de un FID es simple; consulta la guía de instalaciones de Firebase. Un ID del conjunto de aplicaciones te permite analizar el comportamiento de un usuario en varias apps que pertenezcan a tu organización, siempre que no utilices los datos del usuario con fines publicitarios.

Informes de rendimiento

En este caso, tu app recopila métricas de rendimiento, como los tiempos de carga y el uso de batería, para ayudar a mejorar su calidad.

Identificador recomendado para usar: Firebase Performance Monitoring

¿Por qué se brinda esta recomendación?

Firebase Performance Monitoring te ayuda a enfocarte en las métricas que más te interesan y a probar el impacto de un cambio reciente en tu app.

Prueba de apps

En este caso, tu app evalúa la experiencia del usuario con tu app con fines de prueba o depuración.

Identificador recomendado para usar: FID o ID del conjunto de apps

¿Por qué se brinda esta recomendación?

Un FID se limita a la app que lo crea, lo que evita que el identificador se use para hacer un seguimiento de los usuarios en las apps. También se puede restablecer con facilidad, ya que el usuario puede borrar los datos de la app o reinstalarla. El proceso de creación de un FID es simple; consulta la guía de instalaciones de Firebase. Un ID del conjunto de aplicaciones te permite analizar el comportamiento de un usuario en varias apps que pertenezcan a tu organización, siempre que no utilices los datos del usuario con fines publicitarios.

Instalación en varios dispositivos

En este caso, tu app necesita identificar la instancia correcta de la app cuando se instala en varios dispositivos para el mismo usuario.

Identificador recomendado para usar: FID o GUID

¿Por qué se brinda esta recomendación?

Un FID está diseñado explícitamente para este fin; su alcance se limita a la app de modo que no se puede usar para realizar un seguimiento de usuarios en diferentes apps y se restablece cuando se reinstala la app. En los casos poco comunes en los que un FID sea insuficiente, también puedes usar un GUID.

Seguridad

Detección de abusos

En este caso, se intenta detectar varios dispositivos falsos que atacan tus servicios de backend.

Identificador recomendado para usar: El token de integridad de la API de Google Play Integrity

¿Por qué se brinda esta recomendación?

Para verificar que una solicitud provenga de un dispositivo Android genuino (en lugar de un emulador o algún otro código que falsifique la identidad de otro dispositivo), usa la API de Google Play Integrity.

Fraude publicitario

En este caso, la app verifica que las impresiones y acciones de un usuario en la app sean genuinas y se puedan verificar.

Identificador recomendado para usar: ID de publicidad

¿Por qué se brinda esta recomendación?

El uso del ID de publicidad es obligatorio para los casos de uso de publicidad, según la Política de Contenido para Desarrolladores de Google Play, ya que el usuario puede restablecerlo.

Administración de derechos digitales (DRM)

En este caso, tu app quiere proteger el acceso fraudulento a la propiedad intelectual o al contenido pagado.

Identificador recomendado para usar: El uso de un FID o GUID obliga al usuario a reinstalar la app para eludir los límites de contenido, lo que es una carga suficiente para disuadir a la mayoría de las personas. Si esta protección no es suficiente, Android proporciona una API de DRM, que se puede usar para limitar el acceso a contenido, con un identificador por APK, el ID de Widevine.

Preferencias del usuario

En este caso, la app guarda el estado del usuario por dispositivo en la app, en especial para los usuarios que no accedieron. Puedes transferir este estado a otra app que esté firmada con la misma clave en el mismo dispositivo.

Identificador recomendado para usar: FID o GUID

¿Por qué se brinda esta recomendación?

No se recomienda conservar la información después de cada reinstalación, ya que es posible que los usuarios quieran restablecer sus preferencias reinstalando la app.