自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
Android 平台测试
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 开源项目 (AOSP) 提供了多种工具和测试套件,用于测试实现的各个部分。在参阅本部分中的页面之前,您应该熟悉以下术语:
- 与 Android 兼容的设备
- 可运行由第三方开发者使用 Android SDK 和 NDK 编写的任何第三方应用的设备。与 Android 兼容的设备必须遵守兼容性定义文档 (CDD) 中的要求,并通过兼容性测试套件 (CTS) 的测试。与 Android 兼容的设备有资格加入 Android 生态,其中包括获得 Google Play 和 Google 移动服务 (GMS) 应用和 API 套件的潜在许可,以及对 Android 商标的使用。我们欢迎任何人使用 Android 源代码,但要成为 Android 生态系统的一部分,设备必须与 Android 兼容。
- 工件
- 与 build 相关的日志,用于支持本地问题排查。
- 兼容性定义文档 (CDD)
- 一种文档,列出了与 Android 兼容的设备应遵循的软件和硬件要求。
- 兼容性测试套件 (CTS)
一个免费的商业级测试套件,可以下载二进制文件版本,也可以在 AOSP 中下载源代码版本。CTS 是一组单元测试,旨在集成到您的日常工作流程中。CTS 的目的是发现不兼容性,并确保软件在整个开发过程中保持兼容性。
CTS 和平台测试并不互斥。下面列出了一些一般准则:
- 如果测试断言框架 API 函数或行为的正确性,并且应该在 OEM 合作伙伴之间强制执行测试,那么它应该在 CTS 中。
- 如果测试的意图是在平台开发期间捕捉回归,并且可能需要特许权限来执行,还可能依赖于实现细节(如 AOSP 中所发布),那么它应为平台测试。
- Google 移动服务 (GMS)
可在设备上预安装的一系列 Google 应用和 API。
- GoogleTest (GTest)
一个 C++ 测试和模拟框架。GTest 二进制文件通常会访问较低级别的抽象层,或针对各种系统服务执行原始 IPC。GTest 的测试方法通常与接受测试的服务密切相关。CTS 包含 GTest 框架。
- 插桩测试
由 am instrument
命令启动的特殊测试执行环境,其中目标应用进程会重新启动并使用基本的应用上下文进行初始化,并且会在应用进程虚拟机内启动插桩线程。CTS 包含插桩测试。
- Logcat
Logcat 是一个命令行工具,用于创建系统消息日志,包括设备抛出错误时的堆栈轨迹,以及从您的应用使用 Log
类写入的消息。
- 日志记录
使用日志来记录计算机系统事件,例如错误。由于在 Logcat tool 中合并使用了多个标准,Android 中的日志记录较为复杂。
- 提交后测试
在新的补丁提交到通用内核分支后执行的 Android 测试。通过输入 aosp_kernel
作为部分分支名称,您会看到具有结果的内核分支列表。例如,可以在 https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid 上找到 android-mainline
的结果。
- 提交前测试
用于防止在通用内核中引入故障的测试。
- Trade Federation
也称为 Tradefed,是一种连续的测试框架,专门用于在 Android 设备上运行测试。例如,Tradefed 可用于运行兼容性测试套件和供应商测试套件测试。
- 供应商测试套件 (VTS)
一组用于 Android 测试的丰富功能,能够促进由测试驱动的开发流程,并自动执行硬件抽象层 (HAL) 和 OS 内核测试。
平台测试类型
平台测试通常与一个或多个 Android 系统服务或 HAL 层交互、执行受测对象的功能,并断言测试结果的正确性。平台测试可能会:
- (类型 1)使用 Android 框架执行框架 API。执行的特定 API 可能包括:
- 用于第三方应用的公共 API
- 用于特权应用的隐藏 API,即系统 API 或私有 API(
@hide
或 protected
、package private
)
- (类型 2)直接使用原始 binder 或 IPC 代理调用 Android 系统服务。
- (类型 3)使用低级别 API 或 IPC 接口直接与 HAL 交互。
类型 1 和 2 的测试通常是插桩测试,而类型 3 的测试通常是 GTest。
后续操作
若要了解更多详细信息,请参阅下面列出的文档:
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-03-26。"],[],[],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)."]]