2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
Android 플랫폼 테스트
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 오픈소스 프로젝트 (AOSP)는 다양한 구현 부분을 테스트하는 여러 도구와 테스트 모음을 제공합니다. 이 섹션의 페이지를 사용하기 전에 다음 용어를 숙지해야 합니다.
- Android 호환 기기
- Android SDK 및 NDK를 사용하여 서드 파티 개발자가 작성한 서드 파티 앱을 실행할 수 있는 기기입니다. Android 호환 기기는 호환성 정의 문서(CDD)의 요구사항을 준수하고 호환성 테스트 모음(CTS)을 통과해야 합니다. Android 호환 기기는 Android 생태계에 참여할 수 있습니다. 여기에는 Google Play의 잠재적 라이선스와 Google 모바일 서비스 (GMS) 앱 및 API 모음 관련 잠재적 라이선스, Android 상표 사용이 포함됩니다. 누구나 Android 소스 코드를 사용할 수 있지만 Android 생태계의 일부로 간주되려면 기기가 Android와 호환되어야 합니다.
- 아티팩트
- 로컬 문제 해결을 지원하는 빌드 관련 로그입니다.
- 호환성 정의 문서(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
기기에서 오류와 메시지가 발생할 때의 스택 트레이스를 비롯하여 시스템 메시지의 로그를 만드는 명령줄 도구입니다. 이러한 오류와 메시지는 앱에서 Log
클래스로 작성한 것입니다.
- 로깅
로그를 사용하여 오류와 같은 컴퓨터 시스템 이벤트를 추적합니다. Android의 로깅은 Logcat 도구에 결합된 표준이 혼합되어 사용되므로 복잡합니다.
- 사후 제출 테스트
새 패치가 일반 커널 브랜치에 커밋될 때 실행되는 Android 테스트입니다. 부분 브랜치 이름으로 aosp_kernel
을 입력하면 사용 가능한 결과가 있는 커널 브랜치 목록이 표시됩니다. 예를 들어 android-mainline
결과는 다음에서 확인할 수 있습니다. https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid
- 사전 제출 테스트
일반 커널에 장애가 도입되는 것을 방지하는 데 사용되는 테스트입니다.
- Trade Federation
Trade Federation(Tradefed)은 Android 기기에서 테스트를 실행하기 위해 고안된 연속 테스트 프레임워크입니다. 예를 들어 Tradefed는 호환성 테스트 모음 및 공급업체 테스트 모음 테스트를 실행하는 데 사용됩니다.
- 공급업체 테스트 모음(VTS)
Android 테스트를 위한 광범위한 기능을 제공하고, 테스트 기반 개발 프로세스를 촉진하며, 하드웨어 추상화 계층 (HAL) 및 OS 커널 테스트를 자동화하는 기능 모음입니다.
플랫폼 테스트 유형
플랫폼 테스트는 일반적으로 하나 이상의 Android 시스템 서비스 또는 HAL 계층과 상호작용하고 테스트 대상의 기능을 실행하며 테스트 결과의 정확성을 보장합니다. 플랫폼 테스트는 다음과 같을 수 있습니다.
- (유형 1) Android 프레임워크를 사용하여 프레임워크 API를 실행합니다. 실행되는 특정 API에는 다음이 포함될 수 있습니다.
- 서드 파티 앱용 공개 API
- 권한이 있는 앱을 위한 숨겨진 API, 즉 시스템 API 또는 비공개 API (
@hide
, 또는 protected
, package private
)
- (유형 2) 원시 바인더 또는 IPC 프록시를 직접 사용하여 Android 시스템 서비스를 호출합니다.
- (유형 3) 하위 수준 API 또는 IPC 인터페이스를 사용하여 HAL과 직접 상호작용합니다.
유형 1과 유형 2 테스트는 일반적으로 계측 테스트이며 유형 3 테스트는 보통 GTest입니다.
다음 단계
다음은 자세한 내용을 확인할 수 있는 문서 목록입니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 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)."]]