Prácticas recomendadas para identificadores únicos

En este documento, se proporciona orientación para seleccionar los identificadores adecuados para tu app según tu caso de uso.

Para obtener una descripción general de los permisos de Android, consulta Descripción general de los permisos. Para conocer las prácticas recomendadas específicas para trabajar con permisos de Android, consulta Prácticas recomendadas para los permisos de las apps.

Recomendaciones para trabajar con identificadores de Android

Para proteger la privacidad de los usuarios, utiliza el identificador más restrictivo que se adapte al 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 cumplir con la mayoría de sus casos de uso, incluso cuando usa identificadores que no son 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 los identificadores que no se pueden restablecer, que incluyen el IMEI y el número de serie. Tu app debe ser una app de propietario del dispositivo o del perfil, tener permisos especiales del operador o tener el permiso con privilegios READ_PRIVILEGED_PHONE_STATE para acceder a estos identificadores.

  3. Solo usa un ID de publicidad para casos de uso de anuncios o generación de perfiles de usuario. Cuando uses un ID de publicidad, siempre respeta las selecciones de los usuarios con respecto al seguimiento de anuncios. Si debes conectar el identificador de publicidad con 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 siempre que sea posible para todos los demás casos de uso, excepto para la prevención de fraudes en los pagos y la telefonía. Para la gran mayoría de los casos de uso que no son anuncios, un FID o GUID debería ser suficiente.

  6. Usa las APIs que sean adecuadas para tu caso de uso para minimizar el riesgo de privacidad. Usa la API de DRM para proteger el contenido de alto valor y las APIs de Play Integrity para protegerte contra abusos. Las APIs de Play Integrity son la forma más sencilla de determinar si un dispositivo es genuino sin incurrir en riesgos de privacidad.

En las secciones restantes de esta guía, se detallan estas reglas 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, 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 uses otro identificador o huella digital para vincular 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 el restablecimiento, un nuevo identificador de publicidad no debe estar conectado a otro 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 de modo que los usuarios puedan limitar la cantidad de seguimiento asociado al 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:

"…debes respetar los parámetros de configuración para inhabilitar la publicidad basada en intereses o rechazar la personalización de anuncios que haya seleccionado un usuario. Si un usuario habilitó este parámetro de configuración, no podrás usar el identificador de publicidad para crear perfiles de usuario con fines publicitarios ni para establecer la segmentación hacia los usuarios con publicidad personalizada. Las actividades permitidas incluyen la publicidad contextual, la limitación de frecuencia, el seguimiento de conversiones, la generación de 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 y cumplir todas las políticas del SDK de Analytics aplicables.

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

Por ejemplo, supongamos que deseas recopilar información para propagar tablas de bases 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 unirse a la PII a través de la columna account_id en ambas tablas, lo que sería un 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 de anunciante y la PII no siempre son tan explícitos. Es posible tener "cuasiidentificadores" que aparezcan en las tablas con claves de PII y de ID de anuncio, lo que también causa problemas. Por ejemplo, supongamos que cambiamos TABLE-01 y TABLE-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 inusuales, aún es posible unir la TABLA-01 de ID de anunciante y la PII contenida en la TABLA-02 con la marca de tiempo del evento y el modelo del dispositivo.

