このページは Cloud Translation API によって翻訳されました。

Android テストステーション,Android テストステーション

Android Test Station は、Android 開発者とテストエンジニアが、Android Compatibility Test Suite (CTS)などの標準 Android テストスイートを実行するためのユーザーインターフェイスを採用するために使用できるテストツールです。このツールはTrade Federation (TF)の Web インターフェイスとして機能し、最小限のセットアップで一連のテストデバイス上で CTS を簡単に実行できるだけでなく、継続的にテストを実行するスケジュールを確立することもできます。

Android テストステーションをセットアップする

このセクションでは、Android Test Station のインストールとセットアップの方法について説明します。

Android Test Station は、次の場所からのソースコードを使用します。

Android テストステーションのソースコード
TradeFed クラスターのソースコード

Android テストステーションをインストールする

実行するテストスイートのハードウェアおよびソフトウェア要件に従ってください。

CTS の要件は、 source.android.comにあります。

ATS には追加のハードウェア要件はありませんが、開始点としてCTS ホスト要件を使用することをお勧めします。

Android Test Station をインストールするには 2 つの方法があります。

インストーラープログラムを実行します。
手動でインストールします。これには、複数のプログラムとリソースをインストールする必要があります。

インストーラープログラムでインストールする

Ubuntu 20.04 以降では、インストーラープログラムによって、Android Test Station の実行に必要なすべてのプログラムとリソースがインストールされ、構成されます。

インストールプログラムを使用するには:

インストーラープログラムを実行します。

curl https://storage.googleapis.com/android-mtt.appspot.com/prod/install.sh | bash

mtt versionを実行して、インストールされている Android Test Station CLI のバージョンを確認します。

手動でインストールする

Dockerをインストールする

Linux マシンにDocker Community Edition (CE) をインストールする手順に従います。
インストール後の手順に従って、Docker を非 root ユーザーとして管理します。
権限の変更を有効にするには、ターミナルウィンドウを再起動するか、ログアウトしてから再度ログインする必要がある場合があります。

Python3をインストールする

Android Test Station CLI は、Python バージョン 3.7 ～ 3.10 に対して検証されています。

Ubuntu 16.04 以前の場合は、まず次のいずれかを実行して Python 3 のリポジトリを追加します。

次のコマンドを実行します。

sudo add-apt-repository ppa:deadsnakes/ppa

ソースからリポジトリを構築してインストールします。

Python 3 をインストールするには、次のコマンドを実行します。

sudo apt-get update
sudo apt install python3 python3-distutils

特定の Python 3 バージョン (たとえば、3.10) をインストールするには、代わりに次のコマンドを実行します:

sudo apt-get update
sudo apt install python3.10 python3.10-distutils

Android テストステーション CLI を入手する

ここからコマンドラインインターフェイス (CLI) パッケージをダウンロードします。

Android テストステーションを開始する

次のコマンドで Android Test Station を起動します。

mtt start

初めて UI を起動するときは、表示されるまでに数分かかる場合があります。 CLI は、ブラウザーの UI にアクセスするための Web URL を表示します。デフォルトでは、Web URL はlocalhost:8000です。必要に応じて、 --portフラグを使用して起動時にデフォルトのポートを変更できます。

新しいバージョンが利用可能な場合は、現在のバージョンに更新できます。最新のリリースについては、リリースノートを確認してください。

現在のバージョンに更新するには、次を実行します。

mtt start --force_update

アプリを停止するには、次を実行します。

mtt stop

他のコマンドのリストを表示するには、次を使用します。

mtt --help

データベースのバックアップと復元

ATS データベースをバックアップするには、アプリを停止し、次のコマンドを実行します。これにより、現在のデータベースがホームディレクトリ内のmtt-backup.tarという名前の TAR ファイルにバックアップされます。

docker run --rm --mount source=mtt-data,target=/data -v ~:/out ubuntu bash -c "cd /data && tar cvf /out/mtt-backup.tar ."

復元するには、アプリを起動する前に次のコマンドを実行します。

docker run --rm --mount source=mtt-data,target=/data -v ~:/out ubuntu bash -c "cd /data && tar xvf /out/mtt-backup.tar"

