一个新的设备连接会触发一系列不明显但值得理解的异步事件。
物理连接
Tradefed 使用ddmlib
库(Java adb
库)提供与adb
和设备的基本交互。该解决方案的一部分是允许接收新设备事件的IDeviceChangeListener 接口,例如:
-
deviceConnected
:当adb
看到新设备时 deviceDisconnected
:当设备不再向adb
报告时deviceChanged
:当设备发生主要状态时(例如设备离线或设备在线)
这些事件在adb
级别足以决定设备是否已连接、在线或离线。但是对于测试工具,我们需要一个比这更强大的状态来确保设备真正准备好开始运行测试;它不应受到新连接设备可能带来的潜在状态不稳定的影响。
这是 Tradefed 中的事件顺序:
- 设备被识别为
deviceConnected
并对来自adb
的常规事件开放 将创建一个内部 Tradefed 事件,该事件将:
- 检查设备是否已知; Tradefed 保留对某些设备的内部引用(尤其是当前分配和运行的测试),以避免 TF 随机丢失对它们的跟踪。
- 检查设备是
ONLINE
还是OFFLINE
。
如果设备是:
OFFLINE
: 设备将切换到 TradefedCONNECTED_OFFLINE
状态,这还不允许设备运行测试。如果设备稍后在线,它将进入ONLINE
周期。如果我们收到deviceDisconnect
事件,该设备将简单地从列表中删除。ONLINE
(如 adb 所见):设备将置于状态CONNECTED_ONLINE
并将检查其可用性以进行测试分配:checking_availability
。
如果
availability
检查成功,设备将被标记为可用于测试分配;它将能够运行测试。否则,该设备将被标记为unavailable
分配,并且无法接收任何测试。
通过以下方式列出设备时,所有这些状态都会反映在 Tradefed 控制台中: tf> list devices
需要注意的是,当设备当前被分配用于测试时,上述大部分情况都不会发生,Tradefed 将在内部确定设备状态。因此,设备可能会从adb devices
中消失,同时仍被 Tradefed 列出。例如,当测试重新启动设备时,可能会发生这种情况。
通过“adb connect”连接的虚拟设备
创建远程虚拟设备后,Tradefed 使用adb connect
连接到它。这通常会触发在adb devices
中显示为<some ip>:<port number>
的设备,并将遵循与物理连接设备相同的顺序。
发生deviceConnected
事件时的设备跟踪
当deviceConnected
发生时, ddmlib
创建一个新的引用IDevice来跟踪新连接的设备。
Tradefed 使用该引用并将其包装在自己的设备接口ITestDevice实现中,以提供更高级的服务。但底层的 IDevice 始终是来自ddmlib
的那个。
这意味着如果连接了新设备,则会创建一个新的 ITestDevice 并将其与 IDevice 关联。如果在调用期间发生这种情况并且正在使用 ITestDevice,则仍会替换底层 IDevice,因此可以在正确的引用上继续进行测试。每次断开/重新连接设备(例如,在重新启动期间)时,都会无缝完成此操作。