Quantcast
Channel: Google Developers Japan
Viewing all 2206 articles
Browse latest View live

WebView セキュリティの新機能

$
0
0
この記事は Android セキュリティ チーム、Xiaowen Xin、Renu Chaudhary による Android Developers Blog の記事 "What’s new in WebView security" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
アプリのとても重要な機能の 1 つに、信頼できない外部コンテンツの処理があります。ニュースリーダーはトップニュース記事を表示し、ショッピング アプリは商品のカタログを表示します。こういった操作には、リスクを伴います。信頼できないコンテンツの処理は、攻撃者がアプリのセキュリティを侵害する、つまり悪意のあるコンテンツを渡す主要な方法の 1 つだからです。  
 
多くのアプリは、信頼できないコンテンツの処理に WebViewを使っています。Android では、WebView やアプリをセキュリティ侵害から保護するため、ここ数年で多くの改善が行われています。重要な修正をいち早くユーザーに提供できるように、Android Lollipop 以降では WebView が独立した APK として配布され、Play ストアで 6 週間ごとにアップデートされるようになっています。最新の WebView では、いくつかの重要なセキュリティ強化が行われています。  
 

Android O でのレンダラー プロセスの分離


Android O 以降では、WebView のレンダラーはホストアプリとは別の独立したプロセスで実行されるようになります。そのため、他のアプリが利用する Android 提供のプロセスとは分離されているというメリットを活用できます。  

Chrome と同様に、WebView でも 2 つのレベルで分離されるようになります。  
  1. レンダリング エンジンは別のプロセスとして分割されます。これにより、ホストアプリはレンダラー プロセスのバグやクラッシュから切り離され、悪意のあるウェブサイトがレンダラーの脆弱性を利用してホストアプリを攻撃することは難しくなります。
  2. さらなる封じ込めとして、レンダラー プロセスは限られたリソースセットしか使えない独立したプロセス サンドボックス内で実行されます。たとえば、レンダリング エンジン単独では、ディスクへの書き込みやネットワーク通信を行うことはできません。
    Android 版 Chrome で使われているものと同じ seccomp フィルターもバインドされています(seccomp については、近日中にブログに投稿します)。seccomp フィルタは、レンダラー プロセスがアクセスできるシステムコールの数を減らし、さらにシステムコールで許可する引数も制限します。

セーフ ブラウジングの導入


最新版の WebView には、危険性があるサイトを検知してユーザーに警告する Google のセーフ ブラウジング保護が導入されています。正しい設定が行われている場合、WebView は URL と不正なソフトウェアやフィッシングに関するセーフ ブラウジングのデータベースを突き合わせてチェックし、ユーザーが危険なサイトにアクセスする前に警告メッセージを表示します。Chrome では、この有用な情報は月間 2 億 5,000 万回以上表示されています。この機能が Android の WebView でも利用できるようになります。  
 

セーフ ブラウジングの有効化


アプリ内のすべての WebView でセーフ ブラウジングを有効化するには、マニフェスト タグに以下を追加します。  
<manifest>
<meta-data android:name="android.webkit.WebView.EnableSafeBrowsing"
android:value="true" />
. . .
<application> . . . </application>
</manifest>

WebView は個別の APK として配布されているため、現在のところ、WebView のセーフ ブラウジングは Android 5.0 以降を実行している端末で利用できます。マニフェストに 1 行追加してアプリをアップデートするだけで、多くのユーザーのセキュリティを即座に改善できます。
 
 
Reviewed by Yuichi Araki - Developer Relations Team

Android Things Console デベロッパー プレビュー

$
0
0
この記事は IoT デベロッパー アドボケート、Wayne Piekarski による Android Developers Blog の記事 "Android Things Console developer preview" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日(*原文公開当時)、Android Things Consoleのプレビュー版をリリースいたします。このコンソールを使うと、デベロッパーは一連の Android Things IoT 端末上で動作しているソフトウェアを管理できます。たとえば、ファクトリー イメージを作成したり、オペレーティング システムやデベロッパーが提供する APK をアップデートできます。端末が今後のアップデートを受信するには、近日中に公開される Developer Preview 5 など、Android Things Console からダウンロードしたシステム イメージを実行している必要があります。Google は、すべてのインフラストラクチャに対して OTA(無線)アップデートを提供しています。そのため、デベロッパーは固有のアプリケーションに集中でき、独自の実装を開発する必要もなく、IoT 端末を今まで以上に高速かつ安全にマーケットに出すことができます。

それでは、このコンソールが提供する機能を紹介しましょう。

プロダクトの作成と設定


デベロッパーは、最初にプロダクトを定義します。ここでは、名前の設定、端末の SoM(System-on-Module)タイプの選択などを行います。多くのデベロッパーは、IoT 端末を開発する際に Google Play Services を利用します。これはオプション機能となっており、この画面で設定できます。OEM パーティションのサイズも設定できます。この値は、今後の APK の増加分も含めて格納できる十分な大きさにする必要があります。

ファクトリー イメージ


今後、端末がコンソールからプロダクトに向けた適切なアップデートを受信するには、初期基本ファームウェアが必要です。最初は、[Create Build Configuration](ビルド設定の作成)を使い、プロダクト用に設定された空のバンドルを含むデフォルトのファクトリー イメージをビルドします。すると、このファクトリー イメージをダウンロードして端末に書き込めるようになり、端末に APK を読み込ませて、開発を始めることができます。

その後、プロダクトで利用するすべての端末にデプロイするアプリケーションの準備ができた段階で、バンドルをコンソールにアップロードします。このバンドルは ZIP ファイルで、この中にはメイン APK ファイル、APK 内でサービスとして動作するユーザー空間ドライバ、メイン APK によって起動される追加の APK が含まれています。bootanimation.zipファイルもサポートされています。これは、起動時に表示されます。続いて、アップロードしたバンドル ZIP ファイルから完全なシステム イメージが生成され、それが端末にデプロイされます。バンドル ZIP ファイルの内容について詳しくは、ドキュメントに記載されています。

OTA アップデート


このタブでは、一連のプロダクト用端末にプッシュするシステム イメージを選択できます。デベロッパーがシステム イメージを 1 つ選択し、[Push to Devices](端末にプッシュ)を押すと処理が開始されます。アップデートはすべての端末に安全にプッシュされ、A/B パーティションのどちらかにインストールされて、端末が再起動した際にアクティブになります。何らかのエラーが検出されると、端末は以前に動作していたバージョンに自動的にロールバックされるので、アップデートをやり直すこともできます。デベロッパーは、Android Things の新しいリリースを事前にテストしてから、端末の自動アップデートの可否を決定できるようになる予定です。

フィードバック


現在の Android Things Console はプレビュー版で、さらに多くの機能やカスタマイズを追加するための作業が続けられています。Android Things デベロッパーの皆さんは、ぜひ Android Things Console を確認してフィードバックをお寄せください。バグレポート機能リクエストからフィードバックを送信できます。質問は、どんなものでもかまいませんので、Stack Overflowにお寄せください。Android Things Console の詳細については、詳しいドキュメントもご覧ください。Google+ の Google IoT デベロッパー コミュニティにも参加できます。これは、最新情報を入手したりアイデアを話し合うことができるすばらしいリソースです。



Reviewed by Yuichi Araki - Developer Relations Team

Awareness API がセマンティック タイムをサポート

$
0
0
この記事はプロダクト マネージャー、Ritesh Nayak M による Android Developers Blog の記事 "Semantic Time support now available on the Awareness APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


昨年の I/O で、Awareness APIがリリースされました。これは、ロケーション、天気情報、時刻、ユーザー アクティビティなどのシグナルを使ってユーザーの状況に即した体験を提供できるようにする、シンプルで強力な API です。

Awareness API は、Google Play サービス経由で利用でき、2 つの方法によってアプリ内で状況シグナルを活用できます。Snapshot APIは、アプリからユーザーの現在の状況に関する情報をリクエストできます。また、Fence APIは、ユーザーの状況が変化したときや、ある条件に該当した際にアプリを反応させることができます。たとえば、「ユーザーがヘッドフォンをさしたまま歩いているときは教えてください」というようなリクエストが可能です。

これまでも、Awareness API でタイムフェンス(時間の境界)を指定できましたが、時間を厳密に指定しなければならないという制限がありました。デベロッパーの皆さまからのフィードバックにより、タイムフェンスの作成に関連するこの API の柔軟性は、人々が時間について考えたり話したりする際に用いる高レベルの抽象化に対して対応できていないことがわかりました。「今週末」、「次の休日」、「日没後」といった表現は、日常会話で時間を表す際によく使われます。そこで本日(*原文公開当時)、この API にセマンティック タイムのサポートを追加しました。

たとえば、フィットネス アプリで毎朝のエクササイズの開始をユーザーに通知したい場合や、読書アプリで日没後にナイトモードをオンにしたい場合を考えてみましょう。今までは、ユーザーの現在地での日の出や日没の情報を 3p API に問い合わせ、その時間の値を使って Awareness フェンスを記述する必要がありました。今回の最新のアップデートでは、TIME_INSTANT_SUNRISETIME_INSTANT_SUNSETといった定数を使って、複雑な処理をプラットフォームに任せることができます。

例を見てみましょう。火曜日と木曜日の日の出頃に朝のエクササイズの開始を通知するフィットネス アプリを作成しているとします。このトリガーは、次のコードを使って設定できます。
// A sun-state-based fence that is TRUE only on Tuesday and Thursday during Sunrise 
AwarenessFence.and(
TimeFence.aroundTimeInstant(TimeFence.TIME_INSTANT_SUNRISE,
-10 * ONE_MINUTE_MILLIS, 5 * ONE_MINUTE_MILLIS),
AwarenessFence.or(
TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_TUESDAY,
0, ONE_DAY_MILLIS),
TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_THURSDAY,
0, ONE_DAY_MILLIS)));


セマンティック タイムが特にすばらしいのは、祝日に対応している点です。国や地域によって、祝日は異なります。たとえば、近隣で楽しめるハイキングや探検を案内するアプリで、金曜日または月曜日の祝日に楽しむことができるものをユーザーに紹介したい場合、曜日と祝日のフラグを組み合わせれば、世界中のすべてのユーザーに対してこの状況を判別することができます。しかもわずか 3 行のコードで、世界中どこでも動作します。
// A local-time fence that is TRUE only on public holidays in the
// device locale that fall on Fridays or Mondays.
AwarenessFence.and(
TimeFence.inTimeInterval(TimeFence.TIME_INTERVAL_HOLIDAY),
AwarenessFence.or(
TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_FRIDAY,
9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS),
TimeFence.inIntervalOfDay(TimeFence.DAY_OF_WEEK_MONDAY,
9 * ONE_HOUR_MILLIS, 11 * ONE_HOUR_MILLIS)));

どちらの例でも、Awareness API は端末の言語/地域の設定に基づいて、時間や祝日のローカライズという大変な作業を行ってくれます。

皆さまがこの強力な API を使ってどのような問題を解決するか、楽しみにしています。メーリング リストに参加すると、今回の API を含む Google の Context API についてのアップデート情報を受け取ることができます。



Posted by Takuo Suzuki - Developer Relations Team

ピアグループ分析による不審なモバイルアプリの特定

$
0
0
この記事は Google セキュリティおよびプライバシー チーム、Martin Pelikan、Giles Hogben、Ulfar Erlingssonによる Android Developers Blog の記事 "Identifying Intrusive Mobile Apps using Peer Group Analysis" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

モバイルアプリは私たちに娯楽やサポートを提供してくれます。また、簡単に友人や家族とコミュニケーションをとることができ、地図から電子決済まで、さまざまなツールを提供してくれます。しかし、こういったアプリの中には、必要以上に端末の情報、たとえば、個人データや、カメラ、GPS トラッカーといったコンポーネントのセンサーデータなどを取得しようとするものがあります。

