Skip to content

Most visited

Recently visited

navigation

Prácticas recomendadas para identificadores únicos

Si bien hay motivos válidos por los que tu aplicación podría necesitar identificar un dispositivo en lugar de una instancia de aplicación o un usuario autenticado en el dispositivo, para la gran mayoría de las aplicaciones el objetivo principal es identificar una instalación de tu app (no el dispositivo físico en sí).

Afortunadamente, identificar una instalación en Android es sencillo cuando se usa un ID de instancia o se crea un GUID propio en el momento de la instalación. Este documento te orientará en la selección de los identificadores adecuados para tu aplicación, según tu caso de uso.

Para obtener un panorama general sobre los permisos de Android, consulta Permisos y datos de usuario. Si deseas hallar prácticas recomendadas específicas para trabajar con permisos de Android, consulta Prácticas recomendadas para permisos de apps.

Principios básicos del trabajo con identificadores de Android

Te recomendamos que sigas estos principios básicos cuando trabajes con identificadores de Android:

1: Evita usar identificadores de hardware. Los identificadores de hardware como SSAID (ID de Android) e IMEI pueden evitarse en la mayoría de los casos, sin limitar la funcionalidad requerida.

2: Usa solo ID de publicidad para la creación de perfiles de usuario o para anuncios. Cuando uses un ID de publicidad, respeta siempre el indicador Limit Ad Tracking (limitar seguimiento de publicidad), asegúrate de que el identificador no pueda vincularse a información personal y evita conectar restablecimientos de ID de publicidad.

3: Siempre que sea posible, usa un ID de instancia o un GUID almacenado de forma privada para todos los demás casos, salvo para la prevención de pagos fraudulentos y la telefonía. Para la mayoría de los casos que no incluyan anuncios, bastará con un ID o GUID de instancia.

4: Usa API para la protección de contenido de gran valor a fin de minimizar el riesgo de privacidad. Usa la API DRM API para la protección de contenido de gran valor y SafetyNet API para la prevención de abusos. La Safetynet API ofrece la forma más fácil de determinar si un dispositivo es genuino, sin incurrir en un riesgo de privacidad.

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

Identificadores en Android 6.0 y versiones posteriores

Las direcciones MAC son únicas a nivel mundial, el usuario no puede restablecerlas y se conservan tras el restablecimiento de fábrica. Generalmente, no se recomienda usar direcciones MAC para ninguna forma de identificación de usuarios. Como consecuencia, desde Android M, las direcciones MAC en dispositivos locales (por ejemplo, Wi-fi y Bluetooth) no están disponibles a través de API de terceros. Los métodos WifiInfo.getMacAddress() y BluetoothAdapter.getDefaultAdapter().getAddress() mostrarán 02:00:00:00:00:00.

Además, debes tener los siguientes permisos para acceder a direcciones MAC de dispositivos externos cercanos disponibles a través de detecciones de Bluetooth y WiFi:

Método/propiedad Permisos requeridos
WifiManager.getScanResults() ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION
BluetoothDevice.ACTION_FOUND ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION
BluetoothLeScanner.startScan(ScanCallback) ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION

Cómo trabajar con ID de publicidad

El ID de publicidad es un identificador que el usuario puede restablecer y es adecuado para casos de anuncios, pero debes tener en cuenta algunos puntos claves al usarlo:

Respeta siempre la intención del usuario al restablecer el ID de publicidad. No conectes restablecimientos del usuario usando un identificador de dispositivo más persistente o una huella dactilar para vincular ID de publicidad posteriores sin el consentimiento del usuario. La Política de contenido para desarrolladores de Google Play indica lo siguiente:

... ante un restablecimiento, no se debe conectar un identificador de publicidad nuevo 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 ID de publicidad son configurables, ya que el usuario puede limitar la cantidad de seguimiento asociada con el ID. Usa siempre el método AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para asegurarte de no ignorar la voluntad de tus usuarios. La Política de contenido para desarrolladores de Google Play indica lo siguiente:

