Androidテストステーション

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

AndroidTestStationのセットアップ

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

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

• AndroidTestStationのソースコード
• TradeFedクラスターのソースコード

AndroidTestStationのインストール

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

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

追加のハードウェア要件はありませんが、100GBのハードドライブの空き容量と8GBのメモリを備えたマシンを使用することをお勧めします。これは、テストスイートの複数の実行からの出力ファイルを保存するのに十分です。

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

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

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

Ubuntu 18.04以降では、インストーラープログラムが、AndroidTestStationの実行に必要なすべてのプログラムとリソースをインストールして構成します。

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

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

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

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

手動でインストールする

Dockerのインストール

1. LinuxマシンにDockerCommunityEdition（CE）をインストールするための指示に従います。

2. インストール後の手順に従って、Dockerをroot以外のユーザーとして管理します。

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

Python3.7のインストール

Android TestStationCLIにはPython3.7が必要です。

Ubuntu 16.04以前の場合、次のいずれかを実行して、最初にPython3.7のリポジトリを追加する必要があります。

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

  sudo add-apt-repository ppa:deadsnakes/ppa
  

• または、ソースからリポジトリをビルドしてインストールします

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

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

Android TestStationCLIの取得

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

AndroidTestStationの起動

次のコマンドでAndroidTestStationを起動します。

mtt start

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

構成バックアップの復元

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

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

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

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

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

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

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

構成セットのインポート

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

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

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

Wi-Fi設定を含む

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

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

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

デバイスの接続

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

1. 「開発者向けオプションとデバッグを有効にする」の手順に従います。

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

   これらのビルドを実行しているデバイスのデバイスがフラッシュされた後、ファイルは自動的にロードされ、ADBに渡されてUSBデバッグを自動有効にします。

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

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

   

   図6.デバイスの接続

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

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

テストの実行

テストの選択

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

図7.テストの選択

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

テスト実行の構成

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

この手順はデフォルト値を使用して完了することができますが、必要に応じて、 MaxRetryやCommandなどの任意のパラメーターを変更できます。

図8.テスト実行の構成

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

• 名前-実行するテストスイートの名前。
• 実行回数-スケジュールされたときにこのテスト実行を実行する必要がある回数。テストの実行は、通商連合を使用してスケジュールされます。通商連合は、容量がある場合、最大20回のテストを並行して実行します。
• 最大再試行-少なくとも1つのテストが失敗した場合に、テスト実行を再試行する最大回数。これは通常、不安定なテストを処理するための完全なCTS実行に対して4〜6回の再試行に設定されます。
• キュータイムアウト-テスト実行がキュー状態のままでいる時間が長すぎると、自動的にキャンセルされます。ここでキャンセルまでの待機時間を指定します。デフォルトは24時間です。

• コマンド-テストスイートを実行するためのコマンド。ここに追加のコマンドライン引数を入力できます。たとえば、CTS8.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

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

• build_id
• device_serial
• デバイスタイプ
• ホスト名
• 製品
• product_variant
• sim_state

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

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

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

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

デバイスアクションをテスト実行に追加するには、[新しいアクションの追加]をクリックし、追加するアクションのチェックボックスを選択して、[アクションの追加]をクリックします。デバイスアクションは順番に実行されます。アクションをドラッグして並べ替えることができます。

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

テストリソースの設定

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

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

図14.テストリソース

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

図15.テストリソースセレクター-WebURL

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

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

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

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

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

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

再実行構成の追加

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

図19.再実行構成の追加

テスト実行の開始

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

図20.テスト実行の開始

テスト計画の作成

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

図21.テスト計画の作成

テスト計画を構成する

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

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

図22.テスト計画の構成

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

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

図23.テスト実行の構成

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

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

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

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

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

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

テスト実行の表示

テスト実行リスト

[テスト実行]ページで、スケジュールされたテスト実行のリストを表示します。テスト実行の詳細を表示するには、[表示]をクリックします。

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

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

図26.テスト実行リスト

テスト実行の詳細

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

図27.テスト実行の詳細

テスト実行ステータス

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

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

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

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

テスト実行のキャンセル

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

図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.構成ファイルの管理

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

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

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

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

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

1. [新しいデバイスのアクション]をクリックします。

   

   図37.新しいデバイスアクションボタン

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

   

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

3. [ターゲット作成者の追加]をクリックします。

4. Trade Federation Target Preparerのフルクラス名を入力します（例： com.android.tradefed.targetprep.RunHostCommandTargetPreparer 。

   

   図39.ターゲット作成者の追加

   利用可能なターゲット作成者のリストは、 com.android.tradefed.targetprepリファレンスにあります。

   

   図40.ターゲット作成者リスト

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

   

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

6. オプションを追加するには、[ターゲット作成者オプションの追加]をクリックして、必要な値を入力します。

   

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

7. デバイスアクションを実行するために必要なテストリソースを定義します。たとえば、フラッシュ用のイメージを作成します。リソース定義を追加するには、[テストリソースの追加]をクリックして、必要なフィールドに入力します。ファイルの場所がわかっている場合は、[参照]をクリックしてデフォルトのダウンロードURLを指定できます。ターゲット作成者がディレクトリをテストリソースとして受け入れる場合は、[解凍]を選択します。次に、一時作業ディレクトリの下にある相対的な宛先ディレクトリと、解凍するファイル名を指定します。ファイル名が指定されていない場合、すべてのファイルがテストリソースから解凍されます。

   

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

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

   

   図44.変更を保存するアクション

テストの管理

テストの編集

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

図45.テストの編集

新しいテストを追加する

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

図46.テストの作成

図47.テストのコピー

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

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

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

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

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

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

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

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

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：8000でアクセス可能であることを確認してください。

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

   mtt start --control_server_url=http://controller.com: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=${DOCKER_GATEWAY_IP_ADDRESS}:ATS_PORT \
                   --control_file_server_url=${DOCKER_GATEWAY_IP_ADDRESS}:FS_PORT \
                   --operation_mode=ON_PREMISE
   

サポート

バグレポート

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