セットアップウィザード

Android Test Station を初めてインストールして実行すると、セットアップウィザードのいくつかの手順に従って、環境に合わせてツールをカスタマイズできます。ここで行った変更は、後で [設定] ページから再構成できます。

構成のバックアップを復元する

別の Android Test Station ホストからバックアップされた構成ファイルがある場合は、 [ファイルのアップロード]ボタンをクリックして、ファイルをアップロードして、そのホストから変更された構成をコピーできます。

設定のバックアップを復元する

図 1.構成バックアップの復元。

デフォルトのサービスアカウントを設定する

Android Test Station がリソース (Google Cloud Storage、Google Drive など) にアクセスするときにデフォルトで使用するサービスアカウントを設定できます。サービスアカウントを認証するには、 [サービスアカウントキーのアップロード]をクリックし、サービスアカウントの JSON キーファイルを選択します。

サービスアカウントの設定

図 2.サービスアカウントの設定。

サービスアカウントが正常に認証されると、アカウントの電子メールアドレスがページの右上隅に表示されます。サービスアカウントを変更するには、アカウント名をクリックし、現在のデフォルトアカウントを削除し、新しいサービスアカウントキーをアップロードします。

サービスアカウントを変更する

図 3.サービスアカウントの変更。

構成セットをインポートする

構成セットは、関連するデバイスアクションやビルドチャネルなど、テストスイートを実行するための構成のバンドルです。構成セットは、特定の Google Cloud Storage (GCS) バケットでホストされます。 Google アカウントで GCS ビルドチャネルを認証すると、利用可能なすべての構成セットのリストが表示されます。

Test Station ホストに追加する構成セットを選択し、 [選択したものをインポート]をクリックします。

構成セットのインポート

図 4.構成セットのインポート。

Wi-Fi設定を含める

一部の CTS テストでは、デバイスを Wi-Fi ホットスポットに接続する必要があります。 Wi-Fi ネットワークを選択するには、 WiFi SSIDとオプションのWiFi PSKを入力します。

Wi-Fi設定

図 5. Wi-Fi ホットスポットの設定。

セットアップウィザードが完了すると、新しい設定が適用された状態でページがリロードされます。

デバイスを接続する

デバイスをテストに使用するには、USB デバッグを有効にする必要があります。デバッグを有効にするには:

「開発者向けオプションとデバッグを有効にする」の手順に従ってください。
カスタム ADB キーがプリロードされたテスト Android ビルドを使用する場合は、カスタム.adb_keyファイルを~/.android/ディレクトリに置きます。
これらのビルドを実行しているデバイスに対してフラッシュされた後、ファイルは自動的にロードされ、ADB に渡されて、USB デバッグが自動的に有効になります。
注: Android デバッグ可能ビルドにカスタム ADB キーを追加するには、 PRODUCT_ADB_KEYSを追加する変更を参照してください。
USB を使用してデバイスをホストマシンに接続します。
Web インターフェイスを更新してから 1 分以内に、デバイスが [Android Test Station Devices] タブに表示されます。このタブではデバイスの状態を表示することもできます。
図 6.デバイスの接続。

さまざまなデバイスの状態は次のとおりです。

利用可能- デバイスは接続されており、テストを実行する準備ができています。
割り当て済み- デバイスは接続されており、現在テストを実行しています。各デバイスは一度に 1 つのテストのみを実行できるため、デバイスは新しいテストを実行する前に現在のテストを終了する必要があります。

テストを実行する

テストを選択してください

Android Test Station には、事前にバンドルされた CTS 構成のセットが付属しています。これらのテストのいずれかを実行するには、[テストスイート] タブに移動し、目的のテストの[テストの実行]をクリックします。

テストを選択してください

図 7.テストの選択。

新しいテストを編集または追加するには、「テストの追加」を参照してください。

テスト実行を構成する

この特定のテスト実行に使用するパラメータを編集します。ほとんどのパラメーターには、選択したテスト構成で定義された値が事前に設定されています。

このステップはデフォルト値を使用して完了できますが、必要に応じてMax RetryやCommandなどのパラメータを変更できます。

