Android fireside chat

意訳です。間違っているところもあるかもしれません。。。

何もマークがないのは司会者です。
Q: は質問者、名前付きはパネリストです。



---------------------------------------------------------------------

fireside chat の目的は、基本的には Android について知りたいことを君たちが質問することです。今日アナウンスしたことが、どのように行われてきたのか、どのように決まってきたのか。そういうこと全てです。

つまり、Q & A セッションです。部屋の前と真ん中にマイクがあります。質問がある人はそこに並んできいてください。質問がない場合はちょっとした短いセッションをします。

# 会場ちょっと笑い

ここ数週間でオンラインから集めた2、3の質問があります。この内のいくつかも聞きたいと思います。

質問をする準備ができるまで、パネリストは自己紹介してください。自分は誰で、Googleでは何をしているのかを簡単に。

Gabe : Gabe Cohen です。Android OS のプロダクトマネジャーです。Google Play services と他いくつかのことにも関わっています。

Xavier : こんにちは、Xavier Ducrohet です。Developer Tools と SDK のリーダーです。

Adam : Adap Powell です。UI Toolkit のフレームワークエンジニアです。

Rachel : Rachel Garb です。Android OS のインタラクションデザイナーです。

Jhilmil : Jhilmil Jain です。Android のユーザーリサーチのリーダーです。

Chet : Chet Hause です。UI Toolkit チームのエンジニアです。

Dianne : Dianne Hackborn です。Android Core Framework チームのエンジニアです。

Dave : Dave Burke です。エンジニアリングディレクターです。プラットフォームと Nexus デバイスを担当しています。

Kirkpatrick : Kirkpatrick です。Play Store アプリとゲームとハードウェアを担当しています。

Miles : Miles Bar です。Google Play の一部であるアプリのエンジニアリングマネジャーです。

ありがとうございます。では、始めましょう。後ろのほうに列ができています。最初の方どうぞ。



Q : 私の質問は Java 8 についてです。Java 8 は Android にきますか？もしそうならいつですか？すべてのバージョンに対してサポートされますか？

# マイクの渡し合いになり、会場笑い

これは、ちょっと hot potato question ですね。

# hot potato とは、物議をかもしそうな扱いにくい問題のこと

マイクは Xav（Xavier）にいくのかな。。。

Chet : 一般的に、望みが含まれている質問というのは、あなたがそれを考えたいということでしょう。でも、答えがあなたの望むものになるかはわからないですよ。我々は基本的なポリシーに沿って答えます。つまり、将来本当になるをするのかについては話せないのです。
知ってるでしょ。
まぁ、そこにある基礎を並べるだけです。
さぁ Xav 答えて。

じゃあ質問に答えましょうか。
Xav、何がいつ起こる？

# Xav への無茶振りに会場笑い

Xav : ノーコメントで。

# Chetとかパネリスト笑い
# その後、どうするの... 的な雰囲気にw

完璧ですw。
オーケー、これで全部ということですね。わかりました。次の質問に行きましょう。ちゃんと答えられる質問だといいのですが。



Q : Dianne への質問です。Binder についての仕事にとても感謝しています。 これは Android の心臓部を支えているものです。あなたは Binder の開発に関わってこられましたね。Android が Android になる前からも。Binder についての歴史とそこでのあなたの仕事を少し話してもらえませんか？

Dianne : オーケー、ありがとう。Binder は BeOS から始まり、そこから発展したのですが、私は Binder を作ったメインパーソンではありません。私は BE で、その後 Palm Source でエンジニアとしてそれについて働いていました。それで、Android の IPC としてそれを採択しました。でも実際のところ、それが Android のコアだとは思っていません。それは Android で IPC を行う便利な方法です。Binder のかつてのバージョンは確かにもっとプラットフォームデザインのコアでした。現状では、IPC に基づいた機能を実行するとてもいい方法だということです。


では、オンラインから事前に受け取った質問をききたいと思います。



Q : 今日キーノートで見たものでは、Material Design がもっとも興味深いものの一つだと思います。このようなアイディアをまとめあげるために、どのような種類のリサーチを行いましたか？

