最近在做一个OA考勤项目，里面有个需求是一个账号只允许绑定一台设备， 这就需要将设备唯一标识码与账号绑定在一起，咋一听 这还不So Easy啊，直接获取deviceID 不就好了。。。
成都创新互联公司成立十多年来，这条路我们正越走越好，积累了技术与客户资源，形成了良好的口碑。为客户提供成都网站设计、网站建设、网站策划、网页设计、主机域名、网络营销、VI设计、网站改版、漏洞修补等服务。网站是否美观、功能强大、用户体验好、性价比高、打开快等等，这些对于网站建设都非常重要，成都创新互联公司通过对建站技术性的掌握、对创意设计的研究为客户提供一站式互联网解决方案，携手广大客户，共同发展进步。
咋一操作也挺好。 可到了大面积的群体用户测试环节发现了几个问题。
简言之就是如果你的手机需要考虑Android9以上的设备，你就没办法通过获取系统提供的API完全的获取到设备唯一标识码，根据Android文档 唯一标识符最佳做法 你也许可以这样....
呃.... 这个特殊运营商许可 和这个 READ_PRIVILEGED_PHONE_STATE 好像都不是我们一般的安卓应用能获取的到的。
想要能Android9以上又能不受到刷机，格式化的影响。 就只能 使用移动安全联盟（MSA）提出的补充设备标识
是由 移动安全联盟 提出的，包含以下三个标识：
缺点就是：并不是所有的品牌商都兼容了， 而且需要导入他们对应的包 。 这部分可参考 Android 10获取设备标识方案探究 这篇文章
特点： 如果格式化或者刷机，这个设备ID会更改(这个也是合理的)。
完善：可以在第一次生成后放入到内部存储和外部存储，下次进入先从内部存储获取，如果没有在去外部存储比较（App卸载，内部存储就没了）。 如果在没有就生成一个
获取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
最近，因公司产品及客户需要，领导让我研究免存储设备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
11.Build.SUPPORTED_32_BIT_ABIS 支持32位ABIs的列表（数值）示例：[armeabi-v7a,armeabi]
12.Build.SUPPORTED_64_BIT_ABIS 支持64位ABIs的列表（数值）示例：[arm64-v8a]
13.Build.BOOTLOADER 系统启动程序版本号 示例：unknown
14.Build.VERSION.RELEASE 用户可见版本 示例： 6.0
16.Build.BOARD 主板 示例：FRD-AL00
17.Build.BRAND 系统定制商 示例：honor
21.Build.HOST 示例：huawei-RH2288H-V2-12L
23.Build.MANUFACTURER 产品/硬件的制造商 示例：HUAWEI
25.Build.PRODUCT 产品的名称 示例：FRD-AL00
26.Build.TAGS 描述Build的标签（Comma-separated tags describing the build, like "unsigned,debug".） 示例：release-keys
28.Build.USER 描述Build的USER 示例：jslave
31.Build.VERSION.BASE_OS 基带版本 The base OS build the product is based on. 示例：空值
32.自定义字符串或自定义数组
