デバイスシェルコマンド

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')

デバイスシェル コマンド