Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
CTS yang Didukung Developer
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menguraikan panduan penggunaan untuk CTS yang Didukung Developer (CTS-D).
Cakupan pengujian
CTS-D, seperti CTS & CTS Verifier, hanya dapat menerapkan hal berikut:
- Semua API publik yang dijelaskan dalam SDK developer
(developer.android.com) untuk API level tertentu.
- Semua persyaratan HARUS yang disertakan dalam Compatibility
Definition Document (CDD) Android untuk API level tertentu.
Persyaratan non-HARUS, seperti SANGAT DIUJIKAN, HARUS, DAPAT, bersifat opsional
dan tidak dapat diuji menggunakan CTS.
Karena semua API dan persyaratan CDD terikat dengan API level tertentu, semua pengujian
CTS (CTS, CTS-D, dan CTS Verifier) terikat dengan API level yang sama dengan
API atau persyaratan terkait. Jika API tertentu tidak digunakan lagi atau diubah,
pengujian yang sesuai harus tidak digunakan lagi atau diperbarui.
Aturan pembuatan pengujian CTS
- Pengujian harus menghasilkan hasil objektif yang sama secara konsisten.
- Pengujian harus menentukan apakah perangkat lulus atau gagal dengan menguji perangkat tersebut
satu kali secara langsung.
- Kreator pengujian harus menghapus semua kemungkinan faktor yang dapat memengaruhi hasil pengujian.
- Jika perangkat memerlukan kondisi/lingkungan/penyiapan hardware tertentu, penyiapan tersebut
harus ditentukan dengan jelas dalam pesan commit. Untuk contoh petunjuk penyiapan,
lihat Menyiapkan CTS.
- Pengujian tidak boleh berjalan lebih dari 6 jam dalam satu waktu. Jika perlu berjalan lebih lama, sertakan alasannya dalam proposal pengujian Anda agar kami dapat meninjaunya.
Berikut adalah contoh kumpulan kondisi pengujian untuk menguji pembatasan
aplikasi:
- Wi-Fi stabil (untuk pengujian yang mengandalkan Wi-Fi).
- Perangkat tetap diam selama pengujian (atau tidak, bergantung pada pengujian).
- Perangkat dicabut dari sumber listrik dengan persentase baterai X.
- Tidak ada aplikasi, layanan latar depan, atau layanan latar belakang yang berjalan, kecuali
CTS.
- Layar nonaktif saat menjalankan CTS.
- Perangkat BUKAN
isLowRamDevice.
- Batasan penghemat baterai / aplikasi belum diubah dari
status “siap pakai”.
Menguji kelayakan
Kami menerima pengujian baru yang menerapkan perilaku yang tidak diuji oleh pengujian CTS,
Pemverifikasi CTS, atau CTS-D yang ada. Setiap pengujian yang memeriksa perilaku di luar cakupan
cakupan pengujian kami akan ditolak.
Proses pengiriman CTS
- Menulis proposal pengujian: Developer aplikasi mengirimkan proposal pengujian menggunakan
Issue Tracker Google,
yang menjelaskan masalah yang telah diidentifikasi dan mengusulkan pengujian untuk memeriksanya. Proposal harus menyertakan ID persyaratan CDD terkait.
Tim Android akan meninjau proposal tersebut.
- Mengembangkan pengujian CTS: Setelah proposal disetujui, pengirimnya akan membuat
pengujian CTS di AOSP pada cabang rilis terbaru Android
(
android16-release). Tim Android akan meninjau kode dan
jika diterima, memilih perubahan dan menggabungkannya ke dalam cabang
pengembangan internal. Untuk mengetahui detailnya, lihat
Di mana saya harus mengusulkan perubahan pada AOSP?.
Pedoman penulisan pengujian CTS-D
- Ikuti Panduan Gaya Kode Java.
- Ikuti semua langkah yang dijelaskan di Pengembangan CTS.
- Tambahkan pengujian Anda ke rencana pengujian yang sesuai:
- Gunakan
include-filters untuk menambahkan pengujian baru ke rencana pengujian CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Gunakan
exclude-filters untuk mengecualikan pengujian baru dari rencana pengujian CTS utama: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
- Tangani semua peringatan dan saran
errorprone di build_error.log.
- Lakukan rebase pada perubahan Anda ke
head. Hal ini mencakup rencana pengujian cts-developer.xml dan
cts-developer-exclude.xml.
- Bekerja samalah dengan kontak engineer Google Anda untuk menentukan apakah kasus pengujian Anda
dapat disertakan dalam modul CTS yang ada. Jika tidak dapat, mereka akan membantu Anda
membuat modul baru.
- Untuk setiap modul pengujian baru yang dibuat, buat file OWNERS di direktori modul pengujian
baru.
- File OWNERS Anda harus berisi informasi berikut, yang diperoleh dari pemilik pengujian Google yang Anda gunakan:
# Bug component: xxx- LDAP pemilik pengujian Google
- Di
AndroidTest.xml, tentukan parameter berikut. Lihat
file contoh (1,
2)
untuk mengetahui contohnya:
Instant_app atau not_instant_appsecondary_user atau not_secondary_userall_foldable_states atau no_foldable_states
- Untuk menentukan minSDK yang benar, lihat dokumentasi <uses-sdk>.
- Saat memeriksa metode, class, atau modul pengujian baru, tambahkan ke rencana pengujian
CTS-D dan kecualikan dari rencana pengujian CTS utama dengan cara yang sama seperti untuk
pengujian baru.
Menjalankan pengujian CTS-D
Jalankan rencana pengujian CTS-D dari command line
menggunakan run cts --plan cts-developer.
Untuk menjalankan kasus pengujian tertentu, gunakan run cts --include-filter "test_module_name test_name".
Untuk informasi tentang cara menjalankan CTS lengkap, lihat Menjalankan pengujian CTS.
Penerimaan dan rilis
Setelah permintaan pengujian dikirimkan, tim internal akan meninjaunya untuk memastikan
permintaan tersebut menguji persyaratan CDD atau perilaku API yang didokumentasikan. Jika pengujian
ditentukan untuk memeriksa persyaratan atau perilaku yang valid, tim
akan meneruskan kasus pengujian ini ke engineer Google untuk ditinjau lebih lanjut. Engineer Google
akan menghubungi Anda untuk memberikan masukan tentang cara meningkatkan pengujian
sebelum dapat diterima di CTS.
Lihat
Informasi cabang dan jadwal rilis
untuk mengetahui detail tentang jadwal rilis CTS.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