テスト実行の構成

図 8.テスト実行の構成。

テスト実行パラメータは次のとおりです。

名前- 実行するテストスイートの名前。
実行回数- スケジュールされたときにこのテスト実行を実行する必要がある回数。テスト実行はTrade Federationを使用してスケジュールされ、キャパシティがある場合は最大 20 個のテスト実行を並行して実行します。
最大再試行- 少なくとも 1 つのテストが失敗した場合にテスト実行を再試行する最大回数。通常、不安定なテストを処理するために、完全な CTS 実行の場合、これは 4 ～ 6 回の再試行に設定されます。
キュータイムアウト- テスト実行がキューに登録された状態に長時間留まると、テスト実行は自動的にキャンセルされます。ここでキャンセルまでの待ち時間を指定します。デフォルトは 24 時間です。
コマンド- テストスイートを実行するコマンド。ここに追加のコマンドライン引数を入力できます。たとえば、次のようにして CTS 8.1 で特定のモジュールを実行します。
```
cts-suite -m ShortModuleName
```
再試行コマンド- テストスイートを再試行するためのコマンド。ここで追加のコマンドライン引数を追加できます。たとえば、CTS 8.1 で特定のモジュールのみを再試行するには、次を使用します。
```
cts --retry 0 -m ShortModuleName
```
再試行引数は、最初のコマンドで使用可能な引数と異なる場合があるため、選択したテストスイートの公式サイトでサポートされているパラメータを確認してください。
前回のテスト実行- 以前のテスト実行を再実行したい場合:
- ローカル - 現在のホストで実行が開始された場合は、テスト実行の詳細を表示するときに表示されるテスト実行 ID を入力します。
  図 9.ローカルでの前回のテスト実行。
- リモート - 実行が別のホストで開始された場合は、 [リモート]を選択し、 [テスト結果ファイルのアップロード]をクリックして、ローカルストレージからファイルを選択してテスト結果ファイルをアップロードします。
  図 10.リモートでの前回のテスト実行。

デバイスの選択

チェックボックスをクリックして、テストスイートの実行に割り当てるデバイスを選択します。シャード数は、選択したデバイスの数に合わせて自動的に変更されます。

デバイスの選択

図 11.デバイスの選択。

デバイスのシリアル以外の属性でデバイスを選択するには、「デバイスの仕様」を手動で入力します。たとえば、製品名が「bramble」であるデバイスを 3 つ選択するには、次のように入力します。

product:bramble;product:bramble;product:bramble

サポートされている属性は次のとおりです。

ビルドID
デバイスシリアル
デバイスタイプ
ホスト名
製品
製品バリアント
sim_state

テスト実行を実行するには、選択したすべてのデバイスが「使用可能」状態である必要があり、テスト実行が実行されると、すべてのデバイスが「割り当て済み」状態に切り替わります。テスト実行は、デバイスが使用可能になるのを待機している間、 「キューに入った」状態になります。

デバイスアクションの追加

デバイスアクションは、各テストの実行前に実行できるスクリプトです。フラッシュや再起動など、一部のデバイスアクションはすでに構成されています。新しいデバイスアクションを作成するには、「新しいデバイスアクションを作成する」を参照してください。

デバイスのアクション

図 12.デバイスのアクション。

テスト実行にデバイスアクションを追加するには、 [新しいアクションの追加]をクリックし、追加するアクションのチェックボックスをオンにして、 [アクションの追加]をクリックします。デバイスのアクションは順番に実行されます。アクションをドラッグして順序を変更できます。

アクションの追加

図 13.アクションの並べ替え。

テストリソースを設定する

テストリソースは、テストの実行に必要なファイルです。たとえば、CTS を実行するにはandroid-cts*.zipファイルが必要で、デバイスをフラッシュするにはビルドイメージを提供する必要があります。

テストスイートの zip ファイルのダウンロード URL は、デフォルトでパートナーに提供される Google ドライブのリンクである必要があります。 [参照]をクリックすると、別のファイルを選択できます。ポップアップウィンドウで、ファイルのダウンロードリンクを入力したり、認証されたビルドチャネルからのファイルを使用したり、ローカルストレージから使用するファイルをアップロードしたりできます。

