2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
デバイスシェル コマンド
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
VTS テストでは、シェルコマンドを使用して、ターゲット側のテストバイナリの実行、プロパティ、環境変数、システム情報の取得と設定、Android フレームワークの起動と停止を行います。VTS デバイスシェル コマンドの実行には、adb shell コマンドを使用することも、デバイスで動作している VTS シェルドライバ（推奨）を使用することもできます。
ADB シェルを使用する
テスト中に、USB ポートのシャットダウン、またはデバイスの再起動を必要とするテストでは、ADB シェルを使用する必要があります。これは、USB 接続が維持されないと VTS シェルドライバが使用できなくなるためです。ADB シェルは、Python テスト スクリプト内で AndroidDevice オブジェクトから呼び出せます。例:
- Android デバイス オブジェクトを取得します。
self.device = self.android_devices[0]
- 単一のシェルコマンドを発行します。
result = self.device.adb.shell(‘ls')
VTS シェルドライバを使用する
VTS シェルドライバは、デバイス上で実行され、シェルコマンドを実行するエージェント バイナリです。デフォルトでは、デバイスでドライバが動作している場合、VTS はシェルドライバを使用します。この方が adb
shell コマンドを使用するよりレイテンシが短くなるためです。
図 1. VTS シェルドライバ
VTS フレームワークはマルチデバイス テストをサポートし、各 Android デバイスはベースランナーの AndroidDevice オブジェクトとして表されます。デフォルトでは、VTS フレームワークは VTS エージェント バイナリと VTS シェルドライバ バイナリを各 Android デバイスに転送し、それらのデバイス上の VTS エージェントとの TCP 接続を確立します。
シェルコマンドを実行するために、ホスト側の Python スクリプトは、AndroidDevice オブジェクト内の ShellMirror オブジェクトに関数呼び出しを行います。ShellMirror オブジェクトはシェルコマンド テキストを protobuf メッセージにまとめて、（TCP チャネル経由で）Android デバイスの VTS エージェントに送信します。すると、デバイス上で実行されているエージェントは、Unix ソケットを使用してシェルコマンドを VTS シェルドライバに転送します。
VTS シェルドライバはシェルコマンドを受け取ると、デバイスシェルで nohup を使用してコマンドを実行し、ハングしないようにします。stdout、stderr、戻りコードが nohup から取得され、VTS エージェントに戻されます。最後に、エージェントはコマンドの結果を protobuf メッセージに入れてホストに返信します。
メリット
adb
shell ではなく VTS シェルドライバを使用するメリットは、次のとおりです。
- 信頼性: デフォルト設定で、VTS シェルドライバは
nohup を使用してコマンドを実行します。VTS テストは主に下位レベルの HAL テストとカーネルテストであるため、nohup により、シェルコマンドが実行中にハングしないようにします。
- パフォーマンス:
adb shell コマンドは、一部の結果（ディレクトリ内のファイルのリストなど）をキャッシュに保存しますが、テストバイナリの実行などのタスクを実行する際に接続のオーバーヘッドが発生します。VTS シェルドライバはテスト中にアクティブな接続を維持するため、オーバーヘッドは USB の通信だけです。Google によるテストでは、VTS シェルドライバを使用して、空の gtest バイナリを 100 回呼び出すコマンドを実行すると、adb shell を使用するよりも約 20% 高速になっています。VTS シェルの通信では広範囲でログが記録されるため、実際の差はより大きくなります。
- 状態の保持: VTS シェルドライバはターミナル名ごとにターミナル セッションを管理しています（デフォルトのターミナル名は default です）。あるターミナル セッションで設定された環境変数は、同じセッションの以降のコマンドでのみ使用できます。
- 拡張可能: VTS フレームワークとデバイス ドライバ間のシェルコマンドの通信では、将来、圧縮、リモート処理、暗号化などを可能にするため protobuf でラップされています。他のパフォーマンス改善方法としては、通信のオーバーヘッドが結果文字列の解析のオーバーヘッドよりも大きくなった場合に、デバイス側で結果を解析する方法などがあります。
デメリット
adb
shell ではなく VTS シェルドライバを使用するデメリットは、次のとおりです。
- 追加のバイナリ: VTS エージェント ファイルをデバイスに転送し、テストの実行後にクリーンアップする必要があります。
- アクティブな接続が必要: 意図的かどうかに関係なく、USB の切断、ポートのシャットダウン、デバイスのクラッシュなどにより、テスト中にホストとエージェント間の TCP 接続が失われた場合、VTS エージェントにシェルコマンドを送信できなくなります。
adb shell への自動切り替えがあっても、切断前のコマンドの結果と状態は不明です。
例
以下に、VTS ホスト側の Python テスト スクリプトでのシェルコマンドの使用例を示します。
- Android デバイス オブジェクトを取得します。
self.device = self.android_devices[0]
- 選択したデバイスのシェル オブジェクトを取得します。
self.shell = self.device.shell
- 単一のシェルコマンドを発行します。
results = self.shell.Execute(‘ls')
- シェルコマンドのリストを発行します。
results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])
コマンドの結果オブジェクト
シェルコマンドの実行からの戻りオブジェクトは、キーを stdouts、stderrs、return_codes とする辞書です。
与えられたシェルコマンドが単一の文字列かコマンド文字列のリストかにかかわらず、結果の辞書の各値は常にリストです。
コマンドのリストの戻りコードを確認するには、テスト スクリプトで複数のインデックスを確認する必要があります。例:
asserts.assertFalse(any(results[‘return_codes']), ‘some command failed.')
スクリプトで各コマンドのインデックスを個別にチェックすることもできます。
例:
asserts.assertEqual(results[‘return_codes'][0], 0, ‘first command failed')
asserts.assertEqual(results[‘return_codes'][1], 0, ‘second command failed')
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 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-07-27 UTC。"],[],[],null,["# Device shell commands\n\nDuring VTS testing, shell commands are used to execute a target-side test\nbinary, to get/set properties, environment variables, and system information,\nand to start/stop the Android framework. You can execute VTS device shell\ncommands using the `adb shell` command or the VTS shell driver\nrunning on the device (recommended).\n\nUse ADB shell\n-------------\n\nTests that require shutting down the USB port or rebooting the device during\ntesting must use ADB shell as the VTS shell driver is unavailable without a\npersistent USB connection. You can invoke ADB shell from the\n`AndroidDevice` object in the Python test script. Examples:\n\n- Get an Android device object: \n\n ```\n self.device = self.android_devices[0]\n ```\n- Issue a single shell command: \n\n ```\n result = self.device.adb.shell(‘ls')\n ```\n\nUse the VTS shell driver\n------------------------\n\nThe VTS shell driver is an agent binary that runs on the device and executes\nshell commands. By default, VTS uses the shell driver if the driver is running\non device because this method has less latency than using the `adb\nshell` command.\n\n**Figure 1.** VTS shell driver.\n\nThe VTS framework supports multi-device testing where each Android device\nis represented as an AndroidDevice object in base runner. By default, VTS\nframework pushes VTS agent and VTS shell driver binaries to each Android device\nand establishes TCP connections to the VTS agents on those devices.\n\nTo execute a shell command, the host-side Python script makes a function\ncall to the ShellMirror object inside AndroidDevice object. The ShellMirror\nobject packs the shell command texts into a\n[protobuf](https://developers.google.com/protocol-buffers/)\nmessage and sends it (via the TCP channel) to the VTS agent on the Android\ndevice. The agent running on device then forwards the shell command to VTS shell\ndriver via the Unix socket.\n\nWhen the VTS shell driver receives a shell command, it executes the command\nvia [nohup](https://en.wikipedia.org/wiki/Nohup) on\nthe device shell to prevent hanging. Stdout, stderr, and return code are then\nretrieved from `nohup` and sent back to VTS agent. Finally, the agent\nreplies to the host by wrapping the command result(s) into a\n`protobuf` message.\n\n### Advantages\n\nThe advantages of using the VTS shell driver instead of `adb\nshell` include:\n\n- **Reliability.** The VTS shell driver uses `nohup` to execute commands on default setting. As VTS tests are mostly lower level HAL and kernel tests, `nohup` ensures shell commands do not hang during execution.\n- **Performance** . While the `adb shell` command caches some results (such as listing files in a directory) it has a connection overhead when performing tasks such as executing a test binary. VTS shell driver maintains an active connection throughout the test so the only overhead is USB communication. In our testing, using VTS shell driver to execute a command with 100 calls to an empty gtest binary is about 20 percent faster than using `adb shell`; the actual difference is larger since VTS shell communication has extensive logging.\n- **State-keeping** . The VTS shell driver maintains a terminal session for each terminal name (default terminal name is *default*). Environment variables set in one terminal session are available only to subsequent commands in the same session.\n- **Extendable**. Shell command communications between VTS framework and device driver are wrapped in protobuf to enable potential compression, remoting, encryption, etc. in the future. Other possibilities for improving performance are also available, including device-side result parsing when the communication overhead becomes larger than result string parsing.\n\n### Disadvantages\n\nThe disadvantages of using the VTS shell driver instead of `adb\nshell` include:\n\n- **Additional binaries**. VTS agent files must be pushed to device and cleaned up after test execution.\n- **Requires active connection** . If the TCP connection between host and agent is lost during testing (due to USB disconnection, port shutdown, device crash, etc.) either intentionally or unintentionally, a shell command cannot be transmitted to the VTS agent. Even with automatic switching to `adb shell`, the result and state of the command before disconnection would be unknown.\n\n### Examples\n\nExamples of using shell commands in a VTS host-side Python test script:\n\n- Get an Android device object: \n\n ```\n self.device = self.android_devices[0]\n ```\n- Get an shell object for the selected device: \n\n ```\n self.shell = self.device.shell\n ```\n- Issue a single shell command: \n\n ```\n results = self.shell.Execute(‘ls')\n ```\n- Issue a list of shell commands: \n\n ```\n results = self.shell.Execute([‘cd /data/local/tmp', ‘ls'])\n ```\n\n### Command result object\n\nThe return object from shell command execution is a dictionary containing the\nkeys `stdouts`, `stderrs`, and `return_codes`.\nRegardless of whether the shell command is provided as a single string or a list\nof command strings, each value of the result dictionary is always a list.\n\nTo verify the return code of a list of commands, the test script must check\nthe indices. Example: \n\n```\nasserts.assertFalse(any(results[‘return_codes']), ‘some command failed.')\n```\n\nAlternatively, the script can check each command index individually.\nExample: \n\n```\nasserts.assertEqual(results[‘return_codes'][0], 0, ‘first command failed')\n\nasserts.assertEqual(results[‘return_codes'][1], 0, ‘second command failed')\n```"]]