Jhilmil : Material Design のために、会社をまたいでリサーチャーが Google に集まった最初のときのことです。15の異なるグループ、4つの異なるGoogleオフィスがリサーチのために一緒になりました。私たちは4つのメインエリアでリサーチを実施しました。
1つ目はコンポーネントです。コンテナとエレメント、パターン、レイアウト、フローティングのようなアクションボタン、モーション、アクセシビリティ。私たちが行ったリサーチタイプの例としては、まず、キーとなるデザイン原則を見つけ有効なものにしたことです。適切なモーションカーブやスピードなどを見つけ出しました。
次に、デザイナーが留意するべきであるユーザービリティの主要な問題をハイライトしました。例えば、フローティングアクションボタンの色を選ぶとき、背景と混じり合わないようにしないといけない、ということは早い段階のモックで気づきました。また、フローティングアクションボタンのサイズがばらつくとユーザーが混乱するということもわかりました。
3番目は、数々のデザイン変更を行って、非常に多くのアクセシビリティの研究をしました。それらのデザイン変更の1つとして、より改善されたカラーパレットを得ることができました。背景との間で必要になる、色のコントラストが考慮されています。弱視のユーザーもよりよくテキストを読むことができます。

Dave : もしフローティングアクションボタンは何なんだろうと考えているなら、、、僕も1週間前まで何なのか知らなかったんだけど、、、実際はただのImageViewだよ。elevation がセットされているだけの。そう思ってるでしょ。でも格好いいよね、あと、丸いし。丸じゃないといけないんだっけ？電話アプリはフローティングアクションボタンあるよね。

# パネリスト間でがやがや

Dave : 君たちとエンジニアの間で翻訳が必要みたいだ。



Xav に質問です。質問を引用しましょう。

Q: パフォーマンスを考えるなら、なぜ Genymotion を Android のオフィシャルなエミュレータにオファーしないのですか？

# 会場から笑いと拍手

Xav : ええと、、、いい質問ですね。とてもいいプロダクトだと思います。でも、全部が無料なわけではないですよね？だから、デモバージョンがある。デモが実際にはなんなのか知りません。でも、何かを得るために支払いが必要だったと思います。なので、それを配布することはできません。
他のこととして、明らかに我々には改善しなければいけないことがたくさん残っています。本当にやりたいこととして、すでに利用できるすべてのエコシステムのエミュレートがあります。つまり、ARM、Mips、x86。彼らはパフォーマンスのために x86 に注力していますよね、理解できることです。でも我々はそうすることはできません。我々はより多くのハードウェアを長期間サポートしたいのです。Bluetooth、マルチタッチ、などなど。我々が自身のスタックをコントロールするほうがよいのです。そうするためのテクノロジーも保持したいですし。でも、すばらしいプロダクトなのは間違いないですし、必要に応じて使ってみるのがいいと思います。

ありがとう。では、会場からの質問に戻りましょう。



Q : Android L についてです。adaptive bit rate video と HLS のサポートについて何か新しいことはありますか？

Dave : うーん。オーケー。我々がやってきたことで最も興味深いのは、、、まだそれがローンチされたかわからないんだけど、でも差し迫ってることは、我々が ExoPlayer と呼んでいる何かがオープンソースになるってことです。これは YouTube と Play Movies と TV のプレイヤーです。MediaCodec、MediaDRM、MediaExtractor、MediaCrypto 上に構築されています。とてもいい adaptive bit rate プレイヤーです。Dash（MPEG DASHのこと？） を使っています。
それが知るべきことの1つ。それと、多分確かだと思うけど、我々は L で HLS の最新の internet draft へアップデートしました。覚えてるのでは、これで全部だと思います。



Q : L のリリース用に準備された新しい UI と UX を見ました。Action Bar で UP Navigation アフォーダンスを使ってきました。でも、新しいものでは、バックボタンのような見た目になっています。なにが起こったのですか？これは変更ですか？我々は App Navigation を諦めるのですか？

# 会場からすこし拍手

Adam : 短い答えとしては、構造的には Navigation には何も変更はありません。キーノート中に見せられたもののいくつかは、異なるドキュメントを開いた複数の Chrome のタブが Recents に表示されたデモだったと思います。それらのいくつかは、新しい機能の結果として、微妙に変わっていきます。Iconography の点では残念ながら、ここにはビジュアルデザインチームからの代表者がいないと思います。でも Rachel、何か言いたいことある？

Rachel : そうね、、、あれはただの矢印で、多くの人にとって言いたいことがはっきり伝わると私は信じています。以前からやりたかったことです。階層なのか、履歴なのか。

Q : バックボタンは画面に置くなと言われていますよね？

Adam : そう。つまり、我々が見つけたことは、繰り返しになるけど、リサーチの結果、ユーザーはシステムの面かアプリの面かどちらかで考える傾向があります。アプリ内に付加的なアォーダンスがあるとはっきりします。アプリの Action Bar にあるということは、あるアプリのコンテキスト内で操作を続けたいということと結びついています。
一方、システムのバックボタンはアプリ間で動作できる、一種メタアクションのようなものです。たとえ、多くのユーザーがこれら2つの違いをはっきり述べられなくても、アイコンがとても似ていても、多くのユーザーはどちらかをタップするとき、何を予測しているかの直感的な理解を作り出す、ということがリサーチでわかりました。
もちろん開発者にとってはとても興味あることだと思います。なぜなら、ちゃんと理解するには微妙なものが多くあります。我々が出した新しい機能のいくつか、例えば Recent でより多くのドキュメントを開くというようなのが、役に立つことを望みます。
（このあたりよく意味がわからない）
なので、どのように効果的にそれを使うかというガイドラインが公開されるのを待っていてください。



