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.
Pengujian platform Android
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Proyek Open Source Android (AOSP) menyediakan beberapa alat dan rangkaian pengujian
untuk menguji berbagai bagian implementasi Anda. Sebelum menggunakan halaman di bagian
ini, Anda harus memahami istilah berikut:
- Perangkat yang kompatibel dengan Android
- Perangkat yang dapat menjalankan aplikasi pihak ketiga apa pun yang ditulis oleh developer pihak ketiga
menggunakan Android SDK dan NDK. Perangkat yang kompatibel dengan Android harus mematuhi
persyaratan
Compatibility Definition Document (CDD) dan lulus
Compatibility Test Suite (CTS). Perangkat yang kompatibel dengan Android
layak untuk berpartisipasi dalam ekosistem Android, yang mencakup
potensi pemberian lisensi Google Play, potensi pemberian lisensi
suite aplikasi dan API
Layanan Seluler Google (GMS), dan penggunaan merek dagang Android. Siapa pun dapat
menggunakan kode sumber Android, tetapi agar dianggap sebagai bagian dari ekosistem Android,
perangkat harus kompatibel dengan Android.
- artefak
- Log terkait build yang memungkinkan pemecahan masalah lokal.
- Compatibility Definition Document (CDD)
- Dokumen yang mencantumkan persyaratan software dan hardware untuk
perangkat yang kompatibel dengan Android.
- Compatibility Test Suite (CTS)
Rangkaian pengujian gratis kelas komersial, yang tersedia untuk didownload sebagai biner atau sebagai
sumber di AOSP. CTS adalah serangkaian pengujian unit yang dirancang untuk diintegrasikan ke dalam
alur kerja harian Anda. Tujuan CTS adalah untuk mengungkapkan inkompatibilitas, dan
memastikan bahwa software tetap kompatibel selama proses pengembangan.
Pengujian CTS dan platform tidak eksklusif satu sama lain. Berikut ini beberapa panduan umum:
- Jika pengujian menyatakan ketepatan fungsi atau perilaku API framework,
dan pengujian harus diterapkan di seluruh partner OEM, pengujian tersebut harus berada di CTS.
- Jika pengujian dimaksudkan untuk menangkap regresi selama pengembangan platform,
dan mungkin memerlukan izin dengan hak istimewa untuk dijalankan, dan mungkin bergantung
pada detail implementasi (seperti yang dirilis di AOSP), pengujian tersebut harus berupa pengujian
platform.
- Layanan Seluler Google (GMS)
Kumpulan aplikasi dan API Google yang dapat diinstal sebelumnya di perangkat.
- GoogleTest (GTest)
Framework pengujian dan tiruan C++. Biner GTest biasanya
mengakses lapisan abstraksi tingkat rendah atau melakukan IPC mentah terhadap berbagai layanan
sistem. Pendekatan pengujian untuk GTest biasanya sangat terkait dengan
layanan yang sedang diuji. CTS berisi framework GTest.
- pengujian instrumentasi
Lingkungan eksekusi pengujian khusus
yang diluncurkan oleh perintah am instrument
, tempat proses aplikasi yang ditargetkan
dimulai ulang dan diinisialisasi dengan konteks aplikasi dasar, dan
thread instrumentasi dimulai di dalam virtual machine
proses aplikasi. CTS berisi uji instrumentasi.
- Logcat
Alat command line yang membuat log pesan sistem, termasuk
pelacakan tumpukan saat perangkat menampilkan error dan pesan yang telah
Anda tulis dari aplikasi dengan class Log
.
- logging
Menggunakan log untuk melacak peristiwa sistem komputer, seperti
error. Logging di Android bersifat kompleks karena campuran standar yang digunakan
digabungkan dalam alat Logcat.
- pengujian pasca-pengiriman
Pengujian Android yang dilakukan saat patch baru di-commit ke
cabang kernel umum. Dengan memasukkan aosp_kernel
sebagai nama cabang sebagian, Anda
dapat melihat daftar cabang kernel dengan hasil yang tersedia. Misalnya, hasil
untuk android-mainline
dapat ditemukan di
https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.
- pengujian pra-pengiriman
Pengujian yang digunakan untuk mencegah kegagalan dimasukkan ke dalam
kernel umum.
- Trade Federation
Juga disebut Tradefed, framework pengujian berkelanjutan
yang dirancang untuk menjalankan pengujian di perangkat Android. Misalnya,
Tradefed digunakan untuk menjalankan pengujian Compatibility Test Suite dan Vendor Test Suite.
- Vendor Test Suite (VTS)
Kumpulan kemampuan yang luas untuk
pengujian Android, mempromosikan proses pengembangan berbasis pengujian, dan mengotomatiskan
pengujian hardware abstraction layer (HAL) dan kernel OS.
Jenis pengujian platform
Pengujian platform biasanya berinteraksi dengan satu atau beberapa layanan sistem
Android atau lapisan HAL, menjalankan
fungsi subjek yang sedang diuji, dan menyatakan kebenaran
hasil pengujian. Pengujian platform dapat:
- (Jenis 1) Latihan API framework menggunakan framework Android. API tertentu yang
digunakan dapat mencakup:
- API publik yang ditujukan untuk aplikasi pihak ketiga
- API tersembunyi yang ditujukan untuk aplikasi dengan hak istimewa, yaitu API sistem atau
API pribadi (
@hide
, atau protected
, package private
)
- (Jenis 2) Memanggil layanan sistem Android menggunakan binder mentah atau proxy
IPC secara langsung.
- (Jenis 3) Berinteraksi langsung dengan HAL menggunakan API level rendah atau antarmuka IPC.
Pengujian jenis 1 dan 2 biasanya merupakan uji instrumentasi, sedangkan pengujian jenis 3
biasanya adalah GTests.
Apa selanjutnya?
Berikut adalah daftar dokumen yang dapat Anda baca untuk informasi yang lebih mendetail:
Jika Anda belum mempelajari arsitektur Android, lihat
Ringkasan arsitektur.
Jika Anda membuat perangkat yang kompatibel dengan Android, lihat
ringkasan program kompatibilitas Android.
Untuk mengintegrasikan pengujian instrumentasi, fungsional, metrik, dan host JAR
ke dalam layanan pengujian berkelanjutan platform, lihat
Alur kerja pengembangan pengujian.
Untuk mendeteksi dan meningkatkan keamanan perangkat Anda terhadap kerentanan,
lihat Pengujian keamanan.
Untuk mempelajari cara menguji implementasi HAL dan kernel, lihat
Infrastruktur dan Vendor Test Suite (VTS).
Untuk pengujian aplikasi, baca
Dasar-dasar pengujian aplikasi
Android
dan lakukan Android Lanjutan di Kotlin 05.1:Dasar-Dasar
Pengujian
menggunakan
contoh yang disediakan.
Pelajari pengujian pra-pengiriman dasar yang tersedia untuk Anda melalui hook repo.
Hook ini dapat digunakan untuk menjalankan linter, memeriksa pemformatan, dan memicu pengujian
unit sebelum melanjutkan, seperti mengupload commit. Hook ini dinonaktifkan
secara default. Untuk mengetahui informasi selengkapnya, lihat Hook Preupload
AOSP.
Untuk membaca selengkapnya tentang logging, lihat Memahami logging.
Untuk memahami cara men-debug kode Android, lihat
Men-debug kode platform Android native.
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,["# Android platform testing\n\nAndroid Open Source Project (AOSP) provides several tools and test suites\nfor testing various parts of your implementation. Before using the pages in this\nsection, you should be familiar with the following terms:\n\n*Android-compatible device*\n: A device that can run any third-party app written by third-party developers\n using the Android SDK and NDK. Android-compatible devices must adhere to the\n requirements of the\n [Compatibility Definition Document (CDD)](#CDD) and pass the\n [Compatibility Test Suite (CTS)](#cts). Android-compatible\n devices are eligible to participate in the Android ecosystem, which includes\n potential licensure of Google Play, potential licensure of the\n [Google Mobile Services (GMS)](#gms) suite of\n app and APIs, and use of the Android trademark. Anyone is welcome to\n use the Android source code, but to be considered part of the Android ecosystem,\n a device must be Android compatible.\n\n*artifact*\n: A build-related log that enables local troubleshooting.\n\n*Compatibility Definition Document (CDD)*\n: A document that enumerates the software and hardware requirements for an\n Android-compatible device.\n\n*Compatibility Test Suite (CTS)*\n\n: A free, commercial-grade test suite, available for download as a binary or as\n source in AOSP. The CTS is a set of unit tests designed to be integrated into\n your daily workflow. The intent of CTS is to reveal incompatibilities, and\n ensure that the software remains compatible throughout the development process.\n\n CTS and platform tests aren't mutually exclusive. Here are some general\n guidelines:\n\n - If a test is asserting correctness of framework API functions or behaviors, and the test should be enforced across OEM partners, it should be in CTS.\n - If a test is intended to catch regressions during platform development, and might require privileged permission to carry out, and might be dependent on implementation details (as released in AOSP), it should be a platform test.\n\n*Google Mobile Services (GMS)*\n\n: A collection of Google apps and APIs that can be preinstalled on devices.\n\n*GoogleTest (GTest)*\n\n: A C++ testing and mocking framework. GTest binaries typically\n access lower-level abstraction layers or perform raw IPC against various system\n services. The testing approach for GTest is usually tightly coupled with the\n service being tested. CTS contains the GTest framework.\n\n*instrumentation test*\n\n: A special test execution environment\n launched by the `am instrument` command, where the targeted app process\n is restarted and initialized with basic app context, and an\n instrumentation thread is started inside the app process virtual\n machine. CTS contains instrumentation tests.\n\n*Logcat*\n\n: A command-line tool that creates a log of system messages, including\n stack traces of when the device throws an error and messages that you have\n written from your app with the `Log` class.\n\n*logging*\n\n: Using a log to keep track of computer system events, such\n as errors. Logging in Android is complex due to the mix of standards used that\n are combined in the Logcat tool.\n\n*postsubmit test*\n\n: An Android test that is performed when a new patch is committed to a\n common kernel branch. By entering `aosp_kernel` as a partial branch name, you\n can see a list of kernel branches with results available. For example, results\n for `android-mainline` can be found at\n \u003chttps://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid\u003e.\n\n*presubmit test*\n\n: A test used to prevent failures from being introduced into the\n common kernels.\n\n*Trade Federation*\n\n: Also called Tradefed, a continuous test\n framework designed for running tests on Android devices. For example,\n Tradefed is used to run Compatibility Test Suite and Vendor Test Suite tests.\n\n*Vendor Test Suite (VTS)*\n\n: A set of extensive capabilities for\n Android testing, promoting a test-driven development process, and automating\n hardware abstraction layer (HAL) and OS kernel testing.\n\nPlatform test types\n-------------------\n\nA platform test typically interacts with one or more of the Android system\nservices or HAL layers, exercises the\nfunctionalities of the subject under test, and asserts correctness of the\ntesting outcome. A platform test might:\n\n- (Type 1) Exercise framework APIs using Android framework. Specific APIs being exercised can include:\n - Public APIs intended for third-party apps\n - Hidden APIs intended for privileged apps, namely system APIs or private APIs (`@hide`, or `protected`, `package private`)\n- (Type 2) Invoke Android system services using raw binder or IPC proxies directly.\n- (Type 3) Interact directly with HALs using low-level APIs or IPC interfaces.\n\nType 1 and 2 tests are typically instrumentation tests, while type 3 tests are\nusually GTests.\n\nWhat's next?\n------------\n\nHere is a list of documents that you can read for more detailed information:\n\n- If you haven't studied Android architecture, see\n [Architecture overview](/docs/core/architecture).\n\n- If you're creating an Android-compatible device, see\n the [Android compatibility program overview](/docs/compatibility/overview).\n\n- To integrate instrumentation, functional, metric, and JAR host tests\n into a platform continuous testing service, see\n [Test development workflow](/docs/core/tests/development).\n\n- To detect and harden your devices against vulnerabilities,\n see [Security testing](/docs/security/test/fuzz-sanitize).\n\n- To learn about testing your HAL and kernel implementations, see\n [Vendor Test Suite (VTS) and infrastructure](/docs/core/tests/vts).\n\n- For app testing, read\n [Fundamentals of testing Android\n apps](https://developer.android.com/training/testing/fundamentals)\n and conduct the [Advanced Android in Kotlin 05.1:Testing\n Basics](https://codelabs.developers.google.com/codelabs/advanced-android-kotlin-training-testing-basics/index.html)\n using the\n [samples](https://github.com/android/testing-samples) provided.\n\n- Learn about the basic presubmit testing available to you through repo hooks.\n These hooks can be used to run linters, check formatting, and trigger unit\n tests before proceeding, such as uploading a commit. These hooks are disabled\n by default. For further information, see [AOSP Preupload\n Hooks](https://android.googlesource.com/platform/tools/repohooks/+/refs/heads/android16-release/README.md).\n\n- To read more about logging, see [Understand logging](/docs/core/tests/debug/understanding-logging).\n\n- To understand how to debug Android code, see\n [Debug native Android platform code](/docs/core/tests/debug)."]]