テストリソース

図 14.テストリソース。

以下は、Web URL でテストリソースを選択するためのポップアップウィンドウです。ダウンロード URL リンクを入力し、 [選択]ボタンをクリックして選択を確定するだけです。

テストリソースセレクター - Web URL

図 15.テストリソースセレクター - Web URL。

Google Grive、Google Cloud Storage (GCS)、またはその他のチャネルにリソースをアップロードしている場合は、特定のチャネルのタブに移動して、そこでリソースを選択することもできます。ここでは、Google ドライブからリソースを選択する例を示します。

テストリソースセレクター - Google ドライブ

図 16.テストリソースセレクター - Google ドライブ。

ファイルを選択するだけでなく、ファイル名フィールドではワイルドカード文字もサポートされています。ドキュメントはここにあります。

テストリソースセレクター - ワイルドカードパターンのサポート

図 17.テストリソースセレクター - ワイルドカードパターンのサポート。

Android Test Station のローカルファイルストレージからファイルを選択することもできます。ファイルをこのストレージにアップロードすることも、ローカルファイルやディレクトリを直接使用することもできます。

テストリソースセレクター - ローカルファイルストア

図 18.テストリソースセレクター - ローカルファイルストア。

再実行構成を追加する

プライマリ実行が完了してその結果をロードした後に開始する再実行をスケジュールできますが、別のデバイス、アクション、またはリソースを使用することもできます。

再実行構成の追加

図 19.再実行構成の追加。

テスト実行を開始する

テスト実行に必要な情報を入力したら、 「テスト実行の開始」をクリックします。すべての情報が有効な場合、テスト実行が開始され、テスト実行の詳細と進行状況を表示するページにリダイレクトされます。

テスト実行の開始

図 20.テスト実行の開始。

テスト計画を作成する

テスト計画は、定期的なスケジュールでテスト実行を作成するために使用されます。たとえば、毎日午後 5 時に CTS 9.0 を実行します。新しいテスト計画を作成するには、 [新しいテスト計画の作成]をクリックします。

テスト計画の作成

図 21.テスト計画の作成。

テスト計画を構成する

テスト計画の名前と追加するラベルを入力します。次に、使用するスケジュールを選択します。

手動- テスト計画は、ユーザーがテスト計画リストページで[テスト計画の実行]をクリックした場合にのみテスト実行を作成します。
定期- テスト計画は、選択した定期スケジュールに従ってテスト実行を自動的にスケジュールします。たとえば、毎日午後 5 時にテスト実行をスケジュールします。
カスタム- テスト計画は、入力されたcron 式に基づいてテスト実行を自動的にスケジュールします。たとえば、毎日午後 5 時にテスト実行をスケジュールするには、cron 式は0 17 * * *です。

テスト計画の構成

図 22.テスト計画の構成。

テストスイートを追加する

[+ テスト実行構成の追加]をクリックして、テスト計画によってスケジュールするテストスイートを追加します。 [名前]ドロップダウンからテストスイートを選択し、 [次のステップ]をクリックします。次に、テストを実行するデバイスを選択し、 [構成の追加]をクリックします。テスト計画ごとに複数の構成を追加できます。

テスト実行の構成

図 23.テスト実行の構成。

デバイスアクションの追加

各テストの実行前に実行するデバイスアクションを追加します。詳細については、「デバイスアクションの追加」を参照してください。

デバイスアクションの追加

図 24.デバイスアクションの追加。

テストリソースを設定する

テストリソースをテスト計画に追加することは、テストリソースを個々のテスト実行に追加することと同じです。詳細については、「テストリソースの設定」を参照してください。

テストリソースの設定

図 25.テストリソースの設定。

テスト実行の表示

試運転リスト

「テスト実行」ページで、スケジュールされたテスト実行のリストを表示します。 「表示」をクリックすると、テスト実行の詳細が表示されます。

フィルターバーに文字列を入力してEnterキーを押して、リストをフィルターすることもできます。カンマで区切ることで複数のフィルタを使用できます。このフィルターは、 StatusとCreatedを除く、任意の列に正確なテキスト (一致する部分文字列がない) を含むすべての行を返します。