今朝のキーノートでは、Material Design によるすばらしい変更のすべてが見れたと思います。どのようにアプリの見た目をよくするのかなど。1つ質問があります。他の開発者も思ってることだと思います。


Q: Android design guideline に沿ってすでにいい見た目である既存のアプリを、Material Design を実装したすばらしい例に変更するのに、どのくらい作業が必要ですか？

Chet : ちょこっと。

# 笑い

ありがとう。Chet。

Adam : 明日話すつもりなんじゃないの？

Chet : そうだね。明日のトークを見に来てください。答えます。Material Design についてのトークが2つあります。開発者向けが Adam と 11時に。もう少し詳しい情報が欲しい人はそこに行ってください。それについて話します。あなたの Material Design アプリがどうあるべきかというビジョンと、それを達成するためにどのくらい取り入れたいかによって、作業量の勾配みたいなものがあります。
最初のステップは悪くないです。Material Theme を有効にします。もしシステムのカスタムビューを使いたいなら、いくつかを直さないといけないでしょう。他のテーマ用にアセットを作っていたりしたら、そこだけ変に見えるということを覚えておいてください。
基本的には、テーマを変更して、必要なところを直す。それが Material アプリを作る最小限の作業です。その後、アプリを実際の Material Design にしていきます。異なる余白、異なるレイアウト、必要な機能を満たすための変更も必要でしょう。それから、まぁ、どこまで行きたいか把握できます。
必要な多くの作業は既に存在する API を使うだけです。L には新しい API はありません。L のために使わなければいけない巨大な描画 API を出したわけではありません。我々は Real-Time Shadows などを行う新しい機能を持っただけです。適切なときに内部的に View の elevation を取る機能です。アプリにとってそれが適切だと思えば、アクセスすることができます。
パラダイムに沿った新しいデザインがあり、それが Material Design を通して我々が言いたいことです。あなたがたがしなければならないことは、これまでの Android 開発での、レイアウトや余白、アセットを Material Design にあわせることです。

Adam : いけてるものがたくさんあります。もし、多くの有名な Android アプリで起こってきた、ここ数年の Android のデザイン進化を知っているなら、それらの多くがこの方向に移動してきたことに気づくと思います。多くのものが表面に含まれています。横からでてくるナビゲーションがそうですね。
Material Design 用に洗練された同じようなパターンがたくさんあるでしょう。すでにそのような足跡をたくさんたどってきているなら、実際にかかる作業負荷が見た目ほど多くないこともわかると思います。

Gabe : Material Design は、今年 L Developer Preview を行った要因の大きなものの一つです。間違いなく、アプリに Material Design を適用することは、多少の努力が必要だと認識しています。我々は開発者にコンシューマーに先駆けて時間を与えたいのです。さらに、我々にフィードバックを送る機会も与えたいのです。どこで動いて、どこで動かないのか。このデザイン言語でどのようなパターンを表現したいのか。どのように頭の中のデザイン精神にフィットするのかを聞けたらと思います。

これはとても重要なことです。このような Developer Preview の大きなキーは、我々はあなたたちの意見をききたいということです。何が動いて、何が動かないのか、何がクールなのか。我々に言ってください。

次の質問にいきましょう。



Q : まず最初に、これまでにプラットフォーム対する貢献と Deveoper relations に感謝します。私の人生をとてもよくしてくれました。

# 会場から拍手

Q : 異なる開発者から、多くの異なる見方があることに気づきました。ある開発者は両手を投げ出して言いました。「混乱している。1つのActivityに1つのFragmentを使うのはいつで、1つのActivityに複数のFragmentを使うのはいつなのか、わからない。FragmentなしでActivityを使うのはいまでもありなの？」ニュアンスなのはわかっています。でもなにか話してくれると助かります。

# 会場から笑い

Dianne : 私から話すわ。基本的なことの1つは、少なくとも1つはActivityが必要ということ。また、複数 Activity を持つこともあるでしょう。そこで、アプリケーションへのエントリーポイントである Activity について考えます。Android は、メインのエントリーポイントが1つだけあるというわけではありません。Android のエントリーポイントは1つ以上です。Activity はものごとのトップです。もしユーザーがアプリに入っていこうと思ったら、Activity がその方法です。
一度 Activity の中に入ったら、ものごとを行う正しい方法は、、、私の視点からだと、、、Adam が付け加えてくれると思うけど、私の視点からは、システム管理に関する限り、それはアプリによります。
アプリにはこう言う自由があります。複数の Fragment を持つのが、1つだけFragment を持つのが、Fragment を持たないのが、理にかなっている。整理したくても具体的なルールがありません。

