GoogleIO13 "Best Practices for Bluetooth Development"セッションの全訳

Android GoogleIO2013 BTLE

top
Google IO 2013のBest Practices for Bluetooth Developmentのセッション全訳です。
（2013/05/25:質問は未翻訳。後日やる。）


目新しい発表としては

  • 次期APIのlevel 18からBluetooth Low Energyに対応
  • 次期APIのlevel 18からAVRCP1.0->1.3へバージョンアップ
  • 次期APIのlevel 18からBluetoothAdapterのgetDefaultAdapterはサポート外になる。lv18以降は追加されるBluetoothManagerを使うように。

といったところ。


内容としては、これは！という奇抜な技が紹介されているわけではなく
基本的なところを押さえた内容になっています。


導入部分ではBluetoothの起源についての話が出てくるなど
わりと面白い内容にはなっているので
興味有る人はざっと目を通しておいて損はないかと。


※講演者に勝手にキャラつけ遊んでます。翻訳作業が退屈だったんですゴメンナサイ。


補足情報として
@tnoho氏から「SAMSUNG BLE SDKをベースにしているのでは」という情報をもらっています。
http://developer.samsung.com/ble
http://img-developer.samsung.com/onlinedocs/samsung_ble_docs_200/index.html
なるほど、メソッド名もほぼ一致してるぞということで、このBLE SDKを元にしているのはほぼ間違いないかと思います。
またBTLEに関してこのセッションの内容だけではいまいち読み解けなかった人は
@u_akihiro 氏によるプレゼン資料を参考にすると理解が深まります。ボクも参考にさせていただきました。
「Bluetooth LE体験講座」http://www.slideshare.net/reinforcelab/20130322-btle



Best Practices for Bluetooth Development
https://developers.google.com/events/io/sessions/326240948


Richard Hyndman(背の高い男性):
　よし、始まったみたいだね。
「Bluetooth開発のベストプラクティス」のセッションへようこそ。私の名前はRichard Hyndman。Androidヨーロッパ開発チームのリーダーです。


Scout Sinclair Brandy(女性):
　私はScout Sinclair Brodyよ。Androidプラットフォームのプロダクトマネージャをしています。


Matthew Xie(中国？の男性):
　やぁ、私の名前はMatthew Xieアル.AndroidのBluetoothテクノロジリーダーアルよ。


Richard:
　OKじゃぁはじめようか。今日はこの講演に来てくれてありがとう。

（スライドを見ながら）この技術のおかげで苦しんだ経験のある人は少なくないよね。
（会場笑）
わかるよ（笑）僕らみんな経験がある。
ここにいる広い心を持った人たちが、私達の語るAndroid on Bluetoothについて聞きに来てくれて本当に感謝してる。

さて、このスライドを見て欲しい。

※ローマ数字
これは何年だと思う？
（会場手を上げる）
じゃぁ最初の人
（会場答える。マイクでは聞こえない）
違うんだ、1994年なんだよ。これはとてもわかりにくいだろ？ローマ数字にとってはひどい年だね。
そんな年、エリクソンの人たちは、シリアルケーブルをつなげるためにPCの裏側へ手を伸ばさないといけないことにほんとうに嫌気がさしていたんだ。
（訳注：1994年Bluetooth開発をスタートさせたスウェーデンの通信会社）

PCをぐるっと回して裏側を前にしておけばいい？でもそうすると、こんどは電源ボタンが裏に回ってしまうだろ？
だから90年代のイノベーティブな会社はすべてのシステムを新たに考案することに決めた。そしてBluetoothを生み出した。みなさんご存知の短距離ピアツーピア無線通信デバイスだ。

　Bluetoothの語源はHarold Blåtand Gormsson でBlåtandは英語でBluetoothと訳されたんだ。かれはデンマークの王で部族間を統一したんだ。シリアルケーブルなしにね。手とかを使ったのかもしれない。Bluetoothいい名前だよね。HはHaroldからBはBlåtandからとっていて、ルーン文字のHとBで、こうやってBluetoothのロゴに見ることができる。

(訳注:Wikipedia ハーラル１世（デンマーク王） より「"Bluetooth"（“青歯王”）の異名を持つが、これは"Blåtand"（"blå-tand"[浅黒い肌の・英雄]、古デンマーク語で「浅黒い肌の英雄」）を英語に音訳したものである。デンマークとノルウェーを交渉によって平和的に統一した事績にちなんで、複数の電子機器をつなぐ通信技術のBluetoothの語源となった。」)


