2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Trade Federation の概要
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Trade Federation(Tradefed あるいは単に TF)は、Android デバイスでテストを実行するために設計された継続的なテスト フレームワークです。たとえば、Tradefed は互換性テストスイート(CTS)とベンダー テストスイート(VTS)を実行するために使用されます。
Trade Federation はホスト コンピュータ上で稼働する Java アプリケーションであり、adb を介して ddmlib(DDMS の背後にあるライブラリ)を使用して 1 つ以上の Android デバイスと通信します。
以下に、TF の主要な機能の一部といくつかのユースケースを示します。ただし、今すぐ開始する場合は、こちらから直接開始できます。
機能
- モジュール式、柔軟、スケーラブル デザイン
- instrumentation、uiautomator、native/gtest、ホストベースの JUnit など、さまざまな種類の Android テストを実行するためのサポートが組み込まれています。
- adb に信頼性と復元メカニズムを提供する
- 複数のデバイスに対するテストのスケジューリングと実行を並行して行う
Instrumentation などの既存のテストの実行方法については、TFC によるテストをご覧ください。
使用場面
Trade Federation のモジュール性により、既存のビルド、テスト、報告用のインフラストラクチャを備えた環境に簡単に対応できます。以下に、tradefed が効率的でスケーラブルなテスト慣行を実現できるデモ的なユースケースをいくつか紹介します。
まず、「変更可能な部分と静的部分」の観点で考えられるユースケースについて検討することが重要です。たとえば、デバイスの OEM はフレームワーク、システム、ハードウェアを変更できるものの、既存のアプリへの影響はほとんどまたはまったくありません。
一方、アプリ デベロッパーはアプリを変更できますが、システムやフレームワークの大部分については、ほとんど制御できません。
そのため、各ユースケースの当事者によってテスト目標が異なりますし、テストが失敗した場合の対応も異なります。このような違いにもかかわらず、Trade Federation は、各テストプロセスの効率性、柔軟性、スケーラビリティを高めるのに役立ちます。
デバイスの OEM
デバイス OEM はハードウェアを作成します。多くの場合、そのハードウェアで適切に動作するように Android システムとフレームワークを調整します。OEM は、ハードウェアやシステムレベルで安定性とパフォーマンスを維持しながら、フレームワークの目標を達成しようと努めており、フレームワークの変更が既存のアプリケーションとの互換性を損なわないようにする必要がある場合があります。
OEM は、ライフサイクルのターゲット セットアップ ステージで実行されるデバイスのフラッシュ モジュールを実装できます。そのモジュールでは、実行中にデバイスを完全に制御できます。そのため、デバイスをブートローダーに強制的にフラッシュしてフラッシュし、強制的にユーザー空間モードで再起動させることができます。これにより、モジュールを組み合わせて、システムレベルのファームウェアや Java レベルのフレームワークを変更しながら、OEM がデバイス上でテストを実行できます。
デバイスが完全に起動されると、OEM は既存の JUnit ベースのテストを活用したり、新しいテストを記述して目的の機能を検証したりすることができます。最後に、1 つ以上の結果レポート モジュールを作成して、既存のテスト結果リポジトリに関連付けるか、結果(メールなど)を直接報告します。
アプリのデベロッパー
アプリ デベロッパーは、さまざまなプラットフォーム バージョンとさまざまなデバイスで適切に動作する必要があるアプリをビルドします。特定のプラットフォーム バージョンやデバイスで問題が発生した場合は、回避策を追加して続行することが唯一の解決策となります。大規模なデベロッパーの場合は、継続的なビルドシーケンスにテストプロセスを組み込むことができます。小規模なデベロッパーの場合は、定期的にまたは手動で行われることもあります。
ほとんどのアプリ デベロッパーは、TF にすでに存在する APK テスト インストール モジュールを使用します。ローカル ファイル システムからインストールするバージョンと、ビルドサービスからダウンロードした apk をインストールできるバージョンがあります。古いバージョンは、同じホストマシン上で実行されている多数の TF インスタンスで引き続き正常に動作することに注意してください。
TF は複数のデバイスを扱うための高度なスキルを備えているため、各テスト結果をそのテストに使用されたデバイスタイプで簡単に分類できます。そのため、TF は、アプリケーションのビルドごとに 2 次元(または多次元)互換性マトリックスを生成する可能性があります。
検査サービス
たとえば、テストサービスの場合、アプリ デベロッパーは、電力測定ツールを操作したデバイスでアプリを送信して、アプリの電力消費を確認することで、テストを行うことができます。上述の 2 つのユースケースは、サービス ビルダーが実行中のデバイスまたはアプリケーションを制御しないという点で異なります。
Trade Federation はシンプルな IRemoteTest
インターフェースを実装するすべての Java クラスを実行できるため、デバイスで実行されるテストケースを使用して、外部のハードウェアの一部を調整できるドライバを作成するのは簡単です。ドライバ自体は、スレッドを生成したり、他のサーバーにリクエストを送信したり、その他に必要な処理を実行したりできます。さらに、結果レポート インターフェース ITestInvocationListener
の単純性と汎用性により、任意のテスト結果(たとえば、数値による電力指標など)を標準的な結果レポート パイプラインに取り込むのが容易になります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は 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."]]