Adam : こう言いたいんだけど、、、ルールの一つは、、、

# 会場笑い

Dianne : 具体的じゃないことw

Adam : 具体的なルールじゃないw
経験則で、たぶん、API の名前みたいなものだよ。それは Fragment。ピースだよ。Activity のピース。もし Activity がとても大きくなって、扱いにくくなって、コードが大量になってきたら、それは Fragment を使うことを考えるいいタイミングだよ。
つまり、Activity と Fragment 両方とも、アプリの model view controller すべての役割を果たすことを覚えておくこと。 より小さくて理解可能なピース、つまり Fragment に落とし込むかぎり理にかなっている。

Dianne : さらに付け足すと、とても合理的な方法は、すべてを Fragment に実装してしまうこと。すべての UI エレメントは Fragment で、それを Activity に入れる。アプリを整理するにあたって、Fragment はとても柔軟性がある。そして、例えば、ここの UI エレメントを将来別のところで使いたい、ということがあった場合、Activity に実装されているより Fragment に実装されているほうがよいです。

Adam : うん。別の単位の抽象化として考えてみたらどうだろう。



Q : Android のパーミッションについて、ユーザーの経験が知りたいです。ユーザーリサーチではなにが得られましたか？動的なパーミッションはどうですか？そのほうがよりユーザーにパーミッションが使われるコンテキストを伝えられると思うのですが。

Jhilmil : まず、リサーチの視点から話しますね。その後 Dave か誰かがフレームワークの視点から話してくれるでしょう。 リサーチの視点からは、パーミッションについてもっと多くの透明性を提供できるということに気づいています。
アプリをインストールするためにこれらのパーミッションを許可したことは知っている。でもこのデータはどのように表示される？他のサードパーティに共有されるかもしれない。私のすべてのパーミッションを一カ所で管理できる場所はある？そういうことに気づいています。それについてとても深く考えています。なので、期待していてください。

Ficus（Kirkpatrick） : 質問で触れたことについて少しコメントしたいと思います。質問には多くのトピックがふくまれていたのであれですが、、、
Androidの互換性がないバージョンまわりでのコード守備をとっているのだと推測します。特にそれがなんなのか興味があります。なぜなら我々は Play Store を扱っています。聞いたことあると思いますがw
それは多くのデバイスで動いていて、一貫性のない利用可能なパーミッションを扱っています。
（このあたりよくわからない）

もしかして、インストール時に与えたパーミッションのいくつかを必要に応じてユーザーが無効にできることから発生していきた問題について話してます？

Q: そうです。

# Ficus が Dave に話す？と聞いて、断られたため、会場から笑い

Ficus : あー、フィードバックありがとう。それには、大きい洞察があったと思います。我々は長い間、パーミッションに対する開発者のアイディアと、ユーザーのアディアを一緒に結びつけてきました。ユーザーが気にするのはデータだと思います。
アクセスできるデータについて人々はどう思っているのか、我々は見つけることを始めたばかりだと思います。データコントロールについてキーノートでいくつか見たと思います。そうですね、、、最初のステップを見ているのだと思います。
Gabe, App Ops について何か言いたいことある？

Gabe : No...まぁ、でもフィードバックありがとう。僕も多くのユーザーと同じで、使いたいサービスがあり、確かにいくつかのパーミッションはそのサービスを得るために耐えるけど、会話の終わりのようなもので、ときどきだけそれが必要になる。よりコモディティな体験を探しているユーザーにとっては、アプリ間でのパーミッションの違いは、ユーザーが何を選ぶかで実際に違いが生まれると思う。
新しい UI が、アプリ間で何がそれらの違いなのかをよりクリアにしてくれることを望んでいる。新しい UI を出したあと、友達や家族からこれはなに？って聞かれたよ。一般的に、彼らはパーミッションにより気づくようになった。我々のゴールはアイコンとかを使って、よりゲシュタルトな（？）印象を与えることだと思っている。効果があることをね。人々はこんな感じ、おぉ、このアプリはこれをできるのか、ってね。確かにいつでもそれはできるけど、情報に埋もれてそれが言えない。我々がその信号を拾い上げる。
コンテキストと実行時の質問があったと思う。コンテキストがユーザーの決定に役立つことに我々は同意してると思う。 Jhilmil が言ったように、我々はそれについて考えています。まだ道半ばです。

