Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
CTS do nhà phát triển cung cấp
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Trang này trình bày các nguyên tắc sử dụng CTS do nhà phát triển cung cấp (CTS-D).
Mức độ bao phủ kiểm thử
CTS-D, giống như CTS và Trình xác minh CTS, chỉ có thể thực thi những điều sau:
- Tất cả API công khai được mô tả trong SDK dành cho nhà phát triển (developer.android.com) cho một cấp độ API nhất định.
- Tất cả các yêu cầu PHẢI có trong Tài liệu định nghĩa về khả năng tương thích (CDD) với Android cho một cấp độ API nhất định.
Các yêu cầu KHÔNG BẮT BUỘC, chẳng hạn như ĐỀ XUẤT MẠNH, NÊN, CÓ THỂ, là không bắt buộc và không thể kiểm thử bằng CTS.
Vì tất cả API và yêu cầu CDD đều liên kết với một cấp độ API cụ thể, nên tất cả các kiểm thử CTS (CTS, CTS-D và Trình xác minh CTS) đều liên kết với cùng một cấp độ API như các API hoặc yêu cầu liên kết. Nếu một API cụ thể không còn được dùng nữa hoặc thay đổi, thì bạn phải ngừng sử dụng hoặc cập nhật kiểm thử tương ứng.
Quy tắc tạo kiểm thử CTS
- Một kiểm thử phải tạo ra kết quả khách quan giống nhau một cách nhất quán.
- Quy trình kiểm thử phải xác định xem một thiết bị có đạt hay không bằng cách kiểm thử thiết bị đó một lần ngay khi xuất xưởng.
- Người tạo thử nghiệm phải loại bỏ mọi yếu tố có thể ảnh hưởng đến kết quả thử nghiệm.
- Nếu một thiết bị cần một điều kiện/môi trường/chế độ thiết lập phần cứng nhất định, thì chế độ thiết lập đó phải được xác định rõ ràng trong thông báo cam kết. Để biết hướng dẫn thiết lập mẫu, hãy xem phần Thiết lập CTS.
- Mỗi lần chạy, kiểm thử không được chạy quá 6 giờ. Nếu cần chạy lâu hơn, vui lòng đưa lý do vào đề xuất kiểm thử để chúng tôi có thể xem xét.
Sau đây là một bộ điều kiện kiểm thử mẫu để kiểm thử một hạn chế của ứng dụng:
- Wifi ổn định (đối với kiểm thử dựa vào Wifi).
- Thiết bị vẫn đứng yên trong quá trình kiểm thử (hoặc không, tuỳ thuộc vào kiểm thử).
- Thiết bị đã rút phích cắm khỏi nguồn điện bất kỳ với mức pin X%.
- Không có ứng dụng, dịch vụ trên nền trước hoặc dịch vụ trong nền nào đang chạy, ngoại trừ CTS.
- Màn hình tắt khi chạy CTS.
- Thiết bị KHÔNG phải là
isLowRamDevice.
- Các quy tắc hạn chế về trình tiết kiệm pin / ứng dụng không thay đổi từ trạng thái "mới xuất xưởng".
Kiểm tra điều kiện
Chúng tôi chấp nhận các chương trình kiểm thử mới thực thi một hành vi không được kiểm thử bằng các chương trình kiểm thử CTS, CTS Verifier hoặc CTS-D hiện có. Mọi kiểm thử kiểm tra hành vi nằm ngoài phạm vi mức độ bao phủ kiểm thử của chúng tôi sẽ bị từ chối.
Quy trình gửi CTS
- Viết đề xuất kiểm thử: Nhà phát triển ứng dụng gửi đề xuất kiểm thử bằng Công cụ theo dõi lỗi của Google, mô tả vấn đề đã được xác định và đề xuất một kiểm thử để kiểm tra vấn đề đó. Đề xuất phải bao gồm mã yêu cầu CDD liên quan.
Nhóm Android sẽ xem xét đề xuất.
- Phát triển quy trình kiểm thử CTS: Sau khi đề xuất được phê duyệt, người gửi sẽ tạo quy trình kiểm thử CTS trên AOSP trên nhánh phát hành mới nhất của Android (
android16-release). Nhóm Android sẽ xem xét mã và nếu được chấp nhận, hãy chọn thay đổi và hợp nhất thay đổi đó vào nhánh phát triển nội bộ. Để biết thông tin chi tiết, hãy xem bài viết Tôi nên đề xuất thay đổi đối với AOSP ở đâu?.
Nguyên tắc viết kiểm thử CTS-D
- Tuân theo Hướng dẫn về kiểu mã Java.
- Làm theo tất cả các bước được mô tả trong phần Phát triển CTS.
- Thêm kiểm thử vào kế hoạch kiểm thử thích hợp:
- Sử dụng
include-filters để thêm các chương trình kiểm thử mới vào kế hoạch kiểm thử CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Sử dụng
exclude-filters để loại trừ các kiểm thử mới khỏi kế hoạch kiểm thử CTS chính: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Xử lý tất cả cảnh báo và đề xuất
errorprone trong build_error.log.
- Đặt lại các thay đổi của bạn thành
head. Bao gồm cả kế hoạch kiểm thử cts-developer.xml và cts-developer-exclude.xml.
- Hãy làm việc với người liên hệ phụ trách kỹ thuật của Google để xác định xem trường hợp kiểm thử của bạn có thể được đưa vào mô-đun CTS hiện có hay không. Nếu không, họ sẽ giúp bạn tạo một mô-đun mới.
- Đối với mỗi mô-đun kiểm thử mới được tạo, hãy tạo một tệp OWNERS trong thư mục mô-đun kiểm thử mới.
- Tệp OWNERS phải chứa những thông tin sau đây, được lấy từ chủ sở hữu thử nghiệm của Google mà bạn đang hợp tác:
# Bug component: xxx- LDAP của chủ sở hữu kiểm thử của Google
- Trong
AndroidTest.xml, hãy chỉ định các tham số sau. Hãy tham khảo các tệp mẫu (1, 2) để biết ví dụ:
Instant_app hoặc not_instant_appsecondary_user hoặc not_secondary_userall_foldable_states hoặc no_foldable_states
- Để chỉ định đúng minSDK, hãy tham khảo tài liệu về <uses-sdk>.
- Khi kiểm tra các phương thức, lớp hoặc mô-đun kiểm thử mới, hãy thêm các phương thức, lớp hoặc mô-đun đó vào kế hoạch kiểm thử CTS-D và loại trừ các phương thức, lớp hoặc mô-đun đó khỏi kế hoạch kiểm thử CTS chính theo cách tương tự như đối với các kiểm thử mới.
Chạy kiểm thử CTS-D
Chạy kế hoạch kiểm thử CTS-D từ dòng lệnh bằng run cts --plan cts-developer.
Để chạy một trường hợp kiểm thử cụ thể, hãy sử dụng run cts --include-filter "test_module_name test_name".
Để biết thông tin về cách chạy toàn bộ CTS, hãy xem phần Chạy kiểm thử CTS.
Chấp nhận và phát hành
Sau khi bạn gửi yêu cầu kiểm thử, một nhóm nội bộ sẽ xem xét yêu cầu đó để đảm bảo rằng yêu cầu đó kiểm thử một yêu cầu của CDD hoặc hành vi API được ghi nhận. Nếu xác định được kiểm thử đang kiểm tra một yêu cầu hoặc hành vi hợp lệ, nhóm sẽ chuyển tiếp trường hợp kiểm thử này đến một kỹ sư của Google để xem xét thêm. Kỹ sư của Google sẽ liên hệ với bạn để đưa ra ý kiến phản hồi về cách cải thiện quy trình kiểm thử trước khi quy trình đó được chấp nhận vào CTS.
Hãy xem phần Lịch phát hành và thông tin về nhánh để biết thông tin chi tiết về lịch phát hành CTS.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]
