Max」の外観が公開。全国高校eスポーツ選手権運営の舞台裏。I/Oでは、ハンドヘルドデバイス、つまり、スマートフォンやタブレットに加え、マルチスクリーン体験をもたらすプラットフォームとして、Wear、Auto、TVという3つの提案を宣言した。今後のAndroidを考える上で、極めて重要な要素でもある。これらのプラットフォームはAndroidでありながら、これまで慣れ親しんできたハンドヘルドデバイスとは異なる特別な振る舞いをするからだ。Preview」(以下、L)では、Notifications、いわゆる通知のメカニズムに大きな手が入る。Android端末の画面上部を下にスワイプすると引き出されるのが通知領域だ。Design(マテリアル・デザイン)への準拠により、きわめてリッチなものとなる。ロック画面通知がサポートされるようになる。画面がロックされているときにも通知を出せるようになるのだが、ロックされているのに全ての通知を表示してしまってはロックする意味がなくなってしまう。そこで、通知を「プライベート」、「パブリック」、「シークレット」という3種類に分類し、ロック画面への通知の有無やスタイルをアプリケーション側から指定できるようになっている。「プライベート」の場合は、Twitterから3通のメッセージがあることは通知されても、それが誰からのものなのか、どんな内容なのかは表示されない。シークレットの場合は、通知があることさえ表示されないといった具合だ。「Heads-up」と呼ばれる通知のメカニズムが用意される。これは、特定のアプリなどが全画面を占有し、通知バーが表示されていないときにも、緊急度の高い通知を画面最上部にポップアップさせる機能だ。通知はクラウドを通じてデバイス間で同期される。タブレットを使っているときにもスマートフォンに表示される通知を見逃すことはない。重要な要素として、通知内容にプレイバックコントロールと関連付けられたリッチなコンテンツを用意することができるようになった。これだけの要素を見ているだけでは、それがどうした感が強いのだが、実際に調べていくと、シンプルでありながら、Androidの世界観に大きな拡張をもたらすことが分かる。Beanが登場したときだ。このとき、通知リスナーという機能が実装された。OSがアプリからのメッセージを受け取り、その内容を通知領域に表示するだけではなく、別のアプリがリスナーを使い、その内容を受け取れる仕組みだ。Lでは、通知の内容がWearにブリッジされるようになった。Wearに渡る仕組みが実現されている。開発者は、スマートフォンアプリ内に通知をWear用に用意する機能を実装することで、Wearに最適化した通知内容を送れるようにもなっている。通知は、そのものをタップしたり、表示されているボタンをタップすることで、さまざまなアクションを指示することができる。このときに起こるのがインテントだ。OSの最も特徴的な要素であるインテントは、いわゆる共有機能として日常的に目にしていると思う。このページをスマートフォンで見ているときに、メニューから共有を選ぶと、共有できるアプリの一覧が表示され、その中から任意のものをタップすれば、ページ内容やURL、タイトル情報など、相手が受け取れるデータが別のアプリに渡される。古い仕組みとしては、ネットワークパイプのメカニズムにも似ている。いわゆるツールキットアプローチの1種だ。Wearは、スマートフォンから通知を受け取り、その通知に対してユーザーが起こしたアクションをスマートフォンに戻し、インテントを発生させて、さらにその結果を通知として受け取ることを繰り返してUXを実現している。こちらは、通知のプレイバックコントロールをうまく利用している。Autoで動いていることを知らなくてもかまわない。アプリはメディアサービスを使うように機能を拡張し、再生するコンテンツ内容をサービスに渡す機能を実装するだけでいい。スマートフォンで音楽を再生すると、通知バーにジャケット写真や一時停止、次へ、前へなどのボタンが表示されるが、それと同じ仕組みが使われる。これによって、Auto用のアプリを別に用意する必要もなく、既存アプリの機能の大部分を再利用することができるわけだ。Autoデバイス側のクライアントは、メディアサービスからコンテンツ内容を受け取り、運転しながら操作しやすいように最適化したUIでそれを表示する。これによって、アプリは特にAuto専用のUIを自分で持つ必要もなければ、ユーザーの操作を直接受け取る仕組みを持つこともない。画面解像度を気にする必要もなければ、タッチ操作によるメッセージの受け取りを気にする必要もないのだ。Autoは、通知領域の拡張であると考えればいいだろう。ここでもLの通知サービスが重要な意味を持っていることが分かる。TVだけはちょっと違う。このデバイスだけは、スマートフォンやタブレットの力を借りずに、スタンドアロンで稼働しなければならないからだ。このデバイスでは、Androidアプリに、開発者がちょっとした宣言を加えるだけで動いてしまう。Googleは、それを推奨しない。Gameサービスによって、ゲームのプラットフォームとしては使うが、基本的にはChromecast的にコンテンツのプレーヤーとしての利用を推進しようとしているように見える。利用にはGoogleアカウントが必要だが、ユーザーがサインインを拒んだ場合にはゲームアプリはそれを強要しないようにするべきだとしている。ゲームの結果のセーブについても、クラウドセーブが推奨され、ローカルデータを削除できるようにする機能を用意すべきだとも。これによって、ユーザーは、TVであろうが、スマートフォンであろうが、タブレットであろうがクラウドを介して唯一の自分自身のゲームデータを保持し、どこからでも参照することができる仕組みだ。Googleは、ゲームアプリがWebブラウズ機能を持つことも推奨しない。TVはブラウズには向いていないデバイスであるともいう。TVにとってゲームアプリはやはり特別な位置付けにあるようだ。Castを扱うMediaRouterフレームワークの機能が重要視されるべきだ。OSが稼働していても、パーソナル性ができるだけ希薄なものになるように考えられていることが分かる。時計はとてもパーソナルなもので、肌身離さずという使い方がされる。無条件に通知が腕に飛んでくるにしても、スマートフォンから離れれば、ほぼただの時計になってしまう。Wearがクラウドと通信するには、必ずペアとなっているスマートフォンが必要だ。スマートフォンと時計を一緒に放置したら、プライバシーはないに等しい。Wearには、ロックするという概念が実装されていないからだ。I/Oで、人々の暮らしの中で身近な存在になっている各種の画面を新たなプラットフォームとして提案し、Androidの存在感を高める方向性を提示した。開発者は、通知やインテントといった既存アプリで慣れ親しんだ方法で、これらのプラットフォームへの対応ができるわけだ。各種のアプリがこれらのプラットフォームに対応するのに、それほど長い時間はかからないだろう。アプリが増えれば、プラットフォームは普及する。ユーザーは新たな画面プラットフォームをパーソナルなものとして扱わなくてもいい。あらゆるデバイスをまたいで、自分の暮らしをAndroidに掌握されてしまうようなことはないことが分かる。うまい手を考えたものだと思う。