　僕らはこのBluetoothをAndroidに採用した。version 1.0からね。僕らはBluetooth 2.0 with EDRスタックを搭載した。EDRスタックというのはヘッドセットプロファイル、ハンドセットプロファイル、でも実際のAPIはなかったけどね。クラシックBluetoothを使って、音楽プレーヤ、マウスとPC、マウスに付けたヘッドフォンをなにか繋ぎたいものへ繋げることができるんだ。でもここでのポイントはお互いを繋げられるという約束事が必要があるということ。お互いを繋げられるかどうかを判定する必要があることだ。そして共通語で話す必要がある。そのためBluetoothスタックが必要になってくる。


　Bluetoothスタックとはなんだろう？BluetoothスタックとはBluetoothコア仕様の実装部分のことなんだ。（スライドをみながら）Bluetoothコアシステムの一番下のレイヤーには、実際にワイヤレス接続をするためのRFトランシーバがあるのがわかるね。その上にはトランシーバ制御しているベースバンド。そしてその上にプロトコルスタックがある。ここにはとーってもたくさんのプロトコルが詰まってる。こいつらを使うことで通信させることができるんだ。だからたくさんの別々のタイプのBluetoothデバイス間を接続できるってわけ。そう、これがBluetoothスタックだ。


　そしてさらにその上にBluetoothプロファイルがある。BluetoothプロファイルはBluetoothスタックに必要な各々の接続タイプが定義されてる。Bluetoothプロファイルは一般的になにか特定のバージョンのスタックを結びつけることじゃないんだ。単に、必要な規格だったり、必要なスタックを定義しているにすぎない。だからBluetoothのバージョンを見るときはコア仕様のバージョンを見ることをオススメするよ。Ver.1、そしてVer.1.1これは802.15だった。Bluetooth仕様としては1Mbpsぐらいだったね。Ver.2では3Mbpsくらいに上がった。+EDRつまりEnhanced Data Rateというオプションがある。Ver.3で24Mbpsまで登りつめた。これ以上のものは無いだろうね。+HSつまりプラスHigh Speedが付いているのは802.11 Wi-Fiリンクのこと。そしてVer.4へ引き上がった。今はひとまず、とても多くのBluetoothスタック実装がある、ということだけ言っておこう。


　Androidでは、AOSPデバイスやサムソン、HTC、ソニーXperiaなどでBlueZスタックを使ってる。古いBroadcomスタックもある。HTCのICS以前のデバイスとかでね。モトローラデバイス用にモトローラBluetoothスタックもある。他のデバイスも同じようにある。もちろん、すべて互換性があるよ。でもソフトウェア的なバグがあるんだ。それは僕らもわかってる。だからそれぞれのスタックで、さまざまな細かい問題を潰していかなきゃいけないってことが潜在的にひそんでいるんだ。それぞれのスタックに関わっていく間にも、開発者向けのAndroid APIやコンシューマ向けのAndroid Bluetooth機能はBluetoothの歴史を通してどんどん変わっていく。
次はMatt(Matthewさん)に、この１年を通してそれぞれのAPI間で変わってきたBluetooth機能についてカンタンに紐解いてもらおう。


Mattew:
　ﾊｰｲ。ワイの方からはAndroid Bluetoothのバージョン間のAPIの特徴についてカンタンに話してこうと思うアルね。みなさん知ってのとおり、Androidはデザート好きアルね。だからワイらはリアルスイーツBluetoothを持っていると言っていいアル。（会場微妙な空気）え、えっと、まずはじめにBluetoothの採用についてアル。


　Android 1.0ではBluetooth 2.0のヘッドセットとハンズフリープロファイルを取り入れたアル。これでBluetoothヘッドセットで電話がかけられるようになったアルね。そして、Cupcakeで、A2DPを取り入れたアル。ｲｲﾈｯ!これでBluetoothで音楽をストリーム再生させることができるようになったアルよ。次にEclearでBluetooth 2.1にして RFCOMM APIを取り入れたアル。そしてオブジェクトプッシュと電話帳プロファイルも取り入れたアル。

