Android Test Station

Android Test Station とは、Android 互換性テストスイート（CTS）などの標準的な Android テストスイートを実行するためのユーザー インターフェースの実装に使用できる、Android デベロッパーやテスト エンジニア向けのテストツールです。Trade Federation（TF）のウェブ インターフェースとなり、最小限の設定でテストデバイスの CTS を簡単に実行し、継続的なテストを行えるようにします。

Android Test Station の設定

このセクションでは、Android Test Station のインストール方法と設定方法を説明します。

Android Test Station では、以下の場所にあるソースコードを使用します。

Android Test Station のインストール

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

CTS の要件については、source.android.com をご覧ください。

ATS については追加のハードウェア要件はありませんが、出発点として CTS ホスト要件を使用することを推奨します。

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

インストーラ プログラムを使ったインストール

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

次の手順に沿ってインストール プログラムを使用します。

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

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

  2. mtt version を実行して、Android Test Station CLI のバージョンを確認します。

手動でのインストール

Docker のインストール

  1. Linux マシンに Docker Community Edition（CE）をインストールする手順に従います。

  2. root 以外のユーザーが Docker を管理できるように、インストール後の手順を実施します。

  3. 権限の変更を有効にするには、ターミナル ウィンドウを再起動するか、いったんログアウトしてからログインし直す必要があります。

Python 3 のインストール

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 Test Station CLI の取得

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

Android Test Station の起動

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

mtt start

初めて UI を起動したときには、表示されるまでに数分かかることがあります。CLI にブラウザで UI にアクセスするためのウェブ URL が表示されます。デフォルトのウェブ 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 をインストールした後の初めての実行では、設定ウィザードで、環境に合わせてツールをカスタマイズする手順が案内されます。ここで行った変更は、後で [Settings] ページで変更できます。

構成バックアップの復元

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

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

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

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

Android Test Station がリソース（Google Cloud Storage、Google ドライブなど）にアクセスするときにデフォルトに使用するサービス アカウントを設定できます。サービス アカウントを認証するには、[Upload Service Account Key] をクリックして、サービス アカウントの JSON キーファイルを選択します。

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

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

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

サービス アカウントの変更

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

構成セットのインポート

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

Test Station ホストに追加する構成セットを選択し、[Import Selected] をクリックします。

構成セットのインポート

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

Wi-Fi 設定を含める

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

Wi-Fi 設定

図 5. Wi-Fi アクセス ポイントの設定。

設定ウィザードを完了すると、新しい設定を適用したページが読み込まれます。

デバイスの接続

デバイスをテストに使用するには、USB デバッグを有効にする必要があります。デバッグを有効にするには、以下の手順を実施します。

  1. 開発者向けオプションとデバッグの有効化の手順を実施します。

  2. カスタム ADB キーを使ってプリロードされたテスト Android ビルドを使用する場合は、カスタム .adb_key ファイルを ~/.android/ ディレクトリに置きます。

    このファイルは自動的に読み込まれて ADB に渡され、そのビルドを実行しているデバイスで書き込みが完了すると自動的に USB デバッグが有効になります。

  3. USB を使用してデバイスをホストマシンに接続します。

    ウェブ インターフェースを更新してから 1 分以内に、Android Test Station の [Devices] タブにデバイスが表示されます。このタブでデバイスの状態を確認することもできます。

    デバイスの接続

    図 6. デバイスの接続。

デバイスの状態には次のものがあります。

  • [Available] - デバイスは接続されており、テストの準備ができています。
  • [Allocated] - デバイスは接続されており、現在テストを実行しています。各デバイスは一度に 1 つのテストしか実行できないため、新しいテストを実行する前に現在のテストを完了する必要があります。

テストの実行

テストの選択

Android Test Station には、CTS の構成セットが同梱されています。このテストを実行するには、[Test Suites] タブに移動し、実行するテストの [Run test] をクリックします。

テストの選択

図 7. テストの選択。

テストの編集、または新規テストの追加を行う方法については、テストの追加をご覧ください。

テスト実行の構成

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

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