... se deben respetar los ajustes “No recibir anuncios basados en intereses” o “No recibir personalización de anuncios” de un usuario. Si un usuario habilita estos ajustes, no debes usar el identificador de publicidad para crear perfiles de usuario con fines publicitarios o con el propósito de identificar usuarios mediante publicidad personalizada. Las actividades permitidas incluyen publicidad contextual, limitación de frecuencia, seguimiento de conversión, el informe y la seguridad, y la detección de fraude.

Entre las políticas de privacidad o seguridad asociadas con SDK que uses, ten presentes las que estén relacionadas con el uso de ID de publicidad. Por ejemplo, si usas el método mTracker.enableAdvertisingIdCollection(true) de Google Analytics SDK, asegúrate de revisar todas las políticas de Analytics SDK correspondientes y cumplir con ellas.

Ten en cuenta también que, conforme a la Política de contenido para desarrolladores de Google Play, el ID de publicidad “no debe estar vinculado a información personal ni asociado a un identificador de dispositivos persistente (por ejemplo: SSAID, direcciones MAC, IMEI, etc.,) sin el consentimiento explícito del usuario ”.

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

timestamp ad_id account_id clickid

TABLA-01

account_id name dob country

TABLA-02

En este ejemplo, la columna ad_id podría vincularse a información personal a través de la columna account_id en ambas tablas, lo cual representaría una violación 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 ID de publicidad e información personal no siempre son tan explícitos. Es posible que haya “cuasi identificadores” en las tablas de información personal e ID de publicidad protegidas con claves, lo que también causa problemas. Por ejemplo, supón que cambiamos la TABLA-01 y la TABLA-02 de la siguiente manera:

timestamp ad_id clickid dev_model

TABLA-01

timestamp demo account_id dev_model name

TABLA-02

En este caso, con eventos de clic suficientemente infrecuentes, aún es posible establecer un vínculo entre la TABLA-01 de ID de publicidad y la información personal de la TABLA-02 usando la marca de tiempo del evento y el modelo del dispositivo.

Si bien generalmente resulta difícil garantizar que un conjunto de datos no contenga ninguno de estos cuasi identificadores, los riesgos más evidentes de la vinculación pueden evitarse generalizando datos únicos, siempre que sea posible. En el ejemplo, 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.

Entre otras soluciones se incluyen las siguientes:

Para obtener más información sobre cómo trabajar de forma responsable con ID de publicidad, consulta el artículo del centro de ayuda ID de publicidad.

Cómo trabajar con ID y GUID de instancias

La solución más sencilla para identificar una instancia de aplicación que se ejecute en un dispositivo es usar un ID de instancia, y esta es la solución recomendada en la mayoría de los casos que no son 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 consecuencia, los ID de instancia ofrecen mejores propiedades de privacidad en comparación con los ID de hardware para el ámbito del dispositivo que no admiten restablecimiento. Estos también vienen con un par de claves para la firma de mensajes (y acciones similares) y están disponibles en Android, iOS y Chrome. Para obtener más información, consulta el documento ¿Qué es un ID de instancia? del centro de ayuda.

Cuando un ID de instancia no resulta práctico, también se pueden usar ID exclusivos globales (GUID) personalizados para identificar de forma exclusiva una instancia de app. La forma más sencilla de hacerlo es generar tu propio GUID usando el siguiente código.

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

Debido a que el identificador es único a nivel global, puede usarse para identificar una instancia de app específica. Para evitar preocupaciones relacionadas con la vinculación del identificador en diferentes aplicaciones, los GUID deben almacenarse internamente y no en un medio de almacenamiento externo (compartido). Consulta la guía Opciones de almacenamiento para obtener más información.

Comprensión de las características del identificador

El sistema operativo Android ofrece una variedad de ID con diferentes características de comportamiento, y el ID que debes usar depende del funcionamiento de las siguientes características en tu caso. Sin embargo, estas características también tienen consecuencias en la privacidad, por lo cual es importante que comprendas la interacción entre ellas.