Froyoではボイスダイヤリング over Bluetooth。ハニカムでA2DPみたいなプロファイルAPIとハンズフリー、PANテザリング、キーボード、マウス、ゲームパッド、よーするにスマホ上でタイピングする代わりになるものとかアルね。PANはデータテザリング機能のことで、ようはBluetooth使ってネットワークを共有できるアル。ｽｺﾞｲﾈ!

そんでもってICSではヘルスデバイスプロファイルを取り入れたアル。Bluetoothで医療データをリアルタイムに通信させることがでるアル。んでいよいよJelly Beanアルが、これはScoutにバトンタッチするアルね。

  • BluezからBlueDroidそしてBTLEサポートへ


Scout:
　OK. もうご存知の方もいらっしゃるでしょうが、4.2では新しいスタックを取り入れBlueZからBlueDroidへ変更しました。この変更はBroadcomがAOSPへ多大なるコントリビュートをしてくれたおかげで実現したことなの。もちろん、この変更はいくつか計画通りに行かないこともあって、それについては私達が謝らなければいけないと思ってるわ。でも、私達は次のレベルへ進めることこそが重要だと感じているの。まず１つ目に、組込みシステム向けに最適化されたスタックが欲しかった。2つ目にライセンスされたモデルの干渉を避けるために、実際BlueZを自身のプロセスで走らせる必要があったの。これは確実にパフォーマンスに関わってくるわ。そして最後に、AOSPでは時間を追うごとに機能追加や安定性、パフォーマンス強化などのスタック開発が驚異的なスピードで起こっている、と本当に感じたの。

そして皆さんも興味あるトピックをもたらしました。そう、Bluetooth Low Energy(以下BTLE)です。
（会場拍手喝采）
明らかにこの話は大盛況みたいね。でも、みんながみんなBTLEについて精通しているとは思ってないわ。だからBTLEが何なのか、そしてなぜ存在するかについて話していくわね。


　そもそもの着想としてBluetoothは互いに通信し合うものとして設計されていて、そのためには頻繁にチャージしなきゃいけないような比較的大きなバッテリーを必要とされてきたわ。Rich(Richardさん)も言ってたように、Bluetoothクラシックの使い道は、大体オーディオストリーミングだったりバンド幅の高いアプリケーションが多かった。でも、元々の仕様で考え直せば動作が軽くて、小さなバッテリーを持ったデバイスのためのものでしょ？だって、誰だって毎日チャージしたくないじゃない。だからBTLEはまさにこのカテゴリーで動作するように設計されたの。（スライドをみながら）例えばこんなかんじのキーホルダーのような近接タグなんかわかりやすいんじゃないかしら。万歩計や、フィットネスメディカルセンサー、腕時計、ゲームコントローラ、リモコンなんかもあるわね。BTLEにはとても多くの可能性があるの。BTLEを使う目的は、同時に何年も小さなバッテリーで動作させること。リチャージ無しでね。

  • BTLEの用語について

　BTLEという用語は一般的によく使われているけど、公式名はBluetooth SMARTと呼ばれていて、これはBluetooth SIG（訳注：Bluetooth Special Interest Group, Inc. 1998 年に設立された株式非公開の非営利事業者団体。SIG は Bluetooth 商標を所有し、Bluetooth 規格の開発を監督している）が付けた名前なの。そしてBluetooth SMART READYはBTLEとBluetoothクラシックをサポートしているわ。

  • 今後のNexusシリーズをBTLEサポートへ


　(スライドを見ながら)どうして私がここでNexus4を出したかわかるひとはまさかいないわよね。今までのAndroidプラットフォームではBTLEはサポートしていなかったわ。でも今日とってもいい話があって、あと2ヶ月そこそこでAndroid API level 18がリリースされて、Nexus 4とすべての今後のNexusデバイスでBTLEがサポートされる、そして開発者向けAPIを公開するわ。（ドヤァ
（会場拍手喝采）
つまり、あなたのアプリ、ペリフェラルデバイスにこのエキサイティングなテクノロジのすべてのアドバンテージを取り入れることができるようになるってわけ。

  • BTLEの基本


　さて、これから2,3分くらいでBTLEのAPIについて説明していきましょう。でもはじめにちょっとだけ専門用語について説明しておくわ。これを知っておくと、これからでてくる例がわかりやすくなるはずだから。まずはBTLEはGATT(General Attribute Profile)と呼ばれる仕様がベースになっていることを知っておかないとね。これは、あなたのアプリが何のインタフェースと繋がるかを判定する仕組み。GATTはアトリビュートプロトコルを使って通信する仕組みで、文字通りアトリビュート型のデータや、アトリビュートオペレーションを通信するわ。

