CTS に関するよくある質問

Android 互換性プログラムは、Android エコシステムについてのポジティブなフィードバックを維持するうえで重要な要素です。CTS は、スケールの互換性を確保するための主要なツールです。Android チームは、CTS ツールとテスト カバレッジを継続的に改善しています。テストケースを定期的に追加することで、互換性を有するデバイスの品質が大幅に改善されています。

一般的な質問

このセクションでは、CTS に関する一般的な質問について回答します。

CTS のテスト対象は何ですか？

CTS は、強く型付けされたサポート対象 Android API がすべて存在し、正常に動作するかテストします。また、アプリのライフサイクルやパフォーマンスなど、他の非 API システム動作についてもテストします。

CTS のライセンスはどのように供与されますか？

CTS は、大部分の Android で使用されている Apache Software License 2.0 に基づいてライセンス供与されます。

CTS でコーデックは検証されますか？

はい。必須のコーデックについては、すべて CTS で検証されます。

テストに関する質問

このセクションでは、CTS テストをより効率的に実行できるよう、テストに関するよくある質問に回答します。

CTS シャーディングと TF シャーディングの違いは何ですか？

CTS シャーディングと TF シャーディングは、異なるテスト インフラストラクチャのコードベースによる、まったく異なるテスト計画です。run コマンドは異なるバージョン間でも同一ですが、シャーディング結果の動作は異なります。CTS シャーディングでは、次のようにテスト対象デバイス（DUT）にテストケースが静的に割り当てられます。

TF シャーディングでは、次のように利用可能な DUT にテストケースが動的に割り当てられます。

複数の ABI をサポートするデバイスには何が求められますか？

デバイスは、サポートを要求する ABI モードごとに、すべての CTS テストと CTS 検証ツールテストに合格する必要があります。したがって、特定の ABI のアプリを実行する必要があります。複数の ABI に関するガイドラインは次のとおりです。

  • CTS と CTS 検証ツールについては、アーキテクチャごとに ARM と x86 のリリースが存在します。それぞれが 32 ビットモードまたは 64 ビットモードをサポートできます。
  • CTS テストでは、デバイスが ARM と x86 の両方をサポートしている場合は、ARM と x86 の両方の CTS テストをそれぞれ実行して合格する必要があります。

ABI での CDD 要件については、CDD 3.3.1. アプリケーション バイナリ インターフェースをご覧ください。

テストの実行時間を短縮するには、プライマリ ABI（64 ビットなど）でのみテストを実行すれば十分ですか？

いいえ。Android アプリは独自の 32 ビットまたは 64 ビットのランタイムで実行されます。実際のマシンコード、コードパス、状態は 32 ビットと 64 ビットで異なります。1 つのモードを省略すると、対象範囲がデバイス ABI の 50% のみに限定されます。

実行されていないとして報告されるテストケースが非常に多く存在するのはなぜですか？

[Not Executed] ではなく [Module Done] の数値を確認する必要があります。

以前のバージョンでは、CTS モジュールは、完了前に Module Done として積極的に報告されていました。したがって、一部のデバイスに問題がある場合でも、すべてのテストケースが完了していない状態で [Modules Done] の数値が報告されていました。新しいテストハーネスはより保守的であり、問題発生時に報告する [Not Executed] テストの数が増加しています。

次の場合において、完了したモジュール実行は直近に行われた呼び出しで Module Not Done（done="false"）として報告されます。

  • このモジュールのテスト実行は、デバイスの接続に関する問題によって中断されています。
  • このモジュールで想定されるテスト実行がすべて実施されたわけではありません。

  • 次のような追加のフィルタ オプションを使用して再試行（オプション -r/--retry を使用）しました。

    • --include-filter
    • --exclude-filter
    • -t/--test（再試行時にはまだサポートされていないオプション）
    • --retry-type failed
    • --subplan

これらのモジュールについて Module Done（done="true"）というステータスを取得するには、最新の呼び出しで以下の内容を再度試してください。

run retry --retry <session_id> for Android 9 and later versions

run cts --retry <session_id> for Android 8.1 and previous versions

実行した際に、ここまでに示したどの問題も発生しなかったモジュール（テストが残り 0 件の場合も含む）は、新しいレポートで [Module Done] としてマークされます。

例外

  • CtsNNAPITestCases には、args の Linux / OS 制限を原因とする既知の問題が存在します。モジュールは run cts -m CtsNNAPITestCases によって直接、個別に再実行できます。

企業のファイアウォールの背後で、テストの準備が失敗するのを回避するにはどうすればよいですか？

すべての自動テストスイートでは、実行時に CTS メディア ファイルまたはビジネス ロジック ファイルのダウンロードを試行します。多くの企業環境では、一般的にファイアウォールとプロキシが利用されているため、テストの準備が失敗します。以下の行を実行するか、（Ubuntu で）.profile に追加します。

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

セキュア エレメントを対象とする CTS には SIM カードが必要ですか？

テストに SIM カードが必要であるかどうかは、この機能がテストデバイスでサポートされているかどうかによって異なります。

  • モバイル ネットワーク事業者（携帯通信会社）によって配布される UICC（SIM カードなど）に格納されている、またはデバイスに埋め込まれているセキュア エレメントに Android アプリがアクセスすることをデバイスがサポートする必要がない場合は、android.hardware.secure_element HAL 要素を含まないように HIDL マニフェストを構成できます。この場合、android.se.omapi.SEService.getReaders() API は空のリストを報告し、CTS テストについては自動的に合格の判定がなされ、CTS に合格したとして報告されます。
  • モバイル ネットワーク事業者（携帯通信会社）によって配布される UICC（SIM カードなど）に格納されている、またはデバイスに埋め込まれているセキュア エレメントに Android アプリがアクセスすることをデバイスがサポートする必要がある場合は、セキュア エレメントを適切に実装してインハウスでテストする必要があります。セキュア エレメントの CTS テストでは、Android 9 で追加された android.se.omapi API パッケージが機能することを確認する CTS テストを準備する方法について概要を説明しています。また、CTS テストのカバレッジは最小限であるため、独自のテストを行うこともおすすめします。

セキュア エレメントを対象とする CTS に使用する SIM カードはどこで入手できますか？

ご希望の SIM ベンダーにお問い合わせください。

トークンのシャーディングについての CTS の実行中に、ロック画面に Orange の SIM カードが表示されるのはなぜですか？

SIM カードがロックされているため、テストケースが開始されません。トークンのシャーディングについて CTS を実行する前に、**SIM カードロック設定の [SIM カードをロック] を無効にしてください。