android获取设备唯一标识,android获取设备唯一标识完美解决方案

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

android 获得设备唯一标识码（总有一款适合你）

最近在做一个OA考勤项目，里面有个需求是一个账号只允许绑定一台设备，这就需要将设备唯一标识码与账号绑定在一起，咋一听这还不So Easy啊，直接获取deviceID 不就好了。。。

咋一操作也挺好。可到了大面积的群体用户测试环节发现了几个问题。

简言之就是如果你的手机需要考虑Android9以上的设备，你就没办法通过获取系统提供的API完全的获取到设备唯一标识码，根据Android文档唯一标识符最佳做法你也许可以这样....

呃.... 这个特殊运营商许可和这个 READ_PRIVILEGED_PHONE_STATE 好像都不是我们一般的安卓应用能获取的到的。

想要能Android9以上又能不受到刷机，格式化的影响。就只能使用移动安全联盟（MSA）提出的补充设备标识

是由移动安全联盟提出的，包含以下三个标识：

缺点就是：并不是所有的品牌商都兼容了，而且需要导入他们对应的包。这部分可参考 Android 10获取设备标识方案探究这篇文章

特点：如果格式化或者刷机，这个设备ID会更改(这个也是合理的)。

完善：可以在第一次生成后放入到内部存储和外部存储，下次进入先从内部存储获取，如果没有在去外部存储比较（App卸载，内部存储就没了）。如果在没有就生成一个

相关问答

Q1: 如何获取Android唯一标识

获取Android唯一标识的具体操作步骤：

DEVICE_ID

假设确实需要用到真实设备的标识，可能就需要用到DEVICE_ID。在以前，Android设备是手机，这个DEVICE_ID可以同

通过TelephonyManager.getDeviceId()获取，它根据不同的手机设备返回IMEI，MEID或者ESN码，但它在使用的过程中

会遇到很多问题：

非手机设备：如果只带有Wifi的设备或者音乐播放器没有通话的硬件功能的话就没有这个DEVICE_ID

权限：获取DEVICE_ID需要READ_PHONE_STATE权限，如果只为了获取它，没有用到其它的通话功能，那这个权限有点大才小用

bug：在少数的一些手机设备上，该实现有漏洞，会返回垃圾，如:zeros或者asterisks的产品。

2. MAC ADDRESS

也可以通过手机的Wifi或者蓝牙设备获取MAC ADDRESS作为DEVICE ID，但是并不建议这么做，因为并不是所有的设备都有Wifi，并且，如果Wifi没有打开，那硬件设备无法返回MAC ADDRESS.

3. Serial Number

在Android 2.3可以通过android.os.Build.SERIAL获取，非手机设备可以通过该接口获取。

4. ANDROID_ID

ANDROID_ID是设备第一次启动时产生和存储的64bit的一个数，当设备被wipe后该数重置

ANDROID_ID似乎是获取Device ID的一个好选择，但它也有缺陷：

它在Android =2.1 or Android =2.3的版本是可靠、稳定的，但在2.2的版本并不是100%可靠的

在主流厂商生产的设备上，有一个很经常的bug，就是每个设备都会产生相同的ANDROID_ID：9774d56d682e549c

5. Installtion ID : UUID

Q2: android获取设备唯一ID（优化方案）

最近，因公司产品及客户需要，领导让我研究免存储设备ID，以及给出一个设备ID最佳的方案（可与存储相结合）。在研究过浏览器的fingerprient2js后，颇有心得，并且看网上似乎木有完美的解决方案，于是写了这篇文章，仅供需要的开发者参考。（该算法暂未进行验证，这里先给出一个jar包，后期我会在SDK中加入调查接口，分两个jar包（测试版和正式版），希望开发者能支持测试版，稳定后使用正式版。）

在产品中，首先肯定要尽量避免权限，其次考虑卸载APP后ID不一致的问题，再就是尽量结合存储，降低卸载或重装app时，设备ID改变的概率。最后，设计出合理方案，对造成不利的因素进行列举。

A.android_id:

什么是android_id呢？当设备在第一次启动时，系统会随机产生一个64位的数字，然后以16进制的形式保存在设备上，且API提供了获取这一参数的方法：