　最も基本的なアトリビュートのタイプには複数のディスクリプタとキャラクタリスティクスがあるの。一つのディスクリプタには文字通り、他のデータ片のタグについて書かれてる。キャラクタリスティクスは一つのバリューと0以上のディスクリプタから構成されているわ。Bluetooth SIGはたくさんの基本的なキャラクタリスティクスを採用しているの。曜日だったり、血液中のグルコース値だったり、自転車のロケーションセンサの値だったり、こういったデバイス情報を表現するためにね。ようするに頭がおかしくなるくらいいろんなものが含まれてるってわけ。

　キャラクタリスティクスはサービスという型でグループ分けすることができるの。サービスを使うことで、あるデバイスから他のデバイスへ通知することができるわ。サービスの仕様には、GATTサービスが利用可能かのキャラクタリスティクスについてだけじゃなくて、どのキャラクタリスティクスをGATTクライアントが読み書きできたり通知を受けたりすることができるか、といったことも明記されてるの。注意しておかなきゃいけないのは、2つのBTLE有効デバイスが繋がっているとき、どちらか一方がクライアントもしくはサーバの役を務めるってこと。2つともスイッチOFFにすることもできるわ。だれが他のキャラクタリスティクスを利用可能にしたか、にすべて依存しているの。

　仕様のレイヤを上げて、次はちょっと、GATTプロファイルについて。GATTプロファイルは、サービスから提供されたデータがGATTサーバとクライアントでどうやりとりされるかについて定義されているわ。プロファイルは個別の用途を念頭に置いて定義されていて、一部分野でどんなシナリオにも適応できるくらい十分柔軟になるよう設計されているの。正確には今、使用用途別に約20のプロファイルがあるわ。そしてAndroid API level 18では、このプロファイルをあなたのアプリに実装することができるようになる。リリースされた特定のプロファイルや、自分のアプリのためのカスタムプロファイルもね。じゃあRichに返すわ。


Richard:
OK、じゃあBluetoothクラシックのスタックについてざっと見ていこう。次はBTLEのスタックについてだ。（スライドを見ながら）ポイントはここ、一番下のレイヤーLow energy RFだ。これは最適化されていて、クラシックスタックのようなストリーミングデータを転送する代わりに、小さなアトリビュートデータをバッと転送して、そのあとパワーダウンするということを繰り返すんだ。こうすることでBTLEは電力を抑えているってわけさ。そしてプロトコルスタックは、このクラシック側にある目もくらむように多いプロトコルの代わりに、BTLE側ではアトリビュートプロファイルのなかで本当に必要なものだけにフォーカスされている。そしてプロファイルの一番上では、クラシック側の様々なプロファイルの代わりに、BTLE側ではGATTプロファイルだけがあるのがわかるね。だからBTLEスタックはクラシックスタックの何分の１かのサイズなんだ。つまりLow energy RFのおかげで、何分の１かのバッテリーサイズでよくなるってこと。もちろん、何分の１かのコストに抑えられるし、多くのデバイスを長く使えるんだ。

　さて、このセッション名はBluetoothベストプラクティスだったね。ということでいくつかBluetoothのベストプラクティスを見て行こう。これからNexus4とBluetooth脈拍モニタを繋いでみるという例で進めるよ。僕らが作ったBTLE APIをみんなの前で披露する唯一の場所はまさにここだけになるだろうね。よし、じゃあはじめよう。
まずはじめるには、デバイスがBluetooth機能をもっているかどうかをチェックする必要があるんだけど、このスライドを書いているとき、ボクはこう考えた。Bluetoothを持っていないデバイスってなんだ？ボクはもういちどスライドを見返した。そのときのボクはCTS(訳注 : Compatibility Test Suite, Google社がAndroidプラットフォーム採用端末に実施を義務付けているテスト群)テストされたエコシステムの中だけで考えていたんだ。Bluetoothが搭載されていることが保証されているデバイスだけをね。でもたぶんBluetoothを搭載していないデバイスもあるだろう。Google TVにはBluetoothが搭載されなくなる日がくるかもしれない。ゾッとするようなクラッシュは避けるにかぎる。Bluetoothがデバイスに搭載されているかどうかをチェックするのは常にしておいたほうがいいってこと。今からコードを見ながらMattにささっと説明してもらおう。

  • [ベストプラクティス]Bluetoothが端末に存在するかをチェックしよう


