「Android Mのプレビュー3」を試す(前編)

前回の記事のあと、すぐにAndroid MのPreview 2の記事を書けずにバタバタしている間に、Android Mは、マシュマロになり、Preview 3が登場してしまいました。今回はこのPreview 3を見てみることにします。とはいっても、見てわかるような変化はあんまりありません。そこで、今回は、APIという視点からPreviewを見てみることにします。

プレビューを見ると、Android 6.0は、それほど大きく変わったようには見えません。マテリアルデザインへの変更といった視覚的な要素の変更がないからです。また、5月のGoogle IOで発表された機能の中には、Photoアプリのように、Androidとは独立した機能になっているものもあり、必ずしもPreviewでしか見ることができないというものも多くはありません。

昨年Android 5.0が登場し、今年は6.0になったのは、従来のバージョンアップからみると、番号が大きく動きすぎたような感じがあります。Ice Cream Sandwitchは4.0、Jelly Beanは4.1、KitKatは4.4です。これに対して5.0は、Lollipopだけで終わりで、6.0になってしまいました(ただし不具合の修正などでアップデートは続くことがあります)。Googleとしては、大きな改良だとしてバージョン番号を1つ上げたのだと思われます。もっとも、iOSやWindowsよりもバージョン番号が小さいのはイヤというマーケッティング的な理由という可能性も捨てきれませんが……。

Lollipopは、それ以前のKitKatに比べると大きなバージョンアップでしたが、その分、トラブルも多かったようです。Lollipopの発表後に登場したスマートフォンでもKitKatを採用したマシンも少なくありません。バージョン番号が6.0となるMarshmallow(マシュマロ)には、再スタートという意味もあるのかもしれません。

アプリの「許可」が変わる

おそらく、Android 6.0の最大の変更は、アプリのPermissions(パーミッション。許可)の仕組みが変わる点です。大半のアプリは、アンドロイドが持つ、さまざまな機能を利用しますが、一部の機能に対しては、アプリは機能の利用を「要求」し、これに対して「許可」を得る必要があります。

これまでアンドロイドのアプリは、インストール時に一括してアプリに対して許可を得ていました。許可は、「すべて許可」か「すべて拒否」(インストールしない)のどちらかしか選択がなく、インストールするということは要求に対してすべて許可を出すということになっていました。しかし、このやり方は、アップデートで問題が出ます。というのは、アプリの要求が変更になると、ユーザーが手動で許可を出さない限り、アップデートが開始されません。アンドロイドのアプリには、1週間に一回程度の頻度でアップデートするものもあり、また、投入直後のアプリでは、もっと頻度が高い場合があります。許可をインストール時ではなく、実行時に行うことで、アプリは、許可なしでインストール可能になります。

また、アプリの要求は多岐に亘ることが多く、ユーザーも個別にいちいち吟味することは困難です。しかし、こうした状況が、一見無害そうに見えるアプリが「連絡先」情報を勝手に転送するといった「個人情報収集アプリ」などが広まってしまう原因の1つでした。しかし、アプリが具体的に許可の必要な機能にアクセスした段階でユーザーに確認を取るという方式にすれば、アプリの名称などから、ユーザーが判断することが可能になります。

ただ、こうした機能は許可の確認が煩雑になる可能性があります。そこで、Android 6.0では、許可の必要な機能をグループ化し、グループに対して許可を出せるようにしてあります。たとえば、SMSの許可グループには、SMSの送信と受信が含まれていて、アプリがSMS受信機能にアクセスするときに許可を求めますが、このときにSMSグループに対して許可を確認することができ、グループに対して許可を出せば、次に送信機能にアクセスする場合に確認が行われることはありません。

なお、Android 6.0では、すべてのアプリは、インストール時点で「PROTECTION_NORMAL」と呼ばれるカテゴリの機能要求が許可されていることになっています。これらは、無線LAN機能へのアクセスやバイブレーターによる振動のオンオフなど、ユーザーのプライバシーには関係のない機能だけからなっています。従来は、こうした機能の1つ1つに許可を得る必要がありました。このため、この「PROTECTION_NORMAL」に含まれる要求しか持たないアプリは、ユーザーに許可を確認することなく、実行することができます。

ただし、Android 6.0を搭載したマシンで、この新しい許可の仕組みにちゃんと対応できるのは、Android 6.0を想定して作られたアプリだけです。従来のアプリは、インストールされたら、すべての要求が許可されたという前提で動作しているため、起動後に、ユーザーから要求を許可されないという状態に対応できない可能性があります。もし、許可されない機能があれば、そこで終了してしまったり、異常な状態になってしまう可能性があり、そのために入力中などのデータを失ってしまうことになりかねません。

Playストアは、アプリの対応バージョンを認識しているため、Android 6.0未対応アプリの場合、インストール時に従来通りに許可を確認することになるはずです。また、前述の「PROTECTION_NORMAL」により、プライベートな情報やセキュリティが要求される機能にアクセスしないAndroid 6.0未対応アプリは、問題なく動作できるはずです。