Aunque suele ser difícil garantizar que no existan esos cuasiidentificadores en un conjunto de datos, puedes evitar los riesgos de unión más evidentes generalizando los datos únicos siempre que sea posible. En el ejemplo anterior, esto significaría reducir la exactitud de la marca de tiempo para que aparezcan 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 TABLE-01.

  • Separar y supervisar las listas de control de acceso para los usuarios o roles que tienen acceso a los datos con clave de ID de publicidad y a la PII. Si controlas y auditas de forma estricta la capacidad de acceder a ambas fuentes de forma simultánea (por ejemplo, realizando 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 significa hacer lo siguiente:

    1. Mantén las listas de control de acceso (LCA) para los datos con clave de ID de anunciante y la PII separadas para minimizar la cantidad de personas o roles que están en ambas LCA.
    2. Implementa el registro y la auditoría de acceso para detectar y administrar cualquier excepción a esta regla.

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

Trabaja con FID y GUID

La solución más directa para identificar una instancia de la 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 son de anuncios. Solo la instancia de la app para la que se aprovisionó puede acceder a este identificador, y se puede restablecer con (relativa) facilidad, 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 con alcance de 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 sea práctico, también puedes usar IDs únicos globales (GUID) personalizados para identificar de forma inequívoca una instancia de la app. 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();

Como el identificador es único a nivel global, se puede usar para identificar una instancia de app específica. Para evitar problemas relacionados con la vinculación del identificador entre apps, almacena 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 global, no se pueden restablecer por el usuario y sobreviven a los restablecimientos de la configuración de fábrica. Por estos motivos, para proteger la privacidad del usuario, en las versiones 6 y posteriores de Android, el acceso a las direcciones MAC está restringido a las apps del sistema. Las apps de terceros no pueden acceder a ellos.

Cambios en la disponibilidad de la dirección MAC en Android 11

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

  • Nombre de dominio completamente calificado (FQDN)
  • Dominio
  • Credencial, según la credencial que se use 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 los métodos getifaddrs() y NetworkInterface.getHardwareAddress(), así como el envío de mensajes de Netlink RTM_GETLINK.

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 las 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 con 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 de cómo funcionan las siguientes características con tu caso de uso. Sin embargo, estas características también tienen implicaciones de 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 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 solo una instancia de la app puede acceder a un identificador, este no se puede usar para hacer un seguimiento de un dispositivo en las 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 comunes, se incluyen los restablecimientos en la app, los restablecimientos a través de la configuración del sistema, los restablecimientos durante el inicio y los restablecimientos durante la instalación. Los identificadores de Android pueden tener diferentes ciclos de vida, pero estos suelen estar relacionados 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 de la instalación: Se usa un ID nuevo cada vez que el usuario desinstala y vuelve a instalar 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 les permite a los usuarios crear un ID nuevo que no esté asociado con ninguna información de perfil existente. Cuanto más tiempo y de manera más confiable persista un identificador, como uno que persiste tras los restablecimientos de la configuración de fábrica, mayor será el riesgo de que el usuario esté sujeto a un seguimiento a largo plazo. Si el identificador se restablece cuando se reinstala 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.

Unicidad

La exclusividad establece la probabilidad de colisiones, es decir, que existan identificadores idénticos dentro del alcance asociado. En el nivel más alto, un identificador único global nunca tiene una colisión, ni siquiera en otros dispositivos o apps. De lo contrario, el nivel de exclusividad dependerá de la entropía del identificador y de la fuente de aleatoriedad que se use para crearlo. Por ejemplo, la probabilidad de una colisión es mucho mayor para los identificadores aleatorios que se inicializan con la fecha de instalación del calendario (como 2019-03-01) que para los identificadores que se inicializan con la marca de tiempo de Unix de la instalación (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 dentro de una población, mayor será la protección de la privacidad, ya que es menos útil para hacer un 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 el dispositivo o la cuenta asociados tienen ciertas propiedades. Por ejemplo, podrías demostrar que el dispositivo no es un dispositivo virtual que usa 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 envió el mensaje. La no repudiabilidad 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 usar IDs de hardware porque el usuario no puede restablecerlos y están limitados al dispositivo. 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, la app interactúa con las funciones de teléfono y envío de mensajes de texto del dispositivo a través de una cuenta de operador.

Identificadores recomendados para usar: IMEI, IMSI y Line1

¿Por qué se brinda esta recomendación?

Se permite aprovechar los identificadores de hardware si es necesario para la funcionalidad relacionada con el operador. Por ejemplo, podrías usar estos identificadores para cambiar entre operadores de telefonía celular o ranuras de SIM, o para enviar mensajes SMS por IP (para Line1), que son cuentas de usuario basadas en SIM. Sin embargo, para las apps sin privilegios, recomendamos usar un acceso a la cuenta para recuperar la información del dispositivo del usuario del servidor. Un motivo de esto es que, en Android 6.0 (nivel de API 23) y versiones posteriores, estos identificadores solo se pueden usar a través de un permiso de tiempo de ejecución. Es posible que los usuarios desactiven este permiso, por lo que tu app debería controlar estas excepciones de forma correcta.

Estado de la suscripción para dispositivos móviles

En este caso, debes asociar la funcionalidad de la app con ciertas suscripciones a servicios 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 para usar: API de ID de suscripción para identificar las SIM que se usan en el dispositivo.

El ID de suscripción proporciona un valor de índice (que comienza en 1) para identificar de forma única las SIM instaladas (incluidas las físicas y electrónicas) que se usan en el dispositivo. A través de este ID, tu app puede asociar su funcionalidad con información de suscripción diversa 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 distintos dispositivos o en los que diferentes SIM tengan el mismo ID en distintos dispositivos.

¿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 las apps con el permiso READ_PRIVILEGED_PHONE_STATE desde Android 10. A partir de Android 11, se 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 en su lugar.

Inicio de sesión único

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

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

¿Por qué se brinda esta recomendación?

La vinculación de la Cuenta de Google permite que los usuarios asocien su Cuenta de Google existente con tu app, lo que proporciona un acceso más seguro y sin interrupciones a los productos y servicios de tu organización. Además, puedes definir permisos 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 anuncios y se sube o se 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 los anuncios que podría 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 declarar esos fines 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 un perfil de un usuario en función de 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 los anuncios que podría 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, ya que 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, haces 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 los anuncios que podría requerir un ID 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, tu app muestra anuncios basados en los intereses anteriores del usuario.

Identificador recomendado: ID de publicidad

¿Por qué se brinda esta recomendación?

Este es un caso de uso relacionado con los anuncios que podría 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 de un usuario para ayudarte a determinar lo siguiente:

  • Qué 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 tu app
  • Medir las estadísticas de uso y de análisis de los usuarios que no accedieron a su cuenta o que son anónimos

Entre las posibles soluciones, se incluyen las siguientes:

  • ID del conjunto de apps: El ID del conjunto de apps 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 que usan 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 impide que el identificador se use para hacer un seguimiento de los usuarios en todas 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 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 los usuarios.

Identificador recomendado: 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 todas 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 sencillo; consulta la guía de instalaciones de Firebase. El ID del conjunto de apps 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 la calidad de la app.

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 importan 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 para realizar pruebas o depuraciones.

Identificador recomendado: 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 todas 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 sencillo; consulta la guía de instalaciones de Firebase. El ID del conjunto de apps 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ña explícitamente para este propósito; su alcance se limita a la app, de modo que no se puede usar para hacer un seguimiento de los usuarios en diferentes apps, y se restablece cuando se reinstala la app. En los casos excepcionales en los que un FID no sea suficiente, también puedes usar un GUID.

Seguridad

Detección de abusos

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

Identificador recomendado: 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 original, en lugar de un emulador o de otro código que simule ser otro dispositivo, usa la API de Google Play Integrity.

Fraude publicitario

En este caso, tu app verifica que las impresiones y acciones de un usuario en tu app sean genuinas 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: El uso de un FID o un 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 al contenido, y que incluye un identificador por APK, el ID de Widevine.

Preferencias de usuario

En este caso, tu app guarda el estado del usuario por dispositivo, 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: FID o GUID

¿Por qué se brinda esta recomendación?

No se recomienda conservar la información durante las reinstalaciones, ya que es posible que los usuarios quieran restablecer sus preferencias reinstalando la app.