2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
Trade Federation 개요
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Trade Federation(Tradefed, TF)은 Android 기기에서의 테스트 실행을 위해 고안된 연속 테스트 프레임워크입니다. 예를 들어 Tradefed는 호환성 테스트 모음(CTS) 및 공급업체 테스트 모음(VTS)을 실행하는 데 사용됩니다.
Trade Federation은 호스트 컴퓨터에서 실행되는 자바 애플리케이션이며, adb를 통해 ddmlib(DDMS의 배경에서 실행되는 라이브러리)를 사용하여 1개 이상의 Android 기기와 통신합니다.
아래에는 TF의 몇몇 주요 기능과 샘플 사용 사례가 나열되어 있습니다. 바로 시작하고 싶다면 여기서 시작 페이지로 바로 이동하세요.
기능
- 유연하고 확장 가능한 모듈식 설계
- 계측, uiautomator, 네이티브/gtest, 호스트 기반 JUnit을 비롯한 여러 수많은 Android 테스트 유형을 기본으로 실행할 수 있도록 지원
- adb 외의 안정성 및 복구 메커니즘 제공
- 여러 기기에서 테스트를 병렬 방식으로 예약하고 실행할 수 있도록 지원
계측과 같은 기존 테스트를 실행하는 방법에 관한 최신 정보는 TF를 통한 테스트를 참고하세요.
사용 사례
Trade Federation의 모듈성은 기존 빌드, 테스트 및 보고 인프라를 환경에 쉽게 끼워넣을 수 있게 해줍니다. 아래에는 tradefed로 효율적이고 확장 가능한 테스트 관행을 지원할 수 있는 몇 가지 시범적 사용 사례가 나열되어 있습니다.
우선 '어떤 부분이 수정 가능하고 어떤 부분이 고정적인가?'라는 질문으로 잠재적인 사용 사례의 환경을 고려해 보세요. 예를 들어 기기 OEM은 프레임워크, 시스템 및 하드웨어를 수정할 수 있지만 기존 애플리케이션에 대한 영향은 거의 없습니다.
반면에 애플리케이션 개발자는 앱을 수정할 수 있지만 시스템이나 프레임워크에 관한 대부분의 측면을 제어할 수 없습니다.
결과적으로는 각 사용 사례의 개체마다 테스트 목적이 다르며, 테스트 실패 집합의 경우에는 다른 옵션이 주어지게 됩니다. 이러한 차이에도 불구하고 Trade Federation은 각 테스트 프로세스에 효율성, 유연성과 확장성을 부여할 수 있습니다.
기기 OEM
기기 OEM은 하드웨어를 빌드하며, Android 시스템과 프레임워크가 하드웨어에서 제대로 실행되도록 조정할 때가 많습니다. OEM은 이러한 목표를 달성하는 동시에 하드웨어 및 시스템 수준의 안정성과 성능을 유지하고, 프레임워크 변경으로 기존 애플리케이션과의 호환성이 무너지지 않도록 하려고 노력합니다.
OEM은 수명 주기의 타겟 설정 단계가 진행되는 동안 실행될 기기 플래싱 모듈을 구현할 수 있습니다. 이 모듈은 실행 기간 동안 기기를 온전히 제어할 수 있으며, 이 경우 기기에 부트로더, 플래시를 강제한 다음 기기가 다시 사용자 공간 모드로 재부팅되도록 강제할 수 있습니다. 모듈과 결합하여 연속 빌드 시스템에 연결하면 OEM은 시스템 수준 펌웨어와 자바 수준 프레임워크를 변경하면서 기기에서 테스트를 실행할 수 있습니다.
기기가 완전히 부팅되면 OEM은 기존 JUnit 기반 테스트를 활용하거나 새 테스트를 작성하여 관심 기능을 검증할 수 있습니다. 마지막으로 OEM은 1개 이상의 결과 보고 모듈을 작성하여 기존 테스트 결과 저장소에 연결하거나 이메일 등을 사용하여 결과를 직접 보고할 수도 있습니다.
앱 개발자
애플리케이션 개발자는 다양한 플랫폼 버전과 기기에 걸쳐 원활하게 실행되어야 하는 앱을 빌드합니다. 특정 플랫폼 버전이나 기기에 문제가 발생하는 경우에는 해결 방법을 추가하고 넘어가는 것이 유일한 해결책입니다. 대규모 개발자의 경우 테스트 프로세스가 연속 빌드 순서로 통합될 수 있습니다. 소규모 개발자의 경우에는 주기적으로 또는 수동으로 시작될 수 있습니다.
대부분의 앱 개발자는 TF에 이미 존재하는 APK 테스트 설치 모듈을 사용합니다.
로컬 파일 시스템에서 설치하는 버전과 빌드 서비스에서 다운로드한 APK를 설치할 수 있는 버전이 있습니다. 두 번째 버전은 동일한 호스트 시스템에서 실행되는 임의의 수많은 TF 인스턴스와 계속해서 원활하게 작동한다는 점에 주목하는 것이 중요합니다.
TF는 여러 기기를 능숙하게 처리할 수 있어 각 테스트 결과를 테스트에 사용된 기기 유형별로 간단하게 분류합니다. 따라서 TF는 애플리케이션의 모든 빌드에 대한 2차원적 또는 다차원적 호환성 행렬을 생성할 수도 있습니다.
테스트 서비스
테스트 서비스는 예를 들어 앱 개발자가 전력 측정 도구로 계측화한 기기에서 앱을 제출하고 테스트를 실행하여 앱의 전력 소비량을 파악할 수 있게 해줍니다. 이는 서비스 빌더가 실행 중인 기기나 애플리케이션을 제어하지 않는다는 점에서 이전의 두 사용 사례와 차이를 보입니다.
Trade Federation은 단순한 IRemoteTest 인터페이스를 구현하는 모든 자바 클래스를 실행할 수 있기 때문에, 하드웨어의 일부 외부 구성요소와 기기에서 실행되고 있는 테스트 사례를 조율할 수 있는 드라이버를 작성하는 작업이 그렇게 중요하지 않습니다. 드라이버는 그 자체로 스레드를 생성하거나 요청을 다른 서버에 전송하거나 필요한 모든 작업을 수행할 수 있습니다. 더 나아가 결과 보고 인터페이스인 ITestInvocationListenerITestInvocationListener의 단순성과 다용성 덕분에 임의의 테스트 결과(예: 전력 측정항목 수치)를 표준 결과 보고 파이프라인에 표시하는 과정도 간단합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Trade Federation overview\n\nTrade Federation (Tradefed or TF for short) is a continuous test framework designed for running\ntests on Android devices. For example, Tradefed is used to run the\n[Compatibility Test Suite (CTS)](/docs/compatibility/cts) and\n[Vendor Test Suite (VTS)](/docs/core/tests/vts).\n\nTrade Federation is a Java application which runs on a host computer, and communicates to one or\nmore Android devices using ddmlib (the library behind DDMS) over adb.\n\nWe've listed some of TF's main features below, along with a couple sample usecases. That said,\nif you want to jump right in and get started, you can head straight for the\n[Start Here](/docs/core/tests/tradefed/fundamentals) page.\n\nFeatures\n--------\n\n- modular, flexible, scalable design\n- has built in support for running many different types of Android tests: [instrumentation](https://developer.android.com/studio/test#create_instrumented_test_for_a_build_variant), [uiautomator](https://developer.android.com/training/testing/ui-testing), native/gtest, host-based JUnit, etc\n- provides reliability and recovery mechanisms on top of adb\n- supports scheduling and running tests on multiple devices in parallel\n\nSee [Testing Through TF](/docs/core/tests/tradefed/testing/through-tf)\nfor the most up-to-date information about how to run your existing tests, such as\n[Instrumentation](/docs/core/tests/tradefed/testing/through-tf/instrumentation).\n\nUse cases\n---------\n\nTrade Federation's modularity makes it straightforward to slot into environments with existing\nbuild, test, and reporting infrastructures. We list below a few demonstrative\nusecases where tradefed could enable efficient, scalable test practices.\n\nFirst, it is useful to consider the landscape of potential usecases in terms of the question\n\"which parts are modifiable, and what parts are static?\" For instance, a Device OEM can modify the\nframework, the system, and the hardware, but has little or no influence over existing applications.\nAn application developer, on the other hand, can modify the app, but has little control over most\naspects of the system or the framework.\n\nAs a result, an entity in each usecase will have different testing goals, and will have different\noptions in the case of a set of test failures. Despite these differences, Trade Federation can\nhelp make each of their test processes efficient, flexible, and scalable.\n\n### Device OEM\n\nA Device OEM builds hardware, and will often tweak the Android system and frameworks to run well\non that hardware. The OEM might strive to accomplish those goals while retaining stability\nand performance at the hardware and system levels, and making sure the framework changes don't break\ncompatibility with existing applications.\n\nThe OEM could implement a device flashing module that will execute during the Target Setup stage\nof the [lifecycle](/docs/core/tests/tradefed/fundamentals/lifecycle). That\nmodule would have complete control over the device during its execution period, which would allow\nit to potentially force the device into the bootloader, flash, and then force the device to reboot\nback into userspace mode. Combined with a module to tie into a continuous build system, this would\nallow the OEM to run tests on their device as they make changes to the system-level firmware and\nJava-level frameworks.\n\nOnce the device is fully booted, the OEM would be able to leverage existing JUnit-based tests,\nor write new ones, to verify the functionality of interest. Finally, they could write one or more\nresult reporting modules to tie into existing test-result repositories, or to report results\ndirectly (for instance,\n[by email](/reference/com/android/tradefed/result/EmailResultReporter)).\n\n### App developer\n\nAn Application Developer builds an app which needs to run well across a variety of platform\nversions and a variety of devices. If an issue comes up on a particular platform version and/or\ndevice, the only remedy is to add a workaround and move on. For larger developers, the test\nprocess might be incorporated into a continuous build sequence. For smaller developers, it\nmight be kicked off periodically or by hand.\n\nMost app developers would use the apk test installation modules that already exist in TF.\nThere's a version that [installs from the local filesystem](/reference/com/android/tradefed/targetprep/InstallApkSetup), as well as a version that can\n[install\napks downloaded from a build service](/reference/com/android/tradefed/targetprep/InstallBuildEnvApkSetup). It is important to note that the latter version would\ncontinue to work properly with arbitrarily many TF instances running on the same host machine.\n\nBecause of TF's proficiency at dealing with multiple devices, it would be straightforward to\nclassify each test result by the type of device that was used for that test. Thus, TF could\npotentially generate a 2-dimensional (or multi-dimensional) compatibility matrix for every\nbuild of the application.\n\n### Testing service\n\nA Test Service might, for instance, allow app developers to submit apps and run tests on devices\ninstrumented with power-measurement tools to determine power usage for the app. This differs from\nthe prior two usecases in that the service builder does not control the devices or the applications\nthat are being run.\n\nBecause Trade Federation can run any Java class that implements the simple\n[`IRemoteTest`](/reference/com/android/tradefed/testtype/IRemoteTest) interface, it's\ntrivial to write drivers that can coordinate some external piece of hardware with the test case\nthat's being run on the device. The driver itself can spawn Threads, send requests to other\nservers, or do anything else that it might need. Moreover, the simplicity and versatility of the\nresult reporting interface,\n[`ITestInvocationListener`](/reference/com/android/tradefed/result/ITestInvocationListener), means that it is likewise straightforward to\nrepresent arbitrary test results (including, for instance, numerical power metrics) into the\nstandard result reporting pipeline."]]
