自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
貿易聯盟總覽
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Trade Federation (簡稱 Tradefed 或 TF) 是一種持續測試架構，專門用於在 Android 裝置上執行測試。舉例來說，Tradefed 可用於執行 Compatibility Test Suite (CTS) 和 Vendor Test Suite (VTS)。
Trade Federation 是執行於主機電腦上的 Java 應用程式，會透過 ADB 使用 ddmlib (DDMS 背後的程式庫) 與一或多部 Android 裝置通訊。
我們在下方列出 TF 的一些主要功能，以及幾個範例用途。不過，如果您想直接開始使用，可以直接前往「從這裡開始」頁面。
功能
- 模組化、靈活且可擴充的設計
- 內建支援執行多種不同類型的 Android 測試：檢測、uiautomator、原生/gtest、主機 JUnit 等
- 在 ADB 之上提供可靠性和復原機制
- 支援在多部裝置上並行排程及執行測試
如要進一步瞭解如何執行現有測試 (例如檢測設備)，請參閱「透過 TF 進行測試」一文。
用途
Trade Federation 的模組化設計，可讓您輕鬆在現有建構、測試和報表基礎架構的環境中，加入 Trade Federation。以下列出幾個示範用例，說明 tradefed 如何實現高效且可擴充的測試做法。
首先，請從「哪些部分可修改，哪些部分為靜態？」這類問題的角度，考量潛在用途。舉例來說，裝置 OEM 可以修改架構、系統和硬體，但對現有應用程式幾乎沒有影響。另一方面，應用程式開發人員可以修改應用程式，但對系統或架構的大部分方面幾乎沒有控制權。
因此，每個用途中的實體都會有不同的測試目標，並且在發生一組測試失敗的情況下，會有不同的選項。儘管這些差異存在，Trade Federation 仍可協助各自的測試流程，讓其更有效率、更具彈性且可擴充。
裝置原始設備製造商
裝置原始設備製造商 (OEM) 會建構硬體，並經常調整 Android 系統和架構，以便在該硬體上順利執行。原始設備製造商 (OEM) 可能會努力達成這些目標，同時維持硬體和系統層級的穩定性和效能，並確保架構變更不會影響與現有應用程式的相容性。
原始設備製造商 (OEM) 可以實作裝置閃燈模組，在生命週期的目標設定階段執行。該模組在執行期間可完全控制裝置，因此可能會強制裝置進入系統啟動載入程式、閃記，然後強制裝置重新啟動至使用者空間模式。搭配模組連結至持續建構系統，這可讓原始設備製造商在變更系統層級韌體和 Java 層級架構時，在裝置上執行測試。
裝置完全啟動後，原始設備製造商 (OEM) 即可利用現有的 JUnit 測試，或編寫新的測試，以驗證所需的功能。最後，他們可以編寫一或多個結果回報模組，以連結現有的測試結果存放區，或直接回報結果 (例如透過電子郵件)。
應用程式開發人員
應用程式開發人員會建構應用程式，而這些應用程式必須能在各種平台版本和裝置上順利執行。如果在特定平台版本和/或裝置上發生問題，唯一的解決方法就是新增應變措施，然後繼續進行。對於規模較大的開發人員，測試程序可能會整合至持續建構序列。對於規模較小的開發人員，這項作業可能會定期或手動啟動。
大多數應用程式開發人員會使用 TF 中現有的 APK 測試安裝模組。其中一個版本可從本機檔案系統安裝，另一個版本則可安裝從建構服務下載的 APK。請注意，後者版本會繼續正常運作，在同一台主機上執行任意數量的 TF 例項。
由於 TF 擅長處理多種裝置，因此可以根據測試所用裝置的類型，輕鬆分類每個測試結果。因此，TF 可能會為應用程式的每個版本產生 2D (或多維) 相容性矩陣。
測試服務
舉例來說，測試服務可能會允許應用程式開發人員在使用電量測量工具的裝置上提交應用程式並執行測試，以便判斷應用程式的電量使用情形。這與前述兩種用途不同，因為服務建構工具不會控制裝置或正在執行的應用程式。
由於 Trade Federation 可執行任何實作簡單 IRemoteTest 介面的 Java 類別，因此只要編寫驅動程式，就能讓裝置上的測試案例與某些外部硬體協調。驅動程式本身可以產生執行緒、向其他伺服器傳送要求，或執行其他可能需要的操作。此外，由於結果回報介面 ITestInvocationListener 簡單又多功能，因此您也可以輕鬆將任意測試結果 (包括數值功率指標等) 轉換為標準結果回報管道。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],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."]]