空のフィルターはすべての行を返します。現在、空の値を含む行をフィルターする方法はありません。

テスト実行リスト

図 26.テスト実行リスト。

テスト実行の詳細

ここでは、ステータス、ログ、結果などのテスト実行の詳細を表示できます。

テスト実行の詳細

図 27.テスト実行の詳細。

試運転状況

テスト実行の進行状況は「ステータス」セクションに表示されます。ダウンロードの進行状況、キャンセルの理由、エラーメッセージなどの関連メッセージがある場合は、それもここに表示されます。

テスト実行ステータス

図 28.テスト実行ステータス。

テスト実行の状態は次のとおりです。

保留中- 必要なリソースをダウンロード中です。
キューに入れられています- デバイスが使用可能になったときにテストを実行する準備ができています。
実行中- テストは割り当てられたデバイスで実行されています。
完了- テストが完了し、結果が報告されました。
キャンセル- テストはユーザーによってキャンセルされたか、使用可能なデバイスを検索中にタイムアウトになりました。
エラー- テストの実行を妨げるエラーが発生しました。

テスト実行をキャンセルする

テスト実行が完了していない場合は、 「キャンセル」をクリックし、確認ダイアログで「はい」をクリックすることでテストをキャンセルできます。テスト実行がqueue_timeout_secondsフィールドよりも長くキューに登録された状態にある場合も、テスト実行は自動的にキャンセルされます。 「実行中」状態でテスト実行をキャンセルすると、有効になるまでに数分かかる場合があります。

テスト実行のキャンセル

図 29.テスト実行のキャンセル。

テスト実行結果

テスト実行が完了すると、結果が収集されて表示されます。各実行の矢印をクリックすると、追加の詳細を表示できます。 [出力ファイルの表示]をクリックして、収集されたテストアーティファクト ( test_result.xmlやtest_result_failures.htmlなど) を確認します。

テスト実行結果

図 30.テスト実行の結果。

[ログ] タブで、ライブホストと Tradefed のログを表示できます。

テスト実行ログ

図 31. 「ログ」タブ。

個々のモジュールの結果は、「テスト結果」タブに表示されます。

テスト結果タブ

図 32. 「テスト結果」タブ。

[テストリソース] タブの[開く]をクリックすると、テストリソースとして使用されるファイルをダウンロードできます。

「テストリソース」タブ

図 33. [テストリソース] タブ。

create_timeなどのテスト実行の詳細を確認するには、「構成」タブに移動します。

「テスト構成」タブ

図 34. [構成] タブ。

高度な機能

設定ファイルを管理する

Android Test Station は、 YAMLで記述された構成ファイルを使用して、テスト、ビルドチャネル、デバイスアクションなどの事前定義されたオプションを読み込みます。いくつかのオプションの構成ファイルの例を以下に示します。

// example_file.yaml
tests:
- id : android.cts.9_0.arm
  name: CTS 9.0 (ARM)
  test_resource_defs:
  - name: android-cts.zip
    default_download_url: https://dl.google.com/dl/android/cts/android-cts-9.0_r7-linux_x86-arm.zip
    test_resource_type: TEST_PACKAGE
  command: cts
  env_vars:
  - name: TF_PATH
    value: ${TF_WORK_DIR}/android-cts/tools:${TF_WORK_DIR}/android-cts/testcases
  - name: LD_LIBRARY_PATH
    value: ${TF_WORK_DIR}/android-cts/lib:${TF_WORK_DIR}/android-cts/lib64
  setup_scripts:
  output_file_patterns:
  - android-cts/logs/latest/.*
  - android-cts/results/latest/.*\.html
  - android-cts/results/latest/compatibility_result\..*
  - android-cts/results/latest/logo.png
  - android-cts/results/latest/test_result.xml
  result_file: test_result.xml
  java_properties:
  - name: CTS_ROOT
    value: ${TF_WORK_DIR}
  context_file_dir: android-cts/results/
  context_file_pattern: '[\d_\.]+\.zip'
  retry_command_line: retry --retry 0
  runner_sharding_args: --shard-count ${TF_SHARD_COUNT}

