2018年2月8日から9日の2日間にわたって、ベルサール新宿グランドにてDroidKaigi 2018が開催されました。今回でDroidKaigiの開催は4回目、参加者数は1,000名規模のカンファレンスとなりました。セッションの応募総数も300件を超え、海外からの応募・参加も多数受け付けるなど、日本国内に限らず世界からも注目を集めるイベントとなりました。

DroidKaigi 2018ではテーマを「ニッチ」とし、幅広く内容の濃い発表を募集しました。本稿ではそのなかから、「⁠AI is ready for you. Are you ready for AI?」と「アプリをエミュレートするアプリの登場とその危険性」の2つのセッションをピックアップして紹介します。

AI is ready for you. Are you ready for AI?

このセッションは、昨年のGoogleI/Oでも話題にあがったTensorFlowをAndroidで動かす方法から、開発者がモデルを構築しアプリに組み込むまでの一通りの流れを解説しました。

セッションの登壇者である@rejasupotaro氏が冒頭で「AIはアカデミックな領域を超えて、今や私たちが日々利用するアプリケーションでも活用されはじめ、プロダクション環境でも充分に動作できる状態になっている」と述べたように、様々なアプリケーションがユーザの次の行動を予測したり、ユーザのおかれた状況から確度の高い情報を抽出したりして次に何をすればよいかを提案する機能をリリースしはじめています。昨年のGoogleI/OではAI Firstというテーマのもと、Android 8.1 OreoからNeural Networks APIが組み込まれることと、TensorFlow Liteと呼ばれるモバイル端末で機械学習を動作させる軽量なライブラリが発表されました。また、AIや簡単な機械学習を組み込んだアプリが2017年のベストアプリに選出されていることからも、AIに対する注目度の高さがうかがえます。

@rejasupotaro氏は、TensorFlowはレゴのように要素をつなぎ合わせてComputation Graphを構築するためのツールキットであると説明します。Googleの公式なサポートのもとで開発され、モバイル端末を含む様々な環境で動作するように作られていることが、数多くある機械学習のツールキットの中でもTensorFlowを使用する大きなモチベーションであると述べています。

TensorFlowはモバイル向けに2種類のツールキットを用意しています。ひとつはTensorFlow Mobile、もうひとつはTensorFlow Liteです。TensorFlow MobileはC++で記述されたコアにアクセスするためのJavaのクラス群とAndroid向けに用意されたAPIを持っています。そしてTensorFlow Liteはモバイル端末に特化し、より軽量になっています。今後はTensorFlow MobileからTensorFlow Liteへと移行していくようです。

TensorFlowで学習済みのモデルを利用するのは非常に簡単です。他のライブラリを導入するときと同じようにTensorFlowを導入し、学習済みモデルを配置すれば、Javaのコードを記述するだけで利用できます。

モバイル端末というハードウェアリソースの限られた環境で機械学習を動かすには、モデルの最適化が必要だと@rejasupotaro氏は説明します。モバイル端末でTensorFlowを用いる場合、アプリケーションの機能として重要なものは実際のデータからの推論です。モデルの最適化は、Computation Graphに含まれるノードのうち推論では必要ない部分を減らすこと（Computation Graphの軽量化⁠）⁠、また端末のハードウェアスペックを考慮して再トレーニングを行うことの2つの事柄にフォーカスします。

モバイル向けTensorFlowでは、Graph DefinitionファイルとCheckpointファイルから最適化の過程を経て生成するモデルを利用します。最適化の過程にはFreeze・Optimize・Convertの3段階あり、これらの段階を経ることで推論で必要な部分のみをもつComputation Graphができます。@rejasupotaro氏は実際に最適化されたモデルのパフォーマンス計測についても取りあげ、ベンチマークツールによる計測結果の比較も行いました。モデルは小さいほど高速に動作し、かつアプリケーションに組み込んだときのファイルサイズも小さくなります。もし大きなモデルが必要な場合、@rejasupotaro氏はAPKファイルを分割したり、インストール後にネットワークからダウンロードできるようにする方法があると紹介しています。

アプリをエミュレートするアプリの登場とその危険性

アプリをエミュレートするアプリとは、ひとつのアプリケーションを同じ端末内に複数インストールできるように見せかけ、擬似的に複数のアカウントを同時に利用可能にするアプリケーションのことです。マルチアカウントアプリとも呼ばれます。このセッションの登壇者である@oboenikui氏は、このようなアプリケーションがどのように動作するかを解説し、それよって考えられる危険性についても論じました。

マルチアカウントアプリには2種類あり、主にアプローチの違いによって区別されます。1つはAPKを改ざんして同じアプリケーションを同居可能にするもので、もう1つはアプリケーションの動作をエミュレートすることで擬似的に同じアプリケーションが複数同時にインストールできているように見せるものです。このセッションでは後者のアプリをエミュレートするアプリについて取りあげました。