Matthew :
　やぁやぁ、じゃあこのコードについてすこし話すアルよ。デバイスにBluetoothがあるかどうかをチェックするためにはBluetoothアダプタをチェックするアル。このAPIがあるアルね。でも、これだったらスタティックメソッドのBluetoothAdapterのgetDefaultAdapterでも同じことができるアルね。でのその書き方は今はサポートしてないからもし見かけたら書き換えるアル。というわけで、今はBluetoothManagerを使うアル。ContextやgetSystemService、BLUETOOTH_SERVICEが見えるアルね。ManagerからBluetoothAdapterをゲットするアルよ。もしnullが返ってくるだったら、Bluetoothサポートされていないってことがわかるアル。



Richard :
　OK、じゃぁBluetoothデバイスがあるってことがわかったとして、BluetoothがONかOFFかをチェックしよう。第二のおぞましいクラッシュを避けるためにね。

  • [ベストプラクティス]BluetoothがONになっているかチェックしよう


Matthew :
　やぁやぁ、これもAPIでできるアルよ。Adapterからチェックするアル。これでイネーブルかどうかをチェックできるアル。もしイネーブルじゃないならアプリにイネーブルリクエストのインテントを送るのがいいアルね。ぜんぶユーザ認証を通すようにしたいアルから、コードから直接イネーブルにするAPIはないアル。だから、ユーザがわからないようにこっそりとBluetoothをオンにすることはできないアルよ。

  • [ベストプラクティス]BTLEのフローを理解しよう


Richard:
　そうなんだ、だからBluetooth設定画面を出すためにインテントを飛ばすってわけ。よし、じゃあ今からBTLEデバイスをスマホと繋げる準備をするとしよう。（スライドを見ながら）これがBTLEのための新しいフローだ。まずLow energy scanを始めると、スキャニングモードになって、なにかまわりにあるBTLEデバイスを見つけようとするんだ。今、近くにあって利用可能な状態になっているデバイスをね。目的のデバイスが見つかったら、スキャンをやめて、デバイスとコネクションを張ろう。コネクションが張れたらデバイスのサービスが何かを判定しよう。例えば脈拍モニターだったら、脈拍サービスを持っていて、そのサービスのキャラクタリスティクスが見つかるだろうしね。それによってGATTプロファイルがどういう挙動をするかすべてわかるんだ。定義された脈拍サービスのキャラクタリスティクスにはパルス情報があるだろうし、体のどの位置のパルスかなんて位置情報もあるだろうね。手首だとか胸とかいろいろあるだろう。だから心拍数がわかるしいつだって読み出すことができる。いくつかある脈拍計のうちどれか一つを選んでアトリビュートを読み出すことだってできるし、通知を登録することだってできる。コードで書くとこうさ。

  • [ベストプラクティス]BTLEスキャンのコーディング


Matthew:
まず、BTLEデバイスを探すことから始めるアル。そのためにワイらはBluetoothAdapterに新しくAPIを追加したアル。このAPIはBTLEデバイスのためだけに追加したアル。これでLEスキャンを始めるアル。ワイらは２つAPIを追加したんやけど、一つ目はコールバックのためのAPIアル。もう一つは対象デバイスを選定するためにUUIDでフィルタできるようにしたアル。（スライドを見ながら）このAPIはコールバックをベースにしてるアル。コールバックで結果を受けるためには、LeScanCallback APIのonLeScanに実装を書く必要があるアル。3つのパラメータがあるアルね。1つ目はdevice。これは見つけたBTLEデバイスのことアル。2つ目のrssiは受信電波強度(Receive Signal Strength Indication)のことアル。3つ目のscanRecordはバイト配列型のアドバタイズメントデータのことアル。

  • [ベストプラクティス]BTLE接続のコーディング


OK、アドバタイズメントデータの処理が済んだら完了アル。ただ近接BTLEデバイスのサービスを使うには接続を確立しないとダメアル。（スライドを見ながら）このようにBluetoothのdevice.connectGattを使うアル。こうすることで、近接デバイスと繋げることができるアル。これもコールバックベースにしてるアル。（スライドをみながら）ここにいくつかコールバック関数があるのがわかるアルね？このonConnectionStateChange, onServicesDiscovered, onCharacteristicRead, onCharacteristicChangedは非同期にコールされるアル。この関数の実装を書くアル。


