[[["易于理解","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"]],["最后更新时间 (UTC)：2025-05-08。"],[],[],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."]]
