Tradefed 中的设备检测

新设备连接会触发一系列异步事件，这些事件不好理解，但值得我们了解一下。

物理连接

Tradefed 使用 ddmlib 库（一个 Java adb 库）提供与 adb 和设备的基本交互。此解决方案的一部分是 IDeviceChangeListener 接口，该接口用于接收新设备事件，如：

  • deviceConnected：当 adb 看到新设备时
  • deviceDisconnected：当设备不再向 adb 报告时
  • deviceChanged：当出现主要设备状态时（如设备离线或设备在线）

这些事件在 adb 级别足以决定设备是处于已连接、在线还是离线状态。但对于自动化测试框架，我们需要一种比这更强大的状态来确保设备真正准备好开始运行测试；它不应受新连接的设备可能带来的潜在状态不稳定的影响。

下面是 Tradefed 中的事件序列：

  1. 设备被识别为 deviceConnected 并对 adb 中的常规事件开放

  2. 创建一个内部 Tradefed 事件，该事件将：

    • 检查设备是否已知；Tradefed 会保持对某些设备的内部引用（尤其是当前已分配且正在运行测试的设备），以避免 TF 随便地与它们失去联系。
    • 检查设备是处于 ONLINE 还是 OFFLINE 状态。

  3. 如果设备处于以下状态：

    • OFFLINE：设备将切换到 Tradefed CONNECTED_OFFLINE 状态，这种状态尚不允许设备运行测试。如果设备之后变为在线状态，它将经过 ONLINE 循环。如果我们收到 deviceDisconnect 事件，会直接从列表中移除该设备。

    • ONLINE（adb 所看到的状态）：系统会将设备置于 CONNECTED_ONLINE 状态，并检查其可用性以进行测试分配：checking_availability。

  4. 如果 availability 检查成功，会将设备标记为可用于测试分配，因此它将能够运行测试。否则，会将设备标记为 unavailable 进行分配，因此它无法接收任何测试。

通过 tf> list devices 列出相应设备时，所有这些状态都会反映在 Tradefed 控制台中。

务必注意，如果当前已分配设备来运行测试，那么上述大部分事件都不会发生，而是由 Tradefed 在内部确定设备状态。因此，有可能某个设备已从 adb devices 中消失，而仍由 Tradefed 列出。例如，当测试重新启动设备时，可能会发生这种情况。

通过“adb connect”连接的虚拟设备

创建远程虚拟设备后，Tradefed 将使用 adb connect 连接到该设备。这通常会触发以 <some ip>:<port number> 的形式显示在 adb devices 中的设备，并且将遵循与物理连接的设备相同的顺序。

发生 deviceConnected 事件时的设备跟踪

当发生 deviceConnected 时，ddmlib 会创建一个新的引用 IDevice 来跟踪新连接的设备。

Tradefed 使用该引用并将其封装在自己的设备接口 ITestDevice 实现中，以提供更高级的服务。但是，底层 IDevice 始终来自 ddmlib。

这意味着，如果连接了一个新设备，系统会创建一个新的 ITestDevice 并使其与 IDevice 相关联。如果在调用期间发生这种情况，并且正在使用该 ITestDevice，仍会替换底层 IDevice，以便可以基于正确的引用继续进行测试。每次设备断开连接/重新连接时（例如，在重新启动期间），都会顺畅地完成此操作。