前言
udid:
UDID是Unique Device Identifier的缩写,中文意思是设备唯一标识.
uuid:
UUID是Universally Unique Identifier的缩写,中文意思是通用唯一识别码.
简言之：udid对应某个硬件设备，一个硬件设备的唯一标识。而uuid除了表达硬件的唯一标识，还能用来标识软件的标识，比如手机上不同的app的UUID是互斥的
android设备怎么获得udid呢？
这里面，我们主要目的是想获得一台android设备对一个的一个唯一的标识码，即udid.
对于Android平台而言，没有稳定的API可以让开发者获取到这样的设备ID。
开发者通常会遇到这样的困境：随着项目的演进， 越来越多的地方需要用到设备ID；然而随着Android版本的升级，获取设备ID却越来越难了。
加上Android平台碎片化的问题，获取设备ID之路，可以说是步履维艰。
获取设备标识的API屈指可数，而且都或多或少有一些问题。
android设备id通常有以下几种（但是不一定唯一，刷机后可能就变了）
1. IMEI
IMEI本该最理想的设备ID，具备唯一性，恢复出厂设置不会变化（真正的设备相关），可通过拨打*#06# 查询手机的imei码。
然而，获取IMEI需要 READ_PHONE_STATE 权限，估计大家也知道这个权限有多麻烦了。
尤其是Android 6.0以后, 这类权限要动态申请，很多用户可能会选择拒绝授权。我们看到，有的APP不授权这个权限就无法使用， 这可能会降低用户对APP的好感度。
而且，Android 10.0 将彻底禁止第三方应用获取设备的IMEI（即使申请了 READ_PHONE_STATE 权限）。所以，如果是新APP，不建议用IMEI作为设备标识；
如果已经用IMEI作为标识，要赶紧做兼容工作了，尤其是做新设备标识和IMEI的映射。
2. 设备序列号(SN号)
在Android 7.1或更早系统（SDK<=25），java可通过android.os.Build.SERIAL获得，由厂商提供。
如果厂商比较规范的话，设备序列号+Build.MANUFACTURER应该能唯一标识设备。但现实是并非所有厂商都按规范来，尤其是早期的设备。
最致命的是，Android 8.0及 以上（SDK>=26），android.os.Build.SERIAL 总返回 “unknown”；若要获取序列号，可调用Build.getSerial() ，但是需要申请 READ_PHONE_STATE 权限。
到了Android 10.0（SDK>=29）以上，则和IMEI一样，也被禁止获取了。
android ndk获取sn号方法：
//读取序号 __system_property_get("ro.serialno",m_szDevID); LOGE("%s", m_szDevID);
3. MAC地址
大多android设备都有wifi模块，因此，wifi模块的MAC地址就可以作为设备标识。基于隐私考虑，官方不建议获取
获取MAC地址也是越来越困难了，Android 6.0以后通过 WifiManager 获取到的mac将是固定的：02:00:00:00:00:00
7.0之后读取 /sys/class/net/wlan0/address 也获取不到了（小米6）。
4. ANDROID_ID
Android ID 是获取门槛最低的，不需要任何权限，64bit 的取值范围，唯一性算是很好的了。
但是不足之处也很明显：
1、刷机、root、恢复出厂设置等会使得 Android ID 改变；
2、Android 8.0之后，Android ID的规则发生了变化：
对于升级到8.0之前安装的应用，ANDROID_ID会保持不变。如果卸载后重新安装的话，ANDROID_ID将会改变。
对于安装在8.0系统的应用来说，ANDROID_ID根据应用签名和用户的不同而不同。ANDROID_ID的唯一决定于应用签名、用户和设备三者的组合。
两个规则导致的结果就是：
第一，如果用户安装APP设备是8.0以下，后来卸载了，升级到8.0之后又重装了应用，Android ID不一样；
第二，不同签名的APP，获取到的Android ID不一样。
其中第二点可能对于广告联盟之类的有所影响（如果彼此是用Android ID对比数据的话），所以Google文档中说“请使用Advertising ID”，
不过大家都知道，Google的服务在国内用不了。
对Android ID做了约束，对隐私保护起到一定作用，并且用来做APP自己的活跃统计也还是没有问题的。
总结
目前用到的还是以sn号和mac地址为主，还有的会用soc号作为android设备的udid
