27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Geliştirici Tarafından Güçlendirilmiş CTS
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu sayfada, Geliştirici Tarafından Güçlendirilmiş CTS (CTS-D) ile ilgili kullanım yönergeleri özetlenmiştir.
Test kapsamı
CTS ve CTS Doğrulayıcı gibi CTS-D yalnızca aşağıdakileri zorunlu kılabilir:
- Belirli bir API seviyesi için geliştirici SDK'sında (developer.android.com) açıklanan tüm herkese açık API'ler.
- Belirli bir API düzeyi için Android Uyumluluk Tanımlama Belgesi'ne (CDD) dahil edilen tüm GEREKİR koşulları.
ZORUNLU olmayan şartlar (ör. ŞİDDETLE ÖNERİLİR, OLMALI, OLABİLİR) isteğe bağlıdır ve CTS kullanılarak test edilemez.
Tüm API'ler ve CDD koşulları belirli bir API düzeyine bağlı olduğundan tüm CTS testleri (CTS, CTS-D ve CTS Doğrulayıcı), ilişkili API'leri veya koşullarıyla aynı API düzeyine bağlıdır. Belirli bir API'nin desteği sonlandırılırsa veya API değiştirilirse ilgili testin desteği de sonlandırılmalı veya test güncellenmelidir.
CTS testi oluşturma kuralları
- Testler tutarlı bir şekilde aynı objektif sonucu vermelidir.
- Bir test, cihazı kutudan çıkardıktan sonra bir kez test ederek cihazın başarılı olup olmadığını belirlemelidir.
- Test oluşturucular, test sonuçlarını etkileyebilecek tüm olası faktörleri kaldırmalıdır.
- Bir cihazın belirli bir donanım koşuluna/ortamına/kurulumuna ihtiyacı varsa bu kurulum, gönderme mesajında net bir şekilde tanımlanmalıdır. Örnek kurulum talimatları için CTS'yi ayarlama başlıklı makaleyi inceleyin.
- Test, tek seferde 6 saatten uzun süre çalışmamalıdır. Daha uzun süre çalışması gerekiyorsa lütfen test teklifinize gerekçeyi ekleyin. Böylece, gerekçeyi inceleyebiliriz.
Aşağıda, bir uygulama kısıtlamasını test etmek için örnek bir test koşulları grubu verilmiştir:
- Kablosuz ağ kararlı (Kablosuz ağa dayalı bir test için).
- Cihaz, test sırasında sabit kalır (teste bağlı olarak sabit kalmayabilir).
- Cihaz, pil seviyesi X yüzdesindeyken herhangi bir güç kaynağından çıkarılır.
- CTS dışında hiçbir uygulama, ön plan hizmeti veya arka plan hizmeti çalışmıyor.
- CTS çalışırken ekran kapalı.
- Cihaz
isLowRamDevice DEĞİLDİR.
- Pil tasarrufu / uygulama kısıtlamaları "kutudan çıkar çıkmaz" durumundan değiştirilmemiştir.
Test uygunluğu
Mevcut CTS, CTS Doğrulayıcı veya CTS-D testleri tarafından test edilmeyen bir davranışı zorunlu kılan yeni testleri kabul ederiz. Test kapsamımızın dışındaki bir davranışı kontrol eden tüm testler reddedilir.
CTS gönderim süreci
- Test önerisi yazın: Uygulama geliştirici, Google Sorun Takip Aracı'nı kullanarak bir test önerisi gönderir. Bu öneride, tespit edilen sorunun açıklaması ve bu sorunu kontrol etmek için bir test önerilir. Teklif, ilişkili CDD şart kimliğini içermelidir.
Android ekibi öneriyi inceler.
- CTS testi geliştirme: Bir öneri onaylandıktan sonra, öneriyi gönderen kişi Android'in en son sürüm dalında (
android16-release) AOSP'de bir CTS testi oluşturur. Android ekibi kodu inceler ve kabul edilirse değişikliği seçip dahili geliştirme dalına birleştirir. Ayrıntılı bilgi için AOSP'de nerede değişiklik önerisinde bulunmalıyım? başlıklı makaleyi inceleyin.
CTS-D testi yazma yönergeleri
- Java Kod Stili Kılavuzu'na uyun.
- CTS Geliştirme bölümünde açıklanan tüm adımları uygulayın.
- Testlerinizi uygun test planına ekleyin:
- Yeni testlerinizi CTS-D test planına eklemek için
include-filters'ü kullanın: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
- Yeni testlerinizi ana CTS test planından hariç tutmak için
exclude-filters simgesini kullanın: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
build_error.log'daki tüm errorprone uyarılarını ve önerilerini ele alın.- Değişikliklerinizi
head'e yeniden temellendirin. cts-developer.xml ve cts-developer-exclude.xml test planları da buna dahildir.
- Test durumunuzun mevcut bir CTS modülüne dahil edilip edilemeyeceğini belirlemek için Google mühendislik temsilcinizle birlikte çalışın. Bu mümkün değilse yeni bir modül oluşturmanıza yardımcı olurlar.
- Oluşturulan her yeni test modülü için yeni test modülü dizininde bir OWNERS dosyası oluşturun.
- OWNERS dosyanız, birlikte çalıştığınız Google test sahibinden alınan aşağıdaki bilgileri içermelidir:
# Bug component: xxx- Google test sahibi ldap
AndroidTest.xml içinde aşağıdaki parametreleri belirtin. Örnekler için örnek dosyalara (1, 2) bakın:
Instant_app veya not_instant_appsecondary_user veya not_secondary_userall_foldable_states veya no_foldable_states
- Doğru minSDK'yı belirtmek için <uses-sdk> dokümanlarına bakın.
- Yeni test yöntemlerini, sınıfları veya modülleri kontrol ederken bunları CTS-D test planına ekleyin ve yeni testlerde olduğu gibi ana CTS test planından hariç tutun.
CTS-D testinizi çalıştırma
run cts --plan cts-developer kullanarak CTS-D test planını komut satırından çalıştırın.
Belirli bir test vakasını çalıştırmak için run cts --include-filter "test_module_name test_name" simgesini kullanın.
Tam CTS'yi çalıştırma hakkında bilgi edinmek için CTS testlerini çalıştırma başlıklı makaleyi inceleyin.
Kabul ve yayın
Gönderilen test istekleri, bir CDD koşulunu veya belgelenmiş bir API davranışını test edip etmediğini belirlemek için dahili bir ekip tarafından incelenir. Testin geçerli bir koşulu veya davranışı kontrol ettiği belirlenirse ekip, bu test vakasını daha ayrıntılı incelenmesi için bir Google mühendisine iletir. Google mühendisi, CTS'ye kabul edilmeden önce testin nasıl iyileştirilebileceğine dair geri bildirimde bulunmak için sizinle iletişime geçecektir.
CTS sürüm planı hakkında ayrıntılı bilgi için Sürüm planı ve dal bilgileri bölümüne bakın.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
