potatochips #29の発表資料です

1. Android BLEのつらみ
を予防するTips
Twitter : @OE_uia / GitHub: taisukeoe

2. 自己紹介
麻植泰輔 / OE TAISUKE
- Twitter: @OE_uia
- GitHub: taisukeoe
- ScalaMatsuri co-chair
- deeplearning4j/nd4s author
- Android Developer
最近のお仕事
- BONX
- Scala研修
などなど

3. 今日話すこと
● Bluetooth Low Energyとは？
● Android BLEのサポート状況
● Android BLE Central機能のつらみ
● つらみを予防するためのTips

4. ● Bluetooth 4.0
● 2つの役割
○ Central: 見つける、接続する
○ Peripheral: 見つけられる、接続される
● IoTの文脈でしばしば用いられるため、BLEデバイスをiOS,
Android両方から触ることも少なくない
● iOS, Androidともに対応しているが、iOSの方が基本的に安
定動作している
● というより、Android BLEが不安定
Bluetooth Low Energy

5. BLEにおける2つの役割:
CentralとPeripheral
Scan
見つける側
（Central)
見つけられる側
(Peripheral)
BLE Advertise
Connect

6. AndroidのBLEのサポート状況
● OS
Central: 4.3以上〜
Peripheral: 5.0以上~
● チップセット
Central: 全てのチップが対応している（ハズだが、安定性の端末
差が激しい・・・)
Peripheral: Advertiseするには、BroadcomのHCIコマンド
`multiple advertisement`に対応している必要がある(そして、公
開されている端末仕様からはわからない)
詳しくは「BONXを支える技術: Bluetooth編 」

7. Android BLE Centralが不安定？
● Scanはおおよそ安定的に動作する
○ Advertise Packet
○ RSSI強度
○ MACアドレス
● Connectは端末差が大きいが、基本的に不安定。主な失敗
ポイント:
○ Peripheralに接続要求をしても、成功しない
○ 接続できても、目的の Service/Characteristicが見つからない
○ 目的のService/Characteristicが見つかっても、値の読み込み /書き
込みができない
※「成功しない」にも2パターン:「エラーが発生」or「返事が
返ってこない」

8. Android BLEつらい
● コード上で完全に克服するのは難しい
● 仕様で克服しよう

9. Android BLEのつらみを乗り超える仕様
● BLEを極力使わない
● Androidの動作対象端末を限定する
● BLE接続の頻度を下げる
● UUID指定のスキャンを前提にしない

10. Android BLEを極力使わない
● そもそも使わなければ問題が生じない
● それってBLE以外の技術、例えばClassic BT (SPP)で出来な
いのか？
● 実際、BONXではAndroid BLEの一部機能を、SPP経由で
IoTデバイスに肩代わりさせています。

11. Androidの動作対象端末を絞る
● ここ２年に発売されたフラッグシップ級の端末なら「比較的」
安定動作するものが多い。
● できるだけAndroid 4.3以下のサポートをしない。
● 可能なら、Android 4.4もサポート対象外とし、Android 5.0
以上のみ対応とする(BLE APIが4系と5系で異なるため)。
● さらに可能なら、発売当時Android 4.xだった端末もサポー
トしない。その当時のチップはAdvertiseに対応していないこ
とが多いなど、問題の元になることがある。

12. BLE接続の頻度を下げる
● Android BLEは接続のたびに、失敗するリスクがある
● 接続せずに、スキャンだけで済むならそれが良い
● 接続する必要があっても、接続回数および接続相手の数を
減らす
● 短時間の間にいろんな相手と接続/切断を繰り返すアプリが
一番大変

13. UUID指定のスキャンを前提にしない
● BLEスキャンのAPIには、Advertise Packetに含まれる
UUIDを指定したスキャンが用意されている。これにより接
続対象候補の端末を絞ることができる。
● しかし、iOSのAdvertisePacketは、データ領域が足りなく
なった場合などに`overflow領域`と呼ばれる特別な領域に
格納されるという仕様がある。`overflow領域`に格納された
UUIDは、iOSからのスキャンでは利用できるが、Android
のUUID指定スキャンでは利用できない
● iOSがAdvertiseする仕様において、AndroidはUUID指定
スキャンは実質使用することが難しい。

14. ● BLEは節度を守って使う限りにおいて、とても便利な規格。
Android BLEに関してAPIが用意されているからと言って、
全面的に信頼したりしない。
● Android BLEを使用した機能の仕様を決める前に、以下の
ポイントはチェックしておくとつらみが減る(かもしれない)
○ BLEがベストな選択肢なのか？
○ サポート対象端末は？
○ 接続頻度は？
○ BLEスキャンの対象は？
● こんな方法でつらさを回避してるよ！って話があったらぜひ
教えてください
まとめ