有很多不同的方法可以解决ANDROID_ID问题（有时可能为空，或者特定型号的设备总是返回相同的ID），有利弊：

实现自定义ID生成算法（基于应该是静态且不会更改的设备财产->谁知道呢）滥用其他ID，如IMEI、序列号、Wi-Fi/蓝牙MAC地址（它们不会存在于所有设备上，或者需要额外的权限）

我自己更喜欢使用现有的OpenUDID实现（请参见https://github.com/ylechelle/OpenUDID)适用于Android（请参见https://github.com/vieux/OpenUDID). 它很容易集成并利用ANDROID_ID和上述问题的回退。

通常，我的应用程序使用设备唯一id。但有时我会使用IMEI。两者都是唯一的数字。

获取IMEI（国际移动设备标识符）

public String getIMEI(Activity activity) {
    TelephonyManager telephonyManager = (TelephonyManager) activity
            .getSystemService(Context.TELEPHONY_SERVICE);
    return telephonyManager.getDeviceId();
}

获取设备唯一id

public String getDeviceUniqueID(Activity activity){
    String device_unique_id = Secure.getString(activity.getContentResolver(),
            Secure.ANDROID_ID);
    return device_unique_id;
}

不建议使用，因为deviceId可以在第三方手中用作跟踪，但这是另一种方式。

@SuppressLint("HardwareIds")
private String getDeviceID() {
    deviceId = Settings.Secure.getString(getApplicationContext().getContentResolver(),
                    Settings.Secure.ANDROID_ID);
    return deviceId;
}

这是一个简单的问题，没有简单的答案。

此外，这里所有现有的答案要么过时，要么不可靠。

因此，如果您正在寻找2020年后的解决方案。

以下是需要记住的几点：

所有基于硬件的标识符（IMEI、MAC、序列号等）对于非谷歌设备（Pixels和Nexuses除外）都是不可靠的，从统计上看，这些设备是世界上大多数android活动设备。因此，官方Android标识符最佳实践明确指出：

避免使用硬件标识符，如IMEI、MAC地址等。。。

这使得这里的大多数答案无效。同样由于不同的android安全更新，其中一些需要更新和更严格的运行时权限，用户可以简单地拒绝。

例如，CVE-2018-9489影响上述所有基于WIFI的技术。

这使得这些标识符不仅不可靠，而且在许多情况下无法访问。

所以简单地说：不要使用这些技术。

这里的许多其他答案都建议使用AdvertisingIdClient，这也是不兼容的，因为它是专为广告分析而设计的。官方参考文件中也有说明

仅将广告ID用于用户分析或广告用例

它不仅对设备识别不可靠，而且您还必须遵守有关广告跟踪的用户隐私政策，该政策明确规定用户可以随时重置或阻止它。

所以也不要使用它。

因为您无法获得所需的静态全局唯一和可靠的设备标识符。Android的官方参考建议：

在所有其他使用情况下，尽可能使用Firebase安装ID（FID）或私人存储的GUID，支付欺诈预防和电话除外。

它对于设备上的应用程序安装来说是独一无二的，因此当用户卸载应用程序时，它会被删除，因此它不是100%可靠，但它是次佳选择。

注意：截至目前，FirebaseInstanceId已弃用，您应改用FirebaseInstallations。

要使用FirebaseInstallations，请将最新的firebase消息传递依赖项添加到您的等级中

implementation 'com.google.firebase:firebase-messaging:23.0.0'

并使用以下代码获取firebase ID：

FirebaseInstallations.getInstance().getId().addOnCompleteListener(task -> {
     if (task.isSuccessful()) {
        String firebaseIdentifier = task.getResult();
        // Do what you need with firebaseIdentifier
     }
});

如果您需要将设备标识存储在远程服务器上，那么不要按原样存储（纯文本），而是使用带盐的哈希。

今天，这不仅是一种最佳实践，实际上，您必须根据GDPR标识符和类似法规依法进行。

正如DaveWebb提到的，Android开发者博客有一篇文章介绍了这一点。他们的首选解决方案是跟踪应用程序安装而不是设备，这对于大多数使用情况都很有效。博客文章将向您展示实现这一功能所需的代码，我建议您查看一下。

然而，如果您需要设备标识符而不是应用程序安装标识符，博客文章将继续讨论解决方案。我与谷歌的某位人士进行了交谈，以获得一些额外的澄清，以防您需要这样做。以下是我发现的有关设备标识符的信息，这些信息在上述博客文章中没有提及：

ANDROID_ID是首选设备标识符。ANDROID_ID在ANDROID<=2.1或>=2.3版本上非常可靠。只有2.2存在帖子中提到的问题。多个制造商的多个设备受到2.2中ANDROID_ID错误的影响。据我所知，所有受影响的设备都具有相同的ANDROID_ID，即9774d56d682e549c。顺便说一下，这也是模拟器报告的相同设备id。谷歌相信，原始设备制造商已经为他们的许多或大部分设备修补了这个问题，但我能够证实，至少在2011年4月初，找到ANDROID_ID损坏的设备仍然很容易。

根据谷歌的建议，我实现了一个类，该类将为每个设备生成一个唯一的UUID，在适当的情况下使用ANDROID_ID作为种子，必要时返回TelephonyManager.getDeviceId（），如果失败，则使用随机生成的唯一UUID，该UUID将在应用程序重新启动（但不是应用程序重新安装）期间保持。

请注意，对于必须在设备ID上回退的设备，唯一ID将在出厂重置期间保持。这是需要注意的。如果您需要确保出厂重置将重置您的唯一ID，您可能需要考虑直接返回到随机UUID而不是设备ID。

同样，此代码用于设备ID，而不是应用安装ID。对于大多数情况，应用安装ID可能是您要查找的。但是，如果您确实需要设备ID，那么下面的代码可能适用于您。

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;
    }
}

经过多次搜索。我意识到没有确定的方法可以拥有唯一的ID。

假设我们希望每个用户只能在一部手机上使用该应用程序。

我所做的是：

当用户在我的应用程序中注册时，我将当前时间保存为服务器和应用程序数据库中的唯一ID。

当用户尝试登录另一个电话时，我从服务器获取用户信息，并意识到该用户已经登录，因为唯一ID字段已满，所以向他/她显示一个对话框，表明他/她已经登录到另一个设备，无论他/她是否想离开上一个会话，如果他说是，我将为他创建一个新的唯一ID，并更新服务器上的唯一ID详细信息。

在我自己的应用程序中，每次运行时，我都会从服务器获取用户配置文件。如果存储在服务器上的唯一ID与存储在应用程序数据库中的唯一ID不同，我将自动注销用户。