ユーザーを保護し、デベロッパーがこのような複雑な環境に対応できるように、Google は Google Play アプリのプライバシーやセキュリティに関するシグナルを分析し、似たような機能を提供するアプリ群( 機能ピア)と比較しています。ピアグループを作成すると、ユーザーが期待していることを予測できるようになり、安全ではない、または不審な動作に対して妥当な境界線を引けるようになります。このプロセスは、明確なニーズなしにプライベートなデータを収集または送信するアプリを検知する際に役立ち、ユーザーも、プライバシーを尊重しつつ適切な機能を提供しているアプリを見つけやすくなります。たとえば、ほとんどの塗り絵アプリには、ユーザーの厳密なロケーションは不要です。これは、他の塗り絵アプリを分析すればわかります。逆に、地図やナビゲーションのアプリはユーザーのロケーションを知る必要があり、多くの場合、GPS センサーへのアクセスも必要です。

アプリのピアグループを作成する方法の 1 つは、ツール、生産性、ゲームなどの固定カテゴリを作成し、各アプリに 1 つまたは複数のカテゴリを割り当てる方法です。しかし、固定カテゴリはあまりにも大まかな分類で、柔軟性にも欠けるため、変化の早いモバイルアプリの特性をとらえることはできません。このようなカテゴリを手動で整理するのも、退屈でミスが起こりやすい作業です。

これに対処するため、Google は同じような機能を持ったモバイルアプリをクラスタリングで分類する機械学習アルゴリズムを開発しました。このアプローチは、ベクトル エンベディングによるディープ ラーニングを利用して似たような機能を持つアプリのピアグループを決定するもので、テキストによる説明などのアプリのメタデータや、インストール数などのユーザー指標を活用しています。そして、このピアグループを利用し、各アプリがリクエストするパーミッションや監視した動作から、プライバシーやセキュリティに関して変則的または有害な可能性があるシグナルを見つけます。さまざまな Google のチームは、ピアグループ間の相関関係やセキュリティ シグナルから、宣伝すべきアプリや、セキュリティやプライバシーの担当者が注意を払うべきアプリを特定しています。この結果は、デベロッパーがアプリのプライバシーやセキュリティを改善する目的でも活用されています。
アプリは似たような機能を持つグループに分けられます。同じような機能を持つアプリのクラスタ内で、ある一定の基準に従って、プライバシーやセキュリティに関する変則的なシグナルを探します。

これらの技術は、ピアグループを使ったプライバシー関連のシグナル分析、よりよいピアグループを作成する言語モデルのディープ ラーニング、結論を得る際に利用する自動データ分析など、以前から存在していた考え方をもとにしたものです。

このアルゴリズムやその周辺プロセスは、Google の多くのチームの協力のもとに生まれました。Andrew Ahn、Vikas Arora、Hongji Bao、Jun Hong、Nwokedi Idika、Iulia Ion、Suman Jana、Daehwan Kim、Kenny Lim、Jiahui Liu、Sai Teja Peddinti、Sebastian Porst、Gowdy Rajappan、Aaron Rothman、Monir Sharif、Sooel Son、Michael Vrable、Qiang Yan など、欠かすことができないチームメンバーに感謝いたします。

Android で有害な可能性があるアプリ(PHA)を検知して排除する Google の挑戦の詳細については、Google Android セキュリティ チームによる有害な可能性があるアプリの分類をご覧ください。

参考文献


S. Jana, Ú. Erlingsson, I. Ion (2015).Apples and Oranges:Detecting Least-Privilege Violators with Peer Group Analysis. arXiv:1510.07308 [cs.CR].

T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, J. Dean (2013).Distributed Representations of Words and Phrases and their Compositionality.Advances in Neural Information Processing Systems 26 (NIPS 2013).