はじめに@oboenikui氏は、アプリをエミュレートするアプリ（ホストアプリ）が採用しているエミュレート方法について説明しています。大きく分けると3段階あり、ゲストアプリのインストール、ゲストアプリのプロセスの起動、そしてゲストアプリのActivityの起動です。

そして、ゲストアプリのインストールにあたって重要な、ホストアプリのAndroidManifestに@oboenikui氏は着目します。ホストアプリは他のアプリ（ゲストアプリ）を動作させるためにあらゆるパーミッションの使用を宣言しています。これはホストアプリのプロセス内で擬似的にゲストアプリを動作させることから、ゲストアプリが宣言するすべてのパーミッションをホストアプリも宣言しておく必要があるからです。ホストアプリはまた、多数のStubActivityやStubContentProviderを持っています。これらはアプリのインストールや動作をエミュレートする上で重要な役割を担っています。

ホストアプリがゲストアプリをインストールするには、ゲストアプリのAPKを読み取ってホストアプリのデータ領域に展開する必要があります。JavaのリフレクションAPIを用いてゲストアプリのAPKを読み取ると、ホストアプリのデータ領域にゲストアプリ用のデータ領域を作成し、APKファイル内にあるネイティブライブラリ等をコピーします。

@oboenikui氏はホストアプリの重要な役割のひとつにゲストアプリのプロセスの起動をあげています。ゲストアプリのプロセスは実際にはホストアプリがStubContentProviderに割り当てているプロセスで、ゲストアプリの起動に必要な手続きはStubContentProviderが実行します。StubContentProviderは複数個用意されているので、起動するゲストアプリごとに別のStubContentProviderが割り当てられます。StubContentProviderのプロセスが起動すると、ゲストアプリのためのVMを立ち上げ、ActivityThreadをスタートします。ただしActivityThreadはホストアプリ内でつくられるため、そのままではゲストアプリを起動できません。ホストアプリのStubContentProviderはActivityThreadを改ざんしてゲストアプリについての情報に上書きします。またゲストアプリ内でのメソッド呼び出しについて、何らかの改ざんが必要なものについてもこの段階で行います。ここまででアプリケーションの起動の準備が整います。

最後にゲストアプリのActivityを起動する段階では、ゲストアプリのActivityに対するIntentをすり替えてホストアプリのStubActivityを立ち上げます。その後ゲストアプリのプロセスにあるActivityThreadで、受け取ったIntentからもともと起動する予定だったゲストアプリのActivityに対応するIntentを取り出します。ホストアプリにあるStubActivityの役割について、@oboenikui氏はホストアプリではない別のアプリからゲストアプリを起動する場合を考慮した結果であると考察しています。これは実際にゲストアプリのプロセス起動時にActivityを起動するメソッドを改ざんする処理を実行していることからもわかります。

このようなアプリをエミュレートするアプリの危険性として、@oboenikui氏は3つの危険性を指摘しています。1つめはアプリ内広告や課金処理などを不正に書き換えられてしまう危険性、2つめは過剰にパーミッションを与えてしまう危険性、そして3つめはアカウントやパスワード漏洩の危険性です。ホストアプリはゲストアプリに関するデータを自分の領域に置いて管理するため、ゲストアプリがもっている情報が見えてしまいます。またゲストアプリは、本来使用しないはずのパーミッションをホストアプリの宣言によって使えるようになってしまいます。

まとめ

年々規模が大きくなり成長し続けているDroidKaigiですが、今回はじめてセッション公募にあたってテーマを設けました。これまでAndroidはハンドセット端末やタブレット端末のためのOSとして進化を遂げてきましたが、Androidの技術がそれらの端末だけにとどまらず、ウェアラブルデバイスをはじめIoTや自動車といった領域にも広がりを見せているなかで、筆者は私たち開発者がもつ知見もより広く、かつ深くなってきていることを感じました。本稿で紹介したセッション以外にも、動画配信・編集に関する技術やAndroid Auto、NDKなど多様なトピックのセッションがありました。毎年人気をあつめる設計に関するセッションも、MVP・MVVM・MVIなど様々なバリエーションで議論が深まっていたように思います。

また、筆者はAndroidの技術に触れる層の厚みも感じました。DroidKaigi 2018では学生応援プログラムと題して学生向けにDroidKaigiへの参加を支援する取り組みを実施しました。昨年も遠隔地から参加されている高校生がいましたが、今年もこのプログラムを通じて参加していて、平日開催にもかかわらずDroidKaigiへ参加する熱量の高さを感じました。DroidKaigi終了後にも積極的にAndroidの技術や知見を共有するためのイベントを開催している学生も見かけることができ、DroidKaigiが技術カンファレンスという意味だけでなく、技術者どうしをつなぐハブにもなりつつあると思います。

本稿を執筆時点ですでに多くのセッションの資料が公開されています。今後各セッションの録画データも順次公開される予定です。ぜひ、DroidKaigi 2018で得た経験や知見を身の回りの人たちにも伝えていっていただければと思います。そして、次回のDroidKaigiでお会いできることを楽しみにしています。