テスト実行の構成

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

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

  • [Name] - 実行するテストスイートの名前。
  • [Run Count] - スケジュールされた場合にこのテストを実行する回数。テスト実行は Trade Federation を使用してスケジュールされます。十分な能力があれば、最大 20 個のテストを並行して実行できます。
  • [Max Retry] - 1 つ以上のテストが失敗した場合にテスト実行を再試行する最大回数。通常、不安定なテストを扱う CTS のフル実行のため、4～6 回に設定します。
  • [Queue Timeout] - テスト実行が [Queued] 状態に長時間に留まっている場合には、自動的にキャンセルされます。ここには、キャンセルされるまでの時間を指定します。デフォルトは 24 時間です。

  • [Command] - テストスイートを実行するためのコマンド。ここには、追加のコマンドライン引数を入力できます。たとえば、次のようにして CTS 8.1 の特定のモジュールを実行します。

    cts-suite -m ShortModuleName

  • [Retry Command] - テストスイートを再試行するコマンド。ここでは、コマンドライン引数を追加できます。たとえば、CTS 8.1 の特定のモジュールのみを再試行するには、次のコマンドを使用します。

    cts --retry 0 -m ShortModuleName

    再試行の引数は、最初のコマンドで使用できるものと異なる場合があります。このため、選択したテストスイートの公式サイトでサポートされているパラメータを確認してください。

  • [Previous Test Run] - 以前のテストを再実行する場合に、次から選択します。

    • [Local] - 現在のホストで開始したテスト実行の場合は、テスト実行の詳細を表示したときのテスト実行 ID を入力します。

      Local、以前のテスト実行

      図 9. Local、以前のテスト実行。

    • [Remote] - 別のホストで開始したテスト実行の場合は、[Remote] を選択して [Upload Test Results File] をクリックし、ローカル ストレージのファイルを選択して、テスト結果ファイルをアップロードします。

      Remote、以前のテスト実行

      図 10. Remote、以前のテスト実行。

デバイスの選択

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

デバイスの選択

図 11. デバイスの選択。

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

product:bramble;product:bramble;product:bramble

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

  • build_id
  • device_serial
  • device_type
  • hostname
  • product
  • product_variant
  • sim_state

選択したデバイスはすべて、テスト実行を実行可能な [Available] 状態になっていなければなりません。テスト実行が始まるとすべてのデバイスが [Allocated] 状態になります。デバイスが使用可能になるのを待っているテスト実行は、その間 [Queued] 状態になります。

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

デバイス アクションとは、個々のテスト実行の前に実行できるスクリプトです。書き込みや再起動などの一部のデバイス アクションはあらかじめ設定されています。新しいデバイス アクションを作成するには、新しいデバイス アクションを作成するをご覧ください。

デバイス アクション

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

テスト実行にデバイス アクションを追加するには、[Add new action] をクリックし、追加するアクションのチェックボックスをオンにして、[Add Action(s)] をクリックします。デバイス アクションは順番に実行されます。ドラッグしてアクションの順番を変えることができます。

アクションを追加する

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

テストリソースの設定

テストリソースは、テストの実行に必要なファイルです。たとえば、CTS の実行には android-cts*.zip ファイルが必要で、デバイスの書き込みにはビルドイメージが必要です。

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

テストリソース

図 14. テストリソース。

次の例は、ウェブ URL でテストリソースを選択するポップアップ ウィンドウです。ダウンロード URL のリンクを入力し、[Select] ボタンをクリックして選択を確定します。

テストリソースの選択 - ウェブ URL

図 15. テストリソースの選択 - ウェブ URL。

Google ドライブ、Google Cloud Storage（GCS）などのチャンネルにリソースをアップロードしてある場合は、そのチャンネルのタブに移動してリソースを選択することもできます。次の例は、Google ドライブのリソースを選択する場合のものです。

テストリソースの選択 - Google ドライブ

図 16. テストリソースの選択 - Google ドライブ。

ファイルを選択するだけでなく、[Filename] フィールドにワイルドカード文字を使用することもできます。これに関するドキュメントはこちらで確認できます。

テストリソースの選択 - ワイルドカード パターンのサポート

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

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

テストリソースの選択 - ローカル ファイルストア

図 18. テストリソースの選択 - ローカル ファイルストア。

再実行構成の追加

最初の実行が完了してその結果が読み込まれた後で開始される再実行をスケジュールできます。再実行では、さまざまなデバイス、アクション、またはリソースを使用できます。

再実行構成の追加

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

テスト実行の開始

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

テスト実行の開始

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

テストプランの作成

テストプランは、定期的なスケジュールでテスト実行を作成するために使用します。たとえば、CTS 9.0 を毎日午後 5 時に実行するとします。新しいテストプランを作成するには、[Create a new test plan] をクリックします。

テストプランの作成

図 21. テストプランの作成。