Ú. Erlingsson (2016).Data-driven software security:Models and methods.Proceedings of the 29th IEEE Computer Security Foundations Symposium (CSF'16), Lisboa, Portugal.


Reviewed by Yuichi Araki - Developer Relations Team

Cheetah Mobile、AdMob のネイティブ動画広告を使用してアプリのパフォーマンスを向上しながらユーザー広告のエクスペリエンスを改善

$
0
0
この記事はモバイル プロダクト スペシャリスト、Jessica O'Brien による Inside AdMob の記事 "Cheetah Mobile Improves User Ad Experience While Increasing App Performance with AdMob’s Native Video Ads" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
 
7 年前、Cheetah Mobile は PC 向けのソフトウェアを開発する従業員 10 人の小規模な会社としてスタートしました。現在同社は1000 人を超える従業員を抱え、業界をリードするデベロッパーになっています。同社の人気アプリである Clean Master や Battery Doctor は、全世界の何百万人ものユーザーにダウンロードされ、Clean Master 自体は全世界で 6 億を超える MAU を記録しています。
 
問題 

ユーザー基盤の継続的な拡大に伴い、 Cheetah Mobile は革新的な広告フォーマットを使って、同社のユーザー基盤を全世界に広げながら、アプリを収益化するための方法を見つける必要がありました。同社は多様な高品質の広告を使って収益を改善する一方で、ユーザーにとって使いやすいアプリのエクスペリエンスを維持する必要がありました。  
 
解決策 
 
Cheetah Mobile は Google と協力してAdMob を使用し、同社のアプリのパフォーマンスを向上させる新しい方法を見出しました。Cheetah は、新しくリリースされたネイティブ動画フォーマットを導入して、ネイティブ ディスプレイ広告の使用を拡大しました。このようにすることで、Cheetah は多様な広告のミックスが可能になり、動画のブランド力を利用してユーザー エンゲージメントを向上させています。ディスプレイ広告の他に動画広告も取り入れることで、全体的なパフォーマンスを向上させることができました。  
 
 
結果 
 
これらのシンプルな変更を実装して Google の最新のネイティブ広告フォーマットを利用することで、Cheetah Mobile は eCPM が 34% 増加し、31% の広告収益増加を達成できました。動画広告をアプリのフロー内に適切に配置することで(意図されたユーザー アクションの完了後の結果ページ)、Cheetah は高いエンゲージメント率を維持しながら目障りではない広告エクスペリエンスを実現しました。アプリのルック アンド フィールに一致するように動画広告をカスタマイズすることで、ユーザー エクスペリエンスを阻害しない新しい広告の導入が可能になりました。  
 
「ユーティリティ アプリではネイティブ広告が主流のフォーマットであり、モバイル広告では、動画広告がその次に続く重要な手法です。AdMob は、ネイティブ広告と動画広告の両方に対応した完璧なソリューションを提供しました。AdMob で得られたパフォーマンスは非常に有益であり、すでに増益という結果を得ています。」Cheetah Mobile 上級副社長、Chen Yong

 
その他の成功事例は、AdMob のウェブサイトでご覧いただけます。TwitterLinkedInGoogle+でお届けする AdMob の最新情報もご覧ください。  
 

Posted by Rikako Katayama - AdMob Team

Google for Mobile Workshop Day を開催します

$
0
0





Google Play では、Android に関連したテクノロジーや製品の実践的知識を実際に手を動かして学ぶことができるさまざまなワークショップを集めた Workshop Day を 2017 年 8 月 4 日(金)に開催します。

数あるワークショップはエンジニアだけを対象としたものではなく、マーケッターやプロダクト マネージャー向けのものもあります。下記の詳細をご確認いただき、参加を希望される方は登録フォームよりお申し込みください。

※一部英語(通訳付き)で提供されるコースがあります。
※申し込みが定員を上回ったワークショップは募集を終了する場合があります。










Workshop Day とは別に、Google Play チームでは定期的に Android アプリの品質向上を目的としたプログラム 「Google Play APP DOJO」を実施しており、7 月 27 日(木) に説明会とセミナーを開催します。セミナーの参加にはメンバー登録が必要ですが、見学は誰でも可能です。また、本プログラムにご登録いただくと、Google for Mobile Workshop Day のようなイベントの案内をいち早く受け取ったり、配布していない資料をオンラインで閲覧できるメンバーページにアクセスできるようになります。本プログラムへのご登録は「Google Play APP DOJO」のページから可能です。

7 月のセミナーは「事例で学ぶ アプリの品質向上と成長」をテーマに株式会社 Loco Partners 様、株式会社 LIFULL 様にご登壇いただく予定です。Android アプリの成長や品質向上に興味がある方はぜひ下記リンクから詳細をご確認いただき、お申し込みください。








【Google for Mobile Workshop Day 開催概要】
日時:2017 年 8 月 4 日(金)9:00 - 18:00
   ※ワークショップにより、開始時間・終了時間は異なります。
場所:六本木ヒルズ 森タワー Google 東京オフィス



【ワークショップの詳細】



◾午前の部

9:00 - 11:30
コードラボ 「プログレッシブ ウェブ アプリ(PWA)/ AMP」
参加対象:
エンジニア(HTML や Javascript のコーディング知識が必要です)

概要:
プログレッシブ ウェブ アプリ(PWA)/ AMPのセルフペースなコードラボです。
実際に codelabs.developers.google.com 内のコードラボを実施することによって、ServiceWorkerやAMP-BINDなどの主要フィーチャーを利用したPWA/AMPページが開発できるようになります。質疑応答がその場でできるようGoogle デベロッパーリレーションチームがイベントをサポートさせていただきますので、初心者でも歓迎です。

持参していただくもの:
テキストエディター / IDE がインストールされたノートパソコン

9:00 - 12:00
コードラボ「Daydream - VR アプリを作ろう」

参加対象:
エンジニア(C++, C# or Javaのうちどれかのコーディング知識が必要ですが、Unity の経験は必要ありません)

概要:
このコードラボでは Unity を使い、2 つのモジュールに挑戦していただきます。モジュール 1 では、Daydream コントローラのモーション、タッチパッド、クリックでインタアクティブに操作できるシンプルな弓と矢を作ります。モジュール 2 では、Daydream 上でビデオを再生する様々な方法をご紹介します。そして実際に再生コントロールが可能なシンプルなビデオ UI を作ります。

持参していただくもの:
Unity (5.6以上、+Android SDK/NDK, +log-in account)、最新の Android Studio、最新のJava Development Kit (JDK) がインストールされた開発用ノートパソコン

10:00 - 12:30
コードラボ「初めての Android Instant Apps」

参加対象:
エンジニア(Java での Android アプリ開発経験が必要です)

概要:
Android Instant Apps は、 URL リンクからインストールさせることなくネイティブアプリの体験を提供することを可能にするテクノロジーです。このコードラボでは ""Topeka"" という既存の Android プロジェクトをベースに、最新の開発ツールを使って Android Instant Apps を実装する演習を行います。

持参していただくもの:
最新の Android Studio 3.0 プレビュー版がインストール済みの開発用ノートパソコン



◾午後の部

13:30 - 14:30
ワークショップ「Play Console ワークショップ:ビジネス解析」

参加対象:
プロダクトマネージャー、マーケター、エンジニア(コーディングの知識は特に必要ありません)

概要:
ビジネス担当者に特におすすめ。このワークショップでは、ビジネス分析に役立つPlay Console の各無料ツールの使い方をステップバイステップで解説し、習得いただけます。

持参していただくもの:
Play Console にログインできるノートパソコン(必須ではありません)

14:45 - 15:45
ワークショップ「Play Console ワークショップ:失敗しないアプリリリース」

参加対象:
エンジニア・プロダクトマネージャー(コーディングの知識は特に必要ありません)

概要:
とりあえず出してから修正していけばというウェブの考えをアプリに持ち込むのは危険です。このワークショップでは、アプリの失敗しないリリースに役立つPlay Console の各無料ツールの使い方をステップバイステップで解説し、習得いただけます。

持参していただくもの:
Play Console にログインできるノートパソコン(必須ではありません)

16:00 - 17:00
ワークショップ「Play Console ワークショップ:アプリ品質計測と改善」

参加対象:
エンジニア・プロダクトマネージャー(コーディングの知識は特に必要ありません)

概要:
Play ストアでの露出やダウンロードを最大化するための一番の近道は高品質アプリを作ること。このワークショップでは、ユーザーレビューや最新機能である Android Vitals など、アプリの品質改善に役立つPlay Console の各無料ツールの使い方をステップバイステップで解説し、習得いただけます。

持参していただくもの:
Play Console にログインできるノートパソコン(必須ではありません)

13:30 - 16:30
コードラボ「Firebase 実践編」

参加対象:
エンジニア(Java Script, Java, Objective-C のうちいずれかのコーディング知識が必要です)
概要:
このコードラボでは、Firebase の Realtime Database, Authentication, Storage, Hosting などの機能を自分のペースに合わせて学ぶことができます。Android アプリだけでなく、iOS アプリやウェブ開発にも役立つ実践的スキルを身に付けることができます。

持参していただくもの:
最新の Android Studio と Firebase がインストール済みの開発用ノートパソコン

14:00 - 17:00
コードラボ「Tango - AR アプリを作ろう」

参加対象:
エンジニア(C++, C# or Javaのうちどれかのコーディング知識が必要ですが、Unity の経験は必要ありません)

概要:
このコードラボでは Unity を使い、2 つのモジュールに挑戦していただきます。モジュール 1 では Motion Tracking や Depth Perception といった Tango の核になるファンクションを使って、簡単な AR のゲームを作ります。モジュール 2 では Natural Target Detection を使った簡単なアプリの作り方をステップバイステップで説明します。

持参していただくもの:
Unity (5.6以上、+Android SDK/NDK, +log-in account)、最新のJava Development Kit (JDK) 、最新の Tango Unity SDK がインストールされた開発用ノートパソコン

14:30 - 17:30
ワークショップ「TensorFlow を Android アプリに実装しよう」


参加対象:
エンジニア(Java のコーディング知識と Android アプリの開発経験が必要です)
概要:
機械学習を組み込んだAndroidアプリ開発に興味のある方におすすめです。TensorFlow を Android に実装し、 Android 端末で手書き数字が認識できるようにします。

持参していただくもの:
最新の Android Studio がインストールされた PC、Android 端末



◾夜の部

18:00 - 20:00
アプリデザイナー Meetup

参加対象:
アプリ UI/UX デザイナー

概要:
こちらは Google ではなく design-jp主催のイベントです。参加申し込みは、下記の Workshop Day と同じフォームをご利用ください。





Posted by Takuo Suzuki - Developer Relations Team

ユーザーをアプリと支払いの中心に据える新たな方法

$
0
0
この記事は 広告およびコマース担当上級副社長、Sridhar Ramaswamy による Inside AdMob の記事 "Google I/O: New Ways to Put Users at the Center of Your Apps and Payments" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google I/O は Google の魔法の時間です。毎年、何千人ものデベロッパーが Google のもとに集い、新製品のアイデアを共有したり、コンピューティングにおける最新のイノベーションを学んだりします。

私たちは、デベロッパー コミュニティが期待に胸を膨らませているタイミングで顔を合わせています。現在のユーザーは、今までになく選択肢を与えられています。たとえば、どこで買い物をするか、何を見るか、どのゲームをプレイするか、友だちや家族とどうコミュニケーションをとるかなどです。皆さんの製品は人目を引かなければなりません。ビジネスの拡大に役立つツールが必要です。そして、ユーザーを幸せにしなければなりません。

私たちはそれをお手伝いできます。

本日午後(*原文公開当時)、私のチームは、デベロッパーにとっての 3 つの新たなイノベーションについてお話しします。ユーザーが皆さんのサービスに対して簡単に支払いをできるようにし、ビジネスの収益化とユーザーベースの拡大につなげることができるものです。こちらから、または本投稿の末尾からライブ ストリームをご覧ください。
Google を活用した支払いを実現

本日より、Google の一連の支払いソリューションが拡張されます。Google Payment API は、ユーザーがクレジット カードやデビットカードを使って Google アカウントに保存されている口座から簡単に支払う方法を実現するもので、販売者やデベロッパーのチェックアウト コンバージョン率の急上昇に貢献します。ユーザーは、以前に Android Pay に保存したクレジット カードやデビットカード、Play ストアでの決済に使った支払いカード、Chrome に保存されている支払いフォームなど、複数の Google 支払いオプションをいつでも使うことができます。さらに、保存した支払いオプションはサードパーティアプリやモバイルサイト、そしてGoogle Assistant からも利用できるようになります。
Google を使って Google Assistant で Panera Bread に支払い

ユーザーにとって、これは購入手続きの高速化につながります。バスの中で身動きがとれないときに、見知らぬ人の前でクレジット カードを取り出したくはないものです。そのようなユーザーが購入をやめることがなくなります。ベッドに入ってクレジット カードが手元にないときに、夜中に終了するセールに出くわして困ってしまうようなこともなくなります。サポート対象のアプリやサイトに Google で支払うオプションがあれば、いつでも Google アカウントに保存してあるクレジット カードやデビットカードを使うことができるので、ユーザーは時間を節約でき、悩むこともなくなります。

この API は、デベロッパーにとって重要なイノベーションです。すばやく購入を行い、コンバージョン率や売上を増やし、カートのキャンセルを削減できます。しかも、組み込みも簡単です。Google Payment API の詳細は、こちらをご覧ください。
新しくなった AdMob でアプリの収益を上げる
人々は、買い物やコミュニケーション、エンターテイメントのために、一日中モバイル端末に向き合っています。デベロッパーにとって、アプリ内課金は収益化の 1 つの方法です。そして、もう 1 つの方法が広告です。
AdMob は、アプリのエコシステムをサポートするために構築されています。iOS と Android の 100 万以上のアプリで、AdMob は 35 億ドル以上広告収益をデベロッパーにもたらしてきました。しかし、私たちには皆さんの成功に向けてまだできることがあります。

本日は、完全に再設計された AdMobを紹介します。AdMob は 1 から再構築されています。さらに簡単に使えるようになり、ユーザーがアプリの中でどんな体験をしているのかについて、豊かなインサイトをもたらしてくれるようになっています。

さらに使いやすく: AdMob のルック アンド フィール全般にわたって、マテリアル デザインが適用されています。これによって、モバイルか PC かを問わず、プラットフォーム全体で直感的で使いやすい操作が実現され、より迅速に多くのことができるようになります。下の図から、管理するアプリの一覧や主要な指標の確認がどれほど簡単であるかわかるでしょう。そして、パフォーマンスをすばやく微調整できます。

再設計された AdMob の操作

豊かなインサイト:
再設計された AdMob のコアには Google Analytics for Firebase が組み込まれているので、もっともビジネスに影響する指標にすばやくアクセスできます。AdMob と Firebase アカウントをリンクさせると、詳しい広告収益データに加え、ユーザーがアプリを使った時間やアプリ内課金などのすべての分析を 1 か所で確認できます。

AdMob の Google Analytics for Firebase ダッシュボード
ユニバーサル アプリ キャンペーンでユーザーを知り、ユーザーを見つける
アプリで収益を上げることは、パズルのピースの 1 つです。どのようにユーザーベースを拡大するかについても考えなければなりません。

Google によるアプリのイノベーションによって、広告から 50 億以上のインストールが生まれています。現在私たちのサポートによって、デベロッパーの皆さんは 4 半期ごとに 30 億以上のアプリ内イベントを生み出しています。アプリ内イベントとは、たとえばカートに追加、ゲームのレベル 3 に到達といったイベントです。今、デベロッパーが魅力を感じているのは、「ワンストップ ショップ」型キャンペーンであるユニバーサル アプリ キャンペーン(UAC)です。これは、Google の最大の財産である Google Play、検索、YouTube、Gmail、ディスプレイ ネットワークの全体にリーチを広げ、アプリのインストールを最大化するものです。UAC は、Google の機械学習テクノロジーを活用してさまざまなシグナルをリアルタイムに評価し、もっとも興味を持つユーザーに広告を届けるように微調整します。私たちは UAC への取り組みを倍増させ続けています。UAC にはあらゆる新しいイノベーションが組み込まれつつあり、アプリの宣伝は今まで以上に効率的になります。
Google Play での新たな UAC の配置により、アプリを見つけた瞬間にユーザーを魅了 
Android の月間アクティブ端末数は 20 億台以上に達しており、Google Play は世界中の 190 以上の国で利用できます。ユーザーが新しいアプリやゲームを見つけるためにアクセスする場所が Google Play なのです。ユーザーはアプリを検索して試してみるだけではなく、Play ストアや新しいおすすめアプリを見ることに多くの時間を費やしています。 
皆さんのアプリがもっと見つけやすくなるように、Google Play ストアのホームとアプリの掲載情報ページで、広告の配置が新しくなります。この新しい配置は、UAC のみで利用可能です。これにより、「検出モード」のユーザーが次のお気に入りアプリを探してスワイプ、タップ、スクロールした際に、皆さんのアプリがユーザーの目に触れやすくなります。 
ユーザーの目に触れやすい Google Play の新たな広告の配置

UAC の新たな入札オプションでベストユーザーを増やす 
ビジネス上、他のユーザーよりも価値が高いユーザーもいます。たとえば、ゲームでレベルアップしているプレイヤーや、月に何度もフライトを予約している旅行者などです。そのため、さらなる高価値ユーザーの獲得をサポートできるように、UAC のスマート自動入札戦略が拡張されています。スマート自動入札を利用すると、独自のビジネス目標、すなわち目標コンバージョン単価(tCPA)や目標広告費用対効果(tROAS)に合わせて入札を行うことができます。UAC は、インストールやイベント、そして近日中にサポートされる価値などの目標に応じて、適切なユーザーを割り当ててくれます。このアップデートは、今後数カ月のうちに順次 iOS と Android のデベロッパーや広告主に展開されます。 
新たな計測プログラム、App Attribution Partner の導入 
多くのデベロッパーは、サードパーティの計測プロバイダを使って広告の効果を測定し、ユーザーがどのようにアプリを使っているかを分析しています。こういった分析に基づいてすばやくシームレスなアクションを起こすために、App Attribution Partnerを導入します。これは、7 社から得たデータを AdWords に統合する新しいプログラムです。

adjust、Adways、AppsFlyer、Apsalar、CyberZ、Kochava、TUNE の皆さん、ようこそお越しくださいました。皆さんの参加をうれしく思います。

AdWords がこれらのパートナーと統合されることで、一貫性と信頼性のある詳細データでアプリの指標を確認できるようになるので、自信を持ってアクションを行い、ビジネスで最高のパフォーマンスを維持できます。
ユーザーがオンラインで過ごす時間は増えています。今後さらに重要になるのは、デザインするアプリから、提供する体験やユーザーが決済を行う方法に至るまで、あらゆる面でユーザー中心の体験を作り上げることです。それが簡単ではないことはわかっています。だからこそ、Google がサポートいたします。

皆さんとともにこの旅を続けることを楽しみにしています。



Posted by Rikako Katayama - AdMob Team

Google Calendar API を使ってイベントを変更する

$
0
0
この記事は G Suite デベロッパー アドボケート、Wesley Chun(@wescpy)による G Suite Developers Blog の記事 "Modifying events with the Google Calendar API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google Calendar APIメール内のマークアップを使ってユーザーのカレンダーにイベントを登録している方もいるでしょう。うれしいことに、これらのツールを使うとアプリから自動的かつシームレスにイベントを登録でき、ユーザーの時間を大幅に節約できます。しかし、もし予定が変わったらどうなるでしょう。その場合を考慮して、アプリからイベントの変更もできるようにしておく必要があります。

メールによるマークアップでは更新もサポートしていますが、できることは限られます。そこで本日の動画では、Calendar API を使ってイベントを変更する方法を紹介しましょう。合わせて、繰り返しの予定を登録する方法も紹介しています。どうぞご覧ください。

あなたの商品に興味を持っている潜在顧客がいて、1、2 回の打ち合わせを設定する場合を考えてみましょう。顧客の興味が増し、商品が最終候補リストに入ると、定期的な打ち合わせが求められます。CRM では、ユーザーの手を煩わせることなくこのような予定を調整できるようにする必要があります。同じように、「友人とのディナー」イベントも、友人と親しくなるにつれて、「また今度」から隔月になるかもしれません。どちらのイベントも、下のような JSON リクエスト ペイロードで日付を調整したり、繰り返し登録できます。
var TIMEZONE = "America/Los_Angeles";
var EVENT = {
"start": {"dateTime": "2017-07-01T19:00:00", "timeZone": TIMEZONE},
"end": {"dateTime": "2017-07-01T22:00:00", "timeZone": TIMEZONE},
"recurrence": ["RRULE:FREQ=MONTHLY;INTERVAL=2;UNTIL=20171231"]
};

このイベントは、Calendar API の events().patch() メソッドを 1 回呼び出すだけで更新できます。Python を使う場合は、次のようにして API サービスのエンドポイント GCAL に対して更新する有効な EVENT_ID を指定し、上のリクエスト データを渡します。
GCAL.events().patch(calendarId='primary', eventId=EVENT_ID,
sendNotifications=True, body=EVENT).execute()

Google カレンダーにイベントを登録する方法を紹介した動画を見逃した方は、こちらをご覧ください。また、公式 API ドキュメントもご覧いただけます。さらに、Google Apps Script を使っている方は、プログラムを利用して Calendar サービスから Google カレンダーにアクセスできます。

ぜひこの情報を活用してアプリを改良し、さらに便利でタイムリーな機能をユーザーに提供しましょう。


Reviewed by Eiji Kitamura - Developer Relations Team

Google People API が連絡先と連絡先グループの更新をサポート

$
0
0
この記事はソフトウェア エンジニア、Amos Yuen、G Suite デベロッパー アドボケート、Wesley Chun(@wescpy)による G Suite Developers Blog の記事 " Google People API now supports updates to Contacts and Contact Groups" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

本日(*原文公開当時)より、Google People APIに連絡先と連絡先グループ用の新しいエンドポイントを追加しました。昨年、古い Contacts APIを置き換えることを念頭に、読み取り専用のエンドポイントに対応した Google People API をリリースしました。今回、書き込み用のエンドポイントを追加したことにより、その目的に一歩近づきました。デベロッパーが連絡先を作成、削除、更新できるようになっただけでなく、連絡先グループ用のエンドポイントも追加されているため、連絡先グループの読み書きもできるようになっています。

この API にアクセスするには、まずアプリケーションが認可を受ける必要があるため、Google Developers Consoleで People API を有効にしてプロジェクトを作成し、サービスにアクセスできるようにします。実行しなければならないステップについては、ここを参照してください。Google API や Developers Console にまだ慣れていない場合は、シリーズの第 1 弾であるこの動画を見て知識を深めておけば、すぐに追いつけます。


認可を受けると、以下のようにして簡単に(Java 向けの Google API クライアント ライブラリを使って)ユーザーの連絡先を作成できます。
Person contactToCreate = new Person();

List names = new ArrayList<>();
names.add(new Name().setGivenName("John").setFamilyName("Doe"));
contactToCreate.setNames(names);

Person createdContact =
peopleService.people().createContact(contactToCreate).execute();

アプリは、https://www.googleapis.com/auth/contactsのスコープで認可を受けている必要があります。 people.create メソッドの詳細を記述したドキュメントは、ここから参照できます。既存の連絡先は、以下のようにして更新できます。

String resourceName = "people/c12345"; // existing contact resource name
Person contactToUpdate = peopleService.people().get(resourceName)
.setPersonFields("names,emailAddresses")
.execute();

List emailAddresses = new ArrayList<>();
emailAddresses.add(new EmailAddress().setValue("john.doe@gmail.com"));
contactToUpdate.setEmailAddresses(emailAddresses);

Person updatedContact = peopleService.people().updateContact(contactToUpdate)
.setUpdatePersonFields("emailAddresses")
.execute();

 people.update メソッドの詳細を記述したドキュメントは、ここから参照できます。連絡先を変更できるこの新機能を使って皆様が作るアプリを楽しみにしています。People API の詳細については、ここから公式ドキュメントを参照してください。


Reviewed by Eiji Kitamura - Developer Relations Team

Python Admin SDK からデータベースにアクセスする

$
0
0
この記事は ソフトウェア エンジニア、Hiranya Jayathilaka による The Firebase Blog の記事 "Accessing Database from the Python Admin SDK" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

昨年 4 月、Firebase Admin SDK for Python が一般公開されたことをお知らせしました。この SDK の最初のリリースでは、Firebase Authentication の 2 つの重要な機能であるカスタム トークンの作成と ID トークンの検証がサポートされました。そして本日(*原文公開当時)、うれしいことに、バージョン 2.1.0 以降の Firebase Admin SDK for Python でデータベースがサポートされることになりました。

Python SDK の実装方法の特徴により、他の Admin SDK(Node.js および Java)のデータベース API とは大きく異なる点がいくつかあります。もっとも顕著な違いは、リアルタイム イベント リスナーがサポートされていない点です。現在の Python Admin SDK では、データベース リファレンスに対してイベント リスナーを追加してリアルタイムに更新通知を受け取る方法は提供されておらず、データ取得操作はすべてブロッキング メソッドとして提供されています。そのような違いはありますが、この API でできることはたくさんあります。

Python Admin SDK のデータベース モジュールを使うと、基本データ操作と高度な問い合わせの両方を行うことができます。Python 環境からデータベースにアクセスするには、Realtime Database の URL を使って SDK を初期化します。
import firebase_admin
from firebase_admin import credentials

cred = credentials.Cert('path/to/serviceKey.json')
firebase_admin.initialize_app(cred, {
'databaseURL' : 'https://my-db.firebaseio.com'
})

次に、SDK の dbモジュールからデータベース リファレンスを取得します。データベース リファレンスは、一般的なデータベース操作を Python メソッドとして提供しています(get(), set(), push(), update(), delete())。
from firebase_admin import db

root = db.reference()
# Add a new user under /users.
new_user = root.child('users').push({
'name' : 'Mary Anning',
'since' : 1700
})

# Update a child attribute of the new user.
new_user.update({'since' : 1799})

# Obtain a new reference to the user, and retrieve child data.
# Result will be made available as a Python dict.
mary = db.reference('users/{0}'.format(new_user.key)).get()
print 'Name:', mary['name']
print 'Since:', mary['since']

Firebase Realtime Database は、すべてのデータの値を JSON として格納しています。Python Admin SDK が JSON と Python のネイティブ データ型との変換をシームレスに行っている点に注目してください。

高度なクエリーを行うには、データベース リファレンスで提供されているいずれかの order_by_*メソッドを呼び出します。すると query オブジェクトが返され、そこに追加パラメータを設定できます。この API を使うと、件数制限や範囲指定、並べ替えた結果の取得ができます。
from firebase_admin import db

dinos = db.reference('dinosaurs')

# Retrieve the five tallest dinosaurs in the database sorted by height.
# 'result' will be a sorted data structure (list or OrderedDict).
result = dinos.order_by_child('height').limit_to_last(5).get()

# Retrieve the 5 shortest dinosaurs that are taller than 2m.
result = dinos.order_by_child('height').start_at(2).limit_to_first(5).get()

# Retrieve the score entries whose values are between 50 and 60.
result = db.reference('scores').order_by_value() \
.start_at(50).end_at(60).get()

この新しい API の詳細は、Admin SDK ドキュメントGithub レポジトリをご覧ください。また、問題の報告やパッチの提供を通して、Admin SDK の改善にご協力ください。実は、この API をこれほどの短期間で開発してリリースできたのも、皆さんからの絶え間ないフィードバックのおかげです。ぜひ Firebase のコーディングをお楽しみください。


Reviewed by Khanh LeViet - Developer Relations Team

Google Places API の機能の一部変更について

$
0
0
この記事は Google Maps API プロダクト マネージャー、Fontaine Foxworth による Google Geo Developers Blog の記事 "Removing Place Add, Delete & Radar Search features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

このたび、プレイスの追加・削除機能とレーダー検索機能を、Google Places API ウェブサービスと JavaScript ライブラリから削除することになりました。Android と iOS 用の Google Places API でも、プレイスの追加機能のサポートを終了します。なお、これらの機能は、2018 年 6 月 30 日までは利用することができます。それ以降は、Places API へのリクエストに対してエラー メッセージが返されるようになります。

2012年、Google Places APIプレイスの追加と削除機能がリリースされ、アプリケーションからユーザーの Google マップ データベースの情報を即座に更新したり、Google マップに追加する新しいプレイスを送信することができるようになりました。さらに、レーダー検索も導入され、ユーザーも導入され、ユーザーが地域内で具体的なスポットを特定できるようになりました。

しかしながら、これらの機能の利用者は一部にとどまっており、プレイスの追加に関しては、地図に載っていない場所を追加するという方法も提供されていることから、今回の機能変更に至りました。

次のステップ

該当する機能を利用されている方は、2018 年 6 月末までに、これらの機能をアプリケーションから完全に削除し、次の方法で対応されることをおすすめします。

レーダー検索機能の代替として、Nearby 検索を利用することができます。rankby=distanceを指定し、keywordまたは nameを指定せずに検索をしてみてください。詳細については、ウェブサービスまたは Google マップ JavaScript API のプレイス ライブラリのデベロッパー ガイドをご覧ください。

なお、PythonNode.jsJavaGoGoogle マップ ウェブサービス用クライアント ライブラリでも、この機能のサポート終了を反映するアップデートが行われています。

ご不便をおかけしますが、この代替方法がお役に立てば幸いです。ご質問やフィードバックがある方は、Issue Trackerより登録をお願いします。

さらに、Google Maps APIs の利用に関して、ご質問やご意見のある方は、問い合わせフォームよりご連絡をお願いします。

Reviewed by 丸山 智康 (Tomoyasu Maruyama) - Google Customer Engineer Lead, Japan and APAC

Android Vitals: アプリのパフォーマンスを向上してエンゲージメントとインストールを増加させる

$
0
0
この記事は Google Play 製品マネージャー、Fergus Hurley による Android Developers Blog の記事 "Android vitals: Increase engagement and installs through improved app performance " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

多くのユーザーは、アプリのパフォーマンスが悪いと感じたことがあります。アプリのクラッシュ、無応答、遅いレンダリングなどを目にしたときのことを思い出してください。端末の電池の使用量を確認し、電池を使いすぎているアプリを見つけたとき、皆さんはどのように反応したでしょうか。アプリの動作が適切でなければ、ユーザーはそれに気づきます。実際、Google Play のアプリのレビューを社内で分析した結果、星 1 つのレビューの半数で、アプリの安定度が指摘されていました。

逆に、快適に動作するアプリには常に高い評価やレビューが寄せられています。その結果、Google Play のランキングが上がり、インストールも増加します。さらにエンゲージメントも向上し、ユーザーがアプリに費やす時間や金額も増えます。

Google I/O 2017 では、Google Play Console の新しい Android Vitals ダッシュボードについて発表しました。Android Vitals は、適切でないアプリの動作を把握し、分析することを目的に作られているため、アプリのパフォーマンスを改善して、パフォーマンス向上によるメリットを得られます。

Google Play Console の Android Vitals




Android Vitals は、アプリのパフォーマンスを改善する余地を見つけます。ダッシュボードはエンジニアにとってもセールスにとっても便利なものになっています。アプリを監視してパフォーマンスの指標をすばやく参照できるので、データを分析し、改善にしかるべきリソースを割り当てることができます。

Android 端末でユーザーが利用データや診断データを自動的に共有することを選んだ場合、次のようなデータが収集され、確認できるようになります。
  • 安定度: ANR 率 & クラッシュ率
  • レンダリング時間: 遅いレンダリング(16ms)と UI フレームのフリーズ(700ms)
  • 電池使用量: wake locks のスタック、頻繁なスリープ解除

アプリのパフォーマンス改善によって評価が 4.1☆ から 4.5☆ に上昇した Busuu の事例

Busuu は世界屈指の言語学習アプリです。製品責任者の Antoine Sakho から、どのように Busuu がアプリのユーザー評価を上昇させたかをお聞きください。

Android や Google Play のツールを使って高いパフォーマンスを実現するエンジニアリング手法


ダッシュボードに表示されているデータを理解し、アプリのパフォーマンスと安定度を改善する方法については、Android Vitals のベスト プラクティスに関する記事をご覧ください。Android や Google Play のその他のツールを使って不適切な動作を見つけて修正する方法は、I/O セッションでも紹介しています。

また、Playbook アプリでは、その他の Play Console の機能や、Google Play で成功を収めるための最新ニュースや秘訣を学ぶことができます。ぜひベータ版プログラムに参加し、インストールしてください。

このブログ投稿はどのくらい役に立ちましたか?
Reviewed by Hak Matsuda - Developer Relations Team

ディープ ラーニングでプロレベルの写真を生成する

$
0
0
この記事は 機械知覚ソフトウェア エンジニア、Hui Fang による Google Research Blog の記事 "Using Deep Learning to Create Professional-Level Photographs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

機械学習(ML)は、目標が明確に定まる用途で数多くの優れた成果を残しています。正解かどうかの答えが存在するタスクでは学習プロセスが比較的容易になり、目標を達成しやすくなります。たとえば、イメージ内の物体を正確に特定したり、ある言語から別の言語に適切に翻訳したりといったタスクです。しかし、結果の客観的評価が難しい分野もあります。たとえば、写真が美しいかどうかは美的感覚によって決まります。これは非常に主観的な概念です。
カナダ、ジャスパー国立公園のプロ級の(?)写真
ML による主観的概念の学習を追求するため、Google はアートコンテンツを生成するディープ ラーニング システムの試験版を公開しました。このシステムは、プロの写真家のやり方をまねています。Google ストリートビューのパノラマの景色を見て回って最高の構図を探し、さまざまな後処理を実行して「美しい」イメージを作成します。このいわば仮想の写真家は、アルプス、カナダのバンフやジャスパー国立公園、カリフォルニアのビッグサーやヨセミテ国立公園など、4 万以上のパノラマを旅し、とても印象的な写真を生成して帰ってきました。その中には、プロの写真家からプロ級の品質に近いという評価を受けたものもあります。

モデルのトレーニング
「美しさ」は、 AVAなどのデータセットを使ってモデル化できます。しかし、単純にこれを使って写真を加工しようとしても、写真の彩度が上がりすぎるなど、美しさのいずれかの側面が失われることもしばしばです。一方で、教師あり学習によって美しさのさまざまな側面を適切に学習させるには、ラベル付けされたデータセットが必要になるでしょう。これは収集が難しいものです。

私たちのアプローチは、プロ品質の写真のみを集めるというものです。これには、加工前後のイメージのペアや追加のラベルは含まれていません。そして、「美しさ」を自動的に複数の側面に分割し、いくつかのイメージ操作を組み合わせて生成したネガティブ サンプルと合わせて、それぞれの美しさの側面を個別に学習させます。これらのイメージ操作を準「直交」として保持することにより、写真の構図、彩度や HDR レベル、ライティングのドラマチックさを高速かつ分割可能な操作で最適化し、写真の質を高めることができます。
パノラマ写真(a)をトリミングし(b)、彩度と HDR 強度を調整し(c)、ドラマチック マスクを適用する(d)。それぞれのステップは学習した美的感覚の側面の 1 つに沿って実行される。
従来のイメージ フィルタは、彩度や HDR の詳細、構図に関するネガティブ トレーニング サンプルを生成するために使用しました。さらに、ドラマチック マスクという特殊な操作も導入しています。これは、ドラマチック ライティングの概念の学習と合わせて作成したものです。ネガティブ サンプルは、プロの写真にいくつかのイメージ フィルタを適用し、明度をランダムに変えて見栄えを悪くすることによって生成しました。トレーニングには、Generative Adversarial Network(GAN)を使用しています。これは、生成モデルでネガティブ サンプルのライティングを修正するマスクを生成しつつ、識別モデルで加工した写真と実際のプロの写真を見分けようとするものです。ドラマチック マスクは、ビネットのような形が決まったフィルタとは違い、写真の内容を考慮して明度を調整します。GAN のトレーニングでは競い合うようにして学習が進むため、その課程でさまざまなバリエーションの写真が提案されることになります。トレーニングの詳細については、論文をご覧ください。

結果
以下に、このシステムが Google ストリートビューから生成したいくつかの写真を紹介します。トレーニングされた「美しさ」のフィルタを適用することによって、感動的な作品が生まれていることがおわかりいただけるでしょう(本投稿の最初に掲載したイメージも含まれています)。
カナダ、ジャスパー国立公園
スイス、インターラーケン
イタリア、オロビエ・ベルガマスケ公園
カナダ、ジャスパー国立公園
プロによる評価
このアルゴリズムがどの程度成功したかを見極めるため、「チューリング テスト」のような実験を行いました。生成した写真を質の異なる他の写真と混ぜて何名かのプロの写真家に見せ、それぞれの質を点数で評価してもらいました。各評価の意味は以下のとおりです。
  • 1: 構図やライティングなどを考えず、ただ撮影しただけ。
  • 2: 写真の経験がない一般の人にしてはよい写真。ただし、芸術的に卓越した点は認められない。
  • 3: セミプロ級。明らかに芸術的側面が見受けられる優れた写真。このまま行けばプロの写真家になれる。
  • 4: プロ級。
次のグラフのそれぞれの線は、イメージに対して予想される点数の範囲ごとに、プロの写真家の評価点数を示したものです。もっとも高得点が予想された写真では、約 40% が「セミプロ」レベルから「プロ」レベルの評価を受けています。
写真の予測点数とプロの写真家による評価点数
今後の作業
ストリートビューのパノラマは、このプロジェクトの実験材料となりました。いつの日か、皆さんが現実の世界でよい写真をとる際に、この技術が役立つことになるかもしれません。生成した写真の中から、私たちが気に入った写真を集めたショーケースも作成しています。お好みの写真を見つけたら、クリックしてみてください。その近辺のストリートビューのパノラマが表示されます。もしその時あなたがカメラを持っていたら、同じように撮影していたでしょうか?

謝辞
本作品は、Google Research の機械知覚チームの Hui Fang と Meng Zhang によるものです。Inception ネットワークを利用して AVA 点数の予測を行った Vahid Kazemi に感謝いたします。また、Google ストリートビュー パノラマの処理をサポートしてくれた Sagarika Chalasani、Nick Beato、Bryan Klingner、Rupert Breheny にも感謝いたします。有用なレビューやコメントをいただいた Peyman Milanfar、Tomas Izo、Christian Szegedy、Jon Barron、Sergey Ioffe にも感謝いたします。匿名のプロの写真家の皆さんにも、この場を借りてお礼を申し上げます。


Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

柔軟な amp-bind でインタラクティブな AMP ページを作成する

$
0
0
この記事は AMP Project プロジェクト マネージャー、Eric Lindley による Accelerated Mobile Pages Project の記事 "amp-bind brings flexible interactivity to AMP pages " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
4 月に、AMP ページのインタラクティブ性を大幅に強化する実験としてamp-bindデベロッパーの皆さんに開放いたしました。本日は、amp-bind が一般公開されたことをお知らせします。また、この機能によって AMP、とりわけ e コマースのサポートが強化されていることを理解していただくために、amp-bind の機能を詳しく紹介したいと思います。  
 
amp-bind とは 
4 月のブログ投稿では、amp-bind を次のように紹介しました。  
amp-bindは、AMP に欠かせないパフォーマンスと確かな UX を保ちつつ、AMP のインタラクティブ性のモデルに根本的な変革をもたらすものです。amp-bind は AMP のコーディング レイヤーのように機能します。AMP Project が従来からとってきたアプローチは、amp-carouselamp-accordionのように、ユースケースを主眼に置いた限られたインタラクティブ性しか持たないコンポーネントでした。amp-bind はその先を行き、ユーザーのアクションをさまざまなドキュメントの状態のトリガーとリンクさせます。それによって、デベロッパーが定義できるインタラクションの自由度が大きく高まります。

これは技術的に正しい定義ですが、かなり抽象的です。この機能は非常に柔軟性が高いため、大まかな説明では実際何ができるのかよくわからないでしょう。  
 
amp-bind でできること 
ではまず、この機能の基本動作から見てみましょう。その後、AMP by Example の Playgroundで実際に一部のコードを書き換えて試してみることができます。  
 
基本を学習した後は、以下の例をご覧ください。amp-bind と他の AMP HTML 機能を組み合わせて何ができるかを紹介しています。  
  • 商品の色とサイズの選択(詳しくは下の例を参照) 
  • サーバーサイドでのフィルタリングと並べ替え(詳しくは下の例を参照) 
  • ページを再読み込みせずに検索結果を表示(詳しくは下の例を参照) 
  • 検索時の自動候補表示(詳しくは下の例を参照) 
  • カルーセルのスライド インジケーター(詳しくは下の例を参照) 
  • 「select」入力のトリガー ナビゲーション 
  • 「いいね」「カートに追加」などに基づいてページ全体の状態を更新するスマートボタン、この操作に基づくパーソナライズされたおすすめのカルーセル表示、カート内のアイテムの数や「いいね」のカウントの追加 
  • アイテムの一覧を表示するビューの切り替え(リスト表示とグリッド表示) 
  • 購入前に商品のオプションをカスタマイズできるオーバーレイ UI パネルの表示切り替え 
  • ツールチップの表示、非表示 
  • amp-list のデータをフィルタリングするカスタム スライダーの利用 
  • ページ全体を更新せずに通貨を変更(例: 米ドルからユーロに) 
  • その他

 
商品の色とサイズの選択 
 

 
この例では、商品説明のページでよく見られる数多くの機能が組み込まれていますが、一部の機能のみを必要とする場合は、分割して個々に使用することもできます。ここでは amp-bind を使って、amp-form、amp-selector、amp-carousel と基本的な CSS との間で、イベントやアクションを連携させています。 
  1. ユーザーが amp-form を選択(カスタマイズしやすく、意味がわかりやすい amp-selector を使った入力) 
  2. それぞれを選択した際にイベントが発生 
  3. amp-bind はイベントと連携して以下を実行 
    1. 3 つの amp-carousel のいずれかを表示する CSS を設定(リンゴのそれぞれの色に対応) 
    2. 特定の色でサイズを選択できない場合、フォーム入力に「disabled」属性を設定(スタイルも適用) 
    3. リンゴの色に応じて価格を更新
このページでは amp-bind が使われているため、ユーザーは選択した内容を視覚的に確認できます。そのため、フォームを送信する前に何を購入するのかを確実に理解できるようになります。  

サーバーサイドでのフィルタリングと並べ替え 

 
amp-list[src] バインディングによって、サーバーサイドでのデータの並べ替えとフィルタリングができるようになります。ここでは、amp-bind を使って「select」入力と amp-list の間のイベントやアクションを連携させています。細かく見てみましょう。  
 
  1. ユーザーが並べ替えとフィルタリングのルールを選択(「昇順」を選んだとします) 
  2. 「select」の入力状態の変化に伴うイベントが発生 
  3. amp-bind はイベントと連携して amp-list の src 属性を更新し、並べ替えルールに対応するクエリ パラメータ(?sort=price-ascending)が追加され、サーバーに送られる 
  4. サーバーは並べ替えルールに応じた結果リストを返し、定義されているテンプレートに従って amp-list が表示される 
bind イベントは入力の配列から呼び出すこともできるため、追加で結果を表示する「さらに表示」ボタンや結果リストのページングなどの機能にもこの基本パターンを使うことができます。その場合、ユーザーは現在のページを再読み込みせずに、リストの追加アイテムを参照できるようになります。ユーザーにパーソナライズされたおすすめのリストを表示するような実装も可能です。  
 
ベスト プラクティス: ページを最初に読み込んだ際に、div[placeholder] を使って静的に結果を表示します。そうすると、遅延することなく結果をユーザーに表示できます。そして、ユーザーが並べ替えやフィルタリングの仕組みを使用した際に、amp-bind を使って amp-list の「src」属性を更新してその URL を呼び出し、結果を表示します。  
 
ページを再読み込みせずに検索結果を表示  
 

 
ページ全体を再読み込みすることなく検索結果をインラインで取得して表示することにより、ユーザーは帯域幅を節約でき、現在のページの枠組みを維持したままシームレスな操作を行えるようになります。この実装方法は、amp-list のバインディングのもう 1 つの応用例で、今回は amp-form も使用しています。  
 
  1. ユーザーが amp-form で「pear」を検索 
  2. この検索でイベントが発生し、amp-bind との連携によって amp-list の src 属性が更新され、検索クエリに対応したクエリ パラメータ(?searchProduct=pear)が追加され、サーバーに送信される 
  3. サーバーは検索クエリに応じた結果リストを返し、定義されているテンプレートに従って amp-list が表示される 

検索時の自動候補表示 
 

 
これは、amp-list[src] バインディングのもう少し複雑な例です(コードはこちら)。ここでは、amp-bind を使って amp-form と amp-list の間のイベントやアクションを連携させています。  
 
  1. ユーザーが検索ボックスに入力を開始 
  2. フォーム フィールドへのテキスト入力に関連付けられたイベントが発生(ボタンを押すたびにこれらのイベントが発生しないように、デバウンスを行う) 
  3. amp-bind はイベントと連携して以下の 2 つを実行 
    1. amp-list を含む非表示 div を表示 
    2. amp-list の src 属性を更新し、ユーザーがフォームに入力した部分を含むクエリをサーバーに送信 
  4. amp-list によってサーバーがクエリに応じて返す候補リストがテンプレートに表示され、ユーザーに候補として提示される 
  5. いずれかの候補がタップされると、amp-list のテンプレートとの連携によってフォーム フィールドが更新され、インタラクションが完了する 

注: 同時に 2 つの異なる機能の UI が重なって表示されるのを避けるため、独自の自動候補表示を行う場合は、ブラウザの自動候補表示をオフにしてください。

詳しい仕組みについては、GitHub にある例をご覧ください。この例は、別のページにコピーして貼り付けたり、テンプレートやバックエンドをカスタマイズして任意の候補を表示することができます。ユーザーが検索する可能性がある単語を細かく提示することもできれば、価格や写真、評価などが詳しく掲載された商品のカードを表示することもできます。  
 
カルーセルのスライド インジケーター  

 
ここでは、amp-carousel のインデックス番号と単純なページ インジケーター(カルーセルの左下の 4 つの点)の CSS スタイルを連携させるために amp-bind を利用しています。  
 
  1. ユーザーがカルーセルのスライドをスワイプ 
  2. 表示されるスライドの変更に伴うイベントが発生 
  3. amp-bind はイベントと連携して CSS スタイルを変更し、ページ位置を示す点を表示 

この機能によって、デベロッパーはさまざまな目印を使ってカルーセルがスワイプ可能であることを示せるようになるので、amp-carousel のデフォルトの矢印を使う必要はなくなります。  
 
次のステップ 
amp-bind は安定版となりましたが、現在も多くの機能が積極的に追加されています。コミュニティからのフィードバックに基づき、AMP に欠かせないパフォーマンスと安定した UX を損なわずにこのコンポーネントをさらに強化する機能追加が進められています。  
 
主なロードマップには、以下のような機能が含まれています。まず、並べ替えやフィルタリングのユースケースを完成させるため、バインディングからの URL のクエリ パラメータと対応する履歴状態を更新できるようにする予定です。また、インライン コンテンツと埋め込みコンテンツとの間の境界をまたぐ高度なインタラクションを AMP で実現するために、iframes と親ドキュメントと間のメッセージングを可能にする予定です。さらに、サーバーの呼び出しによって検証されるフォームとページ状態を連携させるために、バインディングの強化も行われる予定です。  
 
ぜひ実際に利用して試してみてください(そして発見したことを共有してください) 
最終的に、デベロッパーの皆さんはここで AMP チームが紹介したものよりもたくさんの新機能を見つけてくれることでしょう。ぜひ実際に利用して試してみてください。amp-bind を試してみて、発見したことをお知らせください。皆さんが構築し、幅広い AMP コミュニティに共有してくれるアプリを楽しみにしています。  
 
いつものように、amp-bind や AMP でサポートが必要な他の機能について、フィードバックをお寄せください。皆さんからのご連絡をお待ちしています。  
 
 
Reviewed by Yoshifumi Yamaguchi - Developer Relations Team

Facets: 機械学習トレーニング データ用のオープンソース視覚化ツール

$
0
0
この記事は Google Big Picture チーム シニア ソフトウェア エンジニア、James Wexler による Google Research Blog の記事 "Facets: An Open Source Visualization Tool for Machine Learning Training Data" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google オープンソース ブログにも投稿されています)

機械学習(ML)モデルからベストの結果を得るには、データを正確に理解することが欠かせません。しかし、ML のデータセットには莫大なデータポイントが含まれており、それぞれのデータポイントは数百(場合によっては数千)のフィーチャー(特徴量)で構成されています。そのため、データセット全体を直感的に理解するのはほぼ不可能です。可視化を行うと、巨大なデータセットの微妙な差異や本質を見抜くことができます。一枚の絵は一千語に匹敵すると言われますが、インタラクティブな可視化はそれにも増して価値があります。

私たちは、PAIR Initiativeと合同で Facetsをリリースしました。Facets は、ML データセットの理解と分析に役立つオープンソースの可視化ツールです。Facets は 2 種類の可視化で構成され、ユーザーはさまざまな粒度でデータの全体像を確認できます。Facets Overviewはデータの各特徴量の形状をつかむために利用し、Facets Diveは個々のデータセットを詳細に分析するために利用します。この 2 種類の可視化によってデータのデバッグが可能になります。機械学習では、データのデバッグはモデルのデバッグと同じくらい重要です。これらの機能は、Jupyter Notebookやウェブページに埋め込んでの利用も可能です。合わせて、Facets デモサイトも用意しました。このサイトでは、どなたでもブラウザから直接自分のデータセットを可視化できます。ソフトウェアのインストールやセットアップは一切不要で、データを別の場所にアップロードする必要もありません。

Facets Overview
Facets Overview では、データセットの特徴量の分布をすばやく把握できます。トレーニング セットとテストセットのような複数のデータセットに対して同じ可視化を行い、相互に比較できます。これにより、予期しない値を持つ特徴量や、値の抜けが多い特徴量、分布が不均等な特徴量、データセット間で分布が偏っている特徴量など、モデルの学習を妨げる可能性がある問題を明らかにできます。
Facets Overview で UCI Census データセット [1] の 6 つの数値特徴量を可視化したもの。特徴量は不均等さの順に並べ替えられており、もっとも分布が不均等なものが一番上に表示されている。赤で表示された数値は、問題が生じている可能性がある部分を示す。この例では、高い確率で値が 0 になっている数値特徴量が赤く表示されている。右側のヒストグラムを見ると、トレーニング データ(青)とテストデータ(オレンジ)の分布を比較できる。

UCI Census データセット [1] の 9 つの分類特徴量のうち、2 つを Facets Overview で可視化したもの。特徴量は分布間距離の順に並べ替えられており、トレーニング(青)とテスト(オレンジ)のデータセット間の差がもっとも不均等な特徴量が一番上に表示されている。トレーニングとテストのデータセットの間で「Target」特徴量のラベルの値が異なっている点に注意。テストセットの末尾にはピリオドがついている(「<=50K」と「<=50K.」)。この点は特徴量のグラフと、表の「top」列からもわかる。ラベルが一致していないため、このデータを使ってトレーニングやテストを行うモデルは正しく評価されない可能性がある。
Facets Dive
Facets Dive は、簡単にカスタマイズができる直感的なインターフェースを提供し、データセットの各種特徴量を横断してデータポイント間の関係を分析できます。Facets Dive は、各データポイントの位置、色、視覚表示をフィーチャーの値に基づいて制御します。データポイントにイメージが関連付けられている場合は、そのイメージを視覚表現に使うこともできます。
Facets Dive で UCI Census テスト データセット [1] の 16281 個すべてのデータポイントを可視化したもの。アニメーションは、1 つの特徴量(「Relationship」)でデータポイントに色をつけ、連続特徴量(「Age」)で分類し、さらに離散特徴量(「Marital Status」)で別の分類を行う様子を示している。
「Quick, Draw!」データセットのたくさんの似顔絵を Facets Dive で可視化したもの。似顔絵の線と点の数と、「Quick, Draw!」分類器が顔として正しく分類できるかの関係を示している。
面白い気づき: CIFAR-10 データセット [2] などの大規模なデータセットでは、細かなラベル付けの間違いは見過ごされる傾向があります。Facets Dive で CIFAR-10 データセットを調査したところ、カエル猫(誤って猫のラベルが付けられていたカエルのイメージ)が見つかりました。
Facets Dive で CIFAR-10 データセットを分析する様子。ここでは、横に正解ラベル、縦に予測ラベルを使って分類している。これによって混同行列を表示でき、特定の種類の分類ミスにドリルダウンできるようになる。この例では、ML モデルがわずかな数だけ猫を誤ってカエルと分類している。おもしろいことに、実際のイメージを混同行列に配置し、モデルがカエルだと予測した「本物の猫」を目視で確認したところ、実はカエルだった。Facets Dive を利用することで、この分類ミスは実際にはモデルの分類ミスではなく、データセットのラベルの間違いであることが判明した。
あなたはカエル猫を見つけることができるか?

Facets は Google 社内でもとても役立てられています。この可視化ツールを皆さんと共有できることをうれしく思います。このツールが興味深い新たなデータの真実を発見する助けとなり、さらに強力で正確な機械学習モデルの構築につながることを願います。このツールはオープンソースなので、固有のニーズに応じて視覚表現をカスタマイズしたり、データの理解が深まるようにプロジェクトに貢献したりすることもできます。Facets に関するフィードバックがある方は、ぜひお知らせください

謝辞
この成果は、Big Picture チーム全体からの情報に基づき、Mahima Pushkarna、James Wexler、Jimbo Wilson が共同で実現したものです。ビルドツール一式を提供してくれた Justine Tunney にも感謝いたします。

参考文献
[1] Lichman, M. (2013).UCI Machine Learning Repository [http://archive.ics.uci.edu/ml/datasets/Census+Income].Irvine, CA:University of California, School of Information and Computer Science

[2] Learning Multiple Layers of Features from Tiny Images, Alex Krizhevsky, 2009.





Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

HAL の分離によるセキュリティ向上の仕組み

$
0
0
この記事は Android セキュリティ シニア ソフトウェア エンジニア、Jeff Vander Stoep による Android Developers Blog の記事 "Shut the HAL Up" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

セキュリティにアップデートは不可欠ですが、端末メーカーにとってアップデートは費用のかさむ困難なものになる場合があります。Project Trebleは、基盤となるベンダー実装を Android のコア フレームワークから分離して、アップデートを容易にするものです。このモジュール化技術によって、プラットフォームとベンダーが提供するコンポーネントを別々にアップデートできるようになります。高速かつ簡単にアップデートできるのはすばらしいことですが、Treble によるモジュール化はさらに、セキュリティの向上も考慮した設計になっています。

HAL の分離

ハードウェア抽象化レイヤー(HAL)は、デバイスを意識しないコードと、デバイス固有のハードウェア実装との間のインターフェースを提供します。通常、HAL は共有ライブラリとしてパッケージ化されています。HAL はハードウェアとのインタラクションを必要とするプロセスによって直接読み込まれ、プロセスレベルでセキュリティ境界が適用されます。そのため、HAL がプロセスに読み込まれると、そのプロセスと同じセキュリティ コンテキストで実行されることになります。
プロセス内で複数の HAL を実行する従来の方法では、それぞれのプロセス内 HAL が必要とするすべてのパーミッションがプロセスに必要でした。これには、カーネル ドライバへの直接アクセス パーミッションも含まれます。また同じように、プロセス内のすべての HAL には、他のプロセスと同じパーミッション セットへのアクセスが必要になります。これには、他のプロセス内 HAL が必要とするパーミッションも含まれます。その結果、プロセスや HAL に過剰なパーミッションが与えられることになり、本来アクセスすべきではないパーミッションやハードウェアにもアクセスできることになります。
図 1. 1 つのプロセスに複数の HAL が存在する従来の方法

HAL をそれぞれのプロセスに移動すると、最小権限の原則の実現に近づくことになります。これには、2 つのメリットがあります。
  1. 各 HAL はそれぞれのサンドボックス内で実行され、自身が制御するハードウェア ドライバのみへのアクセスを許可されます。また、プロセスに与えるパーミッションも、ジョブの実行に必要なパーミッションに限定できます。
  2. 同じように、プロセスは HAL が必要とするハードウェア ドライバなどのパーミッションや機能にアクセスできなくなります。
図 2. 各 HAL をそれぞれのプロセス内で実行

HAL をそれぞれのプロセスに移動することには、セキュリティの面で大きなメリットがある一方、クライアント プロセスと HAL との間で IPC によるオーバーヘッドが増加するという代償もあります。HAL とクライアント間の IPC は、binder ドライバの改善によって実用レベルになりました。binder に scatter-gather が導入されたことによって、シリアライズやデシリアライズのステップが不要になり、データのコピー命令の回数が 3 回から 1 回に減るため、各トランザクションのパフォーマンスが向上します。さらに、Android O では、ベンダーのコンポーネントとプラットフォームのコンポーネントに対して別々の通信ストリームを提供するために、binder ドメインも導入されています。アプリや Android フレームワークは引き続き /dev/binder を利用しますが、ベンダーが提供するコンポーネントは、/dev/vndbinder を使うことになります。プラットフォームのコンポーネントとベンダーのコンポーネント間の通信には、/dev/hwbinder を使う必要があります。その他の手段によるプラットフォームとベンダー間の IPC は許可されません。

事例紹介: システム サーバー


コア Android OS がアプリに提供するサービスの多くは、システム サーバーが提供しています。Android が拡大するにつれて、システム サーバーの機能とパーミッションも拡大しているため、システム サーバーは攻撃者の格好のターゲットになっています。Project Treble の一環として、センサー、GPS、指紋、Wi-Fi などの HAL を含むおよそ 20 の HAL がシステム サーバーから分離されています。以前は、これらの HAL のいずれかに欠陥があると、特権のあるシステム パーミッションを得ることができました。しかし、Android O のパーミッションは、特定の HAL が必要とするパーミッションのサブセットに制限されます。

事例紹介: メディア フレームワーク


Android Nougat で行われたメディア スタックの保護強化に向けた取り組みは、Android O でも引き続き実施されています。Nougat では、mediaserver が複数のコンポーネントに分割され、最小権限の原則に近づきました。オーディオ ハードウェアへのアクセスは audioserver に限られ、カメラ ハードウェアへのアクセスは cameraserver に限られる、といった具合です。Android O では、直接ハードウェア アクセスのほとんどがメディア フレームワークから完全に削除されています。たとえば、オーディオ、カメラ、DRM 用の HAL は、それぞれ audioserver、cameraserver、drmserver の外に移されています。

カーネル攻撃対象領域の削減と分離


Android でセキュリティ モデルを適用しているのは、主に Linux カーネルです。サンドボックス メカニズムを抜け出そうとする試みの多くは、カーネルへの攻撃に関連があります。Android カーネルの脆弱性分析から、脆弱性の多くは圧倒的にハードウェア ドライバで発生し、ハードウェア ドライバ経由で悪用されていることがわかっています。
システム サーバーとメディア フレームワークに特権を与えないことが重要になるのは、これらがインストールされたアプリと直接インタラクションを行うためです。ハードウェア ドライバへの直接アクセスを削除することによって、バグの影響範囲が少なくなり、Android のセキュリティ モデルにもう 1 つの防御レイヤーが追加されることになります。



Reviewed by Takeshi Hagikura - Developer Relations Team

AppShip3000: Firebase を利用したゲーム

$
0
0
この記事は デベロッパー プログラム エンジニア、Abe Haskins による The Firebase Blog の記事 "AppShip3000: A Firebase Game" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 
すばらしいゲームを作るのは難しいことです。ゲームは始めやすいものであると同時にやりがいがあって、少し中毒性があり、そしてもちろん楽しいものでなければなければなりません。また、当然ながら、技術的な作業の一環として、そのすばらしいゲームを支えるインフラストラクチャの設計も必要になります。Firebase の目的は、皆さんが手がけるゲームの独自の要素に集中できるように、インフラストラクチャという最後のピースを引き受けることにあります。  
 
今年の Google I/O では、Firebase でゲームを作ることを通して、このプラットフォームのテストを行いました。そして生まれたのが AppShip3000 です。その結果には、とても満足しています。 
 
懸命に作業する AppShip3000 開発チーム。はんだ付けも楽しい作業です!

動作の仕組み
AppShip3000 は、3 人で協力してロケットを飛ばすという簡単なゲームです。上に向かって飛ぶロケットは、すぐに燃料切れになってしまいます。プレーヤーは、そのロケットを協力して操作します。画面の上からは、隕石が次々と落ちてきます。その中でロケットを上昇させるには、Firebase や Google Cloud に関するクイズに答えなければなりません。

難しいのは、プレーヤーには問題か一部の選択肢しか見えないことです。プレーヤーは、時間切れになる前に、話し合って(叫び合って)正解を見つけなければなりません。同じように、他のプレーヤーよりも早く隕石が見えるプレーヤーがいるので、どこに隕石が落ちてくるかを叫び、チーム全員でロケットを操作しなければなりません。燃料を失わずに隕石との衝突を避けるには、プレーヤー全員が同じ方向にジョイスティックを動かす必要があります。

Firebase を使った開発
では、Firebase がどのように AppShip3000 を支えているのかを見てみましょう。まず、ログインには Firebase Authenticationが利用されています。プレーヤーはスマートフォンでプログレッシブ ウェブアプリ(PWA)を開き、自分の Google アカウントでログインします。すると、Cloud Function の Authentication トリガーによってアカウントが作成され、カスタムのボタン操作(起動コード)が生成されます。この起動コードによって、ゲームのプレイ中、アカウントとコントローラが関連付けられ、ゲームの終了時には、すべての状態が自動的にアカウントに関連付けられます。
Google I/O 2017 で公開された完成品

ゲームが終わると、Realtime Databaseを使って PWA のスコアボードを即座に更新します。I/O では、スコアボードが大画面で表示されていました。Realtime Database は、ゲーム中のクイズの管理にも利用されています。そのため、クイズはその場で更新でき、あるゲームが終わったあとに追加されたクイズは、次のゲームで本番環境に反映されます。

さらに、ゲームが終わるごとにロケットの飛行経路のイメージを生成し、Cloud Storage for Firebaseに格納しています。この操作で別の Cloud Function が呼び出され、Firebase Cloud Messagingでプレーヤーに通知されます。この通知によって、プレーヤーは記念になるイメージを友だちと共有できます。


スタートガイド
AppShip3000 の開発はとても楽しい経験でした。ほとんどのインフラストラクチャに Firebase を使ったので、他にはない(と思われる)ゲームの開発に集中でき、皆さんに楽しんでいただくことができました。Firebase を使ってゲームを作ってみたい方は、C++ および Unity のドキュメントをご覧ください。AppShip3000 のデータ パイプラインの管理にどのように Firebase や Google Cloud が使われていたかを詳しく知りたい方は、I/O のセッションをご覧ください。皆さんのゲームのリリースを楽しみにしています。



Reviewed by Khanh LeViet - Developer Relations Team

Android O の seccomp フィルタ

$
0
0
この記事は Android セキュリティ エンジニア、Paul Lawrence による Android Developers Blog の記事 "Seccomp filter in Android O" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android 搭載端末では、Android のセキュリティ モデルが適用されます。その際に大きな役割を果たしているのがカーネルです。セキュリティ チームは、Android のユーザー空間の保護を強化し、プロセスを分離して特権を与えないようにするために作業を進めています。しかし、セキュリティ攻撃の対象としてカーネルが狙われることがますます多くなっています。カーネルを狙う攻撃者が一般的に用いる手法は、システムコールです。
あらゆる Android ソフトウェアは、システムコール(syscall と短縮されることもあります)を使って Linux カーネルと通信しています。カーネルは、多くの端末固有および SOC 固有のシステムコールを提供しています。それによって、アプリを含むユーザー空間プロセスが直接カーネルとやりとりを行えるようになっています。すべてのアプリは、このメカニズムを使って、一意なシステムコールによってインデックスがつけられた動作のコレクション(ファイルのオープンや Binder メッセージの送信など)にアクセスします。しかし Android では、こういったシステムコールの多くは利用されておらず、公式なサポートもされていません。
Android O は、利用されていないシステムコールをアプリのソフトウェアからアクセスできないようにする seccompと呼ばれる Linux 機能を活用します。アプリからこういったシステムコールにアクセスできなくなるため、有害である可能性があるアプリによって悪用されることもなくなります。

seccomp フィルタ

Android O には、zygote にインストールされた seccomp フィルタが 1 つ含まれています。zygote は、すべての Android アプリの派生元となるプロセスです。フィルタは zygote にインストールされているので、すべてのアプリにインストールされることになります。そのため、既存のアプリに問題が発生しないよう、Android セキュリティ チームは特別な注意を払いました。seccomp フィルタによって許可されるのは、以下のシステムコールです。
  • bionic(Android 用の C ランタイム)経由で公開されているすべてのシステムコール。これは、bionic/libc/SYSCALLS.TXT で定義されています。
  • Android を起動できるようにするシステムコール。
  • 一般的な Android アプリに利用されるシステムコール。これは、Google の完全なアプリ互換性スイートを実行することで判断しています。
Android O の seccomp フィルタは、swapon/swapoff などの一部のシステムコールをブロックします。これらは、いくつかのセキュリティ攻撃や重要な制御用システムコールで使われることがありますが、アプリではあまり使われることはありません。このフィルタは合計で、arm64 では 271 のうち 17 のシステムコール、arm では 364 のうち 70 のシステムコールをブロックします。

デベロッパー

Android O を実行している端末でアプリをテストし、禁止されているシステムコールを使っていないかを確認してください。

禁止されているシステムコールの検出

Android O で禁止されているシステムコールを使おうとすると、システムがアプリをクラッシュさせます。ログには、禁止されているシステムコールが出力されます。次に例を示します。
03-09 16:39:32.122 15107 15107 I crash_dump32: performing dump of process 14942 (target tid = 14971)
03-09 16:39:32.127 15107 15107 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-09 16:39:32.127 15107 15107 F DEBUG : Build fingerprint: 'google/sailfish/sailfish:O/OPP1.170223.013/3795621:userdebug/dev-keys'
03-09 16:39:32.127 15107 15107 F DEBUG : Revision: '0'
03-09 16:39:32.127 15107 15107 F DEBUG : ABI: 'arm'
03-09 16:39:32.127 15107 15107 F DEBUG : pid: 14942, tid: 14971, name: WorkHandler >>> com.redacted <<<
03-09 16:39:32.127 15107 15107 F DEBUG : signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
03-09 16:39:32.127 15107 15107 F DEBUG : Cause: seccomp prevented call to disallowed system call 55
03-09 16:39:32.127 15107 15107 F DEBUG : r0 00000091 r1 00000007 r2 ccd8c008 r3 00000001
03-09 16:39:32.127 15107 15107 F DEBUG : r4 00000000 r5 00000000 r6 00000000 r7 00000037
影響を受けるデベロッパーは、禁止されているシステムコールを呼ばないようにアプリを改修する必要があります。

テスト時の seccomp フィルタの切り替え

エラーのロギング以外にも利用できる機能があります。seccomp インストーラは、userdebug および eng ビルドが実行されている端末で setenforce に従います。これを使うと、問題を起こしているのが seccomp であるかどうかをテストができます。次のコマンドを実行すると、
adb shell setenforce 0 && adb stop && adb start
zygote に seccomp ポリシーはインストールされません。実行中のプロセスから seccomp ポリシーを削除することはできないため、このオプションを反映するにはシェルを再起動する必要があります。

端末メーカー

Android O には、//bionic/libc/seccompに関連する seccomp フィルタが含まれています。そのため、端末メーカーが追加で実装する必要はありません。ただし、//cts/tests/tests/security/jni/android_security_cts_SeccompTest.cppには、seccomp をチェックする CTS テストが配置されています。このテストは、add_keyおよび keyctlシステムコールがブロックされていること、また openatや、互換性のために必要となるいくつかのアプリ固有のシステムコールが許可されていることをチェックします。


Reviewed by Yuichi Araki - Developer Relations Team

Android Testing Support Library 1.0 が登場!

$
0
0
この記事は Google モバイル ニンジャ チーム、Michael Amygdalidis、Stephan Linzner、Nick Korostelev による Android Developers Blog の記事 "Android Testing Support Library 1.0 is here!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 
 

Android Testing Support Library(ATSL)バージョン 1.0 がリリースされました。  
 
ATSL バージョン 1.0 は既存のテスト API のメジャー アップデートで、たくさんの新機能、パフォーマンスの改善、安定化、バグ修正が含まれています。サポート終了となった Android プラットフォームのテスト API と同等の機能もすべて提供されています。今回のリリースには、マルチプロセス Espressoのネイティブ サポートや、Android Test Orchestratorなど、Google I/O 2017のセッションでお話しした多くの機能も追加されています。  
 
うれしいことに、ATSL はバージョン 1.0 より、Google の Maven レポジトリで公開されるようになりますので、皆さんのビルドで簡単に使っていただけるようになります。このレポジトリの詳しい利用方法については、Google Maven レポジトリ利用ガイドをご覧ください。なお、今後はプラットフォームのアップデートにテスト用インフラストラクチャのアップデートは含まれなくなりますので、ご注意ください。まだテストを ATSL にアップグレードしていない方は、ぜひこのタイミングでアップグレードしましょう。  
 
もう一点、Android のテスト ドキュメントの大規模な改訂についてもお知らせします。古いテスト ドキュメントは、GitHub ウェブサイトから developers.android.com/testingに移行されており、すべてのテスト ドキュメントが 1 か所で参照できるようになりました。そのため、Android でテストを書いたり実行したりする方法を調べやすくなっています。  
 
それでは皆様お待ちかねの、今回のリリースで提供される新しい API の概要とツールについてご説明します。  
 

Espresso の改善


Espresso 3.0.0には、すばらしい新機能が搭載され、全般的なパフォーマンスが改善されています。主な機能として、マルチプロセス Espresso、アイドリング レジストリ、新しいアイドリング リソースなどがあります。これらの新機能についてさらに深く掘り下げてゆきましょう。  
 
マルチプロセス Espresso 
 
Android O以降では、アプリのデフォルト プロセス外の計測テストがプラットフォームでサポートされています(Android O より前は、アプリのデフォルト プロセスでアプリのコンポーネントをテストすることしかできませんでした)。マルチプロセス Espresso は、そのテストを可能にします。これは、Espresso による同期を保証しつつ、プロセス境界をまたいだアプリの UI インタラクションのテストをシームレスに実行できるようにするものです。  
 
うれしい点は、Espresso がすべての作業を行ってくれることです。設定を一切変更せずに、UI を複数プロセスで操作できます。Espresso テストは、単一プロセスのアプリと同じように記述できます。Espresso が自動的にプロセスの IPC を処理し、プロセス間の同期をとってくれます。  
 
次の図は、Espresso の複数のインスタンスがお互いに通信する仕組みを示しています。  

マルチプロセス Espresso の詳細や使用方法を知りたい方は、ドキュメントマルチプロセスのサンプルをご覧ください。  
 
アイドリング レジストリ 
 
アプリの中には、Gradle のビルド フレーバーや Dagger などの依存性注入フレームワークを使ってアイドリング リソースを登録するテストビルド設定を生成しているものもあるでしょう。また、アクティビティを通して単純にアイドリング リソースを公開しているアプリもあるでしょう。こういったアプローチで問題になるのは、開発ワークフローが複雑になり、カプセル化が破られてしまう場合があることです。Espresso の最新リリースでは、アプリのコードからのアイドリング リソースの登録が簡単になっています。これは、新しい IdlingRegistry API を使って実現されています。IdlingRegistryは、Espresso ライブラリ全体を取り込まずに使える軽量レジストリです。そのため、アプリのコードから簡単にリソースの登録を行うことができます。この API をマルチプロセス Espresso と組み合わせると、アプリのコード内の任意のプロセスからアイドリング リソースを登録できます。  
 
Espresso クラスから登録を行う機能は、サポート対象外となっています。  
 
アイドリング リソース 
 
カスタムのアイドリング リソースの記述は時間がかかるものです。そのため、Espresso 3.0.0 には、スレッドの同期を行う際に簡単に利用できるさまざまなアイドリング リソースが搭載されています。新しく追加されたリソースには、IdlingThreadPoolExecutorIdlingScheduledThreadPoolExecutorなどがあります。今後も、さらに追加される予定です。

新しいアイドリング リソースを活用するには、新しく追加された次の依存関係を build.gradle ファイルに追加します。  
  androidTestCompile "com.android.support.test.espresso.idling:idling-concurrent:3.0.0"

さらに、今回のリリースでは、以前に Espresso の contrib パッケージでサポート対象外となっていた CountingIdlingResourceが削除されています。そのため、Espresso のアイドリング リソースに配置されている新しい CountingIdlingResourceのパッケージを使ってテストをアップデートする必要があります。詳しい移行方法については、リリースノートをご覧ください。  
 

ProviderTestRule


ContentProviderオブジェクトをテストする場合は、ProviderTestCase2の代わりに ProviderTestRuleを使うことができます。ProviderTestRuleでは、現在 AndroidJUnit4 で利用できる他のテストルールと簡単に連携できる方法が提供されています。  
 
ProviderTestRuleには、初期化用 API や、テストの際に ContentProviderに対して実行するコマンドが含まれています。SQLite データベースに基づく ContentProviderを使っている場合は、ProviderTestRuleコマンドを使ってデータベース ファイルや初期化コマンドを設定できます。  
 
詳細については、ProviderTestRuleのドキュメントをご覧ください。  

パーミッション付与ルール


Android M(API レベル 23)では、実行時にアプリがパーミッションをリクエストできるようになっています。ただし、実行時にパーミッションをリクエストするダイアログによって、テストが継続できない状態になり、結果としてテストが失敗する場合があります。GrantPermissionRuleを使うと、ダイアログのポップアップを完全にスキップし、ユーザーが実行時にアプリにパーミッションを与えた状態をシミュレートすることができます。  

Android Test Orchestrator


通常、AndroidJUnitRunner は、同じ計測プロセスのすべてのテストを実行しますが、これによってさまざまな問題が起こることがあります。たとえば、複数のテストがメモリ内で状態を共有している場合、1 つのテストがクラッシュすると、残りのテストスイートが実行できなくなります。  
 
連続して複数の adbコマンドを発行すれば、別々にテストを行うこともできますが、ホスト側の処理の負荷が増加することになります。新しい Android Test Orchestrator を使うと、次の図のように、端末上でテストを完全に分離することができます。  

ただし、テストが成功するために状態を共有することが 必要な場合、Orchestrator を使うとテストが失敗することになります。この動作は、意図的なものです。本投稿の執筆時点で、Android Test Orchestrator はベータ版であり、コマンドラインから利用するものとなっています。近日中には、Firebase Test Lab と Android Studio への統合が行われる予定です。  
 
詳細については、Android Testing Orchestrator デベロッパー ガイドをご覧ください。  

AndroidJUnitRunner


AndroidJUnitRunner にも、次のような追加機能が搭載されています。  
  • JUnitParamsが利用可能になりました。
  • Runner の引数を使ってクラスローダとカスタム JUnit テストフィルタの設定を行えるようになりました。

テスト ワークフローの一環として、暫定的に作成、設定したアクティビティのテストを行いたい場合もあるでしょう。そのような場合に、InterceptingActivityFactoryを使って MonitoringInstrumentation(さらに、拡張機能として AndroidJUnitRunner)を設定できるようになっています。テストの際には、コンパイル時のインジェクションに依存せずに、テスト固有の設定のアクティビティを作成できます。  
 
本投稿で紹介した概要は、ATSL に対するもっとも重要な変更点のほんの一部を紹介したものです。知っておくべき変更点は、まだ他にもたくさんあります。詳しいリリース内容については、リリースノートをご覧ください。  
 
最後になりますが、今回リリースされた機能に貢献してくださったすべてのデベロッパーの皆さん、どうもありがとうございます。また、私たちに協力し、Android Testing Support Library のプレリリース版に貴重なフィードバックをお寄せくださった American Express モバイル エンジニアリング チームの Android テストのエキスパート、Slack、GDE の Chiu-Ki Chan に感謝いたします。  
 
ATSL チームは、皆さまのテストの成功をお祈りしています。  
 
 

Reviewed by Yuichi Araki - Developer Relations Team

Google Drive の監査ログでアプリの利用状況を特定

$
0
0
この記事は Google Drive プロダクト マネージャー、Rio Akasaka、G Suite デベロッパー アドボケート、Wesley Chun(@wescpy)による G Suite Developers Blog の記事 "Identifying app usage in your Google Drive audit logs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

G Suite 管理者(または管理者向けのアプリを作っているデベロッパー)にとって重要なのは、企業で社員が使っているさまざまなアプリやそのアクセス状況について理解しておくことです。本日は、それを簡単に行うために、Admin SDK の Reports APIを使って Google Drive の監査ログ内のアプリ ID(originating_app_id)を取得する方法を紹介します。

現在、Drive Android アプリ、Drive iOS アプリ、Google Chrome、あるいは Google Drive のファイルを利用、変更、作成するさまざまなサードパーティ製アプリ(Smartsheet や Asana など)のうち、ログに記録されたユーザーのアクティビティの実行元をアプリで判別できます。これによって、組織内で利用されているアプリやその利用頻度、利用状況について詳しく把握できます。

ログに表示される App ID は数値である点に注意してください。アプリ名を取得したい場合は、Google Drive REST APIを使って別のリクエストを行う必要があります。Drive のアクティビティ リクエストを通じてすでに情報を取得している場合は、ログに originating_app_id が表示されているはずです。この情報を問い合わせる際に利用できる 2 つの HTTP リクエストを次に示します。

GET 
https://www.googleapis.com/admin/reports/v1/activity/users/userKey

または
GET 
https://www.googleapis.com/admin/reports/v1/activity/users/all/applications/drive

この新機能の詳細については、ドキュメントをご覧ください。皆さんや他の G Suite 管理者がドメイン内のアプリの利用状況を詳しく理解できるように、ぜひこの機能をコードに組み込んでみてください。皆さんが作るアプリを楽しみにしています。


Reviewed by Eiji Kitamura - Developer Relations Team
Viewing all 2206 articles
Browse latest View live