首先，我们先要弄清自己跟踪设备的具体需求。目前看来，需求无非两种：
1、跟踪用户设备使用周期层次上的设备：
意思是将每次用户的擦除设备、恢复出厂设置动作后将设备视为一台新的设备。
2、跟踪硬件层次上的设备：
意思是无论设备擦除数据或者恢复出厂设置后都需要将该设备视为同一台设备。

跟踪用户使用层次上的设备

方案 1:
这个层次上的设备跟踪，我比较推荐使用谷歌官方推荐的办法来跟踪， App 首次启动时生成一个 Random UUID 并保存在本地存储，以后每次启动时检查该 UUID 文件。具体可以查看我的上一篇翻译文章)，其中有具体的代码实现。

方案 2:
如果你不喜欢谷歌推荐的这种方式，或者觉得这种方式涉及到文件读写太过繁琐等。我们也可以通过以上介绍的这些标识符来跟踪设备。因为需要将设备擦除数据或恢复出厂设置后将其视为一台新的设备，所以需要使用一些与当前用户设备使用周期有关的值。

理论上，Android_ID 这一个值就已经足够我们实现这样的需求，不过正是因为 Android_ID 存在缺陷，所以我们无法直接拿来识别设备。这里我们使用多个值拼凑来规避这些缺点。

与用户设备使用周期有关的标识符我推荐使用Android_ID和Sim Serial Number。另外可以加上Device_ID，通过 UUID 或者 MD5 等来计算生成设备的标识符。

跟踪硬件层次上的设备

跟踪硬件层次上的设备建议使用硬件的标识符，比如设备ID(DeviceId)、Mac 地址、设备序列号（SN）或者设备的品牌，型号名等，这些值在用户擦除数据或者恢复出厂设置后也不会改变。同样的，为了提升稳定性及排除单一标识符所存在的缺陷，我们使用多个标识符拼接，然后通过 UUID 或者 MD5 算法计算得出我们需要的设备标识符。

其他

以上这些值在使用前都建议判空。

因为硬件缺失或者不可用，获取标识符过程中也可能返回 null 对象。为了避免 NullPointerException，建议获取标识符操作全部在 try...catch 中操作。

安卓设备的用户不乏极客，修改 Android_ID 或者 Build 文件对他们来说并非难题。所以一定程度上说，没有绝对准确的跟踪设备的标识符。