Android Test Station はマルチホスト モードをサポートしています。このモードでは、単一の ATS コントローラ ホストを使用して、複数の ATS ワーカーホストのデバイスとテストを管理できます。
エミュレータの継続的な実行
開発フェーズ中に CTS を継続的に実行するには、ハードウェアの代わりに Android Virtual Device（AVD）を使用します。テスト失敗の回帰を早期に特定できるため、重大度の決定と根本原因の分析に必要な時間を大幅に節約できます。エミュレータの複数のインスタンスをシャーディングに使用し、Android Test Station で継続的に実行するようにスケジュールを設定できます。
[[["わかりやすい","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-05-09 UTC。"],[],[],null,["# Optimize the CTS\n\nThe Android Compatibility Test Suite (CTS) provides millions of individual tests.\nWhile necessary to run CTS frequently during the software development phase,\nit's possible to shorten the time needed to run these tests.\n| **Important:** To approve a software build for final production, a full run of the CTS test suite is mandatory. The final production build can't contain modules that are either untested or that have failed testing. Partners are responsible for discovering failures early in development. All failures must be addressed before the final build.\n\nThis page describes methods you can use to reduce test execution time and how\nto optimize hardware resources into the process.\n\nSharding devices\n----------------\n\nTo reduce cycle time, consider running the CTS on multiple devices (sharding).\nTo see how sharding can be used, review\n[Run CTS tests](/docs/compatibility/cts/run).\n| **Tip:** For maximum efficiency, we recommend you connect at least six devices. Doing so can shorten total CTS execution time to less than 24 hours.\n\nAndroid test station\n--------------------\n\nUse the\n[Android Test Station (ATS)](/docs/core/tests/development/android-test-station/ats-user-guide)\nto employ a user interface to run standard Android test suites. This tool\nserves as a web interface for\n[Trade Federation (TF)](/docs/core/tests/tradefed),\nallowing you to run the CTS with minimal setup on a set of test devices as well\nas to establish a schedule to continuously run tests.\n\nThe Android test station supports\n[Multi-host mode](/docs/core/tests/development/android-test-station/ats-user-guide#multi-host-mode),\nwith which a single ATS controller host can be used to manage devices and tests\non multiple ATS worker hosts.\n| **Tip:** To run Android Test Station on an emulator, include the parameter `--use_host_adb`.\n\nEmulator continuous run\n-----------------------\n\nTo run the CTS continuously during the development phase,\n[Android Virtual Devices (AVD)](/docs/devices/automotive/start/avd/android_virtual_device)\ncan be used as a substitute for hardware. Regressions of test failures can be\nidentified early, saving much of the time needed to triage and analyze root\ncauses. Multiple instances of the emulator can be used for sharding and can be\nscheduled to run continuously with the Android test station.\n| **Important:** The emulator implementation may not be identical to the hardware and tests may not run or the results may be unreliable. Be sure to analyze which test modules produce different results compared to hardware before setting up the Emulator for continuous run.\n\ndrawElements Quality Program (dEQP)\n-----------------------------------\n\nThe\n[`drawElements` Quality Program (dEQP)](/docs/core/graphics/deqp-testing)\nis included in the Android CTS. Called `CtsDepqTestCases`, this program focuses\non test coverage of Android graphics. This module accounts for almost 80% of all\ntest cases in Android CTS and represents 6% of total execution time.\n\nSince the Android graphics drivers are part of Android firmware (BSP) and do not\nchange much over the course of development, you can run this module\nstrategically. For example, if you run CTS every two weeks (or less) during\nsoftware development, based on the firmware update schedule you can exclude this\nmodule for several cycles.\n| **Important:** To avoid discovering last minute issues during final certification, we highly recommend you run the module multiple times during development and to not skip this module completely.\n\nOne option is to run `CtsDeqpTestCases` separately on a set of devices, and to\nthen submit the CTS reports. For example, on two different hosts.\n\nHost 1:\n\n`cts-tf \u003e run cts --max-log-size 100 --shard-count 6 -o -m CtsDeqpTestCases`\n\nHost 2:\n\n`cts-tf \u003e run cts --max-log-size 100 --shard-count 6 -o --exclude-filter CtsDeqpTestCases`\n\nMedia test cases\n----------------\n\nMedia test cases verify multimedia services such as audio, video, and the\nmultimedia drivers. These multimedia test modules contribute the most to CTS\nexecution time. Delays can occur when:\n\n- Downloading media files or repeatedly playing media files during tests.\n- Retrying failed test cases.\n\nThe Android CTS contains these test modules:\n\n- `CtsMediaStressTestCases`\n- `CtsMediaPlayerTestCases`\n- `CtsMediaAudioTestCases`\n- `CtsVideoTestCases`\n- `CtsMediaDecoderTestCases`\n- `CtsMediaCodecTestCases`\n- `CtsMediaV2TestCases`\n\nConsider running some media tests locally or on a local server. For details, see\n[Run CTS media tests locally](/docs/compatibility/cts/run-locally).\n\nThe multimedia framework and its drivers (decoders and encoders) are part\nof the Android firmware (BSP). You can run this module strategically and exclude\nthese modules for several cycles, based on the firmware update schedule.\n| **Important:** To avoid discovering last minute issues during final certification, we highly recommend you run the multimedia modules multiple times during development and to not skip these modules completely."]]