这就是android_id,当设备重新初始化或者刷机的时候，会被重置。

除此以外，android_id还有其他的bug，比如：

1.不同的设备可能会产生相同的android_id。

2.有的厂商设备无法获取android_id,会返回null。

3.对于CDMA的设备，ANDROID_ID和TelephonyManager.getDeviceId() 的值相同。

4.不同的android系统版本稳定性不同。

B.硬件序列号(SERIAL)

API给的解释是：

A hardware serial number, if available.（一个硬件的序列码，如果有效的话）

so，虽然我没有用几百台手机测试，也能知道这个值有时候是无效的，说的这么隐晦。

C.指纹

fingerprint:设备的唯一标识。由设备的多个信息拼接合成。

也是在JavaScript才接触到这个单词”fingerprint“，这个词也很生动，意思是能大概的标识一个设备，像指纹一样，但不排除重复的可能性。

理论上讲用这个属性是可以标识一个设备的，但是其实并不是，两台一摸一样的新手机，这个值相同的可能性是很多的。为了更加进一步的精确，后面还会介绍几个属性，并把几个属性结合在一起，生成一个接近100%的UUID。

D.android系统提供了获取android系统版本号，生产厂商，固件版本推出时间的API.

E.android系统提供了当前android设备是12或24小时制显示时间的API，

F.android系统提供了当前android设备的修订版本列表，显示屏，主板等等参数。

G.可以允许用户根据需求用自定义字符串去为FP做贡献，比如IP地址等

方案：

在不需要用户权限的前提下，网上最完美的方案是将android_id和硬件序列号，如果其中任意一种失效就使用另外一种。受FingerPrint2js的启发，我看了Android获取系统硬件相关的API，将所有不经常变化且能代表一定用户群体的属性都取出来进行MD5运算，包含但不限于依据中所述的信息。准确性还需进一步验证，但理论上要比FingerPrint2js准确性高，也在网上给出的比较好的方案基础上进一步缩小了FP可能重复的概率。

1.第一次进入APP时，获取系统相关配置信息生成FP，存入SP。

2.每次访问，先从SP取，没有再通过相关配置信息生成FP，存入SP。

3.封装成jar，只给用户暴露出获取ID的接口、传递自定义信息构建FP的接口以及第一次安装时间戳的接口（或设置标签调用的接口）

单纯对于FP而言，有两个主要问题需要解决，一是FP重复的问题，相同配置的新设备重复可能性极大，增多给FP贡献的因素的数量，可以有效降低重复率。二是FP改变的问题，贡献FP的生成因素的其中一个如果改变，FP就会改变。所以如果FP的贡献因素数量过多，导致FP改变的概率也就变大，所以说客户要在两者之间做一个很好的平衡。

对比：

为android FP做贡献的各配置参数：（示例以6.0的华为荣耀8为例）

1.Android_ID:Settings.System.getString(context.getContentResolver(), Settings.System.ANDROID_ID) //低版本稳定，高版本不稳定示例：295a4fbf716094ee

2.Build.SERIAL 设备序列号（有的设备无法获取）示例：WTK7N16923005607

3.Build.FINGERPRINT 设备指纹（同样的新设备该值应该是一样的）示例：honor/FRD-AL00/HWFRD:6.0/HUAWEIFRD-AL00/C00B171:user/release-keys

4.Build.TIME 固件推出日期示例：1477442228000

5.Build.VERSION.INCREMENTAL 源码控制版本号示例： C00B171

6.Build.getRadioVersion() 获取无线电固件版本示例：21.210.03.00.031,21.210.03.00.031

7.Build.HARDWARE 硬件名称示例：hi3650

8.Build.VERSION.SECURITY_PATCH 用户可见安全补丁level（这里我得到的是日期，可能是补丁修复的时间）示例：2016-10-01

9.当前设备是12/24时制：Settings.System.getString(context.getContentResolver(), Settings.System.TIME_12_24) 示例：null（有的手机可以获取）

10.Build.VERSION.SDK_INT SDK版本号（一般讲是与系统版本号一一对应的）示例：23