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.
Kiểm thử nền tảng Android
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.
Dự án nguồn mở Android (AOSP) cung cấp một số công cụ và bộ kiểm thử để kiểm thử nhiều phần trong quá trình triển khai. Trước khi sử dụng các trang trong phần này, bạn nên làm quen với các thuật ngữ sau:
- Thiết bị tương thích với Android
- Thiết bị có thể chạy mọi ứng dụng bên thứ ba do các nhà phát triển bên thứ ba viết bằng SDK và NDK của Android. Thiết bị tương thích với Android phải tuân thủ các yêu cầu của Tài liệu định nghĩa về khả năng tương thích (CDD) và vượt qua Bộ kiểm thử tính tương thích (CTS). Các thiết bị tương thích với Android đủ điều kiện tham gia hệ sinh thái Android, bao gồm cả việc có thể được cấp phép cho Google Play, có thể được cấp phép cho bộ ứng dụng và API Dịch vụ của Google dành cho thiết bị di động (GMS), cũng như có thể sử dụng nhãn hiệu Android. Mọi người đều có thể sử dụng mã nguồn Android, nhưng để được coi là một phần của hệ sinh thái Android, thiết bị phải tương thích với Android.
- cấu phần phần mềm
- Nhật ký liên quan đến bản dựng cho phép khắc phục sự cố cục bộ.
- Tài liệu định nghĩa về khả năng tương thích (CDD)
- Tài liệu liệt kê các yêu cầu về phần mềm và phần cứng đối với thiết bị tương thích với Android.
- Bộ kiểm tra tính tương thích (CTS)
Một bộ kiểm thử miễn phí, cấp thương mại, có thể tải xuống dưới dạng tệp nhị phân hoặc nguồn trong AOSP. CTS là một tập hợp các bài kiểm thử đơn vị được thiết kế để tích hợp vào quy trình làm việc hằng ngày của bạn. Mục đích của CTS là phát hiện các điểm không tương thích và đảm bảo rằng phần mềm vẫn tương thích trong suốt quá trình phát triển.
CTS và kiểm thử nền tảng không loại trừ lẫn nhau. Sau đây là một số nguyên tắc chung:
- Nếu một kiểm thử xác nhận tính chính xác của các hàm hoặc hành vi API khung và kiểm thử đó phải được thực thi trên các đối tác OEM, thì kiểm thử đó phải nằm trong CTS.
- Nếu một kiểm thử nhằm mục đích phát hiện sự hồi quy trong quá trình phát triển nền tảng, có thể yêu cầu quyền đặc quyền để thực hiện và có thể phụ thuộc vào thông tin chi tiết về việc triển khai (như được phát hành trong AOSP), thì đó phải là kiểm thử nền tảng.
- Các dịch vụ của Google dành cho thiết bị di động (GMS)
Một tập hợp các ứng dụng và API của Google có thể được cài đặt sẵn trên thiết bị.
- GoogleTest (GTest)
Khung kiểm thử và mô phỏng C++. Tệp nhị phân GTest thường truy cập vào các lớp trừu tượng cấp thấp hơn hoặc thực hiện IPC thô đối với nhiều dịch vụ hệ thống. Phương pháp kiểm thử cho GTest thường được ghép nối chặt chẽ với dịch vụ đang được kiểm thử. CTS chứa khung GTest.
- kiểm thử đo lường
Môi trường thực thi kiểm thử đặc biệt do lệnh am instrument
khởi chạy, trong đó quy trình ứng dụng được nhắm mục tiêu được khởi động lại và khởi chạy bằng ngữ cảnh ứng dụng cơ bản, đồng thời một luồng đo lường được bắt đầu bên trong máy ảo quy trình ứng dụng. CTS chứa các chương trình kiểm thử đo lường.
- Logcat
Một công cụ dòng lệnh tạo nhật ký thông báo của hệ thống, bao gồm dấu vết ngăn xếp khi thiết bị báo lỗi và thông báo mà bạn đã viết trong ứng dụng của mình bằng lớp Log
.
- ghi nhật ký
Sử dụng nhật ký để theo dõi các sự kiện hệ thống máy tính, chẳng hạn như lỗi. Việc ghi nhật ký trong Android rất phức tạp do sự kết hợp của các tiêu chuẩn được sử dụng được kết hợp trong công cụ Logcat.
- kiểm thử postsubmit
Một kiểm thử Android được thực hiện khi một bản vá mới được cam kết cho một nhánh nhân phổ biến. Bằng cách nhập aosp_kernel
làm một phần tên nhánh, bạn có thể thấy danh sách các nhánh hạt nhân có kết quả. Ví dụ: bạn có thể xem kết quả cho android-mainline
tại https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.
- kiểm thử trước khi gửi
Một kiểm thử dùng để ngăn chặn việc đưa lỗi vào nhân phổ biến.
- Liên minh thương mại
Còn gọi là Tradefed, một khung kiểm thử liên tục được thiết kế để chạy kiểm thử trên các thiết bị Android. Ví dụ: Tradefed được dùng để chạy các bài kiểm thử trong Bộ kiểm thử tính tương thích và Bộ kiểm thử nhà cung cấp.
- Bộ kiểm thử nhà cung cấp (VTS)
Một bộ tính năng mở rộng để kiểm thử Android, thúc đẩy quy trình phát triển dựa trên kiểm thử và tự động hoá lớp trừu tượng phần cứng (HAL) và kiểm thử hạt nhân hệ điều hành.
Các loại kiểm thử nền tảng
Kiểm thử nền tảng thường tương tác với một hoặc nhiều dịch vụ hệ thống Android hoặc lớp HAL, thực thi các chức năng của đối tượng đang được kiểm thử và xác nhận tính chính xác của kết quả kiểm thử. Kiểm thử nền tảng có thể:
- (Loại 1) Thực hành các API khung bằng khung Android. Các API cụ thể đang được thực thi có thể bao gồm:
- API công khai dành cho ứng dụng bên thứ ba
- API ẩn dành cho các ứng dụng đặc quyền, cụ thể là API hệ thống hoặc API riêng tư (
@hide
hoặc protected
, package private
)
- (Loại 2) Gọi các dịch vụ hệ thống Android bằng cách sử dụng trình liên kết thô hoặc proxy IPC trực tiếp.
- (Loại 3) Tương tác trực tiếp với HAL bằng các API cấp thấp hoặc giao diện IPC.
Các bài kiểm thử loại 1 và 2 thường là kiểm thử đo lường, còn các bài kiểm thử loại 3 thường là GTests.
Tiếp theo là gì?
Sau đây là danh sách tài liệu mà bạn có thể đọc để biết thêm thông tin chi tiết:
Nếu bạn chưa tìm hiểu về cấu trúc Android, hãy xem phần Tổng quan về cấu trúc.
Nếu bạn đang tạo một thiết bị tương thích với Android, hãy xem tổng quan về chương trình tương thích của Android.
Để tích hợp các bài kiểm thử đo lường, chức năng, chỉ số và máy chủ lưu trữ JAR vào dịch vụ kiểm thử liên tục của nền tảng, hãy xem Quy trình phát triển kiểm thử.
Để phát hiện và tăng cường bảo mật cho thiết bị của bạn khỏi các lỗ hổng, hãy xem phần Kiểm thử bảo mật.
Để tìm hiểu về cách kiểm thử việc triển khai HAL và hạt nhân, hãy xem phần Bộ kiểm thử nhà cung cấp (VTS) và cơ sở hạ tầng.
Để kiểm thử ứng dụng, hãy đọc bài viết Kiến thức cơ bản về kiểm thử ứng dụng Android và thực hiện bài tập Kotlin nâng cao cho Android 05.1:Kiến thức cơ bản về kiểm thử bằng cách sử dụng mẫu được cung cấp.
Tìm hiểu về quy trình kiểm thử cơ bản trước khi gửi thông qua các trình bổ trợ kho lưu trữ.
Bạn có thể dùng các trình bổ trợ này để chạy trình tìm lỗi mã nguồn, kiểm tra định dạng và kích hoạt các chương trình kiểm thử đơn vị trước khi tiếp tục, chẳng hạn như tải một thay đổi lên. Các trình bổ trợ này bị tắt theo mặc định. Để biết thêm thông tin, hãy xem phần Công cụ đăng tải trước AOSP.
Để đọc thêm về việc ghi nhật ký, hãy xem bài viết Tìm hiểu về việc ghi nhật ký.
Để tìm hiểu cách gỡ lỗi mã Android, hãy xem bài viết Gỡ lỗi mã gốc trên nền tảng Android.
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,["# 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)."]]