Existe-t-il un identifiant unique pour les appareils Android ?

Question

Les appareils Android ont-ils un identifiant unique et, si c'est le cas, quel est le moyen le plus simple d'y accéder en utilisant Java ?

Answer 1

Settings.Secure#ANDROID_ID renvoie l'identifiant Android sous la forme d'un _unique pour chaque utilisateur_ Chaîne hexagonale de 64 bits.

import android.provider.Settings.Secure;

private String android_id = Secure.getString(getContext().getContentResolver(),
                                                        Secure.ANDROID_ID);

Lire aussi Meilleures pratiques pour les identificateurs uniques : https://developer.Android.com/training/articles/user-data-ids

Answer 2

UPDATE : A partir des versions récentes d'Android, de nombreux problèmes avec les ANDROID_ID ont été résolus, et je crois que cette approche n'est plus nécessaire. Veuillez jeter un coup d'œil à La réponse d'Anthony .

Révélation complète : mon application utilisait à l'origine l'approche ci-dessous mais ne l'utilise plus, et nous utilisons maintenant l'approche décrite dans le document Blog des développeurs Android entrée qui La réponse de emmby (à savoir, générer et sauvegarder un [UUID#randomUUID()](http://developer.android.com/reference/java/util/UUID.html#randomUUID()) ).

---

Il existe de nombreuses réponses à cette question, mais la plupart d'entre elles ne fonctionneront qu'une partie du temps, et malheureusement, cela ne suffit pas.

Sur la base de mes tests d'appareils (tous les téléphones, dont au moins un n'est pas activé) :

1. Tous les appareils testés ont renvoyé une valeur pour TelephonyManager.getDeviceId()
2. Tous les appareils GSM (tous testés avec une SIM) ont renvoyé une valeur pour TelephonyManager.getSimSerialNumber()
3. Tous les appareils CDMA ont renvoyé un résultat nul pour getSimSerialNumber() (comme prévu)
4. Tous les appareils avec un compte Google ajouté ont renvoyé une valeur pour ANDROID_ID
5. Tous les dispositifs CDMA ont renvoyé la même valeur (ou une dérivation de la même valeur) pour les deux types d'appareils. ANDROID_ID et TelephonyManager.getDeviceId() -- à condition que un compte Google a été ajouté lors de l'installation.
6. Je n'ai pas encore eu l'occasion de tester les appareils GSM sans carte SIM, un appareil GSM sans compte Google ajouté, ou l'un des appareils en mode avion.

Donc si vous voulez quelque chose d'unique à l'appareil lui-même, TM.getDeviceId() devrait être suffisante. Évidemment, certains utilisateurs sont plus paranoïaques que d'autres, il peut donc être utile de hacher un ou plusieurs de ces identifiants, de sorte que la chaîne soit toujours virtuellement unique au dispositif, mais n'identifie pas explicitement le dispositif réel de l'utilisateur. Par exemple, en utilisant String.hashCode() combiné à un UUID :

final TelephonyManager tm = (TelephonyManager) getBaseContext().getSystemService(Context.TELEPHONY_SERVICE);

final String tmDevice, tmSerial, androidId;
tmDevice = "" + tm.getDeviceId();
tmSerial = "" + tm.getSimSerialNumber();
androidId = "" + android.provider.Settings.Secure.getString(getContentResolver(), android.provider.Settings.Secure.ANDROID_ID);

UUID deviceUuid = new UUID(androidId.hashCode(), ((long)tmDevice.hashCode() << 32) | tmSerial.hashCode());
String deviceId = deviceUuid.toString();

pourrait aboutir à quelque chose comme : 00000000-54b3-e7c7-0000-000046bffd97

Cela fonctionne assez bien pour moi.

Comme Richard le mentionne ci-dessous, n'oubliez pas que vous devez avoir l'autorisation de lire le fichier TelephonyManager donc ajoutez ceci à votre manifeste :

<uses-permission android:name="android.permission.READ_PHONE_STATE" />

les bibliothèques d'importation

import android.content.Context;
import android.telephony.TelephonyManager;
import android.view.View;

Answer 3

Dernière mise à jour : 6/2/15

---

Après avoir lu tous les articles de Stack Overflow sur la création d'un identifiant unique, le blog des développeurs de Google et la documentation Android, j'ai l'impression que le "Pseudo ID" est la meilleure option possible.

Question principale : Matériel et logiciel

Matériel informatique

• Les utilisateurs peuvent changer de matériel, de tablette Android ou de téléphone. Les identifiants uniques basés sur le matériel ne sont donc pas une bonne idée pour SUIVRE LES UTILISATEURS
• Pour MATÉRIEL DE SUIVI C'est une bonne idée.

Logiciel

• Les utilisateurs peuvent effacer/changer leur ROM s'ils sont enracinés.
• Vous pouvez suivre les utilisateurs sur toutes les plateformes (iOS, Android, Windows et Web).
• Les meilleurs veulent SUIVRE UN UTILISATEUR INDIVIDUEL avec leur consentement est de leur demander simplement de se connecter (en utilisant OAuth).

---

Ventilation générale avec Android

- Garantie d'unicité (y compris les appareils rootés) pour API >= 9/10 (99,5 % des appareils Android). ###- Pas de permissions supplémentaires

Un pseudo-code :

if API >= 9/10: (99.5% of devices)

return unique ID containing serial id (rooted devices may be different)

else

return the unique ID of build information (may overlap data - API < 9)

Merci à @stansult pour la publication toutes nos options (dans cette question de Stack Overflow).

Liste des options - raisons de les utiliser ou de ne pas les utiliser :

• Courriel de l'utilisateur - Logiciel

• L'utilisateur pourrait changer d'email - HAUTEMENT improbable

• API 5+ <uses-permission android:name="android.permission.GET_ACCOUNTS" /> ou

• API 14+ <uses-permission android:name="android.permission.READ_PROFILE" /> <uses-permission android:name="android.permission.READ_CONTACTS" /> ( Comment obtenir l'adresse e-mail principale de l'appareil Android ? )

• Numéro de téléphone de l'utilisateur - Logiciel

• Les utilisateurs pourraient changer de numéro de téléphone - HAUTEMENT improbable

• <uses-permission android:name="android.permission.READ_PHONE_STATE" />

• IMEI - Matériel (uniquement les téléphones, les besoins android.permission.READ_PHONE_STATE )

• La plupart des utilisateurs détestent le fait que l'autorisation indique "Appels téléphoniques". Certains utilisateurs donnent de mauvaises notes parce qu'ils pensent que vous ne faites que voler leurs informations personnelles alors que tout ce que vous voulez faire, c'est suivre l'installation des appareils. Il est évident que vous collectez des données.

• <uses-permission android:name="android.permission.READ_PHONE_STATE" />

• Android ID - Matériel (peut être nul, peut changer après une réinitialisation d'usine, peut être modifié sur un appareil enraciné)

• Comme il peut être "null", nous pouvons vérifier s'il est "null" et changer sa valeur, mais cela signifie qu'il ne sera plus unique.

• Si vous avez un utilisateur dont l'appareil a été réinitialisé en usine, la valeur peut avoir été modifiée ou altérée sur l'appareil enraciné, de sorte qu'il peut y avoir des entrées en double si vous suivez les installations des utilisateurs.

• Adresse MAC WLAN - Matériel (besoins android.permission.ACCESS_WIFI_STATE )

• C'est peut-être la deuxième meilleure option, mais vous continuez à collecter et à stocker un identifiant unique qui provient directement d'un utilisateur. Il est évident que vous collectez des données.

• <uses-permission android:name="android.permission.ACCESS_WIFI_STATE "/>

• Adresse MAC Bluetooth - Matériel (appareils avec Bluetooth, besoins android.permission.BLUETOOTH )

• La plupart des applications sur le marché n'utilisent pas Bluetooth, et donc si votre application n'utilise pas Bluetooth et que vous incluez ceci, l'utilisateur pourrait se méfier.

• <uses-permission android:name="android.permission.BLUETOOTH "/>

• Pseudo-Unique ID - Logiciel (pour tous les appareils Android)

• Très possible, peut contenir des collisions - Voir ma méthode postée ci-dessous !

• Cela vous permet d'avoir un identifiant "presque unique" de l'utilisateur sans prendre quoi que ce soit de privé. Vous pouvez créer votre propre identifiant anonyme à partir des informations du dispositif.

---

Je sais qu'il n'existe pas de moyen "parfait" d'obtenir un identifiant unique sans utiliser de permissions ; cependant, il arrive que nous ayons seulement besoin de suivre l'installation du dispositif. Lorsqu'il s'agit de créer un identifiant unique, nous pouvons créer un "pseudo-identifiant unique" basé uniquement sur les informations que l'API Android nous fournit sans utiliser de permissions supplémentaires. De cette façon, nous pouvons montrer du respect à l'utilisateur et essayer de lui offrir une bonne expérience.

Avec un pseudo-identifiant unique, vous ne risquez vraiment que d'être confronté à des doublons en raison de la présence d'appareils similaires. Vous pouvez modifier la méthode combinée pour la rendre plus unique ; cependant, certains développeurs ont besoin de suivre les installations de dispositifs et cela fera l'affaire ou les performances basées sur des dispositifs similaires.

API >= 9 :

Si leur appareil Android est doté de l'API 9 ou d'une version plus récente, il est garanti qu'il sera unique grâce au champ "Build.SERIAL".

SOUVENIR vous ne manquez techniquement qu'environ 0,5% des utilisateurs. qui ont un API < 9 . Vous pouvez donc vous concentrer sur le reste : C'est 99,5% des utilisateurs !

API < 9 :

Si l'appareil Android de l'utilisateur est inférieur à l'API 9, on peut espérer qu'il n'a pas effectué de réinitialisation d'usine et que son 'Secure.ANDROID_ID' sera préservé ou ne sera pas 'null' (cf. http://developer.Android.com/about/dashboards/index.html )

Si tout le reste échoue :

En cas d'échec, si l'utilisateur dispose d'une version inférieure à l'API 9 (inférieure à Gingerbread), s'il a réinitialisé son appareil ou si Secure.ANDROID_ID renvoie "null", l'identifiant renvoyé sera uniquement basé sur les informations relatives à son appareil Android. C'est là que les collisions peuvent se produire.

Changements :

• Suppression de 'Android.SECURE_ID' parce que les réinitialisations d'usine pouvaient entraîner un changement de valeur.
• J'ai modifié le code pour changer l'API
• Modifié le Pseudo

Veuillez consulter la méthode ci-dessous :

/**
 * Return pseudo unique ID
 * @return ID
 */
public static String getUniquePsuedoID() {
    // If all else fails, if the user does have lower than API 9 (lower
    // than Gingerbread), has reset their device or 'Secure.ANDROID_ID'
    // returns 'null', then simply the ID returned will be solely based
    // off their Android device information. This is where the collisions
    // can happen.
    // Thanks http://www.pocketmagic.net/?p=1662!
    // Try not to use DISPLAY, HOST or ID - these items could change.
    // If there are collisions, there will be overlapping data
    String m_szDevIDShort = "35" + (Build.BOARD.length() % 10) + (Build.BRAND.length() % 10) + (Build.CPU_ABI.length() % 10) + (Build.DEVICE.length() % 10) + (Build.MANUFACTURER.length() % 10) + (Build.MODEL.length() % 10) + (Build.PRODUCT.length() % 10);

    // Thanks to @Roman SL!
    // https://stackoverflow.com/a/4789483/950427
    // Only devices with API >= 9 have android.os.Build.SERIAL
    // http://developer.android.com/reference/android/os/Build.html#SERIAL
    // If a user upgrades software or roots their device, there will be a duplicate entry
    String serial = null;
    try {
        serial = android.os.Build.class.getField("SERIAL").get(null).toString();

        // Go ahead and return the serial for api => 9
        return new UUID(m_szDevIDShort.hashCode(), serial.hashCode()).toString();
    } catch (Exception exception) {
        // String needs to be initialized
        serial = "serial"; // some value
    }

    // Thanks @Joe!
    // https://stackoverflow.com/a/2853253/950427
    // Finally, combine the values we have found by using the UUID class to create a unique identifier
    return new UUID(m_szDevIDShort.hashCode(), serial.hashCode()).toString();
}

---

Nouveau (pour les applications avec publicités ET services Google Play) :

Depuis la console des développeurs de Google Play :

À compter du 1er août 2014, les règles du programme de développement Google Play exigent que toutes les nouvelles applications téléchargées et mises à jour utilisent l'identifiant publicitaire à la place de tout autre identifiant persistant à des fins publicitaires. à la place de tout autre identifiant persistant à des fins publicitaires. En savoir plus

Mise en œuvre :

Permission :

<uses-permission android:name="android.permission.INTERNET" />

Code :

import com.google.android.gms.ads.identifier.AdvertisingIdClient;
import com.google.android.gms.ads.identifier.AdvertisingIdClient.Info;
import com.google.android.gms.common.GooglePlayServicesAvailabilityException;
import com.google.android.gms.common.GooglePlayServicesNotAvailableException;
import java.io.IOException;
...

// Do not call this function from the main thread. Otherwise, 
// an IllegalStateException will be thrown.
public void getIdThread() {

  Info adInfo = null;
  try {
    adInfo = AdvertisingIdClient.getAdvertisingIdInfo(mContext);

  } catch (IOException exception) {
    // Unrecoverable error connecting to Google Play services (e.g.,
    // the old version of the service doesn't support getting AdvertisingId).

  } catch (GooglePlayServicesAvailabilityException exception) {
    // Encountered a recoverable error connecting to Google Play services. 

  } catch (GooglePlayServicesNotAvailableException exception) {
    // Google Play services is not available entirely.
  }
  final String id = adInfo.getId();
  final boolean isLAT = adInfo.isLimitAdTrackingEnabled();
}

Source/Docs :

http://developer.Android.com/google/play-services/id.html http://developer.Android.com/reference/com/google/Android/gms/ads/identifier/AdvertisingIdClient.html

Important :

Il est prévu que l'identifiant publicitaire remplace complètement l'utilisation actuelle l'utilisation d'autres identifiants à des fins publicitaires (comme l'utilisation de ANDROID_ID dans Settings.Secure) lorsque les services Google Play seront disponibles. Les cas Les cas où Google Play Services n'est pas disponible sont signalés par une icône GooglePlayServicesNotAvailableException qui est lancée par getAdvertisingIdInfo().

Avertissement, les utilisateurs peuvent réinitialiser :

http://en.kioskea.net/faq/34732-Android-reset-your-advertising-id

J'ai essayé de référencer chaque lien dont j'ai tiré des informations. Si vous êtes absent et que vous devez être inclus, veuillez commenter !

ID de l'instance des services aux joueurs de Google

https://developers.google.com/instance-id/

Answer 4

Comme le mentionne Dave Webb, le Android Developer Blog a un article qui couvre cette question. La solution qu'ils préfèrent est de suivre les installations d'applications plutôt que les appareils, et cela fonctionnera bien pour la plupart des cas d'utilisation. L'article de blog vous montrera le code nécessaire pour que cela fonctionne, et je vous recommande de le consulter.

Toutefois, l'article de blog aborde également des solutions si vous avez besoin d'un identifiant de dispositif plutôt que d'un identifiant d'installation d'application. J'ai parlé avec quelqu'un chez Google pour obtenir des précisions supplémentaires sur certains points, au cas où vous auriez besoin de le faire. Voici ce que j'ai découvert au sujet des identificateurs de périphériques qui ne sont PAS mentionnés dans l'article de blog susmentionné :

• ANDROID_ID est l'identifiant préféré de l'appareil. ANDROID_ID est parfaitement fiable sur les versions d'Android <=2.1 ou >=2.3. Seule la version 2.2 présente les problèmes mentionnés dans le billet.
• Plusieurs appareils de plusieurs fabricants sont affectés par le bogue ANDROID_ID dans la version 2.2.
• D'après ce que j'ai pu déterminer, tous les appareils concernés ont été le même ANDROID_ID qui est 9774d56d682e549c . C'est aussi l'identifiant de l'appareil rapporté par l'émulateur, d'ailleurs.
• Google pense que les équipementiers ont corrigé le problème pour la plupart de leurs appareils, mais j'ai pu vérifier qu'au début du mois d'avril 2011, au moins, il est encore assez facile de trouver des appareils dont l'ANDROID_ID est cassé.

En me basant sur les recommandations de Google, j'ai implémenté une classe qui génère un UUID unique pour chaque appareil, en utilisant ANDROID_ID comme graine lorsque c'est approprié, en recourant à TelephonyManager.getDeviceId() si nécessaire, et si cela échoue, en recourant à un UUID unique généré de manière aléatoire qui est conservé lors des redémarrages de l'application (mais pas lors des réinstallations).

Notez que pour les dispositifs qui doivent se rabattre sur l'ID du dispositif, l'ID unique WILL persistent à travers les réinitialisations d'usine. Il faut en être conscient. Si vous devez vous assurer qu'une réinitialisation d'usine réinitialisera votre ID unique, vous pouvez envisager de revenir directement à l'UUID aléatoire au lieu de l'ID du périphérique.

Encore une fois, ce code est destiné à l'identification d'un appareil, pas à l'identification de l'installation d'une application. Dans la plupart des cas, un identifiant d'installation d'application est probablement ce que vous recherchez. Mais si vous avez besoin d'un ID d'appareil, le code suivant vous conviendra probablement.

import android.content.Context;
import android.content.SharedPreferences;
import android.provider.Settings.Secure;
import android.telephony.TelephonyManager;

import java.io.UnsupportedEncodingException;
import java.util.UUID;

public class DeviceUuidFactory {

    protected static final String PREFS_FILE = "device_id.xml";
    protected static final String PREFS_DEVICE_ID = "device_id";
    protected volatile static UUID uuid;

    public DeviceUuidFactory(Context context) {
        if (uuid == null) {
            synchronized (DeviceUuidFactory.class) {
                if (uuid == null) {
                    final SharedPreferences prefs = context
                            .getSharedPreferences(PREFS_FILE, 0);
                    final String id = prefs.getString(PREFS_DEVICE_ID, null);
                    if (id != null) {
                        // Use the ids previously computed and stored in the
                        // prefs file
                        uuid = UUID.fromString(id);
                    } else {
                        final String androidId = Secure.getString(
                            context.getContentResolver(), Secure.ANDROID_ID);
                        // Use the Android ID unless it's broken, in which case
                        // fallback on deviceId,
                        // unless it's not available, then fallback on a random
                        // number which we store to a prefs file
                        try {
                            if (!"9774d56d682e549c".equals(androidId)) {
                                uuid = UUID.nameUUIDFromBytes(androidId
                                        .getBytes("utf8"));
                            } else {
                                final String deviceId = (
                                    (TelephonyManager) context
                                    .getSystemService(Context.TELEPHONY_SERVICE))
                                    .getDeviceId();
                                uuid = deviceId != null ? UUID
                                    .nameUUIDFromBytes(deviceId
                                            .getBytes("utf8")) : UUID
                                    .randomUUID();
                            }
                        } catch (UnsupportedEncodingException e) {
                            throw new RuntimeException(e);
                        }
                        // Write the value out to the prefs file
                        prefs.edit()
                                .putString(PREFS_DEVICE_ID, uuid.toString())
                                .commit();
                    }
                }
            }
        }
    }

    /**
     * Returns a unique UUID for the current android device. As with all UUIDs,
     * this unique ID is "very highly likely" to be unique across all Android
     * devices. Much more so than ANDROID_ID is.
     * 
     * The UUID is generated by using ANDROID_ID as the base key if appropriate,
     * falling back on TelephonyManager.getDeviceID() if ANDROID_ID is known to
     * be incorrect, and finally falling back on a random UUID that's persisted
     * to SharedPreferences if getDeviceID() does not return a usable value.
     * 
     * In some rare circumstances, this ID may change. In particular, if the
     * device is factory reset a new device ID may be generated. In addition, if
     * a user upgrades their phone from certain buggy implementations of Android
     * 2.2 to a newer, non-buggy version of Android, the device ID may change.
     * Or, if a user uninstalls your app on a device that has neither a proper
     * Android ID nor a Device ID, this ID may change on reinstallation.
     * 
     * Note that if the code falls back on using TelephonyManager.getDeviceId(),
     * the resulting ID will NOT change after a factory reset. Something to be
     * aware of.
     * 
     * Works around a bug in Android 2.2 for many devices when using ANDROID_ID
     * directly.
     * 
     * @see http://code.google.com/p/android/issues/detail?id=10603
     * 
     * @return a UUID that may be used to uniquely identify your device for most
     *         purposes.
     */
    public UUID getDeviceUuid() {
        return uuid;
    }
}

Answer 5

Voici le code que Reto Meier a utilisé dans le cadre de l'opération Google I/O présentation de cette année pour obtenir un identifiant unique pour l'utilisateur :

private static String uniqueID = null;
private static final String PREF_UNIQUE_ID = "PREF_UNIQUE_ID";

public synchronized static String id(Context context) {
    if (uniqueID == null) {
        SharedPreferences sharedPrefs = context.getSharedPreferences(
                PREF_UNIQUE_ID, Context.MODE_PRIVATE);
        uniqueID = sharedPrefs.getString(PREF_UNIQUE_ID, null);
        if (uniqueID == null) {
            uniqueID = UUID.randomUUID().toString();
            Editor editor = sharedPrefs.edit();
            editor.putString(PREF_UNIQUE_ID, uniqueID);
            editor.commit();
        }
    }
    return uniqueID;
}

Si vous couplez cela avec une stratégie de sauvegarde pour envoyer les préférences dans le nuage (également décrit dans l'article de Reto parler Si l'on veut que l'utilisateur ait une identité, il faut qu'elle soit liée à l'utilisateur et qu'elle soit conservée après l'effacement ou le remplacement de l'appareil. J'ai l'intention d'utiliser cela dans les analyses à l'avenir (en d'autres termes, je n'ai pas encore fait cette partie :).