自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
Tradefed 中的裝置偵測
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
新裝置連線會觸發一系列非同步事件，這些事件不明顯，但值得瞭解。
已連線
Tradefed 會使用 ddmlib 程式庫 (Java adb 程式庫) 提供與 adb 和裝置的基本互動。這個解決方案的一部分是 IDeviceChangeListener 介面，可接收新的裝置事件，例如：
deviceConnected：adb 偵測到新裝置時deviceDisconnected：裝置不再回報至 adbdeviceChanged：發生重大裝置狀態 (例如裝置離線或裝置上線) 時
這些事件在 adb 層級就足以判斷裝置是否已連線、上線或離線。不過，對於測試輔助工具，我們需要更強大的狀態，以確保裝置確實已準備好開始執行測試；它不應受到新連線裝置可能帶來的潛在狀態不穩定情形影響。
以下是 Tradefed 中的事件順序：
- 裝置會被視為
deviceConnected，並開放 adb 的一般事件
系統會建立內部 Tradefed 事件，以便執行以下操作：
- 檢查裝置是否已知；Tradefed 會保留部分裝置的內部參照 (尤其是目前已指派並執行測試的裝置)，以免 TF 隨機遺失裝置。
- 檢查裝置是否為
ONLINE 或 OFFLINE。
如果裝置為：
OFFLINE：裝置會切換至 Tradefed CONNECTED_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，以便測試能繼續使用適當的參照。每次裝置斷開/重新連線時 (例如重新啟動時)，系統都會順暢地執行這項操作。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[null,null,["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Device detection in Tradefed\n\nA new device connection triggers a series of asynchronous events that are not\nobvious yet worth understanding.\n\nPhysically connected\n--------------------\n\nTradefed uses the `ddmlib` library (a Java `adb` library) to provide the basic\ninteraction with `adb` and devices. Part of this solution is the\n[IDeviceChangeListener interface](https://android.googlesource.com/platform/tools/base/+/refs/heads/android16-release/ddmlib/src/main/java/com/android/ddmlib/AndroidDebugBridge.java)\nthat allows reception of new device events, such as:\n\n- `deviceConnected`: When a new device is seen by `adb`\n- `deviceDisconnected`: When a device is not reporting to `adb` anymore\n- `deviceChanged`: When a major device state occurs (such as device offline or device online)\n\nThese events are enough at the `adb` level to decide whether or not a device is\nconnected, online, or offline. But for the test harness, we need a stronger\nstate than this to ensure a device is truly ready to start running tests; it\nshould not be impacted by potential state flakiness that can come with a newly\nconnected device.\n\nThis is the sequence of events in Tradefed:\n\n1. Device is recognized as `deviceConnected` and open to regular events from `adb`\n2. An internal Tradefed event is created that will:\n\n - Check if the device is known already; Tradefed keeps internal reference to some devices (especially the one current allocated and running tests) to avoid TF losing track of them randomly.\n - Check if the device is `ONLINE` or `OFFLINE`.\n3. If device is:\n\n - `OFFLINE`: Device will be switched to Tradefed `CONNECTED_OFFLINE`\n state, which doesn't allow the device to run tests yet. If the device is\n online later, it will go through the `ONLINE` cycle. If we receive a\n `deviceDisconnect` event, the device will simply be removed from the list.\n\n - `ONLINE` (as seen by adb): Device will be put in the state\n `CONNECTED_ONLINE` and will have its availability checked for test\n allocation: `checking_availability`.\n\n4. If `availability` check is successful, the device will be marked as\n available for test allocation; it will be able to run tests. If not, the\n device will be marked as `unavailable` for allocation and cannot receive any\n tests.\n\nAll of these states are reflected in the Tradefed console when listing the\ndevices via: `tf\u003e list devices`\n\nIt's important to note that when the device is currently allocated for a test,\nmost of the above will not occur and Tradefed will determine the device state\ninternally. So it's possible for a device to disappear from `adb devices` while\nstill being listed by Tradefed. That can happen when a test is rebooting the\ndevice for example.\n\nVirtual device connected with adb connect\n-----------------------------------------\n\nWhen a remote virtual device is created, Tradefed connects to it using `adb\nconnect`. This will usually trigger the device showing in `adb devices` as\n`\u003csome ip\u003e:\u003cport number\u003e` and will follow the same sequence as physically\nconnected devices.\n\nDevice tracking when a deviceConnected event occurs\n---------------------------------------------------\n\nWhen `deviceConnected` occurs, `ddmlib` creates a new reference\n[IDevice](https://android.googlesource.com/platform/tools/base/+/refs/heads/android16-release/ddmlib/src/main/java/com/android/ddmlib/IDevice.java)\nto track the newly connected device.\n\nTradefed uses that reference and wraps it in its own implementation of device\ninterface\n[ITestDevice](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/device_build_interfaces/com/android/tradefed/device/ITestDevice.java)\nto provide more advanced service. But the underlying IDevice is always the one\ncoming from `ddmlib`.\n\nThis means if a new device is connected, a new ITestDevice is created and\nassociated with the IDevice. When this happens during an invocation and the\nITestDevice is being used, the underlying IDevice is still replaced so\ntesting can proceed on the proper reference. This is done seamlessly each time a\ndevice is disconnected/reconnected (for example, during a reboot)."]]