結果が返ってきたら、このコールバック関数が呼ばれるアル。例えばサービスが見つかった後にはonServiceDiscovered関数が呼ばれてそのstatusを見ることができるアルね。サービスを見つけたということはサービスを捕まえたということアル。
BluetoothGattServiceのリストをforeachで走査して、探しているキャラクタリスティクスを見つけるか、UUIDを使ってサービスを見つけるアル。同じようにBluetoothGattCharacteristicのリストをforeachで走査するアル。そしてUUIDをチェックするアル。この例みたいに、脈拍UUIDにマッチしたら、そのキャラクタリスティクスをノーティフィケーションにセットするアル。こうすることで、もしキャラクタリスティクスに変化があったら通知されるアル。んじゃScoutに返すアル。

  • 新APIについて注意事項

Scout:
　OK.今日は開発中のAndroidのBTLE APIをちょっとだけみることができたわね。これはとってもエキサイティングなテクノロジよ。みんなも心待ちにしていることはわかってるわ。ただ、その前に注意しておかなきゃいけないことがいくつかあるの。まず一つ目に、BTLEはAndroid API level 18に導入されるってことだから、このAPIを使うには次のAPIレベル(訳注:2012/05/16時点ではAPI level 17)が走るデバイスじゃないと使えないってことはわかるわね。でも、リリースされた時点で、BluetoothクラシックAPIと同じようにコンパチビリティプログラムでカバーされるの。つまり、エコシステムを通過していて新しくアップデートされたデバイスではそのコンパチビリティプログラムがあると期待していいわ。


　次に、最初のバージョンのAPIでは、セントラル側をサポートするけどペリフェラル側はサポートされないということを知っておいてほしいの。つまりどういうことかっていうと、BTLEを使って2つのAndroidデバイス間の通信はまだできないってこと。


　次に、このBTLEの性質を話すときには、BTLEを使えばあなたのアプリに魔法の妖精の粉がふりかかって突然バッテリー効率が上がる、というような代物ではないことを頭に置いておいてほしいの。BluetoothとBTLEは使用用途が全く違ってくる。BTLEのことを話すとみんな同じ事を言うの。「おお！BTLEが使えるようになったぞ！これでぜーんぶのBluetooth機器の電池寿命がよくなる！ってことは何度も充電してた生活からはおさらばだね！」なーんてね。でもそうはいかないの。BTLEのデータモデルは小さなアップデートを繰り返すようなものに最適化されているわ。スループットの理論値は200Kbpsで、たとえばストリーミングオーディオとかビデオとかはまったくもって通信が追いつかないわ。でももし、なにか小さなセンサーデータを送るんだったり、あんまり頻繁に通信が発生しなかったり、BTLEの近接タグを使うんであれば、BTLEは素晴らしい選択で、クラシックBluetoothに比べて確実に電池寿命は長くなるわ。


  • バッテリー寿命に関するTips

Richard:
　まさにそのとおり。モバイルOSを使うときはいつもバッテリーは不安要因の一つだよね。だからクラシックBluetoothとBTLEのバッテリーに関するTipsをいくつか見ていこう。デバイスをスキャンするとき、一度探しているデバイスを見つけたら、スキャンをやめるようシステムに伝えよう。これには別の目的もあって、見つけたデバイスをRFCOMMコネクションさせる時、まだディスカバリをかけていると、スタックが影響して通信衝突が生じてしまうんだ。（会場に目をやりながら）おや、何人か船を漕いでるね（笑）だからコネクションを張ろうとしている間はディスカバリをかけないこと、そしてそうすることで少しは電池寿命を伸ばすことにもなる。同じように、RF機能をループさせるのもNGだ。


