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 とプラットフォーム テストは相互に排他的ではありません。一般的なガイドラインは次のとおりです。
- フレームワーク API の機能や動作の正当性をアサーションで検証する目的で、OEM パートナー間でテストを実施する場合は、CTS で行う必要があります。
- プラットフォーム開発中にリグレッションをキャッチするための回帰テストで、実行するために特権的な許可が必要で、実装の詳細(AOSP でリリースされたとおり)に依存する場合、プラットフォーム テストを行う必要があります
- Google モバイル サービス(GMS)
デバイスにプリインストールできる Google アプリおよび API の集合。
- GoogleTest(GTest)
C++ のテストおよびモック フレームワークです。通常、GTest バイナリは、低レベル抽象化レイヤにアクセスするか、さまざまなシステム サービスに対して raw IPC を実行します。GTest のテスト方法は通常、テスト対象のサービスと密接に関連しています。CTS には GTest フレームワークが含まれています。
- インストルメンテーション テスト
am instrument
コマンドによって起動される特別なテスト実行環境です。この環境でターゲット アプリプロセスが再起動され、基本アプリ コンテキストで初期化されて、アプリプロセス仮想マシン内でインストルメンテーション スレッドが起動されます。CTS にはインストルメンテーション テストが含まれています。
- Logcat
デバイスがエラーをスローしたときのスタック トレースや、Log
クラスを使用してアプリから書き込んだメッセージなど、システム メッセージのログを作成するコマンドライン ツールです。
- ロギング
ログを使用してコンピュータ システムのイベント(エラーなど)を追跡します。Android におけるロギングは、さまざまな規格が使用されて Logcat ツールに組み込まれているため、複雑になっています。
- postsubmit テスト
共通カーネル ブランチに新しいカーネルが commit されるときに実施される Android テストです。ブランチ名の一部として aosp_kernel
を入力すると、該当するカーネル ブランチの結果がリスト表示されます。たとえば、android-mainline
の結果は https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid で確認できます。
- presubmit テスト
共通カーネルにエラーが入り込むのを防ぐために使用されるテストです。
- Trade Federation
Android デバイスでテストを実行するために設計された継続的なテスト フレームワークです(Tradefed とも呼ばれます)。たとえば、Tradefed は互換性テストスイートとベンダー テストスイートを実行するために使用されます。
- ベンダー テストスイート(VTS)
Android のテスト用に提供される幅広い機能です。テスト駆動開発プロセスを推進して、Hardware Abstraction Layer(HAL)と OS カーネルのテストを自動化します。
プラットフォーム テストのタイプ
プラットフォーム テストは通常、1 つ以上の 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 です。
次のステップ
以下は、詳細情報を確認できるドキュメントの一覧です。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 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-03-26 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)."]]