ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
CTS ที่ขับเคลื่อนโดยนักพัฒนาแอป
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
หน้านี้จะระบุหลักเกณฑ์การใช้งาน CTS ที่ขับเคลื่อนโดยนักพัฒนาแอป (CTS-D)
การครอบคลุมการทดสอบ
CTS-D เช่นเดียวกับ CTS และโปรแกรมตรวจสอบ CTS จะบังคับใช้สิ่งต่อไปนี้ได้เท่านั้น
- API สาธารณะทั้งหมดที่อธิบายไว้ใน SDK สําหรับนักพัฒนาแอป (developer.android.com) สําหรับระดับ API บางระดับ
- ข้อกำหนด "ต้อง" ทั้งหมดที่ระบุไว้ในเอกสารคำจำกัดความความเข้ากันได้ของ Android (CDD) สำหรับ API ระดับหนึ่งๆ
ข้อกำหนดที่ไม่ใช่ "ต้อง" เช่น "แนะนำอย่างยิ่ง" "ควร" "อาจ" จะเป็นข้อกำหนดที่ไม่บังคับ และไม่สามารถทดสอบโดยใช้ CTS
เนื่องจาก API และข้อกำหนด CDD ทั้งหมดเชื่อมโยงกับระดับ API ที่เฉพาะเจาะจง การทดสอบ CTS ทั้งหมด (CTS, CTS-D และ CTS Verifier) จึงเชื่อมโยงกับระดับ API เดียวกับ API หรือข้อกำหนดที่เกี่ยวข้อง หากมีการเลิกใช้งานหรือเปลี่ยนแปลง API บางรายการ การทดสอบที่เกี่ยวข้องจะต้องเลิกใช้งานหรืออัปเดต
กฎการสร้างการทดสอบ CTS
- การทดสอบต้องให้ผลลัพธ์ที่เป็นกลางแบบเดียวกันอย่างสม่ำเสมอ
- การทดสอบต้องระบุว่าอุปกรณ์ผ่านหรือไม่โดยทดสอบอุปกรณ์นั้นๆ เพียงครั้งเดียว
- ครีเอเตอร์การทดสอบต้องนำปัจจัยที่เป็นไปได้ทั้งหมดที่อาจส่งผลต่อผลการทดสอบออก
- หากอุปกรณ์ต้องการสภาพ/สภาพแวดล้อม/การตั้งค่าฮาร์ดแวร์บางอย่าง การตั้งค่านั้นจะต้องระบุไว้อย่างชัดเจนในข้อความคอมมิต ดูตัวอย่างวิธีการตั้งค่าได้ที่การตั้งค่า CTS
- การทดสอบต้องใช้เวลาไม่เกิน 6 ชั่วโมงต่อครั้ง หากต้องใช้เวลานานกว่านั้น โปรดระบุเหตุผลในข้อเสนอการทดสอบเพื่อให้เราตรวจสอบได้
ต่อไปนี้เป็นตัวอย่างชุดเงื่อนไขการทดสอบสําหรับการทดสอบการจํากัดแอป
- Wi-Fi เสถียร (สําหรับการทดสอบที่อาศัย Wi-Fi)
- อุปกรณ์ไม่เคลื่อนไหวระหว่างการทดสอบ (หรือเคลื่อนไหวก็ได้ ทั้งนี้ขึ้นอยู่กับการทดสอบ)
- อุปกรณ์ถอดปลั๊กออกจากแหล่งจ่ายไฟโดยมีระดับแบตเตอรี่ X เปอร์เซ็นต์
- ไม่มีแอป บริการที่ทำงานอยู่เบื้องหน้า หรือบริการที่ทำงานอยู่เบื้องหลังทำงานอยู่ ยกเว้น CTS
- หน้าจอปิดอยู่ขณะเรียกใช้ CTS
- อุปกรณ์ไม่ใช่
isLowRamDevice
- โหมดประหยัดแบตเตอรี่ / การจำกัดแอปไม่มีการเปลี่ยนแปลงจากสถานะ "พร้อมใช้งานทันที"
การมีสิทธิ์ทดสอบ
เรายอมรับการทดสอบใหม่ที่ใช้บังคับลักษณะการทำงานที่การทดสอบ CTS, CTS Verifier หรือ CTS-D ที่มีอยู่ไม่ได้ทดสอบ การทดสอบที่ตรวจสอบลักษณะการทำงานนอกขอบเขตความครอบคลุมของการทดสอบจะถูกปฏิเสธ
กระบวนการส่ง CTS
- เขียนข้อเสนอการทดสอบ: นักพัฒนาแอปส่งข้อเสนอการทดสอบโดยใช้เครื่องมือติดตามปัญหาของ Google โดยอธิบายปัญหาที่พบและเสนอการทดสอบเพื่อตรวจสอบปัญหาดังกล่าว ข้อเสนอต้องมีรหัสข้อกำหนด CDD ที่เกี่ยวข้อง
ทีม Android จะตรวจสอบข้อเสนอ
- พัฒนาการทดสอบ CTS: หลังจากข้อเสนอได้รับอนุมัติ ผู้ส่งจะสร้างการทดสอบ CTS ใน AOSP บนสาขารุ่นล่าสุดของ Android (
android16-release) ทีม Android จะตรวจสอบโค้ดและหากยอมรับ ก็จะเลือกการเปลี่ยนแปลงที่ต้องการและผสานเข้ากับสาขาการพัฒนาภายใน โปรดดูรายละเอียดที่หัวข้อฉันควรเสนอการเปลี่ยนแปลง AOSP จากที่ใด
หลักเกณฑ์การเขียนข้อสอบ CTS-D
- ปฏิบัติตามคู่มือสไตล์โค้ด Java
- ทำตามขั้นตอนทั้งหมดที่อธิบายไว้ในการพัฒนา CTS
- เพิ่มการทดสอบลงในแผนการทดสอบที่เหมาะสม โดยทำดังนี้
- ใช้
include-filters เพื่อเพิ่มการทดสอบใหม่ลงในแผนการทดสอบ CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml
- ใช้
exclude-filters เพื่อยกเว้นการทดสอบใหม่ออกจากแผนการทดสอบ CTS หลัก: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml
- จัดการคำเตือนและคำแนะนำทั้งหมดใน
errorprone ของ build_error.log
- เปลี่ยนฐานการเปลี่ยนแปลงเป็น
head ซึ่งรวมถึงแผนการทดสอบ cts-developer.xml และ cts-developer-exclude.xml
- โปรดติดต่อตัวแทนทีมวิศวกรของ Google เพื่อดูว่ากรณีทดสอบของคุณรวมอยู่ในข้อบังคับ CTS ที่มีอยู่ได้หรือไม่ หากไม่สำเร็จ ทีมจะช่วยเหลือคุณในการสร้างข้อบังคับใหม่
- สําหรับแต่ละข้อบังคับการทดสอบใหม่ที่สร้างขึ้น ให้สร้างไฟล์ OWNERS ในไดเรกทอรีข้อบังคับการทดสอบใหม่
- ไฟล์ OWNERS ควรมีข้อมูลต่อไปนี้ซึ่งได้จากเจ้าของการทดสอบของ Google ที่คุณร่วมงานด้วย
# Bug component: xxx- ldap ของเจ้าของการทดสอบของ Google
- ใน
AndroidTest.xml ให้ระบุพารามิเตอร์ต่อไปนี้ ดูตัวอย่างจากไฟล์ตัวอย่าง (1,
2)
Instant_app หรือ not_instant_appsecondary_user หรือ not_secondary_userall_foldable_states หรือ no_foldable_states
- หากต้องการระบุ minSDK ที่ถูกต้อง โปรดดูเอกสารประกอบ <uses-sdk>
- เมื่อตรวจสอบวิธีการทดสอบ ชั้นเรียน หรือข้อบังคับใหม่ ให้เพิ่มลงในแผนการทดสอบ CTS-D และยกเว้นออกจากแผนการทดสอบ CTS หลักในลักษณะเดียวกับการทดสอบใหม่
ทำการทดสอบ CTS-D
เรียกใช้แผนการทดสอบ CTS-D จากบรรทัดคำสั่งโดยใช้ run cts --plan cts-developer
หากต้องการเรียกใช้ Test Case ที่เฉพาะเจาะจง ให้ใช้ run cts --include-filter "test_module_name test_name"
ดูข้อมูลเกี่ยวกับการเรียกใช้ CTS แบบเต็มได้ที่เรียกใช้การทดสอบ CTS
การยอมรับและการปล่อย
เมื่อส่งคำขอทดสอบแล้ว ทีมภายในจะตรวจสอบคำขอเพื่อให้แน่ใจว่าคำขอทดสอบข้อกำหนด CDD หรือลักษณะการทํางานของ API ที่ระบุไว้ หากพบว่าการทดสอบกำลังตรวจสอบข้อกำหนดหรือลักษณะการทำงานที่ถูกต้อง ทีมจะส่งต่อกรณีทดสอบนี้ไปยังวิศวกรของ Google เพื่อตรวจสอบเพิ่มเติม วิศวกรของ Google จะติดต่อคุณเพื่อแจ้งความคิดเห็นเกี่ยวกับวิธีปรับปรุงการทดสอบก่อนที่จะยอมรับการทดสอบใน CTS
ดูรายละเอียดเกี่ยวกับกำหนดการเผยแพร่ CTS ได้ที่กำหนดการเผยแพร่และข้อมูลสาขา
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 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-07-27 UTC"],[],[],null,["# Developer-Powered CTS\n\nThis page outlines the usage guidelines for Developer-Powered CTS (CTS-D).\n\nTest coverage\n-------------\n\nCTS-D, like CTS \\& CTS Verifier, can only enforce the following:\n\n- All public APIs that are described in the developer SDK (developer.android.com) for a certain API level.\n- All MUST requirements that are included in the Android Compatibility Definition Document (CDD) for a certain API level.\n\nNon-MUST requirements, such as STRONGLY RECOMMENDED, SHOULD, MAY, are optional\nand can't be tested using CTS.\n\nBecause all APIs and CDD requirements are tied to a specific API level, all CTS\ntests (CTS, CTS-D, and CTS Verifier) are tied to the same API level as their\nassociated APIs or requirements. If a specific API is deprecated or changed,\nits corresponding test must be deprecated or updated.\n\nCTS test creation rules\n-----------------------\n\n- A test must produce the same objective result consistently.\n- A test must determine whether a device passes or fails by testing that device one time out of the box.\n- Test creators must remove all possible factors that could affect test results.\n- If a device needs a certain hardware condition/environment/setup, that setup must be clearly defined in the commit message. For example setup instructions, see [Setting Up CTS](/docs/compatibility/cts/setup).\n- The test must not run for more than 6 hours at a time. If it needs to run for longer, please include the reasoning in your test proposal so that we can review it.\n\nThe following is an example set of test conditions for testing an app\nrestriction:\n\n- Wifi is stable (for a test that relies on Wifi).\n- The device remains stationary during the test (or not, depending on the test).\n- The device is unplugged from any power source with X percent of battery level.\n- No apps, foreground services, or background services are running, except for CTS.\n- The screen is off while running CTS.\n- The device is NOT `isLowRamDevice`.\n- Battery saver / app restrictions have not been changed from the \"out-of-the-box\" state.\n\n### Test eligibility\n\nWe accept new tests that enforce a behavior that isn't tested by existing CTS,\nCTS Verifier, or CTS-D tests. Any test that checks a behavior outside the scope\nof [our test coverage](#coverage) will be rejected.\n\nCTS submission process\n----------------------\n\n1. **Write a test proposal:** An app developer submits a test proposal using [Google Issue Tracker](https://issuetracker.google.com/issues/new?component=1124973&template=1633344), describing the issue that has been identified and proposing a test to check for it. The proposal must include the associated [CDD requirement ID](/docs/compatibility/cts/development#annotation). The Android team reviews the proposal.\n2. **Develop a CTS test:** After a proposal is approved, its submitter creates a CTS test on AOSP on the Android latest release branch (`android16-release`). The Android team reviews the code and if accepted, cherrypicks the change and merges it into the internal development branch. For details, see [Where should I propose changes to AOSP?](/docs/setup/about/faqs#changes-aosp).\n\nCTS-D test writing guidelines\n-----------------------------\n\n- Follow the [Java Code Style Guide](/docs/setup/contribute/code-style).\n- Follow all the steps described in [CTS Development](/docs/compatibility/cts/development).\n- Add your tests to the appropriate test plan:\n - Use `include-filters` to add your new tests to the CTS-D test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer.xml`.\n - Use `exclude-filters` to exclude your new tests from the main CTS test plan: `platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml`.\n- Handle all `errorprone` warnings and suggestions in `build_error.log`.\n- Rebase your changes to `head`. This includes the `cts-developer.xml` and `cts-developer-exclude.xml` test plans.\n- Work with your Google engineering contact to determine whether your test case can be included in an existing CTS module. If it can't, they'll help you create a new module.\n- For each new test module created, create an OWNERS file in the new test module directory.\n - Your OWNERS file should contain the following information, obtained from the Google test owner you're working with:\n - `# Bug component: xxx`\n - Google test owner ldap\n- In `AndroidTest.xml`, specify the following parameters. Refer to the sample files ([1](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/sample/), [2](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/sample/)) for examples:\n - `Instant_app` or `not_instant_app`\n - `secondary_user` or `not_secondary_user`\n - `all_foldable_states` or `no_foldable_states`\n- To specify the correct minSDK, refer to [the \\\u003cuses-sdk\\\u003e documentation](https://developer.android.com/guide/topics/manifest/uses-sdk-element).\n- When checking in new test methods, classes, or modules, add them to the CTS-D test plan and exclude them from the main CTS test plan in the same way as for new tests.\n\nRun your CTS-D test\n-------------------\n\nRun the CTS-D test plan [from the command line](/docs/compatibility/cts/command-console-v2)\nusing `run cts --plan cts-developer`.\n\nTo run a specific test case, use `run cts --include-filter \"test_module_name test_name\"`.\n\nFor information on running the full CTS, see [Run CTS tests](/docs/compatibility/cts/run).\n\nAcceptance and release\n----------------------\n\nOnce a test request is submitted, an internal team will review it to make sure\nit tests a CDD requirement or a documented API behavior. If the test is\ndetermined to be checking for a valid requirement or behavior, the team\nwill forward this test case to a Google engineer for further review. The Google\nengineer will reach out to you with feedback on how the test can be improved\nbefore it can be accepted into CTS.\n\nSee\n[Release schedule and branch information](/docs/compatibility/cts/development#release-schedule)\nfor details on the CTS release schedule."]]
