2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Tradefed でのデバイス検出
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
新しいデバイスを接続すると、一連の非同期的なイベントが起動します。これらのイベントは理解しづらいものの、理解しておくと役に立ちます。
物理的に接続した場合
Tradefed は、adb
およびデバイスとの基本的なインタラクションに ddmlib
ライブラリ(Java adb
ライブラリ)を使用します。このソリューションには、次のような新しいデバイス イベントの受信を可能にする IDeviceChangeListener インターフェースが使用されています。
deviceConnected
: 新しいデバイスが adb
によって検出されたときのイベント
deviceDisconnected
: デバイスがこれ以降 adb
にレポートを送信しなくなるときのイベント
deviceChanged
: デバイスの状態に重要な変化が発生したときのイベント(デバイスのオフラインやオンラインなど)
デバイスが接続中、オンライン、またはオフラインであるかを adb
レベルで判断するためには、上記のイベントで十分です。しかし、テストハーネスでは、デバイスでテストを確実に実行できるようにするために、これよりもさらに強力な状態が必要です。つまり、新しく接続するデバイスで発生する可能性がある不安定な状態に影響を受けないようにする必要があります。
Tradefed におけるイベントのシーケンスは次のとおりです。
- デバイスが
deviceConnected
として認識され、adb
からの通常のイベントを受け付けるようになります。
内部 Tradefed イベントが作成され、次のことを確認します。
- デバイスがすでに認識されているかどうか。Tradefed は、一部のデバイス(特に、現在割り当てられているテスト対象のデバイス)に対して内部参照を維持します。これは、TF がデバイスのトラッキングを突然失ってしまうことを防ぐために行われます。
- デバイスが
ONLINE
または OFFLINE
であるか。
次に、デバイスの状態に応じて以下を実行します。
OFFLINE
の場合: デバイスが Tradefed に対して CONNECTED_OFFLINE
状態に切り替わります。デバイスはまだテストを実行できません。その後、デバイスがオンラインになった場合は ONLINE
サイクルに進みます。deviceDisconnect
イベントを受信した場合、デバイスはリストから削除されます。
ONLINE
の場合(adb で表示): デバイスが CONNECTED_ONLINE
の状態となり、テスト割り当てに対してデバイスが使用可能であるかが確認されます(checking_availability
)。
availability
のチェックが成功すると、デバイスはテスト割り当てに対して使用可能な状態であるとマークされ、テストを実行できるようになります。チェックに失敗した場合、デバイスはテスト割り当てに対して unavailable
としてマークされ、テストを受信できません。
tf> list devices
でデバイスをリストする場合、上記のすべての状態が Tradefed コンソールに反映されます。
デバイスがテストに割り当てられている場合、上記のほとんどの状態は発生せず、Tradefed はデバイスの状態を内部で判別する点に注意してください。つまり、Tradefed によってデバイスがリストされている状態でも、そのデバイスが adb devices
で表示されなくなることがあります。この状況は、テストによってデバイスが再起動された場合などに発生します。
仮想デバイスが adb connect で接続されている場合
リモート仮想デバイスが作成されると、Tradefed は adb
connect
を使ってそのデバイスに接続します。これにより、通常はデバイスがトリガーされて <some ip>:<port number>
内に adb devices
として表示されるようになります。そして、物理的に接続されたデバイスと同じシーケンスが適用されます。
deviceConnected のイベントが発生した場合のデバイス トラッキング
deviceConnected
が発生した場合、ddmlib
が新しいリファレンスである IDevice を作成して、新しく接続されたデバイスをトラッキングします。
Tradefed はこのリファレンスを使用して、デバイス インターフェース ITestDevice の独自の実装にラップし、より高度なサービスを提供します。ただし、基盤となる IDevice は常に ddmlib
で作成されます。
つまり、新しいデバイスが接続されると新しい ITestDevice が作成され、IDevice に関連付けられます。これが呼び出し中に行われ、ITestDevice が使用されている場合でも、基盤となる IDevice は置き換えられ、正しいリファレンスでテストを続行できます。これは、デバイスが接続解除または再接続されるたび(再起動など)にシームレスに実行されます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],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)."]]