Bitkeyは、人々の営みをHome（暮らし）、Workspace（働く）、Experience（非日常の体験）と3つの領域に分割して事業を展開しています。その要素の1つとしてスマホで扉のカギが開くスマートロックを自社で開発しております。通常の扉の以外にもエントランスの自動ドアやエレベーターなどにデバイスを後付けで拡張し、宅配便や家事代行、ビルのアクセスコントロールなど、さまざまな業種・業態に合わせて一貫した体験を提供しています。

これらの価値を実現するために、自社デバイスとスマホの通信に利用するBLEは、弊社の主要な技術トピックの1つとなっています。本稿では、AndroidでBLEを扱う際のTipsと、自社デバイス向けAndroidアプリを開発する際の開発体制について紹介します。

AndroidのBLEといえば…

Android BLEを検索したときのサジェストの図

「Android BLE」に対してサジェストされるのはあいかわらず「ひどい」「不安定」といったキーワード。実際、これまでAndroid BLEの苦労に立ち向かった記事や講演が多数存在し、私も非常に参考にさせていただきました。今回は、そんな評判をくつがえすかもしれない、とある専門家を紹介します。その名もNordicSemiconductor/Android-BLE-Libraryです。

餅は餅屋かと思ったときの図

Nordic SemiconductorというノルウェーのBLEチップを開発している会社が作っているライブラリです。READMEの冒頭には心強い一文が書かれています。

An Android library that solves a lot of Android's Bluetooth Low Energy problems.

ここにはAndroidにおけるBLEのさまざまなつらみを乗り越えた跡が集約されています。たとえば、connectGattメソッドはSDKのバージョンによってはバグを引きますが、このライブラリが良い感じに吸収してくれています。

connectGattとの戦いの様子の図

それだけでもありがたいのに、このライブラリは各種インタフェースも充実しています。LiveData（no.nordicsemi.android:ble-livedata）やKotlinのSuspend/Flow（no.nordicsemi.android:ble-ktx）もサポートしていますので、ViewModelやJetpack Composeともスムーズに連携できます。餅は米屋より餅屋、BLEはWeb屋よりBLE屋に頼りましょう。

BLEコネクションの扱い

BLEコネクション（Android-BLE-LibraryでいうところのBleManager）の扱いは、普段のAndroid開発で扱うデータとは生存期間などの性質が異なります。ViewModelやそこにつらなるRepository/DataStoreで扱うこともできますが、別なアプリに切り替えたり、一旦スリープになった場合の挙動などを考えると、Foreground Serviceで保持することをお勧めします。最初にデバイスを発見してコネクションを確立するまでが時間のかかる部分なので、デバイスの消費電力とも相談ですが、なるべく接続は維持しておきたいです。

1つのAndroid端末から、同時に複数のBLEデバイスを扱う場合は、コネクションプールを作成しましょう。お手軽にやるならandroid.util.LruCacheでAndroid-BLE-LibraryのBleManagerを管理するのがお勧めです。必要に応じて再接続して、LruCacheから削除されるタイミングで切断します。本格的にやるのであれば、RDBなどのデータベースとのコネクションの扱いあたりを真似するとよいのではないかと思います。

BLE上でよく使われるGATTをはじめとする標準仕様には、インターネットでいうところのTCP、UDP、TLSあたりの一部を担ってもらうのがよくあるケースです。ただ、アプリ開発者からすると、そこに足りない部分を埋めてREST APIぐらいのレイヤーぐらいまで欲しいですよね。ですので、BLEデバイスを開発している各社はおそらくだいたいGATT上にさらに何らかのプロトコルを構築したりしていると推測します。弊社もそうです。そうして作ったものがRoomやRetrofitあたりと一緒に並ぶとよいと思います。

デバイス開発との連携体制の構築

ビジネスやユーザ体験の問題に取り組むアプリ開発者がいる一方で、BLEに関する部分は分業されているほうが望ましいと考えています。両者の問題を同時に対応できる優れたエンジニアは、どこを探しても豊富にいるわけではありません。それでも創業当初からなんとかやってきましたが、組織の課題として具体化してきていると感じます。

代表的な課題の1つが、量産の工場で検査に用いるアプリの開発です。GATT上にプロトコルを構築しているため、専用アプリを弊社から工場に提供する必要があるのですが、この開発は関係者の善意で属人的に対応していました。

また、テストに関してもアプリのテストにデバイスが必要で、デバイスの開発にアプリが必要という、ニワトリが先か卵が先かの問題があります。デバイスのファームウェアエンジニアとペアでわいわいやるのはそれはそれでアリなのですが、技術や日程調整の面で疎結合にしていくほうが、全体としては望ましいはずです。

現在、弊社ではこのような問題を解決するために、複数のアプリや複数のBLEデバイスを横断する仕様の管理と、その仕様に対応して開発・検証に用いるツールを開発するチームを整える方向に向かっています。仕様の管理と同時にツールの開発を進めることで、社内のBLEに関するエンジニアリングに対して手を打っていきたいと考えています。そのような中で、Androidは、社内や工場などで利用する内製ツールの分野において、iOSに比べて優位な点があると感じています。端末を比較的自由に操作できてリリースもコントロールしやすいため、素早く柔軟な対応が可能です。

将来このチームでは、スマホアプリとデバイスの開発者を効率的につなげる役割を担っていきたいと考えています。今後この構想が実現して、SETやSREみたいな良い感じの名前を付けてまたご紹介できたらと思います。

まとめ

• NordicSemiconductor/Android-BLE-Libraryを利用することで、SDKのBLEに関するAPIを直接扱った際のさまざまな問題を回避できます。
• BLEの接続はForeground Serviceでコネクションプールによる管理を行い、RoomやRetrofitと同様のレイヤーを開発することをお勧めします。
• 弊社ではBLEに関する技術の専門部隊を、組織構築の1つの案として考えています。

物理現象を扱う自社デバイスとスマホをConnectする手段として、弊社ではBLEを積極的に利用しています。このようなAndroidと開発に少しでもご興味ありましたらぜひご連絡ください。

著者紹介

津島 雅俊

2018年にBitkey入社、主にサーバーサイドの開発を経て、現在はデバイス内の組込みソフトウェアの開発を担当しています。が、今回のAndroidのように担当範囲をはみ出すことも。