Adam : 開発者としてのあなたの経験について述べると、それは我々が望まない経験のすごくいい例だと思います。この問題について引き続き考えたいと思います。ユーザーのニーズと開発者のニーズのバランスをどうとればいいのか、みなの同意が得る方法を見つけたいと思います。

オンラインから別の質問にいきましょう。



Q: Activity のライフサイクルスタックを改善する計画はありますか？開発者にとって、より複雑さが少なくなるような。

Dianne: そうね、、、少ない複雑性、、、この質問は実際なにが間違っているのかなにも言ってないから、私がまとめるけど。

# 会場笑い

Dianne: 一つの見方として、アプリケーションとは何かという点において、Android はこれまでのオペレーティングシステムとは非常に異なるアプローチをとっているということ。通常、アプリケーションにおけるオペレーティングシステムというのはメインです。プラットフォームはこう言う、OK、ユーザーはこのアプリケーションを実行したい、メインいけ。この時点で、アプリケーションが内部でなにが起こるかすべてコントロールする。そしてプラットフォームはなにもコントロールしない。
Android で行ったとき、我々がやりたかった基本的なことは、メインのエントリーポイントを持ちたくなかったということ。なぜなら、アプリケーションにまたがって、多くの興味深いインタラクションを持ちたかったから。だからこの Activit コンポーネントモデルにしたのです。Activity、Service、Receiver などはすべてアプリケーションへのエントリーポイントを作ります。
一度そうすると、ただのメインのブラックボックスアプリケーションとしては扱えなくなります。なぜなら、オペレーティングシステムはアプリケーションとより多くインタラクションする必要があるからです。
あぁ、これはこの Activity から作られた、でも今は他の人が共有したい。じゃあ、別の Activity を作る必要がある。そのことをアプリケーションに伝えなければならない。アプリケーションは常にそれができる状態じゃないといけない。なぜなら、それがいつ起こるかわからないから。なので、多くの複雑性がそこにはあります。これは、アプリ開発者がプラットフォームと調整してそのボックスをコントロールする必要性からきてると思います。
それと、それについての学習曲線があるのだと思います。
一度それを通ったら、本当に多くの利点があると思います。プラットフォームを開発するにあたっても。プラットフォームの新しい機能を既存のアプリで行うための多くの機会を与えてくれます。それなしでは得られないものです。
例えば L では、まったく新しい Recents を導入しました。ドキュメント指向の Recents です。アプリケーションが複数の Recent エントリーを持てるのです。Developer preview を実行してみれば、それが既存のアプリとも動くことがわかるでしょう。Share をして、標準の共有ダイアログを通ったら、共有ターゲットで終了したとき、それは Recents で別のエントリーになります。つまり、オリジナルのアプリとシェアしたアプリで行き来することができます。これができるというのは、プラットフォームとアプリでボックスを調整するように作ってきたからです。
確かに複雑性があります。学習曲線もあります。でも多くの恩恵も与えてくれるものです。

Dave : 君たち開発者が気づいているかどうかわからないけど、毎月これについて出会うよ。我々はこれを4年前にデザインした、なぜなら明日こういうふうに動かしたくなるって知ってたからね。



Q: Scala 言語をオフィシャルにサポートすることはありますか？4年間の仕事のあと、Apple は Swift をリリースしました。Swift は Java ではできないようなことを開発者に与えています。Swift のリリース前と後でなにか考えがありましたか？計画はありますか？

Dave : うーん。僕は Cocoa が好きだよ。でも Objective-C は C をベースにしていて、それはもう40歳だ。だから Apple はそれをアップデートしたんだと思うよ。
ええと、うん。わからない。Scala？知らないな。
誰か話す？

# 会場から笑い

Dianne : No!

# 会場からさらに笑い＆拍手

Dianne : まじめに言うと、Java が Android 用のプログラミング言語です。知ってるでしょ。フレームワークはすべて Java で書かれています。他の言語をサポートすることに多くの恩恵があるとは思えません。

Dave : Swift についてはどう？

# 会場から笑い

Dianne : 考えるわ。

Dave : セミコロンいらないよw

Dianna : NDK があるので、やりたいならそこに何か投げることはできます。しかし NDK はフレームワークへのアクセスがありません。他の言語でやりたいなら、現状のフレームワークに相当する first class の言語として使いたいなら、全く新しいフレームワークかいくつかのバインディングを得ないといけないし、それはとてもよくない経験になると思います。

Q : いつも Scala を使っています。なぜなら Scala は JVM にコンパイルされます。そうですよね？だから Android では動かない。Scala で動く方法はないのですか？