build_channels:
- id: google_drive
  name: Google Drive
  provider_name: Google Drive

device_actions:
- id: flash
  name: Flash
  test_resource_defs:
  - name: bootloader.img
    test_resource_type: DEVICE_IMAGE
  - name: radio.img
    test_resource_type: DEVICE_IMAGE
  - name: img.zip
    test_resource_type: DEVICE_IMAGE
  tradefed_target_preparers:
  - class_name: com.android.tradefed.targetprep.RunHostCommandTargetPreparer
    option_values:
    - name: work-dir
      values:
      - ${TF_WORK_DIR}
    - name: host-setup-command
      values:
      - adb -s $SERIAL reboot-bootloader
      - fastboot -s $SERIAL flash bootloader bootloader.img
      - fastboot -s $SERIAL flash radio radio.img
      - fastboot -s $SERIAL reboot-bootloader
      - fastboot -s $SERIAL -w update img.zip
      - adb -s $SERIAL wait-for-device
    - name: host-cmd-timeout
      values:
      - 10m

Android Test Station インスタンスをセットアップするとき、構成をファイルとしてエクスポートすることで、他のユーザーと共有できます。これを行うには、[設定] ページに移動し、右上の[エクスポート]をクリックします。

設定ファイルの管理

図 35.設定ファイルの管理。

構成ファイルをダウンロードしたら、そのファイルを他のユーザーと共有します。 [インポート]をクリックして構成ファイルを選択することで、構成ファイルを Android Test Station インスタンスに追加できます。

新しいデバイスアクションを作成する

デバイスアクションは、デバイスのセットアッププロセスを自動化するために使用されます。アクションは、再試行前を含む各テストの実行前に、テストが実行されている各デバイスで実行されるスクリプトです。利用可能なデバイスアクションのリストを表示するには、[設定] ページに移動し、[デバイスアクション] タブをクリックします。再起動やフラッシュなど、いくつかのデバイスアクションはすでに構成されています。

「デバイスアクション」タブ

図 36. [デバイスアクション] タブ。

新しいデバイスアクションを追加する

[新しいデバイスアクション]をクリックします。
図 37.新しいデバイスのアクションボタン。
名前と説明を入力します。
図 38.デバイスアクション名。
[ターゲット作成者の追加]をクリックします。
Trade Federation Target Preparer の完全なクラス名を入力します (例: com.android.tradefed.targetprep.RunHostCommandTargetPreparer )。
図 39.ターゲットプリペアラーの追加。
利用可能なターゲットプリペアラーのリストは、 com.android.tradefed.targetprepリファレンスにあります。
図 40.ターゲット作成者リスト。
ターゲットプリペアラーで使用するオプションを追加します。利用可能なオプションを表示するには、AOSP の各ターゲットプリペアラーのソースコードのtargetprepを確認します。
図 41.アクションオプションの例。
オプションを追加するには、 「ターゲット作成オプションの追加」をクリックし、必要な値を入力します。
図 42.アクションコマンドの例。
フラッシュ用のイメージのビルドなど、デバイスアクションの実行に必要なテストリソースを定義します。リソース定義を追加するには、 「テストリソースの追加」をクリックし、必須フィールドに入力します。ファイルの場所がわかっている場合は、 「参照」をクリックしてデフォルトのダウンロード URL を指定できます。ターゲットの準備者がディレクトリをテストリソースとして受け入れる場合は、 [解凍]を選択します。次に、一時作業ディレクトリの下の相対的な宛先ディレクトリと解凍するファイル名を指定します。ファイル名が指定されていない場合、すべてのファイルがテストリソースから解凍されます。
図 43.アクションテストのリソース。
「更新」をクリックします。
図 44.変更を保存するアクション。

テストを管理する

テストを編集する

保存したテストを編集するには、「テスト」ページに移動し、変更するテストの行で「編集」をクリックします。テスト構成を変更した後、 「更新」をクリックします。

テストを編集する

図 45.テストの編集。

新しいテストを追加する

新しいテストを追加するには、「テスト」ページに移動し、 「新しいテストの作成」をクリックします。適切な情報を入力し、 「作成」をクリックします。