ですが、Android 6.0は、インストール後に個々のアプリの許可を個別に管理できます。つまり、古いアプリに対しても、特定の機能へのアクセスを禁止できるようになっています。「設定」 ⇒ 「アプリ」で個別のアプリを選択して、「許可」を開くことで、行うことが可能です。つまり、インストール時にまとめて許可を出した、Android 6.0以前のアプリでも、特定の許可だけを取り消しできます。ただし、前述のようにAndroid 6.0以前に作られたアプリは、特定の機能にだけアクセスできないという状況に対応できない可能性があります。

指紋認証が標準対応へ

もう1つの大きな機能追加は、指紋認証への対応です。これまでに登場したアンドロイド機でも、指紋リーダーを搭載したものがありましたが、これは、メーカーが独自に実装したものでした。Android 6.0の指紋認証は、Androidによる指紋リーダーの公式サポートで、以後、メーカーは、独自実装をしなくても、ドライバなどを用意するだけで指紋認証が行えるようになります。その意味では、ユーザーメリットよりも、メーカーのメリットが大きな機能です。こうした例は、Bluetooth 4.0対応(当初はNECなど日本の一部スマートフォンのみが対応し、KitKatで正式氏対応しました)。

この指紋認証は、すでにサービスが開始されたAndroid Payなどの想定したものです。こうした支払システムでセキュリティをたかめるには、利用時の本人確認、つまり、たしかに本人が利用していて、盗んだり、拾ったりした他人のスマートフォンではないということを確認しなければなりません。このときにパスワードやPINといった方法もあるのですが、他人からのぞき見される心配もあり、買い物の支払という人前での操作ではあまり使いたくないものです。この点、指紋リーダーなら、操作も簡単で、他人に盗み見られる心配もありません。

APIとしては、指紋認証機能と「Credential」(クレデンシャル。資格証明)という機能が用意されました。指紋認証は、指紋リーダーを制御し、ロック画面の解除など、従来PINやパターンが要求されていた場合に指紋リーダーからの入力を受け付けます。

アプリケーションでは、支払の実行など、重要な操作では、正当なユーザーが操作しているのかどうかを確認することが行われます。このときに、アンドロイドが用意する「クレデンシャルの確認」を使うことで、ユーザーが指紋やPINなどで端末をアンロックしたり、他の処理を行ったあと、アプリが指定する時間内ならば、再度認証を行わずに済ませることができます。たとえば、オンライン通販のアプリで、一回目の購入で認証を行い支払を済ませたあとに、別の商品を購入するような場合、前回の認証が有効として認証を省略できます。

音声によるアプリの操作

また、Android 6.0では、アプリが音声入力、音声応答を使うことが簡単にできるようになりました。この機能は「Voice Interactions」(ボイス・インタラクションズ)と呼ばれます。Google Nowの機能として組み込まれ、ユーザーの音声が認識されたとき、アプリがあらかじめ登録していたパターンに合致すると、該当のアプリを起動したり、さらに、アプリ側から質問して、ユーザーに応答してもらうということが可能になりました。デモのビデオを見ると、サードパーティの音楽再生ソフトを起動すると、「どのジャンルを再生したい?」という質問が音声で行われ、それに音声で答えることで、ジャンル選択が行われるというものです。

これまでもGoogle Nowでは、音声によりアプリを動作させることができました。たとえば「タイマーを30分に設定」といった感じです。「ボイス・インタラクションズ」はこれをさらに進めて、アプリ側からの質問とユーザーの応答を可能にしました。 同様の機能は、Windows 10に搭載されているコルタナも持っており、本格的に音声でモバイルデバイスを操作する時代が到来しそうです。なお、Siriについては知りません(ジョークですのでお気になさらぬよう)。

Bluetoothスタイラス

このほかにもいくつか機能拡張があるのですが、気になったのは、「Bluetooth Stylus Support」です。一部のメーカーの機種には、ペンが利用できるものがありました。もともと、アンドロイドは、ポインティングデバイスとしてタッチパネル以外にトラックボールやマウスなどを利用できるような仕組みを持っていました。スタイラス自体は、ICS(Android 4.0)でポインティングデバイスの1つとして区別されるようになっていました。

今回の拡張は、Bluetooth経由でペンのタッチやボタン状態などを定めたもので、APIで単に抽象的な「スタイラス」デバイスが定義されているという状態から少し踏み出した感じがあります。

今回のAPI拡張は、具体的なスタイラスのサポートを前提としているのか、それともセットメーカーや部品メーカーからの要望で追加した機能なのかはわかりません。ですが、タブレットなどでのスタイラスのサポートは、iOS(iPad Pro)やWindows 10(Surfaceシリーズ)など他のプラットフォームでも行われているため、アンドロイドでも、メーカー独自実装ではなく、標準的なスタイラスが登場する可能性はありそうです。

本稿は、2015年9月14日にAndorid情報誌「AndroWire」に掲載した記事を再構成したものです。