Prácticas recomendadas para identificadores únicos

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

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

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. que incluyen 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. Cuándo Utiliza un ID de publicidad y siempre respeta las contraseñas selecciones relacionadas con 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 siempre que posible para todos los demás casos de uso, excepto para la prevención de pagos fraudulentos y telefonía. Para la gran mayoría de los casos de uso que no incluyen anuncios, se requiere un FID o GUID. debería ser suficiente.

6. Usa APIs que sean apropiadas para tu caso de uso para minimizar la privacidad riesgo. Usar la API de DRM para la protección de contenido de alto valor y la Las APIs de Play Integrity para la 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 anuncios casos de uso. 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. El Contenido para programadores de Google Play Policy establece la 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 son configurables, ya que el usuario puede limitar la cantidad de seguimiento asociada con el ID. Usar siempre AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para garantizar que no estés eludiendo deseos. La página Contenido para desarrolladores de Play Policy establece la lo siguiente:

"...se debe respetar la opción 'Inhabilitar publicidad basada en intereses' del usuario o Inhabilitar Personalización de anuncios del lugar. Si un usuario habilitó esta configuración, No puede usar el identificador de publicidad para crear perfiles de usuario para con fines publicitarios o 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 el Contenido para programadores de Google Play La política requiere que el ID de publicidad "no debe estar vinculado a documentos información o se asocia con cualquier identificador de dispositivo persistente (por ejemplo, SSAID, dirección MAC, IMEI, etc.)".

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

En este ejemplo, la columna ad_id podría vincularse a PII a través del account_id. en ambas tablas, lo cual sería una infracción de la política de Google Play Developer Política de Contenido, si no obtuvo permiso explícito de sus usuarios.

Ten en cuenta que los vínculos entre el ID del anunciante y la PII no siempre son así explícito. 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 poco frecuentes, es posible unirse entre el ID del anunciante TABLA-01 y la PII contenida en la TABLA-02 usando el marca de tiempo del evento y el modelo del 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 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 para los usuarios o roles que tienen acceso tanto a los datos protegidos por el ID de publicidad como a la PII. Controlando y auditando de forma estricta la capacidad de acceder a ambas fuentes de forma simultánea (por ejemplo, con 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. Mantener listas de control de acceso (LCA) para la desvinculación de los datos del ID de publicidad protegidos con claves y la PII, a fin de minimizar la cantidad de personas o funciones que se repitan 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 El dispositivo debe usar un ID de instalación de Firebase (FID), que es el de Google Cloud en la mayoría de los casos de uso que no son de anuncios. Solo la instancia de app para la cual se proporcionó 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 á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 resulte práctico, también puedes usar los IDs únicos globales (GUID) para identificar de manera inequívoca una instancia de app. La forma más sencilla Puedes hacerlo generando tu propio GUID usando el siguiente código:

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

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

Debido a que el identificador es único a nivel global, puede usarse para identificar un instancia de app. Para evitar los problemas derivados de vincular el identificador entre apps, guarda los GUID en el almacenamiento interno, en lugar del externo (compartido). Para ver más consulta la sección Almacenamiento de datos y archivos de resumen.

No trabajes con direcciones MAC

Las direcciones MAC son únicas a nivel global, el usuario no puede restablecerlas y se conservan de la fábrica restablecimientos. Por estos motivos, para proteger la privacidad del usuario, en las versiones de Android 6 y 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 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)
• Realm
• Credencial, basada en la credencial utilizada en el perfil de Passpoint:
  • Credencial de usuario: nombre de usuario
  • Credencial de certificado: tipo de certificado y certificado
  • Credencial de SIM: Tipo de EAP y IMSI

