Bluetooth Low Energy
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android では、セントラル ロールとしての Bluetooth Low Energy（BLE）に対する組み込みプラットフォームのサポートが提供されており、アプリでデバイスの検出、サービスのクエリ、情報の送信に使用できる API が用意されています。
一般的なユースケースは次のとおりです。
- 近くにあるデバイス間で少量のデータを転送する。
- 近接センサーと連携して、ユーザーの現在地に基づいてカスタマイズされたエクスペリエンスを提供します。
従来の Bluetooth とは対照的に、BLE は消費電力を大幅に削減できるように設計されています。これにより、近接センサー、心拍数モニター、フィットネス デバイスなど、電力要件が厳しい BLE デバイスとアプリが通信できるようになります。
注意: ユーザーが BLE を使用してデバイスを別のデバイスとペア設定すると、2 つのデバイス間で通信されるデータは、ユーザーのデバイス上のすべてのアプリからアクセス可能になります。
そのため、アプリが機密データをキャプチャする場合は、アプリレイヤ セキュリティを実装して、そのデータのプライバシーを保護する必要があります。
基本情報
BLE 対応デバイス間でデータを送信するには、まず通信チャネルを形成する必要があります。Bluetooth LE API を使用するには、マニフェスト ファイルで複数の権限を宣言する必要があります。アプリが Bluetooth を使用する権限を取得したら、BluetoothAdapter にアクセスして、デバイスで Bluetooth を使用できるかどうかを判断する必要があります。Bluetooth を使用できる場合は、デバイスが近くの BLE デバイスをスキャンします。デバイスが検出されると、BLE デバイスの GATT サーバーに接続して BLE デバイスの機能が検出されます。接続が確立されると、利用可能なサービスと特性に基づいて、接続されたデバイスとデータを転送できます。
主な用語と概念
BLE の主要な用語とコンセプトは次のとおりです。
- Generic Attribute Profile（GATT）
- GATT プロファイルは、BLE リンクを介して「属性」と呼ばれる短いデータの送受信に関する一般的な仕様です。現在の BLE アプリ プロファイルはすべて GATT をベースにしています。詳しくは、GitHub の Android BluetoothLeGatt サンプルをご覧ください。
- プロフィール
- Bluetooth SIG は、BLE デバイス用の多くのプロファイルを定義しています。プロファイルは、特定のアプリでデバイスがどのように動作するかを指定します。デバイスに複数のプロファイルを実装できます。たとえば、デバイスに心拍数モニターとバッテリー レベル検出機能を搭載できます。
- 属性プロトコル（ATT）
- GATT は、属性プロトコル（ATT）上に構築されています。これは GATT/ATT とも呼ばれます。ATT は、BLE デバイスで動作するように最適化されています。そのため、可能な限り少ないバイト数で処理します。各属性は、Universally Unique Identifier（UUID）によって一意に識別されます。UUID は、情報を一意に識別するために使用される、標準化された 128 ビット形式の文字列 ID です。ATT によって転送される属性は、特性とサービスとしてフォーマットされます。
- 特性
- 特性には、単一の値と、特性の値を記述する 0 ～ n 個の記述子が含まれます。特性は、クラスに似た型と考えることができます。
- 記述子
- 記述子は、特徴値を記述する定義済み属性です。たとえば、記述子には、人間が読み取り可能な説明、特性値の許容範囲、特性値に固有の測定単位を指定できます。
- サービス
- サービスは特性の集合です。たとえば、「心拍数モニター」というサービスに「心拍数測定」などの特性を含めることができます。既存の GATT ベースのプロファイルとサービスのリストは、bluetooth.org で確認できます。
役割と責任
デバイスが BLE デバイスと通信する際の役割と責任は、次の 2 つの方法で分類されます。
セントラルとペリフェラルこれは BLE 接続自体に適用されます。つまり、中心的な役割のデバイスがスキャンしてアドバタイズを探し、ペリフェラル ロールのデバイスがアドバタイズします。ペリフェラル ロールのみをサポートする 2 つのデバイスは相互に通信できません。また、セントラル ロールのみをサポートする 2 つのデバイスも相互に通信できません。
GATT サーバー対 GATT クライアント。これにより、2 つのデバイスが接続を確立した後に相互に通信する方法が決まります。クライアント ロールのデバイスがデータのリクエストを送信し、サーバー ロールのデバイスがリクエストを処理します。
セントラル ペリフェラルとサーバー クライアントのロール分割の違いを理解するには、Android スマートフォンと、センサーデータをスマートフォンに報告する BLE 対応のアクティビティ トラッカーがある場合の例を考えてみましょう。
スマートフォン（中央デバイス）が BLE デバイスをアクティブにスキャンします。アクティビティ トラッカー（ペリフェラル デバイス）がアドバタイズし、接続リクエストを受信するのを待ちます。
スマートフォンとアクティビティ トラッカーが接続を確立すると、GATT メタデータの相互転送が開始されます。この場合、スマートフォンで実行されているアプリがデータのリクエストを送信するため、GATT クライアントとして機能します。アクティビティ トラッカーはこれらのリクエストを処理するため、GATT サーバーとして機能します。
アプリの別の設計では、スマートフォンが GATT サーバーとして機能する場合があります。詳細については、BluetoothGattServer をご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[null,null,["最終更新日 2025-07-27 UTC。"],[],[],null,["# Bluetooth Low Energy\n\nAndroid provides built-in platform support for Bluetooth Low Energy (BLE) in the\ncentral role and provides APIs that apps can use to discover devices, query for\nservices, and transmit information.\n\nCommon use cases include the following:\n\n- Transferring small amounts of data between nearby devices.\n- Interacting with proximity sensors to give users a customized experience based on their current location.\n\nIn contrast to [classic Bluetooth](/develop/connectivity/bluetooth),\nBLE is designed for significantly lower power consumption. This allows apps to\ncommunicate with BLE devices that have stricter power requirements, such as\nproximity sensors, heart rate monitors, and fitness devices. \n\n**Caution:** When a user pairs their device with another device\nusing BLE, the data that's communicated between the two devices is\naccessible to **all** apps on the user's device.\n\n\nFor this reason, if your app captures sensitive data, you should implement\napp-layer security to protect the privacy of that data.\n\nThe basics\n----------\n\nFor BLE-enabled devices to transmit data between each other, they must first\nform a channel of communication. Use of the Bluetooth LE APIs requires you to\n[declare several permissions](/develop/connectivity/bluetooth/bt-permissions)\nin your manifest file. Once your app has permission to use Bluetooth, your app\nneeds to access the `BluetoothAdapter` and\n[determine if Bluetooth is available on the device](/develop/connectivity/bluetooth/setup)\nIf Bluetooth is available, the device will\n[scan for nearby BLE devices](/develop/connectivity/bluetooth/ble/find-ble-devices).\nOnce a device is found, the capabilities of the BLE device are discovered by\n[connecting to the GATT server on the BLE device](/develop/connectivity/bluetooth/ble/connect-gatt-server).\nOnce a connection is made,\n[data can be transferred with the connected device](/develop/connectivity/bluetooth/ble/transfer-ble-data)\nbased on the available services and characteristics.\n\nKey terms and concepts\n----------------------\n\nThe following is a summary of key BLE terms and concepts:\n\n-\n\n **Generic Attribute Profile (GATT)**\n : The GATT profile is a general specification for sending and receiving short\n pieces of data known as \"attributes\" over a BLE link. All current BLE\n application profiles are based on GATT. Review the [Android BluetoothLeGatt\n sample](https://github.com/android/platform-samples/tree/main/samples/connectivity/bluetooth/ble/src/main/java/com/example/platform/connectivity/bluetooth/ble)\n on GitHub to learn more.\n-\n\n **Profiles**\n : The **Bluetooth SIG** defines many\n [profiles](https://www.bluetooth.org/en-us/specification/adopted-specifications)\n for BLE devices. A profile is a specification for how a device works in a\n particular application. Note that a device can implement more than one\n profile. For example, a device could contain a heart rate monitor and a\n battery level detector.\n-\n\n **Attribute Protocol (ATT)**\n : GATT is built on top of the Attribute Protocol (ATT). This is also referred to\n as GATT/ATT. ATT is optimized to run on BLE devices. To this end, it uses as\n few bytes as possible. Each attribute is uniquely identified by a Universally\n Unique Identifier (UUID), which is a standardized 128-bit format for a string\n ID used to uniquely identify information. The *attributes* transported by ATT\n are formatted as *characteristics* and *services*.\n-\n\n **Characteristic**\n : A characteristic contains a single value and 0-n descriptors that describe the\n characteristic's value. A characteristic can be thought of as a type,\n analogous to a class.\n-\n\n **Descriptor**\n : Descriptors are defined attributes that describe a characteristic value. For\n example, a descriptor might specify a human-readable description, an\n acceptable range for a characteristic's value, or a unit of measure that is\n specific to a characteristic's value.\n-\n\n **Service**\n : A service is a collection of characteristics. For example, you could have a\n service called \"Heart Rate Monitor\" that includes characteristics such as\n \"heart rate measurement.\" You can find a list of existing GATT-based profiles\n and services on [bluetooth.org](https://www.bluetooth.org/en-us/specification/adopted-specifications).\n\n### Roles and responsibilities\n\nWhen a device interacts with a BLE device, roles and responsibilities are\ndivided in two different ways:\n\n- **Central versus peripheral.** This applies to the BLE connection itself---the\n device in the central role scans, looking for advertisement, and the device in\n the peripheral role advertises. Two devices that only support the peripheral\n role can't talk to each other, and neither can two devices that only support\n the central role.\n\n- **GATT server versus GATT client.** This determines how the two devices talk\n to each other after they've established the connection. The device in the\n client role sends requests for data, and the device in the server role\n fulfills them.\n\nTo understand the distinction between the central-peripheral and server-client\nrole divisions, consider an example where you have an Android phone and a\nBLE-enabled activity tracker that reports sensor data back to the phone.\n\n- The phone---the *central* device---actively scans for BLE devices. The activity\n tracker---the *peripheral* device---advertises and waits to receive a request for\n connection.\n\n- After the phone and the activity tracker have established a connection, they\n start transferring GATT metadata to each other. In this case, the app running\n on the phone sends requests for data, so it acts as the *GATT client* . The\n activity tracker fulfills those requests, so it acts as the *GATT server*.\n\nAn alternative design of the app might involve the phone playing the GATT server\nrole instead. See\n[`BluetoothGattServer`](/reference/android/bluetooth/BluetoothGattServer) for\nmore information."]]