Xav : ツールについては、多分、今年の終わりか、来年のはじめに、gradle 内部に変更があると思います。それだと、もともと Scala で書かれたモジュールを持つのが簡単になります。バイトコードにコンパイルして、アプリケーションにパッケージングします。
しかし、Scala コードから Activity API にアクセスするようなものについては助けになりません。ビジネスロジックのコードとか、なにか Scala で書きたいものがあって、それをバイトコードにして埋め込むことはできますが、Java で Android を書くのとは全然違います。フレームワークの API にはアクセスできません。



Q : Android L の新しい機能、たとえはホーム画面の Notification について、ユーザーはどのくらいのコントロールを持っていますか？この前の What's New in Android のセッションに出たのですが、プライバシーレベルのオプションがあると聞きました。でも考えると、サードパーティの開発者に、それがホームスクリーンに表示されていいかどうかわかるとは思えません。それを完全にオフにすることはできますか？

Gabe : できます。

Q : Play Store パーミッションの新しい App Ops はちょっとわかりにくいです。実際、わかりにくい（読むのが難しい、理解するのが難しい）ものがたくさんあります。そうすべきではないと思います。

# 会場から拍手



Q : L の新しい lush animation と 3D レンダリングシャドウ、その他すべて美しいです。新しいデバイスと古いデバイスはこの点についてフェアですか？

Adam : So when some of the engineers who are working on some of the flashier features that you've been seeing in here first started, this was something that we thought was really important. We didn't want to make a move like this in KitKat, only to just kind of toss it out as soon as we found some new, flashy effects we wanted to implements. So they'd actually found the absolute oldest devices they cound, sitting around in a desk that we still had drivers for. And they actually started on those devices to implement these effects. So this is the sort of thing where performance on low end devices is something that was really intrinsic to the initial design of the implementation. So there's definitely a few cases, a bunch of you're going to get the L preview and go run some of it. You'll probably run into some cases where you say, oh, wait, this is little bit slower than I thought. We know about them already. We're working on them. Many of them actually have already been addressed internally as we've continued along this. So performance is something that we think is really important. We can't really accomplish the goal of Material Design if everything is just janking across the screen the whole time. （Adamさんの英語難しいのでちょっとパス）

Dave : うん。我々はいまだに Svelte についてのミーティング、メモリーのモニタリングとか、を毎週しているということを付け加えたい。後方には行きたくないです。そして ART ランタイムは実際 Dalvik よりメモリ効率がいいです。我々は異なるタイプのガーベージコレクターを持っています。
アプリがバックグラウンドに移動したときに利用されるコレクターもあります。遅いのでフォアグラウンドでは使いたくない、でも簡単に数100KBを節約できます。

関連していることだけど、我々は Svelte や Volta というプロジェクト名がありますね。これらは名前が先ですか？考えが先ですか？

Dave : えーと。。。考えかな



Q : Google Play services についての質問です。Google Analytics や Drive, AdMob などのサービスを、Google Playのない文字通りすべての Android で使いたいのです。かつてこれらのサービスは個別の jar でした。でも今は Google Play services の一部です。すべての Android でこれらのサービスを使いたい場合、どういう提案をしますか？

# 会場から拍手

Gabe : この質問を Google Play services Rocks でもした？

Q : 私はしてませんが、他の人がしました。

Gabe : あー、OK。同じ質問を聞いたよ。残念だけど、そんなに付け加えることはないかな。ここにいる我々は Google Play に対応しているデバイスのエコシステムに対して働いている。我々の一番の関心事は、どのようにこのプラットフォームをそれらのデバイスに提供するかということ。実際、我々のエコシステム外のデバイスについて、Google が何かするかという見解はなにもありません。
なので、これは、Analytics や AdMob チームへの質問なんじゃないかな。私が答えられるとは思わないな。ごめんね。



Q : Cupcake ぐらいから SMS メッセージを受信する BroadcastReceiver を使っています。でも最近は、みんなはハングアウトを使います。あれはすばらしいです。でもハングアウトのメッセージと、アプリからインタラクトすることはあきらめないといけないのでしょうか？それとも、すべきことについてなにかコメントありますか？

Dianne : 人々は SMS を使わない。そうね。彼らが SMS を使わないなら、プラットフォームはそれについて知ることはないです。

Q : つまり、ハングアウトのメッセージに対して、API を介して返信することはできない？

残念だけど、これ以上はハングアウトチームの誰かに質問するべきだと思う。

Adam : フレームワーク側からみると、メッセージングアプリがインターネット上で独自のプロトコルでやりとりしているなら、自分たちのブロードキャストを発行することについては完全に自由です。



Q : Android の Wi-Fi peer to peer ツールの進捗についての質問です。このテクノロジーにはすばらしいポテンシャルがありますが、現状ではこれらのツールは非常に不完全でとてもバギーです。これらを置き換える、もしくは開発を続ける計画はありますか？