Además, las aplicaciones sin privilegios no pueden acceder a la dirección MAC del dispositivo. solamente las interfaces de red con una dirección IP son visibles. Esto afecta la getifaddrs() y NetworkInterface.getHardwareAddress() métodos, 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 deberían usar 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 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 depende del funcionamiento de las siguientes características: para tu caso de uso. Estas características también tienen consecuencias en la privacidad, por lo que es importante comprender cómo interactúan estas características entre sí.

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 ámbito otorgado a un identificador, mayor será el riesgo de que se use con propósitos de seguimiento. Por el contrario, si a un identificador solo pueden acceder una sola instancia de app, no se puede usar para hacer el seguimiento de un dispositivo en todas las transacciones en 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. Entre los activadores de restablecimiento más comunes, se incluyen los siguientes: restablecimientos dentro de la app, reinicios a través de Configuración del sistema; se restablece durante el inicio y durante 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 esté desvinculado a partir de cualquier información de perfil existente. Cuanto más larga y confiable sea, el identificador persiste, como uno que persiste tras restablecer la configuración de fábrica, existe un mayor riesgo de que el usuario esté sujeto a un seguimiento a largo plazo. Si el botón el identificador se restablece tras la reinstalación de la aplicación, lo que reduce la persistencia y proporciona un medio para restablecer el ID, incluso si no hay un usuario explícito para restablecerlo desde la app o desde 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, una estrategia global que el identificador único no sufra 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 aleatorización que se usó para crearlos. Por ejemplo, las probabilidades de que se produzca una colisión son mucho más altas para identificadores aleatorios propagados con la fecha de instalación (p. ej., 2019-03-01) que para los identificadores propagados con la marca de tiempo de instalación de Unix (p. ej., 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 un identificador dentro de una población, mayor es la protección de la privacidad porque 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, 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 la dirección de otra persona dispositivo envió el mensaje. El carácter no repudiable podría ser algo que un usuario quiera, como como cuando se autentica un pago, o puede ser una propiedad no deseada, como como cuando se arrepienten de enviar un mensaje.

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. Usando de hardware, ya que el usuario no puede restablecerlos en el 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, 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 funciones relacionadas con el operador. Por ejemplo, podrías usar estos identificadores para para cambiar entre operadores de telefonía celular o ranuras de SIM, o para enviar SMS IP (para Line1): Cuentas de usuario basadas en SIM. Sin embargo, para las apps sin privilegios, se recomienda usar el acceso con una cuenta para recuperar la información del dispositivo del usuario del servidor. Uno de los motivos es que, en Android 6.0 (con nivel de API 23) y versiones posteriores, estos identificadores solo se puede usar con un permiso de tiempo de ejecución. Los usuarios pueden desactivar este permiso, de manera que tu app debe manejar estas excepciones adecuadamente.

Estado de la suscripción para dispositivos móviles

En este caso, debes asociar las funciones de la app con determinados dispositivos suscripciones a servicios 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 un identificar las SIM instaladas (incluidas las físicas y las electrónicas) que se usan en dispositivo. A través de este ID, tu app puede asociar su funcionalidad con varios tipos 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. 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 ID de ICC es único a nivel global y no se puede restablecer, el acceso se restringió a las apps con READ_PRIVILEGED_PHONE_STATE permiso desde Android 10. A partir de Android 11, Android restringido el acceso al ICCID a través del getIccId() sin importar el nivel de API objetivo de la app. Las apps afectadas deben migrar a usa 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 para usar: Cuentas compatibles con el administrador de cuentas, como 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 para usar: Si la app usa un ID para anuncios y cargas, 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 podría requerir un ID que esté disponible en las distintas apps de tu organización, por lo que usar un ID de publicidad la solución más adecuada. El ID de publicidad es obligatorio para casos de uso de publicidad, según el Política de Contenido para Desarrolladores de Google Play, porque el usuario puede restablecerlo.

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

Medición

En este caso, tu app crea el perfil de un usuario en función de su comportamiento en todas las apps de tu 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 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 el 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 funciona correctamente.

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 ID de publicidad es obligatorio para casos de uso de publicidad, según el Política de Contenido para Desarrolladores de Google Play, porque 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 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 ID de publicidad es obligatorio para casos de uso de publicidad, según el Política de Contenido para Desarrolladores de Google Play, porque 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á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 orienta sus anuncios a dispositivos con tecnología de Google Play de Google, te recomendamos que uses el ID del conjunto de apps.
• 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 volver a instalarla. 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 una en los dispositivos de los usuarios.

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 del conjunto de apps te permite analizar el comportamiento de un usuario en varias apps que que pertenece a tu organización, siempre y cuando no uses los datos del usuario con fines publicitarios comerciales.

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.

Identificadores recomendados: 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 con fines de prueba o depuración.

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

¿Por qué se brinda esta recomendación?

Un FID se limita a la app que lo crea, lo que evita que el identificador que se usan para hacer un seguimiento de los 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.

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 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 al app a fin de que no se pueda usar para hacer un seguimiento de los usuarios en diferentes apps, y restablecer tras reinstalar la app. 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: 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 o cualquier otro código que falsifique la identidad de otro dispositivo, usa el 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 los datos propiedad o 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 esta protección no es suficiente, Android proporciona una API de DRM, que puede usarse para limitar el acceso al contenido, incluye un identificador por 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 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 que la información persista a través de reinstalaciones porque los usuarios podrían reinstalar la app para restablecer sus preferencias.