Ámbito

El ámbito del identificador explica los sistemas que pueden acceder al identificador. El ámbito de los identificadores de Android generalmente tiene tres variantes:

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 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 la manera en que se puede restablecer. Los activadores de restablecimiento más comunes se aplican restablecimientos dentro de la app, a través de configuraciones del sistema, durante el inicio y durante la instalación. La vida útil de los identificadores de Android puede diferir, pero generalmente está relacionada con la forma en que se restablece el ID:

La capacidad de restablecimiento permite a los usuarios crear un nuevo ID que no esté relacionado con información existente del perfil. Esto es importante porque, cuanto mayores sean el tiempo y el grado de confiabilidad en términos de permanencia de un identificador (p. ej., tras varios 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 la reinstalación de la app, se reduce la persistencia y se ofrece un medio para el restablecimiento del ID, aunque el usuario no controle el restablecimiento de forma explícita desde la app o las configuraciones del sistema.

Exclusividad

La exclusividad establece las probabilidades de que existan identificadores idénticos en el ámbito asociado. En el nivel más alto, un identificador exclusivo global nunca experimentará una colisión, ni siquiera en otros dispositivos o apps. En los demás casos, el nivel de exclusividad depende del tamaño del identificador y de la fuente de aleatoriedad usada para crearlo. Por ejemplo, las probabilidades de que ocurra una colisión son mucho más altas para los identificadores aleatorios propagados con la fecha de instalación (p. ej., “2015-01-05”) que para los identificadores propagados con la marca de tiempo de instalación de Unix (p. ej., “1445530977”).

En general, los identificadores de cuenta de usuario se pueden considerar como únicos (es decir, cada par dispositivo/cuenta tiene un ID exclusivo). Por otro lado, cuanto menos exclusivo sea un identificador en una población (p. ej., de dispositivos), mayor será 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

Se puede usar un identificador difícil de falsificar o reproducir para probar que la cuenta o el dispositivo asociados tienen ciertas propiedades (p. ej., no es un dispositivo virtual empleado por un spammer). Los identificadores difíciles de falsificar también proporcionan carácter no repudiable. Si el dispositivo firma un mensaje con una clave secreta, es difícil aseverar que el envío se realizó desde el dispositivo de alguien más. El carácter no repudiable podría ser algo atractivo para un usuario (p. ej., para la autenticación de un pago) o podría ser una propiedad no deseada (p. ej., al enviar un mensaje del que se arrepienten).

Casos de uso comunes e identificadores que deben usarse

En esta sección se ofrecen alternativas para el uso de ID de hardware, como IMEI o SSAID, para la mayoría de los casos de uso. No se recomienda la dependencia de ID de hardware, ya que el usuario no puede restablecerlos y generalmente tiene un control limitado de la colección.

Seguimiento de preferencias de usuarios que cerraron sesión

En este caso, se guarda el estado de cada dispositivo en el servidor.

Te recomendamos: ID de instancia o GUID.

¿Por qué esta recomendación?

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

Seguimiento del comportamiento de usuarios que cerraron sesión

En este caso, se crea el perfil de un usuario según su comportamiento en diferentes apps o sesiones en el mismo dispositivo.

Te recomendamos: ID de publicidad.

¿Por qué esta recomendación?

El use de un ID de publicidad es obligatorio para casos de uso de publicidad conforme a la Política de contenido para desarrolladores de Google Play, ya que el usuario puede restablecerlo.

Generación de análisis de usuarios que han cerrado sesión o son anónimos

En este caso, se miden las estadísticas de uso y el análisis para los usuarios anónimos o que cerraron sesión.

Te recomendamos: ID de instancia. Si con este no basta, también puedes usar un GUID.

¿Por qué esta recomendación?

Un ID de instancia o un GUID se limitan al ámbito de la app que los crea, lo cual evita su uso para el seguimiento de usuarios en las apps. También es fácil restablecerlos borrando los datos de la app o volviendo a instalarla. Crear ID de instancia y GUID es fácil:

Ten en cuenta que si indicas al usuario que los datos que recopilas son anónimos, debes asegurarte de no conectar el identificador con información personal ni con otros identificadores que puedan estar vinculados a información personal.

También puedes usar Google Analytics para apps para dispositivos móviles, que ofrece una solución orientada al análisis de apps individuales.

Seguimiento de la conversión de usuarios que cerraron sesión

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

Te recomendamos: ID de publicidad.

¿Por qué esta recomendación?

Este es un caso de uso relacionado con anuncios que puede requerir un ID disponible en diferentes apps. Por ello, usar un ID de publicidad es la solución más adecuada.

Manejo de varias instalaciones

En este caso, debes verificar la instancia correcta de la app cuando se instala en varios dispositivos de un mismo usuario.

Te recomendamos: ID o GUI de instancia.

¿Por qué esta recomendación?

El ID de instancia fue diseñado 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 tras reinstalar la app. En los casos poco comunes en los cuales un ID de instancia no sea suficiente, también puedes usar un GUID.

Antifraude: Aplicación de límites de contenido libre y detección de ataques de Sybil

En este caso, se busca limitar la cantidad de contenido libre (p. ej., artículos) que un usuario puede ver en un dispositivo.

Te recomendamos: ID o GUI de instancia.

¿Por qué esta recomendación?

Al usar un GUID o un ID de instancia, se fuerza al usuario a reinstalar la app para lidiar con los límites de contenido; esto supone una carga suficiente como para desalentar a la mayoría de las personas. Si esta protección no es suficiente, Android proporciona una DRM API que se puede usar para limitar el acceso a contenido.

Administración de funcionalidad de telefonía y proveedores

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

Te recomendamos: IMEI, IMSI y Line1 (requiere el grupo de permisos PHONE en Android 6.0 [nivel de API 23] y versiones posteriores).

¿Por qué esta recomendación?

El uso de identificadores de hardware es aceptable si se requieren para la funcionalidad de telefonía y proveedores; por ejemplo, para cambiar slots de proveedores de redes celulares o SIM, o entregar mensajes SMS por IP (para Line1) a cuentas de usuario basadas en SIM. Sin embargo, es importante tener en cuenta que, en Android 6.0 y versiones posteriores, estos identificadores solo se pueden usar a través de un permiso de tiempo de ejecución y los usuarios pueden desactivar ese permiso, por lo que tu app debe manejar estas excepciones de manera correcta.

Detección de abusos: Identificación de ataques de bots y DdoS

En este caso, intentas detectar el ataque de tus servicios backend por parte de varios dispositivos falsos.

Te recomendamos: Safetynet API.

¿Por qué esta recomendación?

Un identificador aislado no logra indicar con precisión que un dispositivo es genuino. Puedes verificar si una solicitud proviene de un dispositivo Android genuino (en comparación con un emulador u otro código que falsifique la identidad de un dispositivo) usando el método SafetyNet.SafetyNetApi.attest(mGoogleApiClient, nonce) de la Safetynet API para verificar la integridad de un dispositivo que realiza una solicitud. Para obtener información detallada, consulta Documentación de Safetynet API.

Detección de abusos: Detección de credenciales robadas de gran valor

En este caso, se busca detectar si en un dispositivo se usa muchas veces con credenciales robadas de gran valor (p. ej., para realizar pagos fraudulentos).

Te recomendamos: IMEI/IMSI (requiere el grupo de permisos PHONE en Android 6.0 [nivel de API 23] y versiones posteriores).

¿Por qué esta recomendación?

Con credenciales robadas, los dispositivos pueden usarse para la monetización de varias credenciales robadas de gran valor (como tarjetas de crédito con tokens). En estas situaciones, se pueden restablecer los ID de software para evitar la detección, por lo que pueden usarse identificadores de hardware.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience.
(Sep 2017 survey)