　ここに無線デバイスが何個かあるとしよう。一つは電波範囲外だ。それはバッテリー切れかなにかだとして、もしコネクションを張ろうとして失敗したら、単純にユーザに尋ねるか、もしくは再接続するためのなにか賢いロジックを組むのがいいね。ただ、電波を出したままのループにするのだけは止めよう。いままでそういうやり方を１，２度見てきたけど、そういうことをやればバッテリーの消耗が激しいのは目に見えてる。特にユーザの知り得ないバックグラウンドサービスで走らせていて、そこにあったデバイスになんども再接続をし続けるなんてことをやってる。ただ、車輪の再発明はしないにかぎるよね。Android Beamはいまやかなり洗練されてきてる。例えば、Bluetoothファイル転送をしようとしたとき、最初のBluetoothハンドシェイクや2つの端末間の情報交換に、NFCを使ったいい方法がある。それが、Android BeamのsetBeamPushUrisやCeateBeamUrisCallbackメソッドを使うこと。2つの端末を触れさせるだけで、大きなファイルが転送される。Android Beamはネゴシエーションをして、ファイルはBluetoothを介して転送されるんだ。


　RFCOMM APIについてもいくつか話すことがあるんだ。初期のAPIではlistenUsingRfcommとcreateRfcommがあってどちらもセキュアなAPIで、セキュアな転送をするためにはセキュアな接続だってことが2つの端末の画面に表示されるようになってるんだ。つまりなにをするにもPINコードのエントリーが必要なんだ。もしこのAPIを使ってセキュアに接続しようとして、失敗したら、たぶんターゲットデバイスのPINコードが表示されなかったとかだろう。もしそういった場合は、スライドの下側にあるlistenUsingInsecureやcreateInsecureといったインセキュアなメソッドに戻してみよう。この接続のほうがよりシンプルだ。正直なところ、ほとんどの場合はセキュアなAPIは必要ないだろうね。もし2つのデバイスを自分の手と手に持ってるなら、見知らぬ男が間に入ってアタックをかけてくるなんてことはそうそうないだろ？だからにインセキュアな方法にすることで、認証が失敗する可能性をできるだけ抑えて、面倒になりそうなことは排除しよう。
(訳注: スライド上2つのメソッドはAPI level 5から、スライド下2つのinsecureメソッドはAPI level 10から導入されている)

  • Bluetoothスタック AVRCP1.0->1.3へバージョンアップ


　さて、最後に一つ。こういった難しい問題はさておき、Bluetoothについていい話があるんだ。ボクはとってもいいことだと思ってる。あたらしいスタックについて、他にも伝えておくことがあるんだ。ボクはあと数ヶ月でそれがAPI 18に採用されるってことにとても満足してる。その新しいスタックっていうのはAVRCP 1.3のことさ。(訳注: Audio/Video Remote Control Profile AV機器のリモコン機能を実現するためのプロファイル)これを聴いてる人の中にはとても楽しみにしていたひとがいるんじゃないかな。AVRCP 1.0は初期のAndroidで採用されていて、スマホをカーステレオにつないでリモコンとして使えたんだ。そして1.3になるとメタデータも送れるようになる。アルバムアート、全トラック数、再生中のトラック番号、タイトルといったようなメタデータをね。じゃあ、そのAPIを見ていこう。

（スライドを見ながら）今まで通りRemoteControlClient APIを使っていくんだ。つまりすでにGoogle Musicを使っていたアプリや、RemoteControlClientを使っていたアプリだったらそのまま動くってこと。キミのカーステレオとこれまで以上情報をやり取りできる。どういう情報がやり取りできるかを見たいなら、MediaMetadataRetriverを見てくれ。やり取りできるタグ情報がすべてわかるからね。（スライドを見ながら）例えば、アルバムアートだったり、アーティスト名だったりね。そして、MetaDataEditorを使うことで、クリアさせることもできるし、元々あったメタデータとミックスさせることもできる。なんだってできるんだ。OK、Scoutに返そう。

  • まとめ


Scout:
　いいわ。今日は2つのエキサイティングな話をしたわね。API level 18からBTLE APIとAVRCP 1.3が採用されるって話。このセッションのあとすぐにAndroidサンドボックスでオフィスアワーを予定しているからぜひ来てちょうだい。ただ、たぶんすぐにどっかいっちゃうと思うから、質問があるなら今少しだけ答えるわ。でも、Bluetooth APIのことだったりAndroidに関連したことについて詳細に知りたいのであればデベロッパー向けのウェブサイトをチェックしてちょうだい。（スライドを見ながら）このリンクにBluetooth情報があるわ。(http://developer.android.com/guide/topics/connectivity/bluetooth.html)
質問があるならマイクの前に来てちょうだい。


Richard:
本当にありがとう。
Scout:
ありがとう。
Matthew:
アリガトアル。