テストを作成する

図 46.テストの作成。

テストをコピーする

図 47.テストのコピー。

ホスト構成のエクスポート

ホストを構成した後、ホストの構成をファイルにエクスポートできます。このファイルを他のホストにアップロードして、保存された構成をコピーできます。

ホストの構成をエクスポートするには、「設定」ページに移動し、右上隅にある「エクスポート」をクリックします。

ホスト構成のエクスポート

図 48.ホスト構成のエクスポート。

ホスト構成ファイルをインポートするには、「設定」ページに移動し、右上隅にある「インポート」をクリックします。

ホスト構成のインポート

図 49.ホスト構成のインポート。

ローカルのファイルとディレクトリを使用する

バージョン R11 以降では、Android Test Station で$HOME/.ats_storageディレクトリ内のファイルに自動的にアクセスできるようになります。ファイルをそのディレクトリにコピーまたは移動すると、テスト実行をスケジュールするときに[ローカルファイル]タブからそのファイルを選択できます。

cp /path/to/file $HOME/.ats_storage

ローカルファイルの選択

図 50. $HOME/.ats_storageディレクトリからのファイルの選択。

--mount_local_pathフラグを使用して、追加のディレクトリをローカルファイルストアにマウントできます。

mtt start --mount_local_path=/path/to/dir1 --mount_local_path=/path/to/dir2:renamed_dir2

追加のマウントされたディレクトリ

図 51.ローカルファイルストアにマウントされた追加のディレクトリ。

マルチホストモードを有効にする

マルチホストモードでは、ユーザーは単一の ATS コントローラーホストを使用して、複数の ATS ワーカーホスト上のデバイスとテストを管理できます。

マルチホストモードアーキテクチャ

図 52.マルチホストモードのアーキテクチャ。

ATS コントローラーを開始するには、次のコマンドを使用します。
```
mtt start --operation_mode=ON_PREMISE
```
コントローラがhttp://${CONTROLLER_HOSTNAME}:8000でアクセスできることを確認します。

ワーカーを開始するには、次のコマンドを使用します。

mtt start --control_server_url=http://CONTROLLER_HOSTNAME:8000 --operation_mode=ON_PREMISE

ネットワークでホスト間の通信が許可されていない場合は、ATS ワーカーで以下のより高度なセットアップ手順に従う必要があります。

SSH トンネルを使用して 2 つのホストを接続します。プライマリサーバーポートとファイルサーバーポートのポートを選択します (例: 9000 と 9006)。
```
ssh -L ATS_PORT:localhost:8000 -L FS_PORT:localhost:8006 CONTROLLER_HOSTNAME
```

ATS を設定して開始します。

DOCKER_GATEWAY_IP_ADDRESS=$(ip -4 addr show dev docker0 | grep -Eo 'inet [.0-9]+/' | grep -Eo '[.0-9]+')
socat tcp-listen:ATS_PORT,bind="${DOCKER_GATEWAY_IP_ADDRESS}",reuseaddr,fork tcp-connect:127.0.0.1:ATS_PORT &
socat tcp-listen:FS_PORT,bind="${DOCKER_GATEWAY_IP_ADDRESS}",reuseaddr,fork tcp-connect:127.0.0.1:FS_PORT &
mtt start --control_server_url=http://${DOCKER_GATEWAY_IP_ADDRESS}:ATS_PORT \
                --control_file_server_url=http://${DOCKER_GATEWAY_IP_ADDRESS}:FS_PORT \
                --operation_mode=ON_PREMISE

ファイルクリーナー

ファイルクリーナーは、ユーザー定義の構成に基づいてファイルをクリーンアップするために 1 時間ごとに実行される cron ジョブです。 ATS には、テスト実行結果をアーカイブするためと一時ファイルを削除するための 2 つのデフォルト構成があります。このガイドでは、ファイルを効果的に管理するためにポリシーと構成をカスタマイズする方法について説明します。

ポリシー

ポリシーは、ファイルまたはディレクトリに対して実行される操作と、ターゲットを選択する基準を定義します。利用可能な操作を表に示します。