テストプランの構成

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

  • [Manual] - このテストプランでは、ユーザーがテストプランのリストの [Run test plan] をクリックしたときのみ、テスト実行が作成されます。
  • [Periodic] - このテストプランでは、選択された定期的なスケジュールでテスト実行が自動的にスケジュールされます。たとえば、毎日午後 5 時にテストを実行するようにスケジュール設定します。
  • [Custom] - このテストプランでは、入力した cron 式に基づいてテスト実行を自動的にスケジュールします。たとえば、毎日午後 5 時にテスト実行のスケジュールを設定する場合、cron 式は 0 17 * * * になります。

テストプランの構成

図 22. テストプランの構成。

テストスイートの追加

[+ Add test run configuration] をクリックして、テストプランでスケジュール設定するテストスイートを追加します。[Name] プルダウンからテストスイートを選択し、[Next step] をクリックします。次に、テストを実行するデバイスを選択し、[Add Configuration] をクリックします。各テストプランに複数の構成を追加できます。

テスト実行の構成

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

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

個々のテスト実行の前に実行するデバイス アクションを追加します。詳しくは、デバイス アクションの追加をご覧ください。

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

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

テストリソースの設定

テストプランにテストリソースを追加する方法は、個々のテスト実行に追加する方法と同じです。詳細については、テストリソースの設定をご覧ください。

テストリソースの設定

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

テスト実行の表示

テスト実行の一覧

[Test Runs] ページで、スケジュールされたテスト実行の一覧を表示します。[View] をクリックすると、テスト実行の詳細が表示されます。

フィルタバーに文字列を入力してから Enter キーを押して、一覧をフィルタリングすることもできます。カンマで区切ると複数のフィルタを使用できます。フィルタにより、任意の列（[Status] と [Created] を除く）に完全一致するテキスト（部分文字列一致ではない）を含む行に絞り込まれます。

空のフィルタを指定すると、すべての行になります。現在のところ、空の値がある行に対してフィルタリングする方法はありません。

テスト実行の一覧

図 26. テスト実行の一覧。

テスト実行の詳細

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

テスト実行の詳細

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

テスト実行のステータス

[Status] セクションには、テスト実行の進行状況が表示されます。ダウンロードの進行状況、キャンセルの原因、エラー メッセージなど、関連するメッセージもここに表示されます。

テスト実行のステータス

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

テスト実行のステータスには次のものがあります。

  • [Pending] - 必要なリソースをダウンロードしています。
  • [Queued] - デバイスが使用可能になるとテストを実行できます。
  • [Running] - 割り当てられたデバイスでテストを実行しています。
  • [Completed] - テストが完了し、その結果が報告されました。
  • [Canceled] - ユーザーがテストをキャンセルしたか、使用可能なデバイスを探している間にタイムアウトしました。
  • [Error] - エラーが発生したため、テストを実行できませんでした。

テスト実行のキャンセル

テスト実行が完了していない場合は、[Cancel] をクリックし、確認ダイアログで [Yes] をクリックすると、テストをキャンセルできます。また、[Queued] 状態が queue_timeout_seconds フィールドよりも長く続いた場合も、テスト実行は自動的にキャンセルされます。[Running] 状態のテスト実行をキャンセルするには、数分かかることがあります。

テスト実行のキャンセル

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

テスト実行の結果

テスト実行が終了すると、結果が収集されて表示されます。各実行の矢印をクリックすると詳細を表示できます。[View Output Files] をクリックして、test_result.xml や test_result_failures.html など、収集されたテスト アーティファクトを表示します。

テスト実行の結果

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

ライブホストと Tradefed のログは、[Logs] タブに表示されます。

テスト実行のログ

図 31. [Logs] タブ。

個々のモジュールの結果は、[Test Results] タブで確認できます。

[Test Results] タブ

図 32. [Test Results] タブ。

テストリソースとして使用するファイルをダウンロードするには、[Test Resources] タブで [Open] をクリックします。

[Test Resources] タブ

図 33. [Test Resources] タブ。

[create_time] など、テスト実行の詳細を確認するには、[Config] タブに移動します。

テスト構成タブ

図 34. [Config] タブ。

上級者向け機能

構成ファイルの管理

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 のインスタンスを設定すると、ファイルとしてエクスポートすることにより、構成を他のユーザーと共有できます。それには、[Settings] ページの右上にある [Export] をクリックします。

構成ファイルの管理

図 35. 構成ファイルの管理。

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

新しいデバイス アクションの作成

デバイス アクションは、デバイスの設定プロセスの自動化に使用されます。アクションは、テストを実行しようとする各デバイスで、テスト実行の前（再試行前も含む）に実行されるスクリプトです。使用可能なデバイス アクションの一覧を表示するには、[Settings] ページに移動して、[Device Actions] タブをクリックします。再起動や書き込みなどの一部のデバイス アクションはあらかじめ構成されています。

