[この記事は、Brett Morgan, Developer Programs Engineer による Geo Developers Blog の記事 "Making the most of the Google Maps Web Service APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

アプリ開発の現場において、開発者が目指す堅牢なアプリと、必要最低限の機能のみを実現したコードの間に隔たりが存在する場合があります。したがって、こうしたコードがいったん製品に盛り込まれてしまった場合、後々、エラー発生の原因になることがあります。

Google Maps API チームでは、皆さんのアプリがスムーズにスケールするようにクライアント ライブラリを提供しています。対象となるプログラミング言語は Python、Java、Go で、いずれも世界中で大勢の開発者が利用する言語です。先日このクライアントライブラリに、新たに Node.js が加わりました。

モバイル アプリケーションを開発する場合、Places API for Android や Places API for iOS といったネイティブ API が使えるのであれば、こうしたものを利用することが推奨されます。とはいえ、実際には、Google Maps API Web Services（たとえば Elevation API）でしか手に入らないデータが必要になることもあります。先々のことを考えると、そうした場合にはこういったクライアント ライブラリを使うのが最善の方法となります。

次のようなケースでは、クライアント ライブラリの利用がおすすめです。

• リクエストが、いずれのウェブサービスに対してもデフォルトのレート制限で送られます。もちろん設定変更は可能です。
• API から 500 番台のエラーが返ってきた場合、クライアント ライブラリは自動的にリクエストをリトライします。リトライはエクスポネンシャル バックオフを使用しますが、これは断続的な失敗が生じる場合に有効です。
• クライアント ライブラリを利用すると、自由に入手できる API キーでの認証が簡単になります。Google Maps API プレミアムプランを利用されているお客様は、この API キーを使うか、または、クライアント ID とシークレットを使うことができます。
• Java と Go のライブラリは、API の応答ごとにネイティブなオブジェクトを返します。Python と Node.js のライブラリについては、API からストラクチャを受け取り次第これを返します。

クライアント ライブラリは様々な場面で役立つことでしょう。たとえば、言語間でもっとも互換性のある形式で結果セットを返します。Java と Go のクライアント ライブラリには、各 API の潜在的な結果をタイプセーフな形で表現したものであるオブジェクト階層が含まれています。これにより、使い慣れたエディタで、コンパイラ時のエラーを確認しながら、コーディングすることが可能になります。

Google Maps API を利用しているアプリやウェブサイトは、300 万にものぼります。そこから得られた知見・経験により、ウェブサービスを利用する際の信頼性を確保するうえで重要なポイントがわかりました。Android や iOS から直接ではなく、サーバから API をコールするのです。この方法だと API キーを確保できるので、問題のあるアクターに割り当てを消費されることがありません。また、キャッシュを追加することで、よくあるリクエストを速やかに処理することもできます。

サーバのインスタンスはプロキシの働きをします。Android や iOS からリクエストがあると、そのリクエストを（アプリに代わって）Google Maps Web Service API に転送するのです。サーバ側のプロキシを作成するには、Google App Engine のインスタンスから Google Maps Web Service のクライアント ライブラリを使う方法がもっとも簡単です。詳しくは、Google I/O 2016 で披露された Laurence Morone のセッション、「Building Geo Services that Scale（スケールする位置情報サービスの開発）」の動画をご覧ください。

Google Maps API Web Services について詳しく知りたいという方は、こちらのドキュメントをご覧ください。こうしたAPIを利用し、またベストプラクティスを実施する方法として一番手っ取り早いのは、Google Maps Web Services のクライアント ライブラリを利用することです。Python、Java、Go、Node.js のクライアント ライブラリは、Github でダウンロードいただけます。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps Solution Architect, Google Maps

この記事は Todd Kerpelman による The Firebase Blog の記事 "Announcing Firebase 3.6 for iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

iOS デベロッパーの皆さん、こんにちは！

iOS で Firebase バージョン 3.6 が利用できるようになったことをお知らせします。バージョン 3.6 には、重要なバグの修正や iOS 10 サポートに必要な機能が含まれています。そのため、できるだけ早く pod update を実行（またはフレームワークを手動アップデート）してプロジェクトを再コンパイルすることをお勧めします。

修正内容や機能強化の完全なリストはリリースノートでご覧いただけますが、ここでは新機能について簡単に紹介しましょう。

新しい通知のサポート

Firebase Cloud Messaging は、iOS 10 の新しいユーザー通知をサポートするようになります。iOS 10 で動作するアプリの場合、userNotificationCenter:willPresentNotification: withCompletionHandler メソッドで着信する通知を処理することができます。アプリが古い application:didReceiveRemoteNotification: completionHandler メソッドしかサポートしていなくても、新しいメソッドが存在しなければ APN は古いメソッドを呼び出しますので、心配はいりません。詳しくは、アップデートされた FCM のドキュメントをご覧ください。

アプリのレビュー ガイドラインに関する注意事項

iOS 10 のアップデートに伴い、Apple は App Store のレビュー ガイドラインに多くの変更を加えました。最新版の Firebase では、新しいガイドラインに対応するように多くの変更が行われています。最も重要なのは、NSCalendarsUsageDescription や NSBluetoothPeripheralUsageDescription などに対してテキストを提供するよう促す iTunes Connect エラーが表示されないようにする必要があることです。

このガイドラインに従った結果、Safari で iOS 検索のアプリ インストール広告を測定していた機能が削除されています。

Firebase Invites を利用している方は、plist ファイルで NSContactsUsageDescription を提供する必要があります。Firebase Invites はこの連絡先情報を使ってユーザーが招待状を送る可能性がある友だちのリストを作成しています。

もちろん、このプロセスは現在も継続されています。私たちは、このような変更に細心の注意を払っていますので、必要な場合にはさらにアップデートを公開します。

ログインの回避策

Xcode 8 でシミュレータのキーチェーンに値を書き込めないため Firebase Auth がエラーとなるという最近の ブログ投稿を覚えている方もいるかもしれません。この問題はまだ存在しているため、端末ではキーチェーンを利用しつつ、シミュレータでは NSUserDefaults を利用する回避策を実装しています。これによって、シミュレータで Firebase Auth の開発やテストができるようになり、全機能が利用できるようになります。

バグの修正

皆様が見つけたバグは私たちが修正します。今後も、オンライン フォームから問題や機能リクエストをお寄せください。お寄せいただいた内容は適切に対応いたします。

質問は、Firebase タグを付けて Stack Overflow でお尋ねください。または、Google グループに送信していただいても構いません。

Firebase デベロッパーの皆様、いつもありがとうございます。ぜひ、アプリのアップデートをお願いいたします！


Posted by Khanh LeViet - Developer Relations Team

この記事は Jamal Eason、Android プロダクト マネージャーによる Android Developers Blog の記事 "Android Studio 2.2" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

先週より、Android Studio 2.2 がダウンロードできるようになっています。Google I/O 2016 でプレビュー版が発表された Android Studio 2.2 は、世界中の数百万人の Android デベロッパーが使用する IDE の最新リリースです。

さまざまな機能強化が組み込まれた今回のリリースには、スピード、スマート、Android プラットフォーム サポートという 3 つの主なテーマがあります。アプリのユーザー インターフェースをすばやく直感的に作れる新しい Layout Editor などの機能は、開発のスピードを上げます。新しい APK Analyzer、強化された Layout Inspector、拡張されたコード分析、IntelliJ 2016.1.3 機能などによって、今まで以上にスマートな開発を行うことができます。また、Android アプリ開発の公式 IDE である Android Studio 2.2 では、Android 7.0 Nougat の最新デベロッパー機能がサポートされています。たとえば、マルチ ウィンドウのサポート、クイック設定 API、再設計された通知などの Android プラットフォーム機能を追加するためのコード補完、そしてもちろん、これらすべての機能をテストすることができるビルトイン Android Emulator などの機能が含まれています。

今回のリリースでは、Android フレームワークと IDE をともに進化させた Constraint Layout が導入されています。この強力な新しいレイアウト マネージャーによって、大きく複雑なレイアウトをフラットで効率的な階層を使って設計できるようになります。ConstraintLayout は新しい Layout Editor とともに構築されており、標準 Android サポート ライブラリと同じようにアプリに組み込むことができます。

Android Studio 2.2 には、設計、開発、ビルド、テストという開発プロセスの主なフェーズのすべてを網羅する 20 以上の新機能が含まれています。新しい ConstraintLayout による UI の設計から、Android NDK と C++ コードによる開発、最新の Jack コンパイラーによるビルド、アプリの Espresso テストケースの作成まで、Android Studio 2.2 は見逃してはならないアップデートになっています。以下では、いくつかの重要なアップデートについて詳しく説明します。

設計

• Layout Editor: 新しいユーザー インターフェース デザイナーによって、Android アプリのユーザー インターフェースの作成が今までになく簡単になります。新しく導入されたブループリント モードでアプリの UI 構造をすばやく構築し、新しいプロパティ パネルで各ウィジェットの視覚属性を調整できます。詳細を見る。

Layout Editor

• Constraint Layout: この新しいレイアウトは、複数のレイアウトをネストすることなく、アプリの動的なユーザー インターフェースを作成できる柔軟なレイアウト マネージャーです。Android API レベル 9（Gingerbread）以降と下位互換性があります。ConstraintLayout は、Android Studio 2.2 の新しい Layout Editor とともに使用するのが最適です。詳細を見る。

ConstraintLayout

開発

• C++ サポートの強化: Gradle から C++ プロジェクトをコンパイルする際に CMake か ndk-build を使用できるようになるため、CMake ビルドシステムから Android Studio へのプロジェクトの移行がシームレスになります。Android Studio の新規プロジェクト ウィザードにも C++ サポートが追加され、C++ の編集やデバッグに関する多くのバグの修正がされています。詳細を見る。

C++ のコード編集と CMake のサポート

• サンプル ブラウザ: Android Studio 2.2 では、Android サンプルコードの参照がさらに簡単になります。コードエディタ ウィンドウ内で Google Android サンプルコードにあるアプリのコードを使用することによって、アプリ開発を最初からスピードアップすることができます。詳細を見る。

サンプルコード メニュー

ビルド

• Instant Run の強化: Android Studio 2.0 で導入された Instant Run は、Android 開発を高速化、軽量化するための Google の主要な長期的投資です。この機能がリリースされてから、多くのデベロッパーの編集、ビルド、実行のサイクルが大きく改善されています。今回のリリースでは、たくさんの安定性や信頼性の向上が行われています。以前のバージョンで Instant Run を無効にしている方も、ぜひ Instant Run を有効化して、以前に発生した問題が解消されているかどうかをお知らせください（[Settings] → [Build, Execution, Deployment] → [Instant Run]（Windows/Linux の場合）、[Preferences] → [Build, Execution, Deployment] → [Instant Run]（OS X の場合））。詳しい修正点については、Android Studio 2.2 リリースノートをご覧ください。

Instant Run の有効化

• APK Analyzer: APK の内容を簡単に調査し、各コンポーネントがサイズに与える影響を把握することができます。この機能は、multi-dex の問題のデバッグに役立つ場合もあります。また、APK Analyzer を使って APK の 2 つのバージョンを比較することもできます。詳細を見る。

APK Analyzer

• ビルド キャッシュ（試験運用版）: ビルドの高速化に向けた投資は継続的に行われており、今回はその一環として、新しいビルド キャッシュが試験運用版として搭載されます。これによって、フルビルド、増分ビルドの両方の時間が短縮されます。この機能は、gradle.properties ファイルに android.enableBuildCache=true を追加するだけで有効になります。詳細を見る。

ビルド キャッシュの設定

テスト

• Android Emulator の仮想センサー: Android Emulator にいくつかの仮想センサー コントロールが新しく搭載されます。新しい UI コントロールを使って、加速度計、気温計、磁力計などの Android センサーをテストできます。詳細を見る。

Android Emulator の仮想センサー

• Espresso テスト レコーダー（ベータ版）: Espresso テスト レコーダーを使うと、アプリとのインタラクションを記録して UI テストを簡単に作成できます。記録したテストは、UI テストコードとして出力されます。端末を使ってインタラクションを記録し、アプリの特定のスナップショットの UI 要素を確認するアサーションを追加すると、Espresso テスト レコーダーは保存された記録を読み出して対応する UI テストを自動的に生成します。テストはローカルで実行できる他、継続的インテグレーション サーバーやFirebase Test Lab for Android を使って実行することもできます。詳細を見る。

Espresso テスト レコーダー

• GPU デバッガー（ベータ版）: GPU デバッガーがベータ版になりました。Android 端末上で OpenGL ES コマンドのストリームをキャプチャして Android Studio 内で再生し、分析できます。指定した任意の OpenGL ES コマンドにおける GPU の状態を完全に調査できるため、グラフィック出力を詳細に把握してデバッグできます。詳細を見る。

GPU デバッガー
Android Studio 2.2 に含まれる主な機能をまとめます。

設計 Layout Editor Constraint Layout Layout Inspector（試験運用版） Vector Asset Studio での PSD ファイルのサポート 開発 Firebase プラグイン コード分析と Lint チェックのアップデート ユーザー補助機能のサポート強化 C++ の編集とデバッグのサポート強化 IntelliJ 2016.1.3 プラットフォーム アップデート サンプル ブラウザ フォント レンダリングの改善

ビルド Jack コンパイラーの改善 Java 8 言語サポート C++ ndk-build と CMake 結合マニフェスト ビューア ビルド キャッシュ（試験運用版） OpenJDK サポート Instant Run の強化 テスト Espresso テスト レコーダー（ベータ版） APK Analyzer GPU デバッガー（ベータ版） Android Emulator の仮想センサー

Android Studio 2.2 の詳細については、リリースノートやプレビュー ブログ投稿をご覧ください。

スタートガイド

ダウンロード

旧バージョンの Android Studio をご使用中の方は、ナビゲーション メニューから安定版チャンネルのアップデートを確認できます（Windows / Linux の場合は [Help] → [Check for Update]、OS X の場合は [Android Studio] → [Check for Updates]）。Android Studio 2.2 は、公式ダウンロード ページからもダウンロードできます。Android Studio のすべての新機能や機能強化を利用するには、アプリのプロジェクトの Android Gradle プラグインのバージョンを 2.2.0 にアップデートする必要があります。

次のリリース

今回のリリースに協力いただきました Android デベロッパー コミュニティの皆様、どうもありがとうございました。皆様の貢献、今回のリリースの新機能の元となった継続的なフィードバック、Canary ビルドやベータ版の試用、バグの報告に感謝いたします。私たちは全員、安定性向上やパフォーマンスの修正、そして多くの新機能が搭載された Android Studio 2.2 を最高のリリースとなることを願っています。次のリリースはさらに優れたものをご期待ください。フィードバックへの対応、既存機能の品質や安定性の向上によって、皆様の生産性をさらに上げることができるよう、私たちは懸命に努力を続けています。

気に入った機能や問題点、新機能の提案などのフィードバックは大歓迎です。Google+ のページや Twitter で Android Studio 開発チームからの情報をチェックしてください。

Android Studio 2.2 の新機能


Posted by Yuichi Araki - Developer Relations Team

この記事は Doug Stevenson による The Firebase Blog の記事 "Become a Firebase Taskmaster! (Part 1: The Essentials)" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android 向けの Firebase のクライアント API を使用する際に、デベロッパーのリクエストに応じて Firebase で非同期的に処理を実行させたいケースがあります。たとえばリクエストされたデータをすぐに取得できない場合や、一番最後に何か処理を実行しなければならない場合などです。なお、「アプリ内で処理を 非同期的に 行う」というのは、アプリにおいて最優先すべきビューのレンダリング処理と同時に実行しつつ、かつレンダリングの妨げにならないように処理をする、という意味です。この非同期処理を Android アプリで適切に行えば、任意の処理が Android のメインスレッドを長時間を占有するという事態は回避できます。逆に非同期処理に問題があると、一部のフレームのレンダリングが遅れ、ユーザー エクスペリエンスにおいてカクツキが発生します。さらにひどいと、ANR という最悪の状態に陥ります。遅延を引き起こす代表的な処理には、ネットワーク リクエスト、ファイルの読み取りおよび書き込み、時間のかかる演算などがあります。これらを総称して ブロッキング タスク と呼びます。メインスレッドのブロックは絶対に避けたいところです。

Firebase API を使用して、通常メインスレッドをブロックするような処理をリクエストする場合は、カクツキや ANR を回避するため、その処理を別スレッドで行うよう API で調整をしなければなりません。処理が完了した後は、確実にビューを更新するために結果をメインスレッドに返さなければならない場合もあります。

これを行うのが Play Services Task API です。Task API の目的は、簡単かつ軽量な、Firebase （および Play サービス）クライアント API 向けの Android 対応フレームワークを提供し、処理を非同期に実行できるようにすることです。この API は、Firebase と共に Google Play Services 9.0.0 で導入されました。アプリに Firebase の機能を使用している方は、気づかないうちに Task API を使用していたかもしれません。この一連のブログ記事では、Firebase API で Task を利用する方法を紹介し、高度な利用パターンもいくつか取り上げます。

本題に入る前に知っておいていただきたいのが、Android のあらゆるスレッド技術を Task API で代用できるわけではないという点です。スレッド用のツールには Services、Loaders、Handlers など多様なものがあり、各機能の内容は Android チームが詳細なドキュメントにまとめています。さらに YouTube には Application Performance Patterns の全シーズンがアップされており、こちらの動画でさまざまな手法を学ぶことができます。また、サードパーティのライブラリを利用して Android アプリのスレッド処理を行っているデベロッパーもいます。ぜひ、さまざまなソリューションについて学び、自身のスレッド要件に合った最適な手法を見つけてください。なお Firebase API では、スレッド処理の管理に一貫して Task を使用していますので、これと相性のよい手法を組み合わせて利用することをおすすめします。

シンプルな Task の例

Firebase Storage をご利用の場合、どこかで必ず Task を目にしたことがあるはずです。以下はファイルのメタデータのドキュメントからそのまま引用したコードで、ストレージにアップ済みのファイルのメタデータを取得するシンプルな例です。

    // Create a storage reference from our app
    StorageReference storageRef = storage.getReferenceFromUrl("gs://");

    // Get reference to the file
    StorageReference forestRef = storageRef.child("images/forest.jpg");

    forestRef.getMetadata().addOnSuccessListener(new OnSuccessListener() {
        @Override
        public void onSuccess(StorageMetadata storageMetadata) {
            // Metadata now contains the metadata for 'images/forest.jpg'
        }
    }).addOnFailureListener(new OnFailureListener() {
        @Override
        public void onFailure(@NonNull Exception exception) {
            // Uh-oh, an error occurred!
        }
    });

このコードには「Task」が見当たりませんが、実際には Task が機能している箇所があります。上記のコードの後半部分は、次のように書き換えることができます。

    Task task = forestRef.getMetadata();
    task.addOnSuccessListener(new OnSuccessListener() {
        @Override
        public void onSuccess(StorageMetadata storageMetadata) {
            // Metadata now contains the metadata for 'images/forest.jpg'
        }
    });
    task.addOnFailureListener(new OnFailureListener() {
        @Override
        public void onFailure(@NonNull Exception exception) {
            // Uh-oh, an error occurred!
        }
    });

どうやら、コード内に隠された Task があったようです。

処理をすると約束する

書き直した上記のコードを見ると、Task を使用してファイルのメタデータを取得する方法がよくわかります。StorageReference の getMetadata() メソッドは、ファイルのメタデータがすぐには利用できないと想定して、データを取得するためにネットワーク リクエストを行います。そのネットワーク アクセスにおいて呼び出し元のスレッドがブロックされないように、getMetadata() は Task を返しておきます。この Task をリッスンすることで、最終的に処理が成功したか失敗したかがわかります。次に API は、制御するスレッドでリクエストを実行するよう調整します。このスレッド処理は API 内で行われるため詳細は把握できませんが、結果が利用できるようになると、返された Task を介して通知がきます。返された Task は、処理が完了した後に、追加したリスナーのいずれかを必ず起動することを保証するものです。このような形で非同期処理の結果を扱う API は、プログラミング環境によっては Promise と呼ばれます。

ここで、返された Task が StorageMetadata 型によってパラメータ化されていることに注目してください。これは OnSuccessListener で onSuccess() に渡されるオブジェクトの型でもあります。実際、すべての Task はこのように総称型を宣言して生成したデータの型を示し、その総称型を OnSuccessListener で共有する必要があります。また、エラーが発生すると、Exception が OnFailureListener の onFailure() に渡されます。これは、失敗時に実行する指定の例外処理になります。Exception の詳細情報を知りたい場合は、その型を調べて、期待する型に安全にキャストする必要があります。

最後にもう 1 つ、このコードについて知っておくべきことは、リスナーはメインスレッドから呼ばれるということです。Task API で、自動的にそうなるように調整をしています。StorageMetadata が利用可能になった際に、メインスレッドで行わなければならない処理がある場合は、それをリスナー メソッド内で実行できます。（ただしメインスレッドのリスナー内では、ブロッキング タスクを決して実行しないように注意してください）これらのリスナーには他にもさまざまな利用方法がありますので、次回以降の記事でその詳細を説明します。

一発勝負

Firebase には、Task に関連のないリスナーに対応した API を提供する機能もあります。たとえば Firebase Authentication を使用している場合、ユーザーがアプリのログイン、ログアウトに成功した瞬間を検出するために、ほぼ間違いなくリスナーを登録しているはずです。

    private FirebaseAuth auth = FirebaseAuth.getInstance();
    private FirebaseAuth.AuthStateListener authStateListener = new FirebaseAuth.AuthStateListener() {
        @Override
        public void onAuthStateChanged(@NonNull FirebaseAuth firebaseAuth) {
             // Welcome! Or goodbye?
        }
    };

    @Override
    protected void onStart() {
        super.onStart();
        auth.addAuthStateListener(authStateListener);
    }

    @Override
    protected void onStop() {
        super.onStop();
        auth.removeAuthStateListener(authStateListener);
    }

FirebaseAuth クライアント API は、addAuthStateListener() でリスナーを追加した際に、2 つの主要な処理を必ず実行します。まずは、現在判明しているユーザーのログイン状態に基づいて、すぐにリスナーを呼び出します。もう 1 つは、リスナーが FirebaseAuth オブジェクトに追加されている限り、以降、ユーザーのログイン状態が変わるたびに毎回リスナーを呼び出します。この動作は Task とは大きく異なります。

Task の場合は、結果が利用可能になって初めて、追加されたリスナーを最大で 1 回だけ呼び出すことができます。また、リスナーが追加される前に、既に結果が利用可能であった場合は、Task はすぐにリスナーを起動します。Task オブジェクトは、最終的な結果オブジェクトを効率的に記憶しておき、その内容を以降のリスナーに引き継いで処理します。これは、リスナーがすべてなくなり、ガベージ コレクションが実行されるまで続きます。よって Task オブジェクト以外のもので、リスナーと連携する Firebase API を使用する際は、必ずその動作を理解するようにしてください。すべての Firebase リスナーが Task リスナーのように動作するわけではありません。

もう 1 つの重要なステップ

追加した Task リスナーのアクティブな有効期間を考慮しましょう。それを怠ると 2 つの問題が生じます。まず、追加したリスナーが参照しているアクティビティと、そのビューの有効期間を超えて Task が動作することで、アクティビティのリークが生じるおそれがあります。次に、不要になったリスナーが実行されると無駄な処理が走り、すでに無効なアクティビティ状態にアクセスする処理が行われる可能性があります。このブログの次のパートでは、これらの問題とその回避方法を詳しく説明します。

このシリーズのパート 1 のまとめ

今回は Firebase のサンプルコードについて簡単に説明し、Play Services Task API の概要と（隠された）使用法を紹介しました。Task は、Firebase において処理時間が予測できず、かつメインスレッド以外で実行すべき処理に対応するための手段です。Task を使用すると、リスナーによってメインスレッドに戻って処理結果を扱うようにすることもできます。ただ、この記事で紹介した Task の機能は、ほんの一部にすぎません。次の記事では、さまざまな Task リスナーを紹介しますので、ぜひ自身のユースケースに応じて最適なリスナーを選択してください。

質問がありましたら、Twitter でハッシュタグ #AskFirebase を検索するか、firebase-talk Google Group をご利用ください.専用の Firebase Slack チャネルも用意しています。Twitter で @CodingDoug のフォローもよろしくお願いします。


Posted by Khanh LeViet - Developer Relations Team

この記事は Emily Schechter、Chrome セキュリティ チームによる Google Online Security Blog の記事 "Moving towards a more secure web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーが安全にウェブをブラウジングできるように、Chrome はアドレスバーのアイコンに接続セキュリティを表示しています。今までの Chrome には、HTTP 接続は安全でないことが明示的に表示されていませんでした。しかし、2017 年 1 月（Chrome 56）より、パスワードやクレジット カードの情報を転送する HTTP サイトは安全でないことが明示されるようになります。これは、すべての HTTP サイトを安全でないものと明示する長期計画の一環です。



Posted by Eiji Kitamura - Developer Relations Team

 [この記事は Karolis Balciunas、Google Play 担当 VC & スタートアップ事業開発マネージャーによる Android Developers Blog の記事 "The Power Of “Early Access”" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

モバイルアプリをリリースしたことがある方なら、アプリを世界に向けてリリースして成功を収めるためには、ただ公開して祈るだけではいけないことはよくおわかりでしょう。

こまめにテストをしたり、ユーザーからのフィードバックのループを常に回したり、微調整を重ねたりすることこそが、心から願うような特別なリリースにつながるものです。

Google Play Developer Console では、ベータ版テストや、ストア掲載情報によるアプリのユーザーへのアピール方法の実験など、強力なツールが提供されています。この貴重な初期段階でのフィードバックを得るために必要なのはユーザーだけです。では、まだ完全にリリースされていない新製品の作業を進めているデベロッパーは、どのようにして新しいアプリを試してくれる人々を見つけ、フィードバックを提供する時間を割いてもらえばよいのでしょうか。

今も増え続ける 100 万人以上のテスター

5 月の Google I/O では、この課題に正面から対処する Google Play の新しい方向性が発表されました。そして、29 社のアプリやゲームのパートナーとともに「早期アクセス」コレクションを立ち上げ、公式リリース前に誰でも利用できるオープンベータ版を提供している新しい Android タイトルを選択できるようにしました。これは即座にヒットし、アーリー アダプターたちは、最新のアプリやゲームを楽しむチャンスを得ることになりました。そして、それと引き換えに、具体的なアクションにつなげることができる個人的なフィードバックを熱心かつ積極的に送ってくれています。最も重要なのは、相手を傷つけたくないと思うことが多い友人や家族とは違い、客観的で率直なフィードバックを得られることです。すべてのユーザーがこのコレクションを利用できるようになって 1 か月あまりで、オープンベータ版のタイトルは 100 万回以上インストールされ、さらに需要は拡大を続けています。

3 つの強力な事例

Google のローンチ パートナーたちは、さまざまな形で早期アクセスの力を実感しています。双方向型の言語学習デベロッパーである Lingbe は、ネイティブ スピーカーと語学学習者がアプリを使って音声通話接続をするというコンセプトを検証したいと考えていました。そのためには、世界中のさまざまな言語を話し、異なる文化的背景を持つ十分な数のユーザーに接続してもらわなければなりません。しかし、わずか数週間で、「現在のファン層に加えてユーザーが殺到しました。そして、ブラジル人がスペイン人と会話の練習をして趣味の写真について話し合ったり、メキシコ人がインドの人々と友だちになったり、フィリピン人がモロッコ人と話したりすることになったのです」。

Android で最初のオンライン ブッククラブの 1 つである Readfeed は、早期アクセスによって大きな読者コミュニティを構築できました。さらに、機能リクエストの募集、バグの発見、新しい対象マーケットの発見や既存の対象マーケットの最適化も行うことができました。Readfeed は次のように述べています。「早期アクセスによって対象マーケットが存在することや、ユーザーの求めるものがあることが確認できました。早期アクセスがなければ、今のような立場にはなっていなかったでしょう。1 日目からアイデアの検証や循環を効果的に行うことができたのは、早期アクセスのおかげです。」

最後の事例は、新しい「Wiz」アプリをテストするために早期アクセスに参加した Drippler です。これによって Drippler は、対象とするユーザー層にとってベータ版タイトルの魅力とは何かを理解することができました。早期アクセス コレクションでのパフォーマンスと、新しく獲得した数千人ものベータ版テスターからの個人的フィードバックによって、リリース前にアプリを改善することができ、ユーザーに楽しんでもらえるという確信も得ることができました。

この 3 社のデベロッパー ストーリーは、早期アクセスによってすばらしい新規アプリやゲームを構築できた事例の一部です。ここから、公開前の初期段階でベータ版テスターからフィードバックを得ることの価値がわかるでしょう。

早期アクセスに参加する

Google Play でのリリースの準備をしているデベロッパーの皆様であれば、アプリやゲームを早期アクセスに指定することができます。詳細については、こちらを参照してください。

新規タイトルは毎週追加されており、新しく楽しいアイデアを実験しようという何千人ものユーザーが待っています。

Posted by Takeshi Hagikura - Developer Relations Team

[この記事は Xiaowen Xin、Android セキュリティ チームによる Android Developers Blog の記事 "Keeping Android safe: Security enhancements in Nougat" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

この夏を通して、Android 7.0 Nougat のさまざまなセキュリティ拡張のプレビューが行われてきました。具体的には、セキュリティを重視した脆弱性報奨金プログラム、新しいダイレクト ブート モード、メディアサーバーの再構築、メディア スタックの強化、意図しないクリアテキスト トラフィックに逆行するアプリの保護、Android が信頼される証明機関を取り扱う方法の更新、セキュアブートの厳格な適用とエラー訂正、攻撃対象領域を減らしてメモリ保護を強化するための Linux カーネルの更新などがあげられます。すばらしいですね！

Nougat の展開が始まった今、これらのアップデートの概要を振り返りつつ、いくつかの新しい改善点について重点的に紹介したいと思います。

ダイレクト ブートと暗号化

以前のバージョンの Android では、端末を暗号化しているユーザーは、デフォルトで PIN / パターン / パスワードのいずれかを使用する必要がありました。これは、ブートプロセスでストレージ領域を復号化してブートを完了するために必要な操作でした。Android 7.0 Nougat では、基礎となる暗号化スキームがアップデートされ、ブートプロセスが効率化されているため、スマートフォンを高速に再起動できるようになっています。スマートフォンの主な機能である電話アプリやアラーム クロックは、PIN を入力する前であっても即座に利用できるようになります。そのため、PIN を入力しなくても電話を受けたり目覚ましを鳴らしたりできます。この機能は、ダイレクト ブートと呼ばれています。

内部的には、このユーザー エクスペリエンスの改善はファイルベースの暗号化によって実現されています。この新しい暗号化スキームでは、システムのストレージ領域やユーザー プロファイルはすべて個別に暗号化されます。すべてのデータがひとまとめで暗号化されるディスク全体の暗号化とは異なり、プロファイルごとの暗号化では、端末キーを使うだけでシステムを再起動して機能する状態にすることができます。重要なアプリはオプトインして再起動後に限定的な状態で実行できます。ロック画面で資格情報を入力すると、アプリはユーザーデータにアクセスして完全に機能できるようになります。

ファイルベースの暗号化を使用すると、細かい粒度でデータを暗号化し、個々のユーザーや端末上のプロファイルを個別に保護できます。各プロファイルは一意のキーによって暗号化され、PIN またはパスワードでのみロック解除できます。そのため、データは本人しか復号化できません。
暗号化のサポートは、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 の改善提案は大歓迎です。security@android.com までご連絡ください。


Posted by Yuichi Araki - Developer Relations Team

Google では、2016 年 10 月 7 日（金）に Material Design にフォーカスした開発者向けイベント「Google Developers LaunchPad Build Tokyo 2016」を開催いたします。本イベントでは、Google のエンジニアや外部の企業が、UI/UXを改善したことによって実際にどのような効果があったのかや、アプリの開発におけるデザインの活用方法などをご紹介します。


■イベント概要

• [イベント名] Google Developers LaunchPad Build : Tokyo 2016
• [日程] 2016 年 10 月 7 日（金）13:00 - 18:00 （開場 : 12:30）
• [場所] Hulic Hall （ヒューリック ホール）、東京都台東区浅草橋 1-22-16 ヒューリック浅草橋ビル 2 階
• [定員] 200 名

■プログラムの一部のご紹介

• Material Motion : アニメーションを効果的に使う方法
• アプリデザインで守るべき 25 のルール
• Material Design を活用している企業のセッション

[この記事は Parul Soi、Developer Relations プログラム マネージャーによる The Firebase Blog の記事 "The Firebase Blog: Pirate Metrics (AARRR) with Firebase" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

データを分析して適切な対応ができるかどうかによって、会社が成功するか失敗するかが決まる場合もあります。過去数年間、この分析するデータは大きく拡大し、それに関わるアプリ デベロッパーの数もトラッキングされるイベントの数も増え続けています。しかし、データが多すぎて何を探しているか自分でもわからなくなることが多いのが実情です。

では、製品を改善するためにどのような指標をトラッキングすればよいのでしょうか。

データ分析は非常に大きな分野であり、世界中でいくつかもの人気のある手法やフレームワークが使われています。特に技術製品に関連する分野で人気のあるフレームワークの 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

[この記事は Sam Thorogood、デベロッパー プログラム エンジニアによる Google Developers Blog の記事 "Closure Compiler in JavaScript" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Closure Compiler は、2009 年に元は Java でリリースされました。本日は、まったく同じ Closure Compiler がピュア JavaScript で Java を使わずに利用できることになったことをお知らせします。この仕組みは NodeJS 環境で実行するように設計されており、いくつかのよく使われているビルドツールをサポートしています。

初めて聞く方のために説明すると、Closure Compiler は JavaScript の最適化、トランスパイル、タイプチェックを行うツールです。これを使うと、コードを高パフォーマンスでサイズが縮小されたコードにコンパイルすることができます。この仕組みは Google のほとんどのウェブ フロントエンドで使われており、できる限りサイズが小さく高速なコードを提供しています。

let、const、アロー関数などの ES2015 の新機能をサポートしており、まだすべてではサポートされていない ES2015 メソッドの polyfill も提供しています。メンテナンス性や拡張性の高い優れたコードを書けるよう、Closure Compiler は構文チェック、タイプの使用法の訂正、さまざまな JavaScript における注意点についての警告も行ってくれます。チュートリアルなど、Closure Compiler の詳細は、Google Developers をご覧ください。

動作の仕組み

これは、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

[この記事は Doug Stevenson、デベロッパー アドボケートによる The Firebase Blog の記事 "Organizing your Firebase-enabled Android app builds" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

多くのデベロッパーの皆様に 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 プロジェクト全体であると言え、次の機能が該当します。

• Authentication
• Realtime Database
• Storage
• Hosting

また、Firebase の機能の中には、同じプロジェクト内のすべてのアプリで 独立してデータ を持つものもあります。これらの機能のスコープは、Firebase プロジェクトの個々のアプリであると言え、次の機能が該当します。

• Analytics
• Crash Reporting
• AdMob

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

DevFest は、Google Developer Group（GDG）コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は Android、Firebase、Google Cloud Platform、TensorFlow による機械学習、Webなどの Google のデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。

[この記事は Todd Kerpelman、デベロッパー アドボケートによる The Firebase Blog の記事 "Announcing Real-time Exporting of your Analytics Data into BigQuery" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

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

デベロッパーのみなさまに役立つ技術情報の収集チャネルである、日本語専用の YouTube チャネル Google Developers Japan に Google for Mobile Japan 2016 の講演動画全 42 セッションを公開しました。

今年の Google for Mobile では 5 月に米国で開催された Google I/O の振り返りを中心に、プロダクト マネージャーやエンジニアが世界中から参加し、最新情報を伝えました。
基調講演 Google I/O 2016 の振り返り
2016 年 5 月に Google I/O で発表されたサービスや機能、更新情報を振り返ります。ここで取り上げたトピックの詳細は Google for Mobile の各セッションで語られています。

基調講演 Firebase の概要
モバイルアプリの構築を加速する、Firebase の概要を 15 の各機能毎にお伝えします。Google for Mobile の他セッションでは Firebase の各機能をより深くご紹介しています。

ゲームのルール：ゲーム以外のアプリがゲームアプリから学ぶべきこと
非ゲーム系のアプリデベロッパーがゲームデベロッパーから学べるルールを、「”エンゲージメントの崖”にとことん向き合う」「ユーザーの多様性を理解し、受け入れる」「雨の降るとき、降る場所で傘を売る」の ３ つにまとめ、主に海外のデベロッパーの成功事例をもとにお話しします。
Firebase を使ったアプリ プロモーションの可能性
Firebase をアプリの成長に合わせてどの様に使うかなどの概要をアプリプロモーションの歴史を交えて語る前半と、後半は Firebase マーケティングの可能性と題して、既に導入をされているコミックスマート株式会社様、株式会社ネクスト様を招き、導入プロセス、開発、ビジネスの両面で活用している機能、アンインストール データから見えてきたユーザーの表情、今後の活用イメージなどについてお話しいただきました。

最新 Android Layouts
Android の画面の最新レイアウトである、Constraitnt Layout と Flexbox Layout を コードラボ情報と合わせご紹介します。

全てのセッションは Google I/O よりも短く再編成されて実施され、英語のセッションは日本語音声及び一部を字幕でご視聴いただけます。デベロッパーのみなさまが効率的により多くのトピックに接し、これまでよりもさらに素敵なサービスを開発されるヒントとなれば幸いです。


Posted by Hidenori Fujii - Google Play Team

[この記事は Todd Kerpelman、デベロッパー アドボケートによる The Firebase Blog の記事 "iOS 10, Xcode 8, and Swift 3, oh my!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

最新かつ最高のテクノロジーを導入した環境で、自身のアプリを正しく動作させることは非常に重要です。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

[この記事は William Denniss、ID および認証担当プロダクト マネージャーによる Google Developers Blog の記事 "Modernizing OAuth interactions in Native Apps for Better Usability and Security" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google ユーザーが Google アカウントを使って安全かつシームレスにサードパーティ アプリケーションへログインし、そのアカウントから選択したカレンダーや連絡先情報などの情報を他のアプリと自由に共有できるよう、ID チームは常に努力しています。

このようなインタラクションの背後で実行されているのが OAuth リクエストです。Google は何年もの間、デベロッパーの皆様が OAuth フローを実装するさまざまな方法をサポートしています。その方法の 1 つについて、セキュリティとユーザビリティの向上を考慮した結果、近日中にサポートを終了することになりました。数か月後、「ウェブビュー」と言われる埋め込みブラウザから Google への OAuth リクエストは許可されなくなります。ウェブビューには、Android の WebView UI 要素や iOS の UIWebView/WKWebView、Windows や OS X での同等の要素が含まれます。

埋め込みウェブビューではなく、端末のブラウザを使用して OAuth リクエストを行うことにより、アプリのユーザビリティは大幅に向上します。ユーザーは端末で 1 度だけ Google にログインすればいいため、アプリでのログインのコンバージョン率や認証フローが改善されます。Android の Chrome Custom Tab や iOS の SFSafariViewController など、いくつかのオペレーティング システムで利用できる最新の「アプリ内ブラウザタブ」パターンを使うと、ブラウザベースの OAuth フローの UX をさらに改善できます。

逆に、OAuth に埋め込みブラウザを使用する古い方式では、端末の既存のログイン済みセッションを使うことはできないため、ユーザーはその都度 Google にログインする必要があります。ウェブビューの内容はアプリが検査したり変更したりできますが、ブラウザ内に表示されるコンテンツではそれができないため、端末のブラウザの方がセキュリティが高くなります。

この移行をサポートするため、皆様が利用できる最新のベスト プラクティスに基づくライブラリとサンプルを公開しています。

• Google Sign-In: Android と iOS 向け。Google アカウントを使ったログインと OAuth の推奨 SDK です。
• AppAuth: Android と iOS および OS X 向け。Google などの OAuth プロバイダで使用できるオープンソース OAuth クライアント ライブラリです。さらに、Objective-C 向け Google API クライアント ライブラリで AppAuth サポートを有効にするライブラリ GTMAppAuth（iOS および OS X 向け）と、GTM Session Fetcher プロジェクトも提供しています。
• Windows 向け Google Sign-In および OAuth サンプル: Universal Windows Platform（UWP）コンソールや PC アプリなど、さまざまな Windows 環境からブラウザを使って 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

[この記事は Rahul Roy-Chowdhury、マネージメント担当副社長による Chromium Blog の記事 "From Chrome Apps to the Web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

私たちは、オープンで互換性があるウェブを作るということに関し、常にとても強い信念を持ってきました。ウェブには、あるときまで、オフラインでの動作、通知の送信、ハードウェアとの接続など、実現できない機能が存在していました。このギャップを埋めるため、私たちは 3 年前に Chrome アプリを公開しました。

そのときから、ウェブ標準化コミュニティとともに前述の機能を利用可能にし、ユースケースを増やしてきました。デベロッパーの皆様は、Service Worker  や プッシュ通知といった新しい API を使い、複数のブラウザで動作する、強固なプログレッシブ ウェブアプリ（PWA）をビルドすることができます。これからウェブ上で利用できる機能はさらに増えていく予定です。

私たちは、Chrome をシンプルにするための努力を続けていますが、Chrome アプリ プラットフォームを離れるという時期がきたと感じます。Chrome アプリにはパッケージ アプリとホストアプリの 2 種類がありますが、現在、パッケージ アプリを積極的に使っているのは、Windows、Mac、Linux ユーザーの約 1% に過ぎず、また、ほとんどのホスト アプリは通常のウェブアプリとしてすでに実装されています。そのため、Windows、Mac、Linux 上の Chrome で、今後 2 年をかけ、パッケージ アプリとホストアプリのサポートを段階的に終了していくことにしました。

Chrome OS 上の Chrome アプリは、すべての種類に関し、当面の間サポートが継続されます。Chrome アプリ プラットフォームの拡張は、キオスク端末を含む Chrome OS 端末のみに適用されます。デベロッパーの皆様は、Chrome OS 向けの Chrome アプリ（または Android アプリ）の構築を継続できます。

2016 年後半以降、新しく公開される Chrome アプリが利用できるのは、Chrome OS のユーザーのみとなります。既存の Chrome アプリに関しては、引き続きすべてのプラットフォームからのアクセスが可能で、デベロッパーはアップデートを継続できます。

2017 年後半以降は、Windows、Mac、Linux 上の Chrome ウェブストアでは、Chrome アプリは表示されなくなりますが、拡張機能やテーマは引き続き表示されます。2018 年はじめ頃には、前述のプラットフォームのユーザーは Chrome アプリを読み込めなくなります。

Windows、Mac、Linux プラットフォーム上では、デベロッパーの皆様に Chrome アプリをウェブに移行することを推奨します。完全にアプリをウェブに移行できないデベロッパーは、自身のケースを報告し、Chrome アプリとのギャップを埋める新しい API の開発で私たちが何を優先すべきかを明確にするサポートをお願いします。短期的には、Chrome 拡張機能や Electron または NW.js などのプラットフォームの使用も検討可能です。

ウェブの可能性は広がり続けており、デベロッパーによって次に何が作られるのかはとてもわくわくすることです。ウェブのオープンさと広いリーチによって得られるメリットをユーザーやデベロッパーの皆様が享受できるよう、Chrome 以外のブラウザ ベンダーとともに、私たちはウェブへの投資を続けることにコミットし続けていきます。


2017 年 12 月 5 日更新
12 月中旬より、Chrome ウェブストアでは Chrome アプリを検索しても表示されなくなります。既存のアプリは引き続き利用可能で、アップデートも受け取れます。

また、Windows、Mac、Linux プラットフォーム上の Chrome ブラウザにおける Packaged Apps および Hosted Apps の読み込みの廃止については、前回お知らせした 2018 年はじめ頃より後になる見込みです。サポート終了時期が決まりましたらまたこちらでお知らせをいたします。

Posted by Eiji Kitamura - Developer Relations Team