Dave : うーん。確かにちょっとバギーだよね。実際、チームを大きくしようと、今多くの人を雇用しています。より多くワイアレスに投資しようとしています。Bluetooth、Wi-Fi, cellular、Volke（これなに？）それらすべて。peer to peer Wi-Fi を複製する計画はないです。
新しい Wi-Fi 機能が来ます。つまり、Wi-Fi Alliance で標準化のいくつかを見ることができます。Network Neighborhood とか、そういうの。 他になにかあったかな。Wi-Fi について、内部的にたくさんリファクタリングしています。
以前のリリースでは WPA Supplicant は多くのロジックを持っていました。我々はそのロジックをいくつか取り除いて移動して書き直しました。Wi-Fi state machine の一部として。我々はWi-Fiの機能を抽象化するための新しい Wi-Fi How（この単語でいいのか？） を導入しています。例えば、デバイスがロケーションをスキャンするとき、現状ではすべてのチャネルをスキャンしますが、新しい Wi-Fi How では、選択的にスキャンをできます。
ともかく、我々はその領域に投資しているし、改善しようとしています。

オンラインからの質問です。



Q : アプリを作る上で最初にフォーカスすべきもっとも重要なことは、エンジニアリングですか？デザインですか？

Jhilmil : 間違った方法で考えますね。本当にフォーカスすべきはユーザーです。
今日話したプロダクト、Auto や TV でさえ、本当にはスタートしていません。まだデザインとかだけです。コーディングも始まったばかりですし、根本的な問題もいくつかあります。今も間違っていたり。ユーザーの問題を真に解決するプロダクトをどうすれば作れるのか、もっと賢くなろうとしています。



Q : 新しいリリースのデザインについて、ありがとうございます。とても興奮しています。多くの開発者が、新しい見た目と、そこでなにかする方法についてそれぞれのデザインチームと話すときに思うことについてです。
彼らは Galaxy S4 を取り出して、テキストメッセージアプリを見せて言うでしょう。
Android は一貫したデザイン言語を持っていると思う？これは私のテキストメッセージアプリだけど、我々は我々がデザインしたい方法でデザインするつもりです。
どんなステップをとりますか？Androidの世界に存在している、そういうクレイジーなデザインエコシステムにどう対処しますか？

# 会場から拍手

Rachel : これを助けるためにとれるステップの一つは、我々自身のアプリケーションでいい仕事をすることだと思っています。我々がきちんとガイドラインに従って。

# 会場からめっちゃ拍手
（みんな Google のアプリがガイドラインに従ってないのどうなのよって思ってたのね）

Rachel : それは我々がしばらくの間取り組んできたことです。我々は大きい会社ですし、Android アプリの開発を行っている 100 近いチームが会社中にあります。彼らはすべて異なるリリーススケジュールをもっています。なので、ある意味チャレンジでした。加えて、みなさん知っていると思いますが、デザインガイドラインも進化しました。通常はそれは内部で起こって次に外部にでます。
内部で先に開始する戦略をとると、ガイドラインが外部にでたとき、それについての具体的な例がすでにあるというのが重要なポイントす。



Q : 私の質問は開発者としての個人的な経験についてです。テスト周りについてつらいことがたくさんあると聞きます。特に Android でのユニットテストについて。Roblectricのようなソリューションがいいです。問題への適切なソリューションよりも bandaid のような。L プレビューについてなにかありますか？もしくはテストについての一般的な考えでも。

# 会場から拍手

Xav : うーん。まず、Robolectric を手助けしたいです。現状のわれわれのツールとよりよくインテグレートできるように。 それが bandaid なのは知っています。パーフェクトなソリューションではない。しかし、多くのチームが今それに頼っています。なのでソリューションを改善したいです。
あとは、Android デバイス上で動かないものはすべからく bandaid です。つまり、純粋に Android じゃないコードがあり、VM 上で動かせるなら、Java module を作ってそこでロジックをテストすることができます。
Android の API にアクセスするものについては、デバイスで実行しないといけません。現在の問題は、テストを走らせるには、デプロイに時間がかかって、ビルドにも時間がかかることです。ビルドについては状況を改善しようとしています。gradle はもっと速くビルドできるようにしようとしています。
デプロイについては、より複雑です。取り組みたいものはあります。しかし、実現するにはラインタイムに手を入れる必要がありそうです。なので、L では何もないです。既存の Android API でも他に方法はないです。テスト結果として信頼性のあるものを得るには、デバイスで実行する必要があります。



Q : 画像の周りにテキストを回り込ませる汎用的な方法がわかりません。そのとき調べたサードパーティのライブラリでは満足できませんでした。そこで一年前に自分たちで Canvas をオーバーライドして作りました。複雑でテストしにくいものです。Android チームはこの問題を見ていますか？

