これは昔話。昔話なので記憶ちがいもあるかもしれない。
今は昔
Androidでハードウェアを制御してみようというストーリーは古くからあった。まだスマホがそれほど普及していない2010年ごろにはすでにあった。いろんなものが現れては消えた。まだ過去形で語るには早すぎるかもしれないが、もう一区切りついたのではないか。
ADK
2011年のことである。Google I/OでADK(Android Open Accessory Development Kit)が発表された。AndroidのスマホやタブレットとアクセサリをUSBで接続しようというものだった。Android2.3.4以降と3.1以降が対応。アクセサリモードとホストモードがあって、アクセサリモードではAndroid側がUSBデバイス、ホストモードではAndroid側がUSBホストとなる。ただしホストモードに対応するのはAndroid3.x系のみであった。当時はAndroid2.x系とタブレット向けのAndroid3.x系に分かれていた時期で、スマホではUSBホスト機能が使えなかった。アクセサリモードのターゲットとしては、Arduino UNO+USBホストシールドなどが使えた。
日本Androidの会の神戸支部や秋葉原支部ロボ部、横浜支部ロボ部の開発者のあいだでも盛り上がり、こんな本とかこんな本とか出た。神戸支部の@yishiiさんなどはADKが使えるPICボード(PIC ADK Miniboard)を開発したりされていた。とても思い出深い。でもADKじたいはその後マッハで廃れた。なにしろAndroid 4.0以降スマホでもUSBホスト機能が使えるようになったので存在意義が薄れてしまった。アクセサリというコンセプトがいまいちエコシステムを築けなかったようにも思う。こんなふうに短命ではあったが「Androidでハードウェア制御」の道を開いた歴史的意義は大きいと思う。
microbridge
おなじく2011年のことである。ADB(Android Debug Bridge)を利用してAndroidとハードウェアをUSBでつなごういう話が出てきた。それがmicrobridgeである。ADKに対応しない古いAndroidでもUSBデバッグモードをONにさえすれば利用できるメリットがあった。やはりArduino UNO+USBホストシールドなどがターゲットとして使えた。ADKと比べてもマイナーな存在だったけど、電子工作界隈ではけっこう流行った。ぼくもシャアザクカメラとか作った。今は昔の話である。なにぶんデバイス側にUSBホストが必要で対応ハードが限られているのはADKと同様で、ADKと同様にフェードアウトしていった。
FTDriver / Physicaloid
ADKがはやくもオワコンとか言われだした2013年、@ksksueさんがFTDriver / Physicaloidを公開した。FTDriverはAndroidのUSBホストAPIをラップしてFTDIのUSBシリアルICなどと手軽にシリアル通信できるようにしたもの。Physicaloidはさらに機能を統合し、Arduinoのファームを書き換えられるようにしたものだった。Android 4.x系の普及でスマホでもUSBホストが使えるようになったので、ターゲット側にUSBホスト機能が必要なADKやmicrobridgeよりこっちのほうがターゲットの幅が広がるというメリットがあった。同様のコンセプトのプロジェクトとしてusb-serial-for-androidというのもあった。
組込みAndroid
もう一つの流れとして、スマホやタブレットでなく組込みLinuxボードにAndroidを載せようというアプローチがあった。当時はArmadilloとかBeagleBoardとか組込みLinuxボードがいろいろ出て来ており、組込みLinuxじたいが盛り上がっていた時期でもあった。そういったボードにAndroidを載せようという動きである。組込みLinuxはアプリ開発がたいへんだからAndroid載せて開発を効率化しようぜ、というストーリーだった。
先に述べたスマホにハードウェアを接続するアプローチにはカジュアル勢も多かったのに比べ、こちらに取り組んでいたのはおもにガチ勢だったように思う。なにぶんLinuxカーネルやらデバイスドライバの知識が要るし、ビルドにはかなりのCPUパワーが要る。ハードウェアを叩くにはAndroid NDK、つまりあのめんどくさいJNIを使うことになる。しかも組込み機器には一般的にはスマホやタブレットのようなGUIデバイスは必ずしも存在しない。そしてどんどんスペック要求のあがっていくAndroidに対して当時の組込みLinuxボードはやや非力であった。加えて2012年に登場したラズパイがとにかく安くてお手軽だったのでLinuxボード使いたいカジュアル勢はみんなラズパイのほうに行ってしまった。
いつしか下火に
2010年代も半ばになると、だれもが当たり前にスマホを持っている時代になった。Androidは当たり前の技術になり、技術者界隈もかつての目新しさゆえににぎわいはなくなり、もともとイロモノ系色の強かった「Androidでハードウェア制御」という物語は語られることも少なくなった。アプリ技術者とかがカジュアルにモノづくりするならArduinoかラズパイが定番となり、AndroidのスマホとはWiFiやBluetoothを使って連携という形をとることが多くなった。そうなるとAndroid側は技術的には通常のアプリとなんら変わるところはなくなった。いや、目新しいところとしてはBLE(Bluetooth Low Energy)があったか。AndroidはBLE対応ではiOSに後れを取り、またAPIがクソだとか言われながらも、しばらくはその話題で盛り上がった。それも2016年ごろにはだいぶ落ち着いたように思う。
Android Things
2010年代半ばごろから新たなバズワードとして「IoT」が大きく喧伝されるようになった。2015年、ラズパイなどで動くIoT向けWindowsとしてWindows 10 IoT Coreが登場した。そしてそれに呼応するかのように2016年末にはAndroid Thingsが発表された。おなじくラズパイなどで動くIoT向けのAndroidである。画面は必須でない・単一アプリ動作(システムアプリ不在)など組込み向けに整理された軽量OSであり、ラズパイの性能が向上したこともあって、従来の組込みAndroidに比べて無理筋感がかなりなくなったと思う。めんどくさいJNI不要でハードウェアを叩けるThings Support Libraryも用意された。悪くないかもしれん。ただまあThings Support Libraryは本格的な組込み制御にはとうてい使えない。というよりガチの組込みに使うことを考えたAPIではないと思う。アプリ技術者にカジュアルにハードウェアを叩いてもらうためのAPIという印象を受けた。
2018年現在のぼくの答え
ぼくは組込み系のワンチップマイコンにリッチなUIを担わせるのは悪手だと思ってる。どうがんばってもスマホに比べれば見劣りするし、なにより開発効率が悪すぎる。だから何らかの通信手段を介してスマホやタブレットに組込み機器のUIを担わせるのがスマートだと思ってる。通信手段としてはWiFi、Bluetooth(BLEまたはSPP)、USB(シリアル通信)の3つだろう。とりわけWiFiとBluetoothは、ESP8266やESP32といった無線マイコンモジュールが出て来たことでハードウェア側の敷居が大いに下がった。コスト的にも技術的にも。
もう一つのアプローチ、組込みボードにAndroid Thingsを載せるのは、Androidの豊富なフレームワークを利用してアプリ開発を効率化しようというストーリーとしてはアリかもしれんと思ってる。ただしThings Support Libraryはおもちゃだと思ってるので、カジュアルなものと承知の上で割り切って使うか、ガチのリアルタイム部分はサブマイコンに任せるのが正解だろう。