[Device Actions] タブ

図 36. [Device Actions] タブ。

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

  1. [New device action] をクリックします。

    [New device action] ボタン

    図 37. [New device action] ボタン。

  2. 名前と説明を入力します。

    デバイス アクション名

    図 38. デバイス アクション名。

  3. [Add Target Preparer] をクリックします。

  4. Trade Federation ターゲット作成ツールの完全なクラス名（例: com.android.tradefed.targetprep.RunHostCommandTargetPreparer）を入力します。

    ターゲット作成ツールを追加する

    図 39. ターゲット作成ツールの追加。

    使用可能なターゲット作成ツールのリストについては、com.android.tradefed.targetprep リファレンスをご覧ください。

    ターゲット作成ツールのリスト

    図 40. ターゲット作成ツールのリスト。

  5. ターゲット作成ツールで使用するオプションを追加します。使用可能なオプションは、AOSP にある各ターゲット作成ツールのソースコードの targetprep で確認してください。

    アクション オプションの例

    図 41. アクション オプションの例。

  6. オプションを追加するには、[Add Target Preparer Options] をクリックし、必要な値を入力します。

    アクション コマンドの例

    図 42. アクション コマンドの例。

  7. デバイス アクションの実行に必要なテストリソース（たとえば、書き込むイメージの作成）を定義します。リソース定義を追加するには、[Add Test Resource] をクリックし、必須項目を入力します。ファイルの場所がわかっている場合は、[browse] をクリックしてデフォルトのダウンロード URL を指定できます。ターゲット作成ツールにテストリソースとしてディレクトリを指定できる場合は、[Decompres] を選択し、一時的な作業ディレクトリの下の相対パスで Destination ディレクトリを指定し、解凍する File Names を指定します。ファイル名を指定しない場合、テストリソースからすべてのファイルが解凍されます。

    アクションのテストリソース

    図 43. アクションのテストリソース。

  8. [更新] をクリックします。

    アクションの変更の保存

    図 44. アクションの変更の保存。

テストの管理

テストの編集

保存されているテストを編集するには、[Tests] ページに移動し、変更するテストの行で [Edit] をクリックします。テスト構成を変更したら、[Update] をクリックします。

テストの編集

図 45. テストの編集。

新しいテストの追加

新しいテストを追加するには、[Tests] ページに移動して、[Create a New Test] をクリックします。必要な情報を入力して [Create] をクリックします。

テストの作成

図 46. テストの作成。

テストのコピー

図 47. テストのコピー。

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

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

ホストの構成をエクスポートするには、[Settings] ページの右上にある [Export] をクリックします。

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

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

ホストの構成ファイルをインポートするには、[Settings] ページの右上にある [Import] をクリックします。

ホスト構成のインポート

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

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

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

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. マルチホスト モードのアーキテクチャ。

  1. ATS コントローラを起動するには、次のコマンドを使用します。

    mtt start --operation_mode=ON_PREMISE

  2. http://${CONTROLLER_HOSTNAME}:8000 でコントローラにアクセスできることを確認します。

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

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

ネットワークでホスト間の通信が許可されていない場合は、ATS ワーカーで下記のより高度な設定を行う必要があります。

  1. SSH トンネルを使用して 2 つのホストを接続します。プライマリ サーバーポートとファイル サーバーポートのポート（9000 と 9006 など）を選択します。

    ssh -L ATS_PORT:localhost:8000 -L FS_PORT:localhost:8006 CONTROLLER_HOSTNAME

  2. 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

ファイル クリーナー

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

ポリシー

ポリシーでは、ファイルやディレクトリに対して実行するオペレーションと、対象の選択条件を定義します。利用できるオペレーションは以下の表のとおりです。

オペレーションのタイプパラメータ
ARCHIVEremove_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. ファイル クリーナー設定の編集。

リセット

[Reset Settings] をクリックすると、ファイル クリーナー設定がデフォルトの状態に戻ります。このアクションを実行すると、カスタム項目がすべて消去されます。

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

図 55. ファイル クリーナー設定のリセット。

サポート

バグレポート

Android Test Station に関する問題や提案をお知らせいただくと、このツールを改善するための開発に役立ちます。ぜひご意見をお寄せください。最新のリリースについて詳しくは、ATS リリースノートをご覧ください。バグレポートや提案は、バグレポートの提出からお伝えください。 パートナーの方は、パートナー チャンネルを通じてお伝えください。