暗号化のサポートは、Android エコシステム全体でも強化されています。Marshmallow 以降、すべての対応端末は暗号化のサポートが必須になっています。Nexus 5X や 6P のような多くの端末でも、ARM TrustZone などの信頼できるハードウェアからのみアクセス可能な一意なキーが使われています。7.0 Nougat では、すべての新しい Android 対応端末でこういった種類のキー ストレージのハードウェア サポートが必須となっています。これによって、総当たり攻撃に対する保護を提供しつつ、キーが使用される前にロック画面で資格情報を検証するようになっています。以上のような仕組みによって、すべてのデータは自分の端末上で本人によってしか復号化できないようになっています。
メディア スタックとプラットフォームの強化
Android Nougat では、メディアサーバーの
再構築 と強化が行われています。メディアサーバーは、信頼されていない入力を処理する主要なシステム サービスの 1 つです。まず、Clang の
UndefinedBehaviorSanitizer の一部である整数オーバーフローの無害化を取り入れることによって、報告されている libstagefright のバグの大半を占む、あらゆる種類の脆弱性を防止しました。整数オーバーフローを検知すると、攻撃を防ぐためにプロセスをシャットダウンします。さらに、メディア スタックをモジュール化して各コンポーネントを個々のサンドボックスに入れ、各サンドボックスの権限を厳格化して、ジョブの実行に最低限必要な権限のみを持たせるようにしました。この封じ込め技術によって、攻撃者がスタックの多くの部分の欠陥をついて取得できる権限は非常に小さなものになり、カーネルの攻撃対象領域も大幅に削減されています。
メディアサーバーの強化に加え、次のようなさまざまなプラットフォームの保護機能も追加されています。
セキュアブート : セキュアブートが厳格に適用されるようになり、問題のある端末がブートできなくなります。さらに、エラー訂正 によって、悪意のないデータの破損に対する信頼性が向上しています。
SELinux : SELinux の設定がアップデートされ、Seccomp の対象範囲が増加しています。それによって、アプリケーション サンドボックスが厳重に保護され、攻撃対象領域がさらに少なくなります。
ライブラリの読み込み順序のランダム化と ASLR の改善 : ランダム性が増加することによって、ある種のコード再利用攻撃は難しくなります。
カーネルの強化 カーネルメモリの一部を読み取り専用とマーク することで、新しいカーネルにメモリ保護を追加し、カーネルがユーザースペースのアドレスにアクセスすることを制限 します。これによって、既存の攻撃対象領域がさらに減少します。
APK 署名スキーム v2 検証速度 の改善と整合性の保証の強化を図るファイル全体の署名スキームが導入されました。
アプリのセキュリティ改善
Android Nougat は、アプリのデベロッパーにとって最も安全で最も簡単に使える Android のバージョンです。
別のアプリとデータを共有したいアプリは、FileProvider などのコンテンツ プロバイダ を通してファイルを提供することにより、明示的にオプトインする必要があります。API レベル 24 以上を対象にしたアプリでは、アプリのプライベート ディレクトリ（通常は /data/data/）の Linux パーミッションが 0700 になります。
アプリがセキュアなネットワーク トラフィックへのアクセスを簡単に制御できるように、API レベル 24 以上では、ユーザーがインストールした証明機関と Device Admin API によってインストールされた証明機関は、デフォルトで信頼されなくなります 。さらに、すべての新しい Android 端末は、同じ信頼される証明機関 を搭載した状態で出荷される必要があります。
ネットワーク セキュリティ構成 によって、デベロッパーは宣言型設定ファイルを使って今まで以上にネットワーク セキュリティ ポリシーを簡単に設定できます。これには、クリアテキスト トラフィックのブロック、信頼される証明機関や証明書の設定、個別のデバッグ設定が含まれます。
さらに、有害な可能性があるアプリからユーザーを保護するために、アプリのパーミッションや機能の改善が継続されています。
端末のプライバシー保護のため、MAC アドレスなどの永続的に端末を識別できる情報へのアクセスをさらに制限または廃止しています。
パーミッション ダイアログ上にユーザー インターフェース オーバーレイを表示することはできなくなっています。この「クリックジャック」技術は、いくつかのアプリで不正にパーミッションを取得するために使われていました。
ロック画面を設定している場合、そのロック画面を変更できないように端末管理アプリの能力を低下させました。また、端末管理者を無効化する際の onDisableRequested() による通知は受けられなくなります。これは、いくつかのランサムウェアが端末を制御するために使用した方法でした。
システム アップデート
また、OTA アップデート システムが大幅に拡張され、最新のシステム ソフトウェアとセキュリティ パッチによって端末を最新の状態に保つ方法がはるかに簡単になっています。OTA のインストール時間を大幅に短縮し、セキュリティ アップデートの OTA サイズも小さくなっています。アップデート プロセスの中でも特に時間がかかるアプリの最適化ステップを待つ必要はなくなりました。これは、インストールとアップデートを高速に行えるように新しい JIT コンパイラーが
最適化 されたためです。
ファームウェアがアップデートされた Nougat を実行している新しい Android 端末では、アップデートがさらに高速に行えるようになっています。Chromebook と同様に、アップデートは端末が通常どおり実行されている間にバックグラウンドで適用されます。アップデートは別のシステム パーティションに適用され、再起動した際に新しいバージョンのシステム ソフトウェアを実行しているパーティションにシームレスに切り替わります。
Google は Android のセキュリティ改善のための作業を続けており、Android Nougat はあらゆる面で大幅なセキュリティ改善が図られています。いつものように、作業に対するフィードバックや Android の改善提案は大歓迎です。
[email protected] までご連絡ください。
Posted by
Yuichi Araki - Developer Relations Team
[この記事は Xiaowen Xin、Android セキュリティ チームによる Android Developers Blog の記事 "Keeping Android safe: Security enhancements in Nougat " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
脆弱性報奨金プログラム 、新しいダイレクト ブート モード、メディアサーバーの再構築、メディア スタックの強化 、意図しないクリアテキスト トラフィックに逆行 するアプリの保護、Android が信頼される証明機関 を取り扱う方法の更新、セキュアブート の厳格な適用とエラー訂正、攻撃対象領域を減らしてメモリ保護を強化するための Linux カーネルの更新 などがあげられます。すばらしいですね！
ダイレクト ブートと暗号化
以前のバージョンの Android では、端末を暗号化しているユーザーは、デフォルトで PIN / パターン / パスワードのいずれかを使用する必要がありました。これは、ブートプロセスでストレージ領域を復号化してブートを完了するために必要な操作でした。Android 7.0 Nougat では、基礎となる暗号化スキームがアップデートされ、ブートプロセスが効率化されているため、スマートフォンを高速に再起動できるようになっています。スマートフォンの主な機能である電話アプリやアラーム クロックは、PIN を入力する前であっても即座に利用できるようになります。そのため、PIN を入力しなくても電話を受けたり目覚ましを鳴らしたりできます。この機能は、ダイレクト ブート と呼ばれています。
メディア スタックとプラットフォームの強化
Android Nougat では、メディアサーバーの再構築 と強化が行われています。メディアサーバーは、信頼されていない入力を処理する主要なシステム サービスの 1 つです。まず、Clang の UndefinedBehaviorSanitizer の一部である整数オーバーフローの無害化を取り入れることによって、報告されている libstagefright のバグの大半を占む、あらゆる種類の脆弱性を防止しました。整数オーバーフローを検知すると、攻撃を防ぐためにプロセスをシャットダウンします。さらに、メディア スタックをモジュール化して各コンポーネントを個々のサンドボックスに入れ、各サンドボックスの権限を厳格化して、ジョブの実行に最低限必要な権限のみを持たせるようにしました。この封じ込め技術によって、攻撃者がスタックの多くの部分の欠陥をついて取得できる権限は非常に小さなものになり、カーネルの攻撃対象領域も大幅に削減されています。
セキュアブート : セキュアブートが厳格に適用されるようになり、問題のある端末がブートできなくなります。さらに、エラー訂正 によって、悪意のないデータの破損に対する信頼性が向上しています。
SELinux : SELinux の設定がアップデートされ、Seccomp の対象範囲が増加しています。それによって、アプリケーション サンドボックスが厳重に保護され、攻撃対象領域がさらに少なくなります。
ライブラリの読み込み順序のランダム化と ASLR の改善 : ランダム性が増加することによって、ある種のコード再利用攻撃は難しくなります。
カーネルの強化 カーネルメモリの一部を読み取り専用とマーク することで、新しいカーネルにメモリ保護を追加し、カーネルがユーザースペースのアドレスにアクセスすることを制限 します。これによって、既存の攻撃対象領域がさらに減少します。
APK 署名スキーム v2 検証速度 の改善と整合性の保証の強化を図るファイル全体の署名スキームが導入されました。
アプリのセキュリティ改善
Android Nougat は、アプリのデベロッパーにとって最も安全で最も簡単に使える Android のバージョンです。
別のアプリとデータを共有したいアプリは、FileProvider などのコンテンツ プロバイダ を通してファイルを提供することにより、明示的にオプトインする必要があります。API レベル 24 以上を対象にしたアプリでは、アプリのプライベート ディレクトリ（通常は /data/data/）の Linux パーミッションが 0700 になります。
アプリがセキュアなネットワーク トラフィックへのアクセスを簡単に制御できるように、API レベル 24 以上では、ユーザーがインストールした証明機関と Device Admin API によってインストールされた証明機関は、デフォルトで信頼されなくなります 。さらに、すべての新しい Android 端末は、同じ信頼される証明機関 を搭載した状態で出荷される必要があります。
ネットワーク セキュリティ構成 によって、デベロッパーは宣言型設定ファイルを使って今まで以上にネットワーク セキュリティ ポリシーを簡単に設定できます。これには、クリアテキスト トラフィックのブロック、信頼される証明機関や証明書の設定、個別のデバッグ設定が含まれます。
端末のプライバシー保護のため、MAC アドレスなどの永続的に端末を識別できる情報へのアクセスをさらに制限または廃止しています。
パーミッション ダイアログ上にユーザー インターフェース オーバーレイを表示することはできなくなっています。この「クリックジャック」技術は、いくつかのアプリで不正にパーミッションを取得するために使われていました。
ロック画面を設定している場合、そのロック画面を変更できないように端末管理アプリの能力を低下させました。また、端末管理者を無効化する際の onDisableRequested() による通知は受けられなくなります。これは、いくつかのランサムウェアが端末を制御するために使用した方法でした。
システム アップデート
また、OTA アップデート システムが大幅に拡張され、最新のシステム ソフトウェアとセキュリティ パッチによって端末を最新の状態に保つ方法がはるかに簡単になっています。OTA のインストール時間を大幅に短縮し、セキュリティ アップデートの OTA サイズも小さくなっています。アップデート プロセスの中でも特に時間がかかるアプリの最適化ステップを待つ必要はなくなりました。これは、インストールとアップデートを高速に行えるように新しい JIT コンパイラーが最適化 されたためです。
security@android.com までご連絡ください。
Yuichi Araki - Developer Relations Team
Parul Soi
Developer Relations プログラム マネージャー
データを分析して適切な対応ができるかどうかによって、会社が成功するか失敗するかが決まる場合もあります。過去数年間、この分析するデータは大きく拡大し、それに関わるアプリ デベロッパーの数もトラッキングされるイベントの数も増え続けています。しかし、データが多すぎて何を探しているか自分でもわからなくなることが多いのが実情です。
では、製品を改善するためにどのような指標をトラッキングすればよいのでしょうか。
データ分析は非常に大きな分野であり、世界中でいくつかもの人気のある手法やフレームワークが使われています。特に技術製品に関連する分野で人気のあるフレームワークの 1 つが Pirate Metrics です。この用語は、500 Startups の設立者である Dave McClure が生み出したものです。この手法は製品ユーザーのライフサイクルをシンプルにかつ明細に表しているため、世界中のプロダクト マネージャーやグロース ハッカーの人気を集めています。
本投稿では、Pirate Metrics を構成する 5 つの指標を紹介し、その重要性について考えてみます。本シリーズの以降の投稿では、Firebase 製品を使ってこれらの指標を向上させ、製品をさらに魅力なものにする方法について考える予定です。
ステージ 1
どんな製品でも、ユーザー ライフサイクルの最初の要素は
ユーザー獲得 です。これは、ユーザーが皆さんのアプリをインストールするということです。ユーザーの獲得はさまざまな方法で行うことができます。これには、ソーシャル メディア マーケティング、App Store の最適化、検索、ニュース、コンテンツ マーケティングなど、あるいは広告などの手法があります。
ステージ 2
ユーザーを獲得することができたとしても、仕事はまだ半分も終わっていません。次は、ユーザーが手元に置いておくべきアプリであることを確信してもらう必要があります。そのためには、アプリが特別なものであるということを経験してもらい、ユーザーを
活性化 させる必要があります。たとえば、ゲームであればユーザーにトレーニング レベルを終えてもらうこと、写真フィルタアプリであれば、1 つの画像で実験してもらうことがこれに当たるでしょう。
ステージ 3
ほとんどの製品にとって、最大の難関となるのが獲得したユーザーを
維持 することです。
一般的なユーザーが毎日使っているのは、インストールしているアプリのわずか 26% です。ユーザーは、数日でアプリをアンインストールしたり、単にダウンロードしたことを忘れてしまう傾向があります。新しい健全な製品にとっての目標は、それを維持する戦略を見つけてリピート率を上げることです。
ステージ 4
また、ユーザーには最大のサポーターになってもらいたいと思うでしょう。
紹介 キャンペーンほど強力な獲得戦略はありません。製品を気に入ったユーザーは、友人にも試してみるよう心から勧めたくなります。もちろん、皆さんはユーザーにそうしてもらいたいと思うでしょう。それにはユーザーを阻害するような要素は取り除く必要があります。
ステージ 5
最終的に、企業を拡大させ、さらに多くのユーザーを獲得できるよう、アプリを
収益化 します。
この
獲得 、
活性化 、
維持 、
紹介 、
収益化 という 5 つのステージは、まとめて Pirate Metrics と呼ばれています。これはかなり汎用的で、ほとんどのデジタル製品に適用できます。プロダクト マネージャーは、これらの指標をトラッキングするためにさまざまなツールを使用しています。しかし、新しい
Firebase を使うと、各指標を 1 か所でトラッキングできるだけでなく、それを向上させることができるさまざまなツールを活用することもできます。
この点については、今後の投稿で紹介します。ご期待ください。
Posted by
Takuo Suzuki - Developer Relations Team
[この記事は Parul Soi、Developer Relations プログラム マネージャーによる The Firebase Blog の記事 "The Firebase Blog: Pirate Metrics (AARRR) with Firebase " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Parul Soi
Developer Relations プログラム マネージャー
ステージ 1
ユーザー獲得 です。これは、ユーザーが皆さんのアプリをインストールするということです。ユーザーの獲得はさまざまな方法で行うことができます。これには、ソーシャル メディア マーケティング、App Store の最適化、検索、ニュース、コンテンツ マーケティングなど、あるいは広告などの手法があります。
ステージ 2
活性化 させる必要があります。たとえば、ゲームであればユーザーにトレーニング レベルを終えてもらうこと、写真フィルタアプリであれば、1 つの画像で実験してもらうことがこれに当たるでしょう。
ステージ 3
維持 することです。一般的なユーザーが毎日使っているのは、インストールしているアプリのわずか 26% です。ユーザーは、数日でアプリをアンインストールしたり、単にダウンロードしたことを忘れてしまう傾向があります。新しい健全な製品にとっての目標は、それを維持する戦略を見つけてリピート率を上げることです。
ステージ 4
紹介 キャンペーンほど強力な獲得戦略はありません。製品を気に入ったユーザーは、友人にも試してみるよう心から勧めたくなります。もちろん、皆さんはユーザーにそうしてもらいたいと思うでしょう。それにはユーザーを阻害するような要素は取り除く必要があります。
ステージ 5
収益化 します。
獲得 、活性化 、維持 、紹介 、収益化 という 5 つのステージは、まとめて Pirate Metrics と呼ばれています。これはかなり汎用的で、ほとんどのデジタル製品に適用できます。プロダクト マネージャーは、これらの指標をトラッキングするためにさまざまなツールを使用しています。しかし、新しい Firebase を使うと、各指標を 1 か所でトラッキングできるだけでなく、それを向上させることができるさまざまなツールを活用することもできます。
Takuo Suzuki - Developer Relations Team
動作の仕組み
これは、JavaScript 用に Closure Compiler を書き換えたものではなく、Node や古いブラウザでも実行できるように Java ソースを JS にコンパイルしたものです。Closure Compiler についてのすべての投稿やリソースは、このバージョンにも適用されます。
Closure Compiler の内部についての詳細は、Google の Closure チームの一員である
Dimitris によるこの投稿 や
Closure Tools ブログの投稿、
Closure についての説明 やそれがどのようにプロジェクトに役立つかを説明した 2016 年の投稿をご覧ください。
なお、JS 版は試験運用版であることにご注意ください。まだネイティブ Java 版とは同じように動作しない可能性がありますが、私たちはコンパイラー ファミリーへの興味深い追加機能であると考えています。Closure チームは今後も改善とサポートを継続する予定です。
使用方法
JS 版の Closure Compiler をプロジェクトに含めるには、NPM を使ってプロジェクトに依存性を追加する必要があります。
npm install --save-dev google-closure-compiler-js
次に、
Gulp でコンパイラーを使用するために、次のようなタスクを追加します。
const compiler = require('google-closure-compiler-js').gulp();
gulp.task('script', function() {
// select your JS code here
return gulp.src('./src/**/*.js', {base: './'})
.pipe(compiler({
compilation_level: 'SIMPLE',
warning_level: 'VERBOSE',
output_wrapper: '(function(){\n%output%\n}).call(this)',
js_output_file: 'output.min.js', // outputs single file
create_source_map: true
}))
.pipe(gulp.dest('./dist'));
});
google-closure-compiler （動作には Java が必要です）から移行する場合、
gulp.src() またはそれに代わる機能を使ってコンパイル前に JavaScript を読み込む必要があります。
詳細については、
使用方法 、
サポートされているフラグ 、
デモ プロジェクト をご確認ください。現在利用可能な試験運用版では、Java リリースのすべてのフラグがサポートされているわけではありませんが、何か見逃していることがあった場合には、このコンパイラーが例外を通して教えてくれるでしょう。
Posted by
Eiji Kitamura - Developer Relations Team
[この記事は Sam Thorogood 、デベロッパー プログラム エンジニアによる Google Developers Blog の記事 "Closure Compiler in JavaScript " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
2009 年 に元は Java でリリースされました。本日は、まったく同じ Closure Compiler がピュア JavaScript で Java を使わずに利用できることになったことをお知らせします。この仕組みは NodeJS 環境で実行するように設計されており、いくつかのよく使われているビルドツールをサポートしています。
Google Developers をご覧ください。
動作の仕組み
これは、JavaScript 用に Closure Compiler を書き換えたものではなく、Node や古いブラウザでも実行できるように Java ソースを JS にコンパイルしたものです。Closure Compiler についてのすべての投稿やリソースは、このバージョンにも適用されます。
Dimitris によるこの投稿 や Closure Tools ブログの投稿、Closure についての説明 やそれがどのようにプロジェクトに役立つかを説明した 2016 年の投稿をご覧ください。
使用方法
JS 版の Closure Compiler をプロジェクトに含めるには、NPM を使ってプロジェクトに依存性を追加する必要があります。
npm install --save-dev google-closure-compiler-js
Gulp でコンパイラーを使用するために、次のようなタスクを追加します。
const compiler = require('google-closure-compiler-js').gulp();
gulp.task('script', function() {
// select your JS code here
return gulp.src('./src/**/*.js', {base: './'})
.pipe(compiler({
compilation_level: 'SIMPLE',
warning_level: 'VERBOSE',
output_wrapper: '(function(){\n%output%\n}).call(this)',
js_output_file: 'output.min.js', // outputs single file
create_source_map: true
}))
.pipe(gulp.dest('./dist'));
});
google-closure-compiler （動作には Java が必要です）から移行する場合、gulp.src() またはそれに代わる機能を使ってコンパイル前に JavaScript を読み込む必要があります。使用方法 、サポートされているフラグ 、デモ プロジェクト をご確認ください。現在利用可能な試験運用版では、Java リリースのすべてのフラグがサポートされているわけではありませんが、何か見逃していることがあった場合には、このコンパイラーが例外を通して教えてくれるでしょう。
Eiji Kitamura - Developer Relations Team
Doug Stevenson
デベロッパー アドボケート
多くのデベロッパーの皆様に Firebase を試していただいていることをとてもうれしく思っています。試用環境を本番環境に移行した方もいらっしゃるでしょう。その中で、Android プロジェクトのビルドをどう管理すればよいかについて疑問に思った方もいらっしゃるかもしれません。一番よくある質問は、こんなものではないでしょうか。
「毎日の開発データとリリースデータを分けるには、どうすればよいでしょうか？」
分析を行う際には、
実際 のアプリの利用データ（開発時の
人為的 な利用ではないもの）のみを反映させたいと誰もが思うでしょう。また、日々の開発でのクラッシュ データと、公開されているリリース版のクラッシュ データが混在していては不便です。何よりも、開発チームが拡大してアプリが複雑になると、お互いの作業が衝突しないように、各チームメンバーの作業環境を個々のサンドボックスに分割したいと考えるはずです。
ここでは、プロジェクトを設定してこういった状況に対応する方法をいくつか考えてみます。Android でアプリをビルドする場合、もっとも好まれる方式は Android Gradle プラグインの設定機能を活用することです。これは、
Firebase コンソール のいくつかの設定と合わせて適用されます。
その設定について説明する前に、まずはいくつかの用語を整理しておきましょう。今回使用する用語は、次のとおりです。
Firebase プロジェクト
[Firebase コンソール] のトップレベルで作成するプロジェクトです。作成したプロジェクトは、カード形式で表示されます。 Firebase アプリ
Firebase プロジェクト内に作成するアプリです。Firebase プロジェクトには、いくつでも Android アプリや iOS アプリを含めることができます。プロジェクトに含まれているアプリはホーム画面に表示され、同じ設定を共有します。また、異なる設定も持っています（この点は後ほど詳しく説明します）。 Android Gradle ビルドタイプ
Android Gradle プラグインはビルド時にアプリの設定を行い、その際にビルドタイプが定義されます。ビルドタイプには、デフォルトで「debug」と「release」の 2 種類があります。この設定は buildTypes ブロックで行われており、必要に応じてビルドタイプを追加することもできます。debug タイプは日々のデプロイ用、release タイプはユーザーへの配布用の設定です。 Android Gradle ビルド フレーバー
ビルド時に Android アプリを設定する際に、オプションで「ビルド フレーバー」を割り当てることができます。これはビルドタイプとほぼ同じですが、ビルド フレーバーを使うと必要に応じてさらに細かい設定を行うことができます。たとえば、ほとんどの機能が同じで、アプリケーション ID や有効にする機能のみが異なる「無償」版と「有償」版の両方のアプリをビルドすることができます。 Android Gradle ビルド バリアント
ビルド バリアント は、ビルドタイプとビルド フレーバーの固有の組み合わせです。アプリのビルド設定では、タイプとフレーバーのそれぞれの組み合わせについて、必ずバリアントが 1 つだけ存在します。たとえば、debug と release というタイプを設定しており、「free」と「paid」というフレーバーを設定している場合、Android Gradle プラグインは「debug/free」、「debug/paid」、「release/free」、「release/paid」という組み合わせのバリアントを生成します。コードからビルドした APK は、必ず 1 つだけバリアントを持っています。Android アプリケーション ID
アプリを一意に識別する文字列の識別子です。Play ストアで公開する際、他のアプリと重複しない一意の値になっている必要があります。通常は、「com.company.project」のように Java パッケージ名形式のフォーマットを使用します。 Firebase 対応のアプリを効果的に設定する際に重要になる考え方があります。それは、個別のデータ コレクションが必要になるアプリのビルド バリアントごとに固有のアプリケーション ID を割り当てることです。 それには、最初にアプリの build.gradle を設定し、次に Firebase コンソールでミラーの設定を行います。しかし、アプリに最適な設定を決めるためには、プロジェクトとアプリの間で Firebase の各機能がどのように動作しているかについてもう少し知っておく必要があります。
Firebase 機能ごとのデータスコープ
Firebase の機能の中には、同じプロジェクト内のすべてのアプリ（Android、iOS、ウェブ）間で
データを共有 するものもあります。これらの機能のデータの「スコープ」は、Firebase プロジェクト全体であると言え、次の機能が該当します。
また、Firebase の機能の中には、同じプロジェクト内のすべてのアプリで
独立してデータ を持つものもあります。これらの機能のスコープは、Firebase プロジェクトの個々のアプリであると言え、次の機能が該当します。
Analytics と Crash Reporting のダッシュボードの上部には、アプリのセレクターがあることにお気づきでしょう。ここから、データを参照したい（プロジェクトで作成されている）個々のアプリを選択できます。
アプリ セレクターが表示されている Analytics ダッシュボード
Firebase の機能の中には、ハイブリッドなスコープを持つものもあります。次の機能では、特定の操作の対象とするアプリの数を自由に選択できます。
Remote Config は、プロジェクト内のアプリ間で異なる値を設定することができますが、デフォルトではすべてのアプリに同じ値が設定されます。
Notifications は、コンソールで選択したプロジェクト内の 1 つまたは複数のアプリを対象にできます。
Dynamic Links は、1 つの Android および / または 1 つの iOS アプリが対象になります。
どちらを対象にするかは、現在のプラットフォームに基づいてリンク自身が判断します。
Firebase Test Lab for Android は特殊なケースです。この機能には課金が有効になったプロジェクトが必要ですが、1 つのプロジェクトという制約はなく、任意の APK を対象にすることができます。そのため、無償プランで Firebase の開発を行いつつ有償プランの Test Lab で APK をテストしたい場合は、Test Lab 専用のまったく新しいプロジェクトを作成し、課金を有効にすることをお勧めします。Firebase 統合の有無に関わらず、このプロジェクトでどのようなアプリでもテストできます。
仕組みがわかったところで、現実的ないくつかの実例を見てみましょう。いくつかの設定用レシピも紹介します。この中の 1 つ、あるいはこの中の方法を組み合わせることによって、状況に最適な方式が見つかるでしょう。
小規模チームとシンプルなアプリ
個人デベロッパーや小規模なチームの場合、アプリはかなりシンプルなはずです。そのため、アナリティクスと障害レポートで日々のデバッグと公開リリースビルドを分けるだけで済みます。このケースでは、デバッグとリリースで別のアプリケーション ID を持つことができるようにアプリを設定すれば十分です。次のような簡単な Gradle 設定をするとよいでしょう。
defaultConfig {
applicationId "com.company.project"
// etc...
}
buildTypes {
debug {
applicationIdSuffix ".debug"
}
release {
// etc...
}
}
この例では、リリースビルドに適用されるアプリケーション ID は「com.company.project」ですが、デバッグビルドのアプリケーション ID は「com.company.project.debug」になります。このような接尾語を使わなければならないということではありません。まったく新しい applicationId の値を指定することもできます。
次に、Firebase コンソールで 1 つのプロジェクトを作成し、そのプロジェクト内にそれぞれのビルドタイプに対応する 2 つのアプリを作ります。デバッグアプリではアプリケーション ID「com.company.project.debug」を使用し、リリースアプリでは「com.company.project」を使用します。SHA-1 ハッシュが必要な Firebase 機能を使用している場合は、各ビルドに署名する際に使う別々のキーが SHA-1 ハッシュにも反映されている必要があります。
1 つのプロジェクト内にあり、アプリ ID が異なるデバッグ用とリリース用の 2 つのアプリ
両方 のアプリを作成できたら、コンソールから google-services.json ファイルをダウンロードしてアプリに配置します。このファイルの中を見てみると、両方のアプリが記述されていることがわかるでしょう。Google サービス プラグインは、各バリアントのビルドの際にその設定が使われたかを検出します。
"client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.company.project.debug "
}
},
"client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.company.project "
}
google-services.json は、プロジェクト内のすべての Android アプリを含む
このプロジェクトが課金プランかどうかを知っておくことは重要です。課金は、
両方の アプリの帯域幅とストレージに対して行われます。そのため、開発中に大量のデータを取得すると、課金額が増加する可能性があります。課金額に驚いてしまうことがないように、[課金プラン] をよく理解しておいてください。
また、注意すべき重要な点は、この設定では、開発中も完全リリース版のアプリで実際のユーザーが使うものと同じデータを使用することです。Realtime Database のデータを破壊する予定だったり、開発中に Remote Config の値を実験する場合、この方法はあまり安全とは言えません。
大規模チームと安全な開発
ライブデータを使って開発を行うという先ほどのレシピは問題かもしれません。多くのメンバーを抱える大規模チームで安全でない形でデータを更新する場合や、本番データを破損させるリスクを防ぎたい場合には、複数のプロジェクトをセットアップして開発データを本番データから分離させる必要があります。実は、チーム内のひとりひとりが無償版の個々の「サンドボックス」プロジェクトを使い、他の人や課金に影響を与えずに安全な実験を行うこともできます。
このような環境は、build.gradle に特別な設定をしなくても実現でき、全員が同じアプリケーション ID を使いつつ、サンドボックス プロジェクト内にアプリを作成できます。ただし、これには署名を行うための一意なデバッグキーが必要です。Android SDK ツールは、SDK の各ユーザーに一意なデバッグキーを作成していますので、この点は通常は問題になりません。しかし、Firebase コンソールは、アプリケーション ID と SHA-1 キーのペアが重複したアプリの作成を許可しないことに注意する必要があります。このペアは、
すべて のアカウントの
すべて のプロジェクトの
すべて のアプリで一意でなければなりません。そのため、チームのメンバーがデバッグキーを共有している場合、この設定は動作しません。
Firebase コンソールはパッケージ名と SHA-1 の組み合わせの重複を許可しない
この仕組みはそれぞれのメンバーの環境を分離する際に便利ですが、一点だけ気をつけるべきことがあります。すべてのデベロッパーがそれぞれのプロジェクトを作ることになるため、いくつかの重複した設定を行わないとプロジェクトが正しく動作しない可能性もあります。たとえば、新しいプロジェクト用のデータベースには、あらかじめいくつかのデータを入れておかなければ利用開始できないかもしれません。また、正しいセキュリティ ルールも重複して設定する必要があります。Remote Configs にも適切な値を設定する必要があるかもしれません。Authentication にも同じような設定が必要になる場合があります。さらに、すべてのデベロッパーが自分のプロジェクト用に生成された google-services.json ファイルを使う必要があります。また、このファイルをソース管理システムにチェックインしては
いけません 。これは、チームメンバー間での競合を避けるためです。
開発、QA、ステージング、本番の各環境の分離
複数の環境間でデータを分離する必要がある状況では、上記の大規模チーム向けの設定と同じ方法で設定するとよいでしょう。もちろん、各環境ごとに異なるプロジェクトを作成する必要があります。それぞれの環境は、同じアカウントで管理しても、別のアカウントで管理しても構いません。
ビルド対象の環境を簡単に選択できるように、それぞれの環境向けのアプリに対するビルド フレーバーを活用できます。たとえば、開発、QA、本番の各環境間でデータを分離させる場合、アプリの build.gradle の buildTypes ブロックの隣にある productFlavors ブロックに 3 つのビルド フレーバーを定義します。次の例をご覧ください。
productFlavors {
dev {
}
qa {
}
prod {
}
}
この場合、バリアントは別々に存在しますが、各バリアント間で異なるものはありません。バリアント間で同じアプリケーション ID が共有されますが、これは問題にはなりません。あるいは、ID を分けたい場合には、個別の ID を割り当てることもできます。どちらのケースも、フレーバー固有のディレクトリに各プロジェクトの google-services.json ファイルを入れておく必要があります。上記の各フレーバーが定義されている場合、Android Gradle プラグインはデフォルトで次の規則に基づいてディレクトリを配置します。
app/
src/
main/
dev/
google-services.json (for dev only)
qa/
google-services.json (for qa only)
prod/
google-services.json (for prod only)
各フレーバーのディレクトリは、src ディレクトリ内にある通常プロジェクトのコードが格納されている main ディレクトリと隣り合う場所にあります。各フレーバー名がディレクトリ名となる点に注意してください。このような構造になっているため、各プロジェクト用の google-services.json を直接専用のディレクトリに入れることができます。これによって、アプリの「dev」フレーバーをビルドしたい場合、Android Studio のビルド バリアントを指定するウィンドウから「devDebug」を選択するか、Gradle のコマンドラインでそのバリアントのビルドタスクである「assembleDevDebug」を対象にすることができます。
ご質問がある場合
今回掲載した情報に該当しないアプリのビルドを行うという珍しい状況にある方は、遠慮なく
firebase-talk Google Group から質問をお寄せください。緊急のサポートが必要な件については、
Firebase Support サイトから問題をお送りください。また、私の Twitter アカウント
CodingDoug もぜひフォローしてください。
Posted by
Yoshifumi Yamaguchi - Developer Relations Team
[この記事は Doug Stevenson、デベロッパー アドボケートによる The Firebase Blog の記事 "Organizing your Firebase-enabled Android app builds " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Doug Stevenson
デベロッパー アドボケート
「毎日の開発データとリリースデータを分けるには、どうすればよいでしょうか？」
実際 のアプリの利用データ（開発時の 人為的 な利用ではないもの）のみを反映させたいと誰もが思うでしょう。また、日々の開発でのクラッシュ データと、公開されているリリース版のクラッシュ データが混在していては不便です。何よりも、開発チームが拡大してアプリが複雑になると、お互いの作業が衝突しないように、各チームメンバーの作業環境を個々のサンドボックスに分割したいと考えるはずです。
Firebase コンソール のいくつかの設定と合わせて適用されます。
Firebase プロジェクト
[Firebase コンソール] のトップレベルで作成するプロジェクトです。作成したプロジェクトは、カード形式で表示されます。 Firebase アプリ
Firebase プロジェクト内に作成するアプリです。Firebase プロジェクトには、いくつでも Android アプリや iOS アプリを含めることができます。プロジェクトに含まれているアプリはホーム画面に表示され、同じ設定を共有します。また、異なる設定も持っています（この点は後ほど詳しく説明します）。 Android Gradle ビルドタイプ
Android Gradle プラグインはビルド時にアプリの設定を行い、その際にビルドタイプが定義されます。ビルドタイプには、デフォルトで「debug」と「release」の 2 種類があります。この設定は buildTypes ブロックで行われており、必要に応じてビルドタイプを追加することもできます。debug タイプは日々のデプロイ用、release タイプはユーザーへの配布用の設定です。 Android Gradle ビルド フレーバー
ビルド時に Android アプリを設定する際に、オプションで「ビルド フレーバー」を割り当てることができます。これはビルドタイプとほぼ同じですが、ビルド フレーバーを使うと必要に応じてさらに細かい設定を行うことができます。たとえば、ほとんどの機能が同じで、アプリケーション ID や有効にする機能のみが異なる「無償」版と「有償」版の両方のアプリをビルドすることができます。 Android Gradle ビルド バリアント
ビルド バリアント は、ビルドタイプとビルド フレーバーの固有の組み合わせです。アプリのビルド設定では、タイプとフレーバーのそれぞれの組み合わせについて、必ずバリアントが 1 つだけ存在します。たとえば、debug と release というタイプを設定しており、「free」と「paid」というフレーバーを設定している場合、Android Gradle プラグインは「debug/free」、「debug/paid」、「release/free」、「release/paid」という組み合わせのバリアントを生成します。コードからビルドした APK は、必ず 1 つだけバリアントを持っています。Android アプリケーション ID
アプリを一意に識別する文字列の識別子です。Play ストアで公開する際、他のアプリと重複しない一意の値になっている必要があります。通常は、「com.company.project」のように Java パッケージ名形式のフォーマットを使用します。 Firebase 対応のアプリを効果的に設定する際に重要になる考え方があります。それは、個別のデータ コレクションが必要になるアプリのビルド バリアントごとに固有のアプリケーション ID を割り当てることです。 それには、最初にアプリの build.gradle を設定し、次に Firebase コンソールでミラーの設定を行います。しかし、アプリに最適な設定を決めるためには、プロジェクトとアプリの間で Firebase の各機能がどのように動作しているかについてもう少し知っておく必要があります。
Firebase 機能ごとのデータスコープ
データを共有 するものもあります。これらの機能のデータの「スコープ」は、Firebase プロジェクト全体であると言え、次の機能が該当します。
独立してデータ を持つものもあります。これらの機能のスコープは、Firebase プロジェクトの個々のアプリであると言え、次の機能が該当します。
アプリ セレクターが表示されている Analytics ダッシュボード
Remote Config は、プロジェクト内のアプリ間で異なる値を設定することができますが、デフォルトではすべてのアプリに同じ値が設定されます。
Notifications は、コンソールで選択したプロジェクト内の 1 つまたは複数のアプリを対象にできます。
Dynamic Links は、1 つの Android および / または 1 つの iOS アプリが対象になります。
どちらを対象にするかは、現在のプラットフォームに基づいてリンク自身が判断します。
Firebase Test Lab for Android は特殊なケースです。この機能には課金が有効になったプロジェクトが必要ですが、1 つのプロジェクトという制約はなく、任意の APK を対象にすることができます。そのため、無償プランで Firebase の開発を行いつつ有償プランの Test Lab で APK をテストしたい場合は、Test Lab 専用のまったく新しいプロジェクトを作成し、課金を有効にすることをお勧めします。Firebase 統合の有無に関わらず、このプロジェクトでどのようなアプリでもテストできます。
小規模チームとシンプルなアプリ
defaultConfig {
applicationId "com.company.project"
// etc...
}
buildTypes {
debug {
applicationIdSuffix ".debug"
}
release {
// etc...
}
}
1 つのプロジェクト内にあり、アプリ ID が異なるデバッグ用とリリース用の 2 つのアプリ
両方 のアプリを作成できたら、コンソールから google-services.json ファイルをダウンロードしてアプリに配置します。このファイルの中を見てみると、両方のアプリが記述されていることがわかるでしょう。Google サービス プラグインは、各バリアントのビルドの際にその設定が使われたかを検出します。 "client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.company.project.debug "
}
},
"client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.company.project "
}
google-services.json は、プロジェクト内のすべての Android アプリを含む
両方の アプリの帯域幅とストレージに対して行われます。そのため、開発中に大量のデータを取得すると、課金額が増加する可能性があります。課金額に驚いてしまうことがないように、[課金プラン] をよく理解しておいてください。
大規模チームと安全な開発
すべて のアカウントの すべて のプロジェクトの すべて のアプリで一意でなければなりません。そのため、チームのメンバーがデバッグキーを共有している場合、この設定は動作しません。
Firebase コンソールはパッケージ名と SHA-1 の組み合わせの重複を許可しない
いけません 。これは、チームメンバー間での競合を避けるためです。
開発、QA、ステージング、本番の各環境の分離
productFlavors {
dev {
}
qa {
}
prod {
}
}
app/
src/
main/
dev/
google-services.json (for dev only)
qa/
google-services.json (for qa only)
prod/
google-services.json (for prod only)
ご質問がある場合
firebase-talk Google Group から質問をお寄せください。緊急のサポートが必要な件については、Firebase Support サイトから問題をお送りください。また、私の Twitter アカウント CodingDoug もぜひフォローしてください。
Yoshifumi Yamaguchi - Developer Relations Team
Todd Kerpelman
デベロッパー アドボケート
Firebase Analytics の非常に強力な機能の 1 つが、BigQuery からの Analytics データの直接参照や分析できることです。Firebase アプリと BigQuery をリンクさせれば、生のサンプリングされていないアプリデータを毎日 BigQuery にエクスポートでき、データに対して強力なクエリをアドホックに実行したり、Firebase Analytics データと別のアナリティクス ライブラリのデータを組み合わせたり、カスタム レポーティング ツールを直接実行できるようになります。
しかし、この機能はデベロッパーに非常に人気がある一方、時にじれったく感じるような制限もあります。通常、日々のアナリティクス データが収集されて BigQuery テーブルにエクスポートされるまで、24 時間待たなければならないことです。これは、開発とテストという視点から考えると不便に映ることが多い制限で、アプリのデベロッパーの対応スピードが落ちてしまうことにもなります。もし最新の A/B テストの影響でユーザーがアプリを使わなくなってしまった場合、24 時間ではなく 20 分でそれがわかればすばらしいとは思いませんか？
そこで、うれしいことに、今週より、Firebase Analytics データがほぼリアルタイムで BigQuery から参照できるようになることをお知らせいたします。
以下で、その仕組みについて説明します。既に Firebase プロジェクトと BigQuery をリンクさせていれば、デフォルトで Firebase Analytics はできるだけ早く BigQuery にデータを送信するようになります。通常の
appevents_ テーブルに加え、その日の受信するすべてのデータを集めた特殊な
appevents_intraday_ テーブルができます。
この
intraday テーブルは、自由に分析を行ったりクエリを実行したりでき、他の BigQuery アナリティクス テーブルとまったく同じように扱うことができます。このテーブルにないデータは、生涯価値（LTV）データとキャンペーン情報（
traffic_source レコード）のみです。1 日が終わると[1]、このデータは永続テーブルである
appevents_
ホームに移動し、古い intraday テーブルは自動的にクリーンアップされます。
もちろん、BigQuery の使用量とストレージの
料金 はそのまま適用されます。つまり、このメリットを受けるには、Firebase プロジェクトを Blaze プランにアップグレードする必要があるということです。しかし、BigQuery へのエクスポートは、今までアナリティクス ユーザーが多額をつぎ込まなければならなかった機能だったため、これは十分よい条件だと言えるでしょう。
BigQuery を初めて使う方は、
こちらから詳しい情報 をご覧いただき、使い始めることができます。BigQuery で取得した巨大なデータセットに対して高速にクエリを実行するのはとても楽しいものです！
[1] デベロッパーのタイムゾーンで判断しています。
Posted by
Khanh LeViet - Developer Relations Team
[この記事は Todd Kerpelman、デベロッパー アドボケートによる The Firebase Blog の記事 "Announcing Real-time Exporting of your Analytics Data into BigQuery " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Todd Kerpelman
デベロッパー アドボケート
appevents_appevents_intraday_intradaytraffic_sourceappevents_
料金 はそのまま適用されます。つまり、このメリットを受けるには、Firebase プロジェクトを Blaze プランにアップグレードする必要があるということです。しかし、BigQuery へのエクスポートは、今までアナリティクス ユーザーが多額をつぎ込まなければならなかった機能だったため、これは十分よい条件だと言えるでしょう。 こちらから詳しい情報 をご覧いただき、使い始めることができます。BigQuery で取得した巨大なデータセットに対して高速にクエリを実行するのはとても楽しいものです！ Khanh LeViet - Developer Relations Team
Todd Kerpelman
デベロッパー アドボケート
最新かつ最高のテクノロジーを導入した環境で、自身のアプリを正しく動作させることは非常に重要です。iOS 開発について言えば、近々リリースされる iOS 10 向けにアプリをサポートしようと考えているデベロッパーの方も多いと思います。
Firebase チームでは、iOS 10 が一般公開されてすぐに、デベロッパーの皆様が自身のアプリを iOS 10 上で実行できるように準備を進めています。本記事では、Firebase CocoaPod の最新バージョン（3.5.1）における変更点を改めて紹介します。あわせて、今後予定されている変更点のうち、iOS 10 向けの開発を始めるにあたり影響がある内容についてお伝えします。
Dynamic Links、Invites、App Indexing
最新版の Firebase ライブラリでは、iOS 10 向けのディープリンク機能が新たにサポートされています。自身のアプリで Dynamic Links、Firebase Invites、App Indexing などのディープリンクを活用する機能を使用している場合は、ライブラリを最新版に更新してください。これらの機能は、（コードを変更しなくても）アプリを再ビルドするだけで正しく動作するようになります。
Firebase Analytics
Firebase SDK の最新版では、検索機能と連動した AdWords 広告経由でのアプリのインストール状況を、より正確にトラックできるようになっています。この機能は Firebase SDK のバージョン 3.3.0 で追加済みなので、既にご存じの方もいると思いますが、今回はさらに iOS 10 向けのサポートを追加しています。上述のディープリンク機能の更新と同様に、新しいライブラリを用いてコードを再ビルドすると、自動的に新機能が有効になります。
Firebase Cloud Messaging
iOS 10 では通知関連の機能が大幅に進化しており、デベロッパー側で受信したユーザー通知を処理するための新たな方法も提供されています。具体的には、
application:didReceiveRemoteNotification などの古い
UIApplicationDelegate メソッドの廃止に伴い、
UNUserNotificationCenterDelegate プロトコルのメソッドで通知を処理するようになっています。
ただし、お気づきの方もいるかと思いますが、Firebase SDK の最新版では、まだ古い appDelegate メソッドを使用しています。新しい
UNUserNotificationCenterDelegate プロトコルのメソッドについては、近々サポートを開始できるように努めています。ライブラリを更新した際はお知らせしますので、今後の配信情報をチェックしておいてください。
Firebase Auth と Xcode 8 に関するお知らせ
最新の iOS 10（この記事を書いている時点では ベータ版 6 まで）のシミュレータでは、キーチェーンに値が書き込めず、Firebase Auth がエラーを返すという問題が発生することが判明しています。なお、この問題による実機への影響はありません。
本件は、既に Apple のバグ トラッキング システムに報告済みですので、近いうちに解決されると見込まれますが、それまではシミュレータで Firebase Auth の試験を実施すると、エラーが発生する可能性があります。この問題を回避する方法として、Auth の試験は iOS 10 が搭載された実機で実施することをお勧めします。実機をお持ちでない場合は、
アプリの Capabilities セクションで Keychain Sharing を有効にしてください。 詳しくは
StackOverflow の投稿をご覧ください。
Swift 3 対応
既にお気づきの方もいるかもしれませんが、ドキュメントのサンプルコードでは、まだ Swift 2.3 を使用しています。Swift 3 は現在も開発中であるため、バージョン 3.0 が正式にリリースされてから、ドキュメント内のサンプルコードを入れ替える予定です。
もちろん現段階で、Swift 3 でサンプルの動作を試すことも可能です。最新のサンプルコードをダウンロードして、Xcode の Swift 変換ツールでサンプルを変換すると、ご利用いただけます。また、近日中にサンプルアプリ用に Swift 3 の専用ブランチを作成する予定です。そちらのブランチを GitHub からチェックアウトすれば、変換処理をしなくてもソースコードをご覧いただけます。
フィードバックをお待ちしています
今回は、ベータ版のオペレーティング システム向けにライブラリをリリースしているため、厄介な問題が発生することが見込まれます。iOS 10 の新バージョン公開に伴い、さまざまな不具合が検出された際は、できるだけ迅速に改修するよう努めてまいります。皆様の方でも iOS 10 固有の問題を発見しましたら、ぜひお知らせください。まずは
Google グループ をご活用ください。
Posted by
Khanh LeViet - Developer Relations Team
[この記事は Todd Kerpelman、デベロッパー アドボケートによる The Firebase Blog の記事 "iOS 10, Xcode 8, and Swift 3, oh my! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Todd Kerpelman
デベロッパー アドボケート
Dynamic Links、Invites、App Indexing
Firebase Analytics
Firebase Cloud Messaging
application:didReceiveRemoteNotification などの古い UIApplicationDelegate メソッドの廃止に伴い、UNUserNotificationCenterDelegate プロトコルのメソッドで通知を処理するようになっています。 UNUserNotificationCenterDelegate プロトコルのメソッドについては、近々サポートを開始できるように努めています。ライブラリを更新した際はお知らせしますので、今後の配信情報をチェックしておいてください。 Firebase Auth と Xcode 8 に関するお知らせ
アプリの Capabilities セクションで Keychain Sharing を有効にしてください。 詳しくは StackOverflow の投稿をご覧ください。 Swift 3 対応
フィードバックをお待ちしています
Google グループ をご活用ください。 Khanh LeViet - Developer Relations Team
埋め込みウェブビューではなく、端末のブラウザを使用して OAuth リクエストを行うことにより、アプリのユーザビリティは大幅に向上します。ユーザーは端末で 1 度だけ Google にログインすればいいため、アプリでのログインのコンバージョン率や認証フローが改善されます。Android の Chrome Custom Tab や iOS の SFSafariViewController など、いくつかのオペレーティング システムで利用できる最新の「アプリ内ブラウザタブ」パターンを使うと、ブラウザベースの OAuth フローの UX をさらに改善できます。
逆に、OAuth に埋め込みブラウザを使用する古い方式では、端末の既存のログイン済みセッションを使うことはできないため、ユーザーはその都度 Google にログインする必要があります。ウェブビューの内容はアプリが検査したり変更したりできますが、ブラウザ内に表示されるコンテンツではそれができないため、端末のブラウザの方がセキュリティが高くなります。
この移行をサポートするため、皆様が利用できる最新のベスト プラクティスに基づくライブラリとサンプルを公開しています。
ネイティブ アプリの標準ベースの OAuth サポートに関する
プロトコル レベルのドキュメント や、このトピックに関する
現在の IETF のベスト プラクティス のドラフトもご覧ください。
バージョン 3.0 以前の iOS で使われているバージョンの Google Sign-In も、アプリ内ブラウザタブの現在の業界のベスト プラクティスに対応していないため、サポートを終了します。Google Sign-In を使用する場合は、最新のバージョンにアップデートし、セキュリティやユーザビリティを最新の状態にしてください。現在のところ、このポリシーによって iOS 8 の WebView のサポートが終了することはありませんが、今後、セキュリティ向上のために端末をアップグレードすることを促す通知がユーザーに表示される可能性があります。
ウェブビューでの Google への OAuth リクエストのサポート終了スケジュールは、次のようになっています。
2016 年 10 月 20 日 以降、有効な代替手段があるプラットフォームで、新しい OAuth クライアントがウェブビューを使用することを禁止し、段階的に既存の OAuth クライアントのユーザーに対して通知を表示します。
2017 年 4 月 20 日 に、有効な代替手段があるプラットフォーム上のすべての OAuth クライアントに対し、ウェブビューからの OAuth リクエストのブロックを開始します。
移行に関する質問がある方は、「
google-oauth 」タグをつけて Stack Overflow に投稿してください。
Posted by
Eiji Kitamura - Developer Relations Team
[この記事は William Denniss、ID および認証担当プロダクト マネージャーによる Google Developers Blog の記事 "Modernizing OAuth interactions in Native Apps for Better Usability and Security " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
数か月後、「ウェブビュー」と言われる埋め込みブラウザから Google への OAuth リクエストは許可されなくなります。 ウェブビューには、Android の WebView UI 要素や iOS の UIWebView/WKWebView、Windows や OS X での同等の要素が含まれます。 プロトコル レベルのドキュメント や、このトピックに関する現在の IETF のベスト プラクティス のドラフトもご覧ください。 2016 年 10 月 20 日 以降、有効な代替手段があるプラットフォームで、新しい OAuth クライアントがウェブビューを使用することを禁止し、段階的に既存の OAuth クライアントのユーザーに対して通知を表示します。2017 年 4 月 20 日 に、有効な代替手段があるプラットフォーム上のすべての OAuth クライアントに対し、ウェブビューからの OAuth リクエストのブロックを開始します。 google-oauth 」タグをつけて Stack Overflow に投稿してください。
Eiji Kitamura - Developer Relations Team
