移动安全新“驾照”

一、背景

随着大数据和人工智能时代的到来，数据的价值也逐渐增加，移动终端设备标识码，如国际移动设备识别码（IMEI）、Wi-Fi MAC地址、SIM卡国际移动用户识别码（IMSI）和蓝牙地址等终端设备标识信息的收集和使用成为普遍现象。

但是，Android 10新系统给IMEI等传统设备标识码的使用带来了挑战。根据Google的官方发布信息，Android 10系统新增了防止设备追踪的特性，即Android 10不允许一般应用访问IMEI码、序列号等不可重置的设备识别号。当应用连接至WiFi时，设备的Mac地址将默认被随机化处理。如此一来，传统设备标识码（如IMEI）将无法继续在Android 10系统的设备上使用。

为更好的适配Android 10系统，近期小编所在的项目产品接入了移动安全联盟（MSA）推广的统一的OAID SDK，下面将简单的介绍下OAID及该SDK的测试总结。

二、OAID介绍

移动安全联盟（MSA）等联合制定的联盟标准《移动智能终端补充设备标识体系规范》中，为保护用户的隐私和标识设备的唯一性，根据不同使用对象和不同用途，基于移动智能终端设备，生成如下补充设备标识体系。

匿名设备标识符（OAID）是可以连接所有应用数据的标识符，移动智能终端系统首次启动后立即生成，协助移动应用开发者更便捷的访问移动智能终端补充设备标识体系，推进相关业务（eg.广告业务）。

当前，根据“移动智能终端补充设备标识体系”技术要求，华为、小米、OPPO、vivo、中兴、努比亚、魅族、联想、三星等设备厂商均将逐步实现本标识体系，联盟计划开发并发布支持多厂商的统一的补充设备标识调用SDK，协助移动应用推进相关业务。（目前补充设备标识统一调用SDK处于开放试用阶段，可注册后下载使用）

三、OAID测试总结

近期小编所在项目的适配Android 10系统的版本中，接入了统一的OAID SDK，下面将简单介绍在OAID SDK测试过程中的主要关（踩）注（的）点（坑）。

• 测试关注点

1. 功能测试

• OAID SDK的调用时机

可通过log的方式验证，根据适配结果可以发现，支持的厂商设备在首次冷启动应用时调用SDK，不支持的厂商设备在每次冷启动时均会调用。

• OAID的获取时机

可通过log或者抓请求的方式验证，在实际测试中发现，由于不同的设备，数据的获取可能在异步线程，OAID数据的获取时机就可能会有一定的延迟。

• OAID的本地存储方式

具体取决于各应用的开发实现方案，一般可通过log验证逻辑。

• OAID的本地读写

具体取决于各应用的开发实现方案，一般可通过log验证逻辑，并利用root手机查看本地数据。

• OAID作为请求中新增字段的容错测试

可通过不同厂商设备验证获取的OAID数据的长度、格式、空值的情况，例如华为厂商的OAID为36位字符，小米厂商的OAID为16位字符，vivo厂商的OAID为64位字符，三星魅族等为空值；其他的容错case场景可通过开发协助验证，另外，需要关注的是发灰阶段有无相关崩溃异常数据。

• 新增OAID字段的请求功能范围

除了需要验证开发给出的覆盖范围，测试还需要站在整体产品的角度思考范围的合理性，如埋点请求的覆盖、重要功能请求的覆盖、第三方SDK的兼容、后续OAID添加的可扩展性、配合端对OAID字段的处理等等。

2. 兼容性测试

• 主流厂商各系统机型的适配测试

根据移动安全联盟（MSA）官网说明，当前SDK支持的厂商及版本计划如下所示。

3. 性能测试

一般来说，应用都会在安装后首次启动就可获取到OAID，也就是说SDK的初始化时机是在应用冷启动。在实际测试过程中，可能需要关注OAID SDK的初始化对应用冷启动过程中其他已有行为的影响，例如，数据读写时机、其他第三方SDK或者第三方库的调用时机等等。

举个栗子：

小编所在的项目中，首次冷启动中需要考虑内核的加载时机，但是在接入OAID SDK后，发现一个引入的问题，即首次冷启动内核加载失败。原因是OAID SDK的初始化时机在内核初始化之前，而且还会调用内核的方法，导致内核的初始化被中断，内核加载不成功。

• 测试总结

在项目实际测试中，虽然OAID SDK的功能点较小，但是从中小编吸取了两个方面的经验教训，在此分享共勉，抛砖引玉。

• 在接入第三方技术时，测试前要做好充分的调研准备。比如本次的OAID SDK，不仅要了解其背景、原理，还要考虑兼容适配的调研，如此也引申出一个工作方法，知己知彼百战不殆，前期的思考及准备越充分，工作的执行效率才有可能提升；
• 多思多沟通。比如本次的新SDK的引入对冷启动过程中其他逻辑的影响，可以通过及时的组内信息沟通同步来实现风险前移。