Adam : 短い答えは Yes です。間違いなく、いくつかのアプリで痛いポイントになっているなということを認識しています。どうやって解決したらいいのか質問がきたことがあります。
これはかなり複雑な問題です。TextView が Canvas とインタラクションする方法がたくさんあり、それはテキストやフォントなどいろいろなものを扱っていて、とっても複雑です。少なくとも複雑で、しかもとても強く結びついています。将来的にはその問題に取りかかりたいと思っていますし、我々ができることがあるか見ています。より自然な方法で達成できるように、いくつかのモジュールに分けるとか。

オンラインからの質問です。



Q : Chrome OS 内で、Android のフルビルドとテストができるようになる可能性はありますか？

# 会場から拍手

Dave : えー、、、しらないよ。Chrome OS 用の IDE ってことかな？

Ficus : Chrome OS の精神だと、IDE はクラウドみたいなもんでしょ？ Chrome OS 用の IDE を作る意味があるかわからないよ。

クラウドチームへの質問かな。

Ficus : クラウドアプリ用の IDE （たぶん、Chrome Dev Editor のこと）を彼らから見せてもらったけど、Android をビルドできるようになるのかどうかは見てないよ。

Xav : デプロイのことも考えないといけないよね。多くの開発者はテストに実機をつかっているんじゃないかな。それをクラウドに持っていって、小さいハローワールドみたいなアプリじゃないなら、ビルドするたびにローカルに10Mとかの APK をダウンロードしてこないといけない。
現在の Web IDE の状態は始まったばかりで、IntelliJ みたいな本当によくできた Java IDE と比べると、、、比べないけど。つまり、まだまだテスト段階だと思うよ。



Q : L Developer Preview にとてもわくわくしています。factory image としてのみ提供されているので、開発者もしくは極端な愛好者向けだということがよくわかります。このような方法は将来にもあると思っていていいでしょうか？各メジャーリリースの初期バージョンを使っているより一般的な平均的なユーザーからの多くの文句があったのを見ています。

Dave : うん。みんなこれが自分の考えだって主張するんだ、おもしろいよね。だから僕の考えだって主張するよ。でも、みんなの考えだったんだ。
僕が注目していたものの一つはプラットフォーム。すごく大きくなっている。だよね。描画エリアは大きくなっているし。我々にはすばらしい QAチームがあるし、トップ1000のアプリもテストしてよくなるようにしてる。CTSもやってね。でもすべてをテストすることはできない。
もしアプリをリリースしたときに何かが起こって何かが壊れたら。。。KitKatでJBMR2トリアージバグポストを覚えています。あれは恥ずかしかった。
このモデルから移行しないといけないことは明白だった。だから Developer Preview を出して、みんなが自分のアプリをテストして、バグを投稿して、我々が直せるようにした。
約束はできないけど、我々がこれを行った理由は合理的で、エントロピーは増大して減ることはないから、これからも続ける可能性が高いと思います。約束はできないけど、イエスだよ。

# 会場から笑い

Preview リリースはどうですか？

# 会場から拍手

Dave : その他に望むこととして、OEM がもっと早くデバイスを作れるようになるということだね。だって、一度プレビューが利用可能になったら、もう秘密にする必要はないし、ビルドを共有できるし、ソースコードも共有できるし、ベンダーを見れるし。僕の望みとしては、L が秋に正式にリリースされたら、多くのデバイスがそれに追随してほしい。

Xav : エミュレータのシステムイメージが利用可能だから、必要ならそれが使えるよ。



Q: 新しい gradle build system が気に入っています。でもそこまでインテリジェントなユーザーではありません。ええと、Eclipse は Android の red-headed stepchild になっていくのですか？それともこれまでのようにサポートされ続けるのですか？

（red-headed stepchild とは、無視されたり、望まれなかったり、不当な扱いをうける人やもののこと）

Xav : Reto（司会）、時間みた？

# 会場笑い

Dave : Eclipse で Java form を開く時間がないよー。

# 会場笑い＆どよめき＆拍手

Q : でも IntelliJ でアプリをビルドする時間もないでしょ。

Dave : そうだね。わかったよ。難しいと思う。
理想の世界ではすべての IDE をサポートするけど、pull down するものを選ばないといけない。我々は IntelliJ から pull down を始めることにしたんだと思う。Android とは別に、Eclipse と gradle のインテグレーションを改善しようとする動きはある。gradle 自身を改善しようという動きもある。我々のモデルもそれらでより互換性をもてるようになるかもしれない。全部の IDE に対応できるのが理想だけど、今は Android Studio にフォーカスしているよ。