Prácticas recomendadas para identificadores únicos

En este documento, se brinda orientación sobre cómo seleccionar los identificadores adecuados para tu app en función de tu caso de uso.

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

Recomendaciones para trabajar con identificadores de Android

Para proteger la privacidad de los usuarios, usa el identificador más restrictivo que se adapte a tu caso de uso. 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 distintos de los 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 equipo móvil (IMEI), sin limitar la funcionalidad requerida.

   Android 10 (nivel de API 29) agrega restricciones para identificadores que no se pueden restablecer, incluido el IMEI y el número de serie. Tu app debe ser una app del propietario del perfil o del dispositivo, tener permisos especiales del operador o tener el permiso con privilegios de 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 conectes los restablecimientos del ID de publicidad.

5. Usa un ID de instalación de Firebase (FID) o un GUID almacenado de forma privada cuando sea posible para todos los demás casos prácticos, salvo 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 el contenido de alto valor y las APIs de Play Integrity para brindar protección 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 con 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 los casos prácticos de anuncios. Sin embargo, hay algunos puntos clave que debes tener en cuenta cuando uses este ID:

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

"… ante un restablecimiento, no se debe vincular un nuevo identificador de publicidad a uno 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 tus 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 en el método enableAdvertisingIdCollection() desde el SDK de Google Analytics, asegúrate de revisar todas las políticas del SDK de Analytics correspondientes y de 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 puede vincularse 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 propagar tablas de bases de datos con las siguientes columnas:

En este ejemplo, la columna ad_id podría vincularse a PII por medio 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 expreso de tus usuarios.

Recuerda que los vínculos entre el ID de publicidad y la PII no siempre son tan explícitos. Es posible que haya "cuasi identificadores" que aparecen tanto en las tablas de PII como en las de ID de publicidad protegidos con claves, lo cual causa problemas. Por ejemplo, supongamos que cambiamos la TABLA-01 y la TABLA-02 de la siguiente manera:

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

Si bien, a veces, es difícil garantizar que no existan tales cuasi identificadores en un conjunto de datos, puedes evitar los riesgos de vinculación más evidentes 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 de modo que aparezcan varios dispositivos del mismo modelo para 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 que se muestra más arriba, esta acción significaría no incluir la columna account_id en la TABLA-01.

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

  1. Mantén inconexas las listas de control de acceso (LCA) para la PII y los datos del ID de anunciante con clave a fin de minimizar la cantidad de personas o funciones que se encuentren en ambas LCA.
  2. Implementar registros y auditorías de acceso 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 sencilla 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 prácticos que no incluyen anuncios. Solo la instancia de la app para la que se aprovisionó puede acceder a este identificador, y es (relativamente) fácil de restablecer porque 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 ámbito del dispositivo, que no se pueden restablecer. Para 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 los IDs únicos globales (GUID) personalizados para identificar de forma exclusiva una instancia de app. La forma más sencilla de hacerlo es generar tu propio GUID con el siguiente código:

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

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

Como el identificador es único a nivel global, puede usarse para identificar una instancia de app específica. Para evitar los problemas derivados de vincular el identificador entre apps, guarda los GUID en el almacenamiento interno, en lugar del 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 mundial, se conservan tras el restablecimiento de la configuración de fábrica y no permiten que el usuario las restablezca. Por estos motivos, para proteger la privacidad del usuario, en las versiones 6 y posteriores de Android, el acceso a las direcciones MAC se restringe a las apps del sistema. Las apps de terceros no pueden acceder a ellos.

Cambios en la disponibilidad de las 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 es por perfil de Passpoint, lo que genera una dirección MAC única según los siguientes campos:

• Nombre de dominio completamente calificado (FQDN)
• Dominio
• Credencial, según la credencial que se usa en el perfil de Passpoint:
  • Credencial de usuario: nombre de usuario
  • Credential de certificado: certificado y tipo de certificado
  • Credencial SIM: IMSI y tipo EAP

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 los métodos getifaddrs() y NetworkInterface.getHardwareAddress(), así como el 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 obtener esta información escuchando los cambios de red con ConnectivityManager.registerNetworkCallback() y llamando al LinkProperties.getRoutes() asociado a la red.

Características de los identificadores

El SO Android ofrece varios ID con diferentes características de comportamiento. El ID que debes usar dependerá del funcionamiento de las siguientes características con tu caso de uso. Sin embargo, estas características tienen consecuencias en la privacidad, por lo tanto es importante que comprendas cómo interactúan entre ellas.

Alcance

El ámbito del identificador explica los sistemas que pueden acceder al identificador. Por lo general, el ámbito de los identificadores 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 un seguimiento del 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 este. Los activadores de restablecimiento más comunes ocurren cuando se restablece dentro de la app, a través de configuraciones del sistema, durante el inicio y la instalación. La vida útil de los identificadores de Android puede variar, pero generalmente está relacionada 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 permite a los usuarios crear un nuevo ID que no esté relacionado con información del perfil existente. Cuanto más tiempo y de manera más confiable permanezca un identificador, como uno que persiste después de un restablecimiento de la configuración de fábrica, mayor es el riesgo de que el usuario pueda estar sujeto a un seguimiento a largo plazo. Si se restablece el identificador después de la reinstalación de la app, se reduce la persistencia y se proporciona un método para restablecer el ID, aunque el usuario no controle el restablecimiento de forma explícita desde la app o la configuración del sistema.

Exclusividad

La exclusividad establece la probabilidad de colisión, es decir, de que existan dos identificadores idénticos en el ámbito asociado. En el nivel más alto, un identificador único a nivel global nunca tendrá una colisión, ni siquiera en otros dispositivos o apps. De lo contrario, el nivel de unicidad depende de la entropía del identificador y de la fuente de aleatorización que se usó para crearlo. Por ejemplo, las probabilidades de que ocurra una colisión son mucho más altas para identificadores aleatorios propagados con la fecha de instalación (como 2019-03-01) que para 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 exclusivo 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 probar que la cuenta o el dispositivo asociado tienen ciertas propiedades. Por ejemplo, puedes probar que el dispositivo no es un dispositivo virtual manipulado 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 aseverar que fue otra persona quién lo envió. El carácter no repudiable podría ser algo que un usuario desea, como cuando 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 ámbito es limitado. En muchos casos, un identificador que funcione en el ámbito de la app sería suficiente.

Cuentas

Estado de la empresa de transporte

En este caso, tu app interactúa con la funcionalidad de teléfono y mensajería del dispositivo mediante una cuenta de operador.

Identificador recomendado: 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 de telefonía y proveedores. Por ejemplo, puedes usarlos para cambiar de proveedor de servicios móviles o de ranura de SIM, o para entregar mensajes SMS por IP (para Line1) a cuentas de usuario basadas en SIM. Sin embargo, en el caso de las apps que no tienen privilegios, se recomienda implementar el acceso con una cuenta para recuperar información en el servidor. Uno de los motivos 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 debe manejar estas excepciones con elegancia.

Estado de la suscripción para dispositivos móviles

En este caso, debes asociar la funcionalidad 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 la app según las suscripciones móviles del dispositivo a través de la SIM.

Identificador recomendado: 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 las electrónicas) que se usan en el dispositivo. Mediante este ID, la app puede asociar su funcionalidad con información de suscripción determinada de una SIM determinada. Este valor es estable para una SIM determinada, a menos que se realice el restablecimiento de la configuración de fábrica del dispositivo. Sin embargo, puede haber casos en los que la misma tarjeta SIM tenga un ID de suscripción diferente en diferentes dispositivos o que diferentes tarjetas SIM tengan el mismo ID en diferentes dispositivos.

¿Por qué se brinda esta recomendación?

Es posible que algunas apps usen actualmente el ID de ICC para este fin. Debido a que el ICCID es único a nivel global y no se puede restablecer, el acceso se restringió a las 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 a través de la API de getIccId(), independientemente del nivel de API objetivo de la app. Las apps afectadas deben migrar para usar el ID de suscripción.

Inicio de sesión único

En este caso, tu 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: 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 existente con tu app, lo que proporciona un acceso más seguro y sin inconvenientes a los productos y servicios de tu organización. Además, puedes definir alcances de OAuth personalizados para compartir solo los datos necesarios, lo que aumenta la confianza de los usuarios, ya que se define claramente cómo se usan sus datos.

Anuncios

Segmentación

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

Identificador recomendado: Si tu app usa un ID para los anuncios y lo sube o publica 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 disponible en diferentes apps de tu organización. Por lo tanto, 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 para fines publicitarios, debes declarar los fines publicitarios en la sección 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 tu organización en el mismo dispositivo.

Identificador recomendado: 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 disponible en diferentes apps de tu organización. Por lo tanto, 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: 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 disponible en diferentes apps de tu organización. Por lo tanto, 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, de acuerdo con la Política de Contenido para Desarrolladores de Google Play, ya que el usuario puede restablecerlo.

Remarketing

En este caso, tu app muestra anuncios en función de los intereses anteriores de un 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 disponible en diferentes apps de tu organización. Por lo tanto, 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 de un usuario para ayudarte a determinar lo siguiente:

• Cuáles de los otros productos o apps de tu organización podrían ser adecuados para el usuario.
• Cómo mantener el interés de los usuarios en usar tu app.
• Mide las estadísticas de uso y el análisis de los usuarios anónimos o que salieron de la cuenta.

Entre las posibles soluciones, se incluyen las siguientes:

• ID del conjunto de aplicaciones: Un ID del conjunto de aplicaciones te permite analizar el comportamiento de un usuario en varias apps que pertenecen a tu organización, siempre y cuando no uses los datos del usuario con fines publicitarios. Si segmentas tus anuncios para dispositivos con los Servicios de Google Play, te recomendamos que uses el ID del conjunto de aplicaciones.
• ID de Firebase (FID): Un FID se limita al ámbito de la app que lo crea, lo cual evita que se use para el seguimiento de usuarios en las apps. También se puede restablecer fácilmente, 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 instalaciones de Firebase.

Desarrollo de apps

Informes de fallas

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

Identificador recomendado: FID o ID del conjunto de aplicaciones

¿Por qué se brinda esta recomendación?

Un FID se limita al ámbito de la app que lo crea, lo cual evita que se use para el seguimiento de usuarios en las apps. También es fácil restablecerlos borrando los datos de la app o volviendo a instalarla. El proceso de creación de un FID es sencillo. Consulta la guía de instalaciones de Firebase. Un ID de conjunto de aplicaciones te permite analizar el comportamiento de un usuario en varias apps que pertenecen a tu organización, siempre y cuando no uses 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: 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 de un usuario con tu app con fines de prueba o depuración.

Identificador recomendado: FID o ID del conjunto de aplicaciones

¿Por qué se brinda esta recomendación?

Un FID se limita al ámbito de la app que lo crea, lo cual evita que se use para el seguimiento de 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 de conjunto de aplicaciones te permite analizar el comportamiento de un usuario en varias apps que pertenecen a tu organización, siempre y cuando no uses los datos del usuario con fines publicitarios.

Instalación multidispositivo

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

Identificador recomendado: FID o GUID

¿Por qué se brinda esta recomendación?

Un FID se diseñó explícitamente para este fin; su ámbito se limita a la app, por lo que no se puede usar para realizar un seguimiento de usuarios en diferentes apps y se restablece con la reinstalación. En los casos poco comunes en los que un FID no sea suficiente, también puedes usar un GUID.

Seguridad

Detección de abusos

En este caso, se intentan 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 originales y verificables.

Identificador recomendado: 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: Si usas un FID o un GUID, se obliga al usuario a reinstalar la app para eludir los límites de contenido, lo que normalmente desalienta a la mayoría de las personas. Si crees que esta protección no alcanza, Android proporciona una API de DRM, que se puede usar para limitar el acceso a contenido mediante un identificador para cada APK, el ID de Widevine.

Preferencias del usuario

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

Identificador recomendado: FID o GUID

¿Por qué se brinda esta recomendación?

No se recomienda que la información persista a lo largo de las reinstalaciones, ya que los usuarios podrían querer restablecer sus preferencias reinstalando la app.