操作の種類	パラメーター
`ARCHIVE`	`remove_file` : `true`の場合、アーカイブ後にファイルを削除します。
`DELETE`

基準はファイル属性とシステム情報に基づいています。利用可能な基準を表に示します。

基準の種類	説明	パラメーター
`LAST_MODIFIED_TIME`	最終変更日時に基づいてファイルをフィルタリングします。	`ttl` : `10m` 、 `2h` 、 `7 days` 、 `4w`など、さまざまな種類の時間表現がサポートされています。サポートされている形式については、 `pytimeparse`参照してください。
`LAST_ACCESS_TIME`	最終アクセス日時に基づいてファイルをフィルタリングします。	`LAST_MODIFIED_TIME`と同じ。
`NAME_MATCH`	正規表現を使用して、名前に基づいてファイルをフィルタリングします。	`pattern` : 正規表現。たとえば、 `[a-f0-9]{8}-([a-f0-9]{4}-){3}[a-f0-9]{12}\.zip`と一致します。結果のzip。
`SYSTEM_AVAILABLE_SPACE`	システム上の利用可能なスペースに基づいてアクションをトリガーします。	`threshold` : 利用可能なスペースがしきい値 (例: `200` (B)、 `200KB` 、 `200MB` 、 `200GB` 、 `2TB` ) を下回ったときにアクションをトリガーします。

新しいファイルクリーナーポリシー

図 53.新しいファイルクリーナーポリシーを追加します。

構成

構成は、1 つ以上のポリシーと特定のディレクトリを組み合わせます。指定されたディレクトリ内のファイルとディレクトリは、定義されたポリシーに基づいて処理されます。ポリシーは、構成内に表示される順序で適用されます。

すべてのターゲットディレクトリは/dataディレクトリの下に配置する必要があります。構成でターゲットディレクトリをlogsとして指定している場合、それは/data/logsとして解釈されます。

ファイルクリーナー構成を編集する

図 54.ファイルクリーナー構成を編集します。

リセット

「設定をリセット」をクリックすると、ファイルクリーナー構成がデフォルトの状態に戻ります。このアクションにより、すべてのカスタム項目がクリアされます。

ファイルクリーナーの設定をリセットする

図 55.ファイルクリーナー設定をリセットします。

サポート

バグレポート

Android Test Station へのあなたの貢献は、ツールの開発の改善に役立ちます。私たちはあなたの意見をお待ちしています。最新リリースの詳細については、ATS リリースノートを参照してください。バグを報告したり、提案を提供したりするには、バグレポートを提出してください。パートナーは、パートナーチャネルを通じてバグや提案を報告する必要があります。

Android テスト ステーション,Android テスト ステーション

Android テスト ステーションをセットアップする

Android テスト ステーションをインストールする

インストーラープログラムでインストールする

手動でインストールする

Dockerをインストールする

Python3をインストールする

Android テスト ステーション CLI を入手する

Android テスト ステーションを開始する

データベースのバックアップと復元

セットアップウィザード

構成のバックアップを復元する

デフォルトのサービスアカウントを設定する

構成セットをインポートする

Wi-Fi設定を含める

デバイスを接続する

テストを実行する

テストを選択してください

テスト実行を構成する

デバイスの選択

デバイスアクションの追加

テストリソースを設定する

再実行構成を追加する

テスト実行を開始する

テスト計画を作成する

テスト計画を構成する

テストスイートを追加する

デバイスアクションの追加

テストリソースを設定する

テスト実行の表示

試運転リスト

テスト実行の詳細

試運転状況

テスト実行をキャンセルする

テスト実行結果

高度な機能

設定ファイルを管理する

新しいデバイスアクションを作成する

新しいデバイスアクションを追加する

テストを管理する

テストを編集する

新しいテストを追加する

ホスト構成のエクスポート

ローカルのファイルとディレクトリを使用する

マルチホストモードを有効にする

ファイルクリーナー

ポリシー

構成

リセット

サポート

バグレポート

Android テストステーション,Android テストステーション

Android テストステーションをセットアップする

Android テストステーションをインストールする

Android テストステーション CLI を入手する

Android テストステーションを開始する