車とスマホがつながるSDLの世界 第4回

Ubuntu 14.04.5を用意すべし！

SDL対応アプリ開発環境の構築その1～車載機エミュレーターを作成する

ブラウザー上でHMIを起動して画面を確認しよう

　ここまで来れば、残る作業もあとわずかだ。ウェブブラウザーで車載機エミュレーターのUI部分、HMIを実現するウェブアプリを開けばいいだけだ。これは、SDL Coreを動かした2種類の環境によって2通りの手順がある。言い換えれば、macOSまたはWindows環境か、Ubuntu環境か、という違いだ。以下、両方の場合について説明する。

1. Generic HMIを入手する

　HMIをウェブブラウザー上で起動する作業の最初のステップは、GitHubからGeneric HMIのソースコードを入手することだ。ソースコードの入手先は同じだが、Dockerを使ってSDL Coreを動かした場合と、Ubuntu上でSDL Coreをビルドして動かした場合では、異なる手順が必要となる。

　まず、Docker用にGeneric HMIを用意するには、適当なブラウザーでGitHubのページを開き、そこからZIPファイルとしてソースコード一式を入手するのがいいだろう（図10）。

図10　macOSやWindows上でGeneric HMIを動かす場合は、GitHubにあるgeneric_hmiをZIPファイルとしてダウンロードするのが簡単だ

　このようにして入手したZIPファイルは、どこか適当な場所に展開しておこう。ZIPファイルを展開すると、「generic_hmi-master」というフォルダができる。

　一方、Ubuntu環境で使用するGeneric HMIは、gitコマンドのclone機能を利用して、GitHubから直接コピーするのがいい。ホームの下のSDLディレクトリにいる状態で、以下のコマンドを実行する。

$ git clone https://github.com/smartdevicelink/generic_hmi.git

　これにより、SDLの下にgeneric_hmiディレクトリが作成され、その中にHMIのソースコードがすべてダウンロードされる。

　HMIの場合は、ブラウザー上で実行する一種のウェブアプリなので、原理的にはソースコードをそのまま実行できる。実際にはかなり多くの構成要素（JavaScriptやCSSなど）をビルドしてまとめた状態となっているが、特にソースコードに手を加える必要がない限り、GitHubから入手したディレクトリの内容をそのまま実行できると考えていい。

2-1. ブラウザー上でHMIを実行する（Docker版）

　このステップでは、いよいよ車載機エミュレーターを起動して利用可能な状態にする。前提条件としては、Dockerを利用して、すでにSDL Coreが起動した状態になっていること。そのうえで、ダウンロードしたZIPファイルを展開したgeneric_hmi-masterフォルダに含まれるindex.htmlファイルをブラウザーで開けばいいだけだ（図11）。

図11　GitHubからZIPファイルとしてダウンロードしたgeneric_hmi-masterを展開したフォルダ内にあるindex.htmlファイルをブラウザーで開く

　index.htmlファイルをダブルクリックするか、ブラウザーアプリのアイコンにドラッグ＆ドロップして開く。最新のブラウザーであれば、たいていのもので動作可能だが、SDLとしての推奨はGoogle Chromeなので、特に理由がない限りChromeで開くのがいいだろう。その結果、真っ黒な画面の上部中央に白い「Apps」という文字が表示されれば、まだ何も対応アプリとリンクしていない状態の車載機エミュレーターが動作したことになる（図12）。

図12　ブラウザー上でHMIを動かすと、初期状態では真っ黒なディスプレイの上部中央に「Apps」とだけ表示される。今はこれでOKだ

　最初に述べたように、Dockerを利用する場合にはややマイナーな不具合が発生する。次に示す図は、次回に解説するSDL対応アプリを作成して動かした状態だが、本来表示されるべきアプリのアイコンが、見つからない（リンク切れの）画像ファイルとして表示されている（図13）。

図13　DockerでSDL Coreを動かす場合には、今のところ、リンクしたSDLアプリのアイコンが表示されないという不具合がある

　この原因は、macOSの場合、Docker上のSDL Coreが利用しようとする作業用ディレクトリが、最近のmacOSのSIP（System Integrity Protection）によって保護された領域にあるため、SDL Coreがアプリから受信したアイコンファイルを保存できないことによる。Windowsの場合も、やはり受信したファイルを保存できないが、その理由は、そもそもディレクトリ構成がLinuxとはまったく異なるからだと思われる。

　現状では、これらの問題を簡単に回避する方法はなさそうなので、SDL Coreのビルドの手間を惜しまなければ、Ubuntuによる方法を採用するほうが無難だ。念のために付け加えると、macOSの場合、リカバリーブートしてSIPを解除しても、この問題は解決しなかった。

　なお、Windows版のDockerは、仮想化技術としてマイクロソフトのHyper-Vを利用する。それに対して、次回に説明するAndroidアプリの開発環境では、デバイスのエミュレーターを動かすための仮想化技術としてインテルのVT-xを利用する。これらを1台のマシンで同時に動かすことはできない。

　そのためDockerによるSDL Coreの動作と、Androidの開発環境で仮想デバイスは1台のマシン上で両立できない。Androidの実機をUSBで接続すれば動かすことができるものの、この点でもDockerではなく、多少面倒でもUbuntuによってSDL Coreを動かすほうが確実だ。