2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Android Open Accessory 1.0
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android USB アクセサリーは、Android Open Accessory(AOA)プロトコルに準拠する必要があります。AOA プロトコルは、アクセサリーによる Android 搭載デバイスとの通信の検出方法と設定方法を定義したものです。アクセサリーは次の手順に従う必要があります。
- デバイスとの接続を待ち、検出します。
- デバイスがアクセサリー モードをサポートしているか判別します。
- 必要に応じて、デバイスをアクセサリー モードで起動させます。
- デバイスが AOA をサポートしていれば、デバイスとの通信を確立します。
以降のセクションでは、これらの手順の実装方法について説明します。
デバイス接続を待機して検出する
アクセサリーは、Android 搭載デバイスとの接続を継続的に確認する必要があります。デバイスが接続されたら、デバイスがアクセサリー モードをサポートしているかどうかを判別します。
アクセサリー モードのサポートを判別する
注: アクセサリーの接続に USB デバッグは必要ありませんが、開発中は ADB が必要になる場合があります。詳しくは、デバッグに関する考慮事項をご覧ください。
Android 搭載デバイスが接続されると、次の 3 つの状態のいずれかになります。
- Android アクセサリー モードをサポートしており、アクセサリー モードになっている。
- Android アクセサリー モードをサポートしているが、アクセサリー モードにはなっていない。
- Android アクセサリー モードをサポートしていない。
アクセサリーは、最初の接続時に、接続されたデバイスの USB デバイス記述子に含まれているバージョン、ベンダー ID、プロダクト ID を確認します。ベンダー ID は Google の ID(0x18D1
)と一致する必要があります。デバイスがすでにアクセサリー モードになっている場合、プロダクト ID は 0x2D00
または 0x2D01
でなければなりません。アクセサリーは独自の通信プロトコルを使用して、一括転送エンドポイント経由でデバイスとの通信を確立できます(デバイスをアクセサリー モードで起動する必要はありません)。
注: 0x2D00
は、アクセサリー モードをサポートする Android 搭載デバイス用に予約された ID です。0x2D01
は、アクセサリー モードと Android Debug Bridge(ADB)プロトコルをサポートするデバイス用に予約された ID です。このプロトコルは、ADB 用の 2 つの一括エンドポイントを持つ第 2 のインターフェースを公開します。パソコンでアクセサリーをシミュレートする場合は、これらのエンドポイントを使用してアクセサリー アプリをデバッグできます。一般的に、アクセサリーがデバイス上で ADB へのパススルーを実装していない限り、このインターフェースは使用しません。
USB デバイス記述子のバージョン、ベンダー ID、プロダクト ID が予想される値と一致しない場合、デバイスが Android アクセサリー モードをサポートしているかどうかをアクセサリーが判別することはできません。アクセサリーは、デバイスのサポートを判別するためにデバイスをアクセサリー モードで起動しようと試みます(詳細は下記を参照)。
重要なポイント: USB アクセサリーは、最初の handshake 時にヘッダーを送信する必要があります。ヘッダーには、メーカー、モデル、バージョンが含まれています。バージョンは省略可能なフィールドですが、バージョンのみで一致する Android アプリをインストールしても、アクセサリーがバージョンを送信しない場合、Android 10 以前を搭載した Android デバイスは、システム プロセスでスローされている例外により再起動します。
アクセサリー モードで起動を試みる
バージョン、ベンダー ID、プロダクト ID がアクセサリー モードの Android 搭載デバイスに対応していない場合、デバイスがアクセサリー モードをサポートしている(ただし、そのモードになっていない)のかサポートしていないのかをアクセサリーが判別することはできません。これは、アクセサリー モードをサポートする(ただし、そのモードになっていない)デバイスが最初に報告するのはデバイス メーカーのベンダー ID とプロダクト ID であり、AOA のベンダー ID とプロダクト ID ではないためです。
アクセサリーは、デバイスがアクセサリー モードをサポートしているかどうかを判別するため、デバイスをアクセサリー モードで起動しようと試みます。
- デバイスが Android アクセサリー プロトコルをサポートしているかどうかを判別するには、コントロール リクエスト 51(GET プロトコル)を送信します。デバイスがこのプロトコルをサポートしていれば、サポートしているプロトコル バージョンを表すゼロ以外の数値を返します。コントロール リクエストはエンドポイント 0 にあり、次の特性を持ちます。
requestType: USB_DIR_IN | USB_TYPE_VENDOR
request: 51
value: 0
index: 0
data: protocol version number (16 bits little endian sent from the
device to the accessory)
- デバイスからサポートされているプロトコル バージョンが返された場合は、識別文字列の情報を含むコントロール リクエストをデバイスに送信します。この情報により、デバイスはアクセサリーに適したアプリを決定できます(適切なアプリが存在しない場合は、URL をユーザーに提示します)。コントロール リクエストは各文字列 ID ごとにエンドポイント 0 にあり、次の特性を持ちます。
requestType: USB_DIR_OUT | USB_TYPE_VENDOR
request: 52
value: 0
index: string ID
data zero terminated UTF8 string sent from accessory to device
次の文字列 ID がサポートされます。各文字列の最大サイズは 256 バイトです(\0
によりゼロで終わる必要があります)。
manufacturer name: 0
model name: 1
description: 2
version: 3
URI: 4
serial number: 5
- コントロール リクエストを送信して、アクセサリー モードで起動するようにデバイスに要求します。コントロール リクエストはエンドポイント 0 にあり、次の特性を持ちます。
requestType: USB_DIR_OUT | USB_TYPE_VENDOR
request: 53
value: 0
index: 0
data: none
以上のステップを完了した後、アクセサリーは、接続された USB デバイスがアクセサリー モードでバスに再登録され、接続されたデバイスとして再び列挙されるのを待ちます。このアルゴリズムでは、ベンダー ID とプロダクト ID を確認することでアクセサリー モードのサポートを判別しています。デバイスがアクセサリー モードへの切り替えに成功した場合、これらの ID は正しい(デバイス メーカーの ID ではなく、Google のベンダー ID とプロダクト ID に対応している)はずです。ID とバージョンが正しければ、アクセサリーはデバイスとの通信を確立するステップに進みます。
注: 現在、AOA は AOA と MTP の同時接続をサポートしていません。AOA から MTP に切り替えるには、USB デバイスを物理的に取り外すか電源を切断してから、MTP を使用して再接続します。
いずれかのステップが失敗した場合、アクセサリーはデバイスが Android アクセサリー モードをサポートしていないと判断し、別のデバイスが接続されるのを待ちます。
デバイスとの通信を確立する
アクセサリーは、アクセサリー モードの Android 搭載デバイスを検出すると、デバイスのインターフェース記述子とエンドポイント記述子をクエリして、デバイスと通信するための一括エンドポイントを取得します。
インターフェースと一括エンドポイントの数は、次に示すように、Android 搭載デバイスのプロダクト ID によって異なります。
- プロダクト ID が
0x2D00
の場合、インターフェースは 1 つで、入力および出力通信用に 2 つの一括エンドポイントがあります。
- プロダクト ID が
0x2D01
の場合、インターフェースは 2 つで、入力および出力通信用にそれぞれ 2 つの一括エンドポイントがあります。第 1 のインターフェースは標準の通信を処理し、第 2 のインターフェースは ADB 通信を処理します。インターフェースを使用するには、第 1 の一括入力 / 出力エンドポイントを見つけて、SET_CONFIGURATION
(0x09
)デバイス リクエストによりデバイス設定の値を 1 に設定し、エンドポイントを使用して通信を行います。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。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,["# Android Open Accessory 1.0\n\nAndroid USB accessories must adhere to the Android Open Accessory (AOA)\nprotocol, which defines how an accessory detects and sets up communication with\nan Android-powered device. Accessories should carry out the following steps:\n\n1. Wait for and detect a connected device.\n2. Determine the device's accessory mode support.\n3. Attempt to start the device in accessory mode (if needed).\n4. If the device supports AOA, establish communication with the device.\n\nThe following sections explain how to implement these steps.\n\nWait for and detect connected\ndevices\n-------------------------------------\n\nAccessories should continuously check for connected Android-powered devices.\nWhen a device is connected, the accessory should determine if the device\nsupports accessory mode.\n\nDetermine accessory mode support\n--------------------------------\n\n**Note:** USB debugging isn't required for connecting accessories but\nADB might be necessary during development. For details, see\n[Debug considerations](https://developer.android.com/guide/topics/connectivity/usb#debug-considerations).\n\nWhen an Android-powered device connects, it can be in one of three states:\n\n- Supports Android accessory mode and is already in accessory mode.\n- Supports Android accessory mode but it is not in accessory mode.\n- Does not support Android accessory mode.\n\nDuring the initial connection, the accessory should check the version, vendor ID,\nand product ID of the connected device's USB device descriptor. The vendor ID\nshould match Google's ID (`0x18D1`). If the device is already in\naccessory mode, the product ID should be `0x2D00` or\n`0x2D01` and the accessory can\n[establish communication with\nthe device](#establish-communication-with-the-device) through bulk transfer endpoints using its own communication\nprotocol (the device does not need to be started in accessory mode).\n\n**Note:** `0x2D00` is reserved for\nAndroid-powered devices that support accessory mode. `0x2D01` is\nreserved for devices that support accessory mode as well as the Android Debug\nBridge (ADB) protocol, which exposes a second interface with two bulk endpoints\nfor ADB. You can use these endpoints for debugging the accessory application if\nyou are simulating the accessory on a computer. In general, do not use this\ninterface unless the accessory implements a passthrough to ADB on the device.\n\nIf the version, vendor ID, or product ID in the USB device descriptor do not\nmatch expected values, the accessory cannot determine if the device supports\nAndroid accessory mode. The accessory should attempt to start the device in\naccessory mode (detailed below) to determine device support.\n\n**Key point:**A USB accessory must\nsend a header upon initial handshake. The header contains the manufacturer, model, and\nversion. Though version is an optional field, if an Android app is installed that only\nmatches on version, but the accessory doesn't send a version, Android devices\nrunning on Android 10 and below will reboot due to an exception being thrown in\nthe system process.\n\nAttempt to start in accessory\nmode\n----------------------------------\n\nIf the version, vendor, and product IDs do not correspond to an Android-powered\ndevice in accessory mode, the accessory cannot determine if the device supports (but\nis not in) accessory mode or if the device does not support accessory mode. This\ncan occur because devices that support accessory mode (but are not in accessory\nmode) initially report the *device* manufacturer vendor and product IDs\ninstead of the *AOA* vendor and product IDs.\n\nThe accessory should try to start the device in accessory mode to determine\nif the device supports that mode:\n\n1. Send a 51 control request (\"Get Protocol\") to determine if the device supports the Android accessory protocol. If the device supports the protocol, it returns a non-zero number that represents the supported protocol version. The control request is on endpoint 0 with the following characteristics: \n\n ```\n requestType: USB_DIR_IN | USB_TYPE_VENDOR\n request: 51\n value: 0\n index: 0\n data: protocol version number (16 bits little endian sent from the\n device to the accessory)\n ```\n2. If the device returns a supported protocol version, send a control request with identifying string information to the device. This information allows the device to determine an appropriate application for the accessory (or present a URL to the user if an appropriate application does not exist). The control request is on endpoint 0 (for each string ID) with the following characteristics: \n\n ```\n requestType: USB_DIR_OUT | USB_TYPE_VENDOR\n request: 52\n value: 0\n index: string ID\n data zero terminated UTF8 string sent from accessory to device\n ```\n\n The following string IDs are supported, with a maximum size of 256 bytes\n for each string (must be zero-terminated with `\\0`). \n\n ```\n manufacturer name: 0\n model name: 1\n description: 2\n version: 3\n URI: 4\n serial number: 5\n ```\n3. Send a control request to ask the device to start in accessory mode. The control request is on endpoint 0 with the following characteristics: \n\n ```\n requestType: USB_DIR_OUT | USB_TYPE_VENDOR\n request: 53\n value: 0\n index: 0\n data: none\n ```\n\nAfter completing these steps, the accessory should wait for the connected USB\ndevice to re-introduce itself on the bus in accessory mode, then re-enumerate\nconnected devices. The algorithm\n[determines accessory mode support](#determine-accessory-mode-support)\nby checking the vendor and product IDs, which should be correct (for example, correspond\nto Google's vendor and product IDs instead of to the device manufacturer's IDs) if\nthe device successfully switched to accessory mode. If IDs and version are correct,\nthe accessory moves to [establish\ncommunication with the device](#establish-communication-with-the-device).\n\n**Note:** AOA does not currently support\nsimultaneous AOA and MTP connections. To switch from AOA to MTP, the accessory\nmust first disconnect the USB device (either physically or in an electrically\nequivalent way) and then reconnect using MTP.\n\nIf any step fails, the accessory determines the device does not support\nAndroid accessory mode and waits for the next device to connect.\n\nEstablish communication with\nthe device\n---------------------------------------\n\nIf the accessory detects an Android-powered device in accessory mode, the\naccessory can query the device interface and endpoint descriptors to obtain the\nbulk endpoints for communicating with the device.\n\nThe number of interfaces and bulk endpoints depends on the product ID. An\nAndroid-powered device with a product ID of:\n\n- `0x2D00` has one interface with two bulk endpoints for input and output communication.\n- `0x2D01` has two interfaces with two bulk endpoints each for input and output communication. The first interface handles standard communication and the second interface handles ADB communication. To use an interface, locate the first bulk input and output endpoints, set the device configuration to a value of 1 with a `SET_CONFIGURATION` (`0x09`) device request, then communicate using the endpoints."]]