2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
シャーディングを設定する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、シャーディングを介してスイート モジュール(AndroidTest.xml
)を調整し、ラボでの連続実行中に最適な速度パフォーマンスを得る方法について説明します。各オプションの一般的な使用について、その根拠とともに説明します。
ラボでスイートを連続して実行する場合、全体の完了時間を短縮するために、スイートは通常複数のデバイス間でシャーディングされます。ハーネスは通常、各シャードの実行時間のバランスをとって全体的な完了時間(最後のシャードの終了時)を最小化しようとします。しかし一部のテストの性質上、必ずしも十分なイントロスペクションがあるとは限らず、モジュールのオーナーがなんらかの動作を調整する必要があります。
シャーディング可能かどうか
モジュール(AndroidTest.xml
)に <option name="not-shardable" value="true" />
というタグを付けて、シャーディング不可であることをハーネスに通知できます。
一般的なモジュールではハーネスでモジュールをシャーディングするのが正しい方法(デフォルトの動作)ですが、場合によっては、この動作をオーバーライドする必要があります。
モジュールをシャーディングすると、対象のデバイスごとに、準備(APK や push ファイルなどのインストール)が 1 回実行される可能性があります。モジュールの設定に時間やコストがかかり、テスト実行時に比べて複製に値しない場合は、モジュールに not-shardable のタグを付けます。
モジュールをシャーディングすると、すべてのテストケースが異なるデバイスで独立して実行される可能性があります。これは最初の項目に関連しています。テストの数が少ないと、一部のシャードでテストが 1 回しか実行されないか、まったく実行されないことがあり、準備のコストが割高になります。たとえば 1 つのテストケースに APK をインストールすることは、通常、価値がありません。
インストルメンテーション テスト: シャードの最大数
AndroidJUnitTest で実行されるインストルメンテーション テストでは、実際に APK をインストールして実行するまで、インストルメンテーションに含まれるテストの数がハーネスに対し明らかにされません。このようなオペレーションにはコストがかかり、スイートの全モジュール部分のシャーディング時に実行できません。
ハーネスがインストルメンテーション テストを過度にシャーディングし、空のシャードになる場合があります。5 つのテストがあるインストルメンテーション テストを 6 つのシャードにシャーディングした場合、1 つのテストを含むシャード 5 つと、テストを含まないシャード 1 つになります。これらのシャードがそれぞれ、コストがかかる APK のインストールを必要とします。
そのため、インストルメンテーション テスト APK のテスト数が少ない場合は、モジュールに <option name="not-shardable" value="true" />
のタグを付けることで、シャーディングする価値がないことをハーネスに通知できます。
AndroidJUnitTest
ランナーには、シャーディング可能な最大数を指定できる特別なオプション <option name="ajur-max-shard" value="5" />
があります。
これにより、呼び出しレベルでリクエストされるシャードの数に関係なく、インストルメンテーションをシャーディングできる最大回数を指定できます。デフォルトで、インストルメンテーションは、呼び出しでリクエストされたシャード数にシャーディングされます。
たとえば、インストルメンテーション テスト APK に含まれるテストケースが 2 つしかなくてもシャーディングを行う場合、ajur-max-shard
値を 2
にすると、空のシャードは作成されません。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Configure sharding\n\nThis page describes what is possible to tune for a suite module\n(`AndroidTest.xml`) via sharding and get the best speed performance during\ncontinuous execution in the lab. We will attempt to describe the options in a\ngeneric manner with the rationale for using each.\n\nWhen running continuously a suite in the lab, the suite is usually sharded\nacross several devices to reduce the overall completion time. The harness\ntypically attempts to balance the execution time of each shard to minimize the\noverall completion time (when the last shard finishes); but due to the nature of\nsome tests, we do not always have enough introspection and need the module owner\nto tune some behavior.\n\nShardable or not shardable?\n---------------------------\n\nIt is possible to tag a module (`AndroidTest.xml`) with\n`\u003coption name=\"not-shardable\" value=\"true\" /\u003e` to notify the harness that it\nshould not be sharded.\n\nIn a typical module, letting the harness shard your module\n(the default behavior) is the right thing to do. But in some cases, you might\nwant to override that behavior:\n\n- When the setup of your module is expensive:\n\nSharding a module results in the preparation (install APK, push file, etc.)\npossibly run once per device involved. If your module setup is long and\nexpensive and not worth being replicated compared to the test's runtime, you\nshould tag your module as not-shardable.\n\n- When the number of tests in your module is low:\n\nSharding a module results in all the test cases possibly executing independently\non different devices. This relates to the first point; if your number of tests\nis low, you might end up with a single test or no test in some shards, which\nwould make any preparation step quite expensive. Installing an APK for a single\ntest case is usually not worth it, for example.\n\nInstrumentation tests: Max number of shards?\n--------------------------------------------\n\nAn instrumentation test running through [AndroidJUnitTest](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/test_framework/com/android/tradefed/testtype/AndroidJUnitTest.java)\ndoes not expose to the harness how many tests are part of the instrumentation\nuntil we actually install and run the APK. These operations are costly and\ncannot be executed at sharding time for all the modules part of the suite.\n\nThe harness might over-shard the instrumentation test and end up with some\nempty shards; sharding an instrumentation test with five tests in six shards\nresults in five shards with one test and one shard with no tests. Each of these\nshards would require a costly APK installation.\n\nSo when the number of tests in the instrumentation test APK is low, tagging the\nmodule with `\u003coption name=\"not-shardable\" value=\"true\" /\u003e` would allow the\nharness to know sharding that module is not worth it.\n\nThe `AndroidJUnitTest` runner has a special option allowing it to specify the\nmax number of shards it is allowed to shard into:\n`\u003coption name=\"ajur-max-shard\" value=\"5\" /\u003e`.\n\nThis allows you to specify a maximum number of times the instrumentation can be\nsharded regardless of the number of shards requested at the invocation level. By\ndefault, the instrumentation will be sharded into the number of shards requested\nfor the invocation.\n\nFor example, if your instrumentation test APK contains only two test cases but\nyou still want to shard it, having a `ajur-max-shard` value of `2` would ensure\nyou are not creating empty shards."]]