この記事は Chris Banes による Android Developers - Medium の記事 "Jetpack Compose — Before and after" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今年になってから、サンプル アプリTivi の UI を Jetpack Compose に徐々に移行していました。そして 2020  年 12 月第 2 週、移行作業の第一段階がほぼ完了しました。

今回のブログ投稿では、重要な指標の数値を振り返って比較し、Compose によって何が変わるのかを確認してみましょう。比較するのは、APK サイズ、ビルド速度、コードの行数です。


アプリの説明

Compose の話題を進める前に、まずは簡単にアプリについて説明します。

Tivi はかなり細かくモジュール化されており、それぞれの UI の「画面」ごとに Gradle モジュール（ui-$NAME）があります。それぞれの画面は Fragment で実装され、メインアプリ モジュールでは AndroidX Navigation を使ってそれらを組み合わせています。

Tivi モジュールのグラフ。Jake Wharton の Gradle task を使って作成


ナビゲーション グラフはディープリンク URI を使って実装されているので、ほとんどの Fragment はお互いのことを知りません。そのため、疎結合が保証されます。しかし、それよりも重要なことは、独立してコンパイルできるため、ビルドの並列化がしやすくなることでしょう。

Compose に移行する前の Tivi は、Android デベロッパーが利用できるありとあらゆるクールな UI を利用していました。一例をあげれば、データ バインディング、Epoxy、マテリアル デザイン コンポーネント、Insetter DBX、MotionLayout などです。しかし残念ながら、これらの大半ではアノテーション処理が使われているため、ビルドのコストがかかります。


第一段階の定義

先ほど、移行の「第一段階」を終えたばかりだと書きました。これはどういう意味でしょうか。2020 年 1 月にこの作業を始めたときから、アプリの見た目はほとんど変わっていません。

アプリがモジュール化されているということは、移行自体も部品単位になり、一度に 1 つの Fragment だけ移行できるということです。この 11 か月間はまさにそれを実践し、46 個のプル リクエストに対応しています。

最初に簡単な画面 Episode details を移行し、次に Show details、そして ‘Discover’、‘Search’、‘Followed shows’ と移行を進めました。最近追加された Compose の Paging3 サポートと合わせて、最後の画面となった ‘list’ グリッドを移行できました。

Tivi のマイグレーション前後を比較

2020 年 12 月 10 日（日本時間 12 月 11 日）、アプリから AppCompat、マテリアル デザイン コンポーネント、その他の AndroidX ウィジェット ライブラリを削除する処理を始めました。これは、Tivi の UI が Compose ベースになったことを意味します。

Remove AppCompat + MDC by chrisbanes · Pull Request #737 · chrisbanes/tivi

アプリで Fragment と Navigation を使っている点は変わりませんが、論理的な次のステップは、Fragment から移行して直接新しい Navigation Compose コンポーネントを使うようになります。

この移行の過程は近日中に別のブログ記事で書きたいと思いますが、本投稿の最後の「まとめ」から、私自身の言葉を引用しておきます。

いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。

では、いくつかの指標を確認してみましょう。


指標

以下のそれぞれの指標では、3 つのバージョンのアプリを比較します。

  1. Pre-Compose（Compose 前）: 2020 年 2 月時点、つまり Tivi に Compose サポートを追加する最初の PR を行う前のコミットです。

  2. Mid-transition（移行中）: これは現在のメインブランチのトップレベルのコミットで、すべての UI 画面が Compose で実装されています。しかし、AppCompat、MDC などへの依存関係はまだ（直接的または推移的に）存在しています。

  3. Without view libraries（ビュー ライブラリなし）: これは（現在の）ドラフト PR で、AppCompat、MDC などのすべての痕跡を強制的に取り除いたものです。


APK サイズ

ユーザーが最も気にする指標は、APK サイズです。 

以下の結果は、リソース圧縮を有効にし、R8 を使って最小化した release APK を APK Analyzer で測定したものです。

Tivi  の APK サイズ

Tivi の メソッド カウント


‘adjusted’（調整済み）の値と ‘Pre-Compose’ を比較すると、Compose を使った場合は APK サイズが 41%、メソッド数は 17% 削減されていることがわかります。

Compose を使った場合は、APK サイズが 41%、メソッド数は 17% 削減されていることがわかる

この数から、AppCompat や MDC などがアプリ内でどれほどの容量を占めているかがわかります。それだけではなく、レイアウト ファイルで使われる場合に備えてすべての View クラスを保持しなければならない場合には、最小化ツールはほとんど役に立たないこともわかります。


数字に関する注意点:

  • ここでは、（ダウンロード サイズではなく）APK Analyzer で報告される「APK ファイルサイズ」を使いました。

  • ‘Current’ と ‘Without view libs’（* 印）のどちらも、合計 APK サイズと res フォルダのサイズには、バンドルされる TTF フォント ファイルの 560 KB が含まれています。このファイルは、‘Pre-Compose’ の APK には含まれていません。その理由は、Compose がまだダウンロード可能フォントをサポートしておらず（バグ）、APK にバンドルする必要があるからです。‘adjusted’ 列は、テスト用にフォント ファイルを省き、同じ条件で比較できるようにしたものです。

  • ‘Mid-transition’ でサイズが増加しているのは、Jetpack Compose と AppCompat、MDC などの両方が含まれているためです。


コード行数 

ソフトウェア プロジェクトを比較する場合、ソースの行数を数えても特に役立つ統計情報にはならないことは承知していますが、この比較によって、どのような変化が起きているのかは確実に把握できます。

このテストでは、cloc ツールで以下のコマンドを使い、すべてのビルドと生成されたファイル、設定ファイルを除外しました。

cloc . --exclude-dir=build,.idea,schemas



cloc ツールにはコメントを無視する機能が組み込まれているので（ただし、検証はしていません）、上記は実際の「コード」の結果です。当然ながら、XML の行数は大幅に少なくなり、76% 削減されています。レイアウト ファイル、スタイル、テーマなど、たくさんの XML ファイルとお別れできます。

同じように興味深いのは、Kotlin の合計行数も減っていることです。仮説としては、アプリ内のボイラープレートが減り、たくさんのビューヘルパーやユーティリティ コードを削除できたためだと考えられます。3,000 行近くを削除できたこちらの PR をご覧ください。

Remove a load of old code 🗑️ by chrisbanes · Pull Request #713 · chrisbanes/tivi


ビルド速度

ビルド速度はデベロッパーの関心が非常に高い指標です。このプロセスを開始する前は、多くのアノテーション プロセッサを削除できることでビルド速度が向上するものと考えていましたが、どの程度かはよくわかりませんでした。


テストの設定

説明を続ける前に、以下の数値をどのようにして測定したのかを知っておくことが重要になります。ここでは、Chris Horner が異なる CPU でビルド速度を測定したときと同じ設定を使いました。

テストに使ったマシンは、192 GB の RAM と超高速な Xeon® Gold 6154 CPU を搭載した Lenovo P920 です。言うまでもなく、このマシンは一般的なデベロッパーの設定ではありません。そこで、現実に近いテストを行うため、CPU を最低クロック周波数に固定しました。

# Use performance governor to allow tweaking of max freq

sudo cpupower frequency-set -g performance

# Set max frequency to CPU minimum: 1.2GHz

sudo cpupower frequency-set -u 1.2GHz

その後、すべてのリモート アーティファクト キャッシュを準備するため、./gradlew assembleDebug を実行しました。

そして、テストを実行するため、次のコマンドをループで 5 回実行します。

./gradlew --profile \

          --offline \

          --rerun-tasks \

          --max-workers=4 \

          assembleDebug


厳密には --max-workers は必要ありませんが、この CPU では、デフォルトで Gradle が利用できる 64 個の「コア」のすべてが使われます。これを 4 に制限することで、通常のラップトップ CPU と比較しやすくします。


結果

テスト結果は以下のとおりです。それぞれの結果プロファイル レポートの ‘Total Build Time’（合計ビルド時間）の値をご覧ください。


この結果にはかなり驚かされました。ほとんど数値が変わらなかったからです。予想では、多くのアノテーション プロセッサが削除されることで、‘Without view libs’（ビュー ライブラリなし）が大幅に速くなると思っていました。

結果の明細を見てみると、kapt の実行時間はすべて同じくらいでした。おそらくこれは、View Binding、Dagger/Hilt、Room の使用を継続しているためではないかと思います。

しかし、Kotlin コンパイラや Compose コンパイラ プラグインが行ってくれることを考えれば、ビルド時間が 5% 削減されたことに何も不満はありません。

注意点

これまでに説明してきた全ての結果に当てはまる注意点があります。

機能に関する作業

この 11 か月間、Tivi には何の機能も追加しませんでしたが、この点を厳密に制限したわけではありません。移行とはあまり関係のない部分で多くの変更を行っており、それが結果に影響した可能性もあります。

依存性の更新

移行を行った 11 か月間で、多くの依存性が更新されました。ほとんどの依存性の更新はランタイム ライブラリの依存性だったので、APK サイズ指標に影響する可能性は低いはずです。

Gradle のアップデート（6.0.1 から 6.7.0）、Android Gradle Plugin のアップデート（3.6.0 から 4.2.0）、そして Kotlin のアップデート（1.3.61 から 1.4.20）などは、すべてビルド速度に大きな影響があります。

Compose はアルファ版

Compose は現在アルファ版なので、すべての成果物は開発中のスナップショットになります。来年 1.0 の安定版になったとき、これらのテストを再実行して違いが出るかを見るのが楽しみです。

まとめ

結果と注意点を見る限り、リンゴ 🍎 とリンゴ 🍏 を比較しているわけではない（同じ条件で比較しているわけではない）ので、あまり多くの結論を出すべきではありません。これは、リンゴ 🍎 とそれよりも少し甘いナシ 🍐 を比べているようなものです。

果物の例はさておき、最大のポイントは Compose がほとんどのデベロッパー指標で良好な（または中立的な）影響を示していることです。この点と Compose でデベロッパーの生産性が大幅に向上することを踏まえれば、いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。


Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC


個人や小規模グループでゲームを開発するデベロッパーの情熱やイノベーションを称えるため、今年 3 年目となる Google Play | Indie Games Festival 2020 を開催しました。例年のようにファイナルイベントを公開対面形式で実施できないため、オンラインでの最終選考会をデベロッパーや、株式会社 Sisilala 安藤様を始めとする業界のさまざまな方からのご協力のもと開催することができました。

多くの取り組みが変更を余儀なくされる中でも、従来のイベントでは実現できなかった Top 20 全作品のプレゼンテーション枠の確保など、オンラインだからこそ実現できることに取り組みました。動画内では、Top 3 に入賞した合同会社リビルドゲームスの「METBOY!」様からイベントに対する感想も頂戴しています。

Google Play | Indie Gaes Festival 2020 の詳細をまとめた動画をご覧ください。




Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

It’s a wrap_content!

Modern Android Development（最先端の Android 開発）について取り上げる連載シリーズ MAD Skills の動画と記事の 3 番目のトピックが完結しました。今回は、マテリアル デザイン コンポーネント（MDC）についてご説明しました。このライブラリは、マテリアル コンポーネントを Android ウィジェットとして提供します。これを使うと、マテリアル テーマ、ダークテーマ、モーションなど、material.io で使われているデザイン パターンを簡単に実装できます。

説明した内容については、下記にまとめた各エピソードからご確認ください。これらの動画では、MDC についての最新の記事や、既存のサンプルアプリ、Codelab を詳しく説明しています。また、MCD チームのエンジニアによる Q&Aセッションも含まれています 。

エピソード 1: MDC を使う理由

最初のエピソードは、Nick Butcher が、なぜ私たちが MDC の利用を推奨するのかなど、今回の MAD Skills シリーズ全体の概要を説明しています。その後、マテリアル テーマ、ダークテーマ、モーションについて詳しく掘り下げていきます。また、MDC を Jetpack Compose と合わせて使う方法、MDC やテーマ、スタイルのベスト プラクティスを含むようにアップデートされた Android Studio のテンプレートについてもお話ししています。


エピソード 2: マテリアル テーマ

エピソード 2 では、Nick Rout がマテリアル テーマについて説明し、Android で MDC を使ってこれを実装するチュートリアルについて解説しています。主な内容は、Theme.MaterialComponents.* アプリのテーマを設定し、material.io のツールを使用して色や種類、形状の属性を選択し、最終的にそれらをテーマに追加して、ウィジェットがどのように自動的に反応して UI を適応させるかを確認します。また、テーマカラー属性を解決する、イメージに図形を適用するなど、MDC が特定のシナリオ向けに提供している便利なユーティリティ クラスについても説明します。


エピソード 3: ダークテーマ

Chris Banes が、Android アプリで MDC を使ってダークテーマを実装する方法を紹介しています。説明する内容は、Force Dark を使って短時間で変換しビューを除外する方法、デザインを選んでダークテーマを手動で作成する方法、`.DayNight` MDC アプリテーマ、`.PrimarySurface` MDC ウィジェット スタイル、そしてシステム UI を扱う方法などです。


エピソード 4: マテリアル モーション

エピソード 4 では、Nick Rout がマテリアルのモーション システムについて解説しています。また、既存の「Android でマテリアル モーションを使って美しい画面遷移を構築する」Codelab の手順を詳しくフォローしています。この Codelab では、Reply サンプルアプリを使って、コンテナ変換、共有軸、フェードスルー、フェードという遷移パターンを活用してスムーズでわかりやすいユーザー エクスペリエンスを実現する方法を紹介しています。また、Fragment（Navigation コンポーネントを含む）、Activity、View を使うシナリオについて説明しています。


エピソード 5: コミュニティ Tip

エピソード 5 は、Android コミュニティから Google Developer Expert (GDE) の Zarah Dominguez さんが、MDC カタログアプリをウィジェットの機能や API の例として参考にしながら紹介してくれました。そのほか、異なる画面やフローにまたがる一貫したデザイン言語を確保するために、彼女が取り組んでいるアプリに「テーマショーケース」ページを構築することが、どのように有益であるかを説明しています。


エピソード 6: リアルタイム Q&A

最後のまとめとして、Chet Haase が MDC エンジニアリング チームの Dan Nizri と Connie Shi と一緒に Q&A セッションを行い、Twitter や YouTube で寄せられた皆さんからの質問に回答しました。このセッションでは MDC の起源、AppCompat との関係、今までの改善点について解説したほか、テーマやリソースを整理するためのベストプラクティス、さまざまなフォントやタイポグラフィ スタイルの使用方法、シェイプ テーミングなどについてお話しました。また、私たちはお気に入りの Material コンポーネントをすべて公開し、最後に、将来的に MDCと Jetpack Compose という Androidの次世代 UI ツールキットでは、デフォルトで Material Design が組み込まれる新しいコンポーネントが登場することについて議論しました。


サンプルアプリ

このシリーズでは、MDC のデモとして、次の 2 つのサンプルアプリを使いました。

  • 「Build a Material Theme」（別名 MaterialThemeBuilder）は、色、書体、形状の値をカスタマイズして独自のマテリアル テーマを作成できるインタラクティブ プロジェクトです。

  • Material Studies にも含まれている Reply は、マテリアル デザイン コンポーネントとマテリアル テーマを使ってブランドに合わせたコミュニケーションを作成できるメールアプリです。

これらは、もう 1 つの Material Studies のサンプルアプリである Owl とともに、GitHub リポジトリの MDC サンプルで確認できます。


Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC


Google は最新の技術情報やツールを、ウェブサイトやブログ、メール、各種動画、オンラインや対面のイベントで広くデベロッパーの皆さまに提供しています。2020 年はオンラインでの情報発信を強化し、Android 11 Android Developers Japan Blog の開設や、Android 11 Meetups をはじめ、さまざまなイベントをオンライン開催に切り替えました。以前より、サービスの改善と技術力、スキルの向上に Google の最新技術を積極的にご活用頂いている株式会社 LIFULL は、昨年から本年にかけてマテリアル デザインを使ってアプリの UI/UX を刷新しました。大規模な改修の後にも関わらず、ユーザー レビューで高い評価を得るなど、ビジネス面でも良い結果を残すことができました。

株式会社 LIFULL の取り組みをまとめた動画をご覧ください。



Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems


この記事は Justin Poehnelt による Google Cloud Blog の記事 "Google Maps Platform JavaScript API and TypeScript" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google では今年 7 月から、Maps JavaScript API のドキュメントにて TypeScript のサンプルの公開を開始しました。これは、最先端をいくウェブ デベロッパーを支援することを目的としたものです。JavaScript デベロッパーを対象にした 2019 年の調査によると、およそ 60% の人が TypeScript を使用したことがあり、今後も使用するつもりであると回答しています。また、同言語を学ぶことに興味があると回答した人の割合は 20% を超えています。Google では、Google Maps Platform デベロッパーが開発を行いやすい環境の整備に努めています。TypeScript は人気が高まっているだけでなく、Google Maps Platform での開発時にコード検証ができて便利であるという点からも、Google ではこの言語をサポートすることを重視しています。

新しいサンプルコードを表示するには、任意のスニペットで TypeScript タブをクリックします。たとえば、JavaScript 用の Simple Map のサンプルは以下のとおりです。

JavaScript タブのコード スニペット

ここに、TypeScript のタブが以下のように追加されました。

TypeScript タブのコード スニペット

TypeScript と Google Maps Platform のガイドでは、使用可能なコンパイラ オプションやインストール手順など、基本的な情報を紹介しています。入門に最適な内容となっていますので、ぜひご活用ください。なお、サンプルコードの公開にあたっては、オープンソースの TypeScript コミュニティの成果および DefinitelyTyped で維持、公開されている型定義を大いに活用させていただきました。これらの型は、NPM で以下を実行してインストールできます。


npm i -D @types/googlemaps

もちろん、サーバー環境で Google Maps Platform の API を使用している Node.js デベロッパーのことも忘れていません。クライアント ライブラリの TypeScript 書き換えを今年すでに公開済みです。

Google Maps Platform の詳細については、ウェブサイトをご覧ください。ウェブサイトでは  Google Maps Platform の詳細やニュースレターの購読などをご案内しています。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer

Modern Android Development（最先端の Android 開発）の Android App Bundle ミニシリーズが最終回のリアルタイム Q&A セッションで完結しました。私は Chet Haase、Wojtek Kaliciński、Iurii Makhno とともに、Twitter の #AskAndroid ハッシュタグやライブ ストリームのチャットから寄せられたたくさんの質問にお答えしました。

ここで少し時間を巻き戻して、最初から振り返ってみることにしましょう。

Android App Bundle の概要

最初のエピソードでは Wojtek が、なぜデベロッパーやアプリにとって App Bundle が重要なのかを説明し、このシリーズの方向性を示しました。



Google Play アプリ署名について知っておくべきこと

このエピソードでは、Wojtek が Play Console について詳しく解説しました。Play App Signing をオプトインする方法を学習でき、Play App Signing をオプトインする際に利用できるオプションについて理解できるはずです。



この動画と合わせて、 ブログ記事 Answers to common questions about Play App Signing やアプリ署名についての Android ドキュメント、Play Console のヘルプページの Google Play アプリ署名を使用する も参照することをおすすめします。  


初めての App Bundle のビルド

次に、初めての Android App Bundle をビルドしてアップロードする方法を学びました。このエピソードでは、Android Studio とコマンドライン インターフェースを使ってバンドルをビルドする手順について、私がご説明しています。



このエピソードはブログ記事（英語）で読むこともできます。合わせて、App Bundle のドキュメントもご覧ください。 


アプリで Play Feature Delivery を設定する

このエピソードでは、配信オプションについて学ぶことができます。インストール時の配信に加え、条件付き配信やオンデマンド配信など、あらゆることを解説しています。また、 GitHub のサンプルについても説明しています。



このエピソードもブログ記事（英語）で読むことができます。さらに、重要な参考資料として Play Core ガイドも準備しています。 

bundletool と Play Console で App Bundle をテストする

App Bundle のテスト方法について疑問に思ったことはないでしょうか。もうその必要はありません。Wojtek が ご説明する App Bundle をローカルと Play Console でテストする方法についての動画をご覧ください。



このエピソードのコンテンツは、ブログ記事（英語）やガイド Android App Bundle のテスト で読むこともできます。


さらに、Play Console のデベロッパー ツールにガイドを掲載しており、Play Console のヘルプページでは内部アプリ共有の説明も確認できます。

また、bundletool をダウンロードしたい方は、こちらをご覧ください。

Android App Bundle で大きな節約

Android GDE の Angélica Oliveira さんが、Android App Bundle への切り替えを行った手順と、そのときに経験した大幅なサイズの削減について解説しています。



リアルタイム Q&A セッション

Twitter で質問を募集したところ、皆さんから #AskAndroid ハッシュタグ付きの返信をいただき、リアルタイム Q&A セッションの間も質問は続きました。Chet と Wojtek、Iurii、そして私がカメラの前に立ち、皆さんの質問にお答えしました。



お知らせ: 2021 年 8 月から新規アプリで App Bundle が必須に

詳しくは 2021 年の新しい Android App Bundle とターゲット API レベル要件をご覧ください。


Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC


多くのユーザーが、お気に入りのウェブサイトで使う支払い情報やパスワードを Google アカウントに保存して、簡単にアクセスできるようにしています。しかし最近まで、Chrome でこういった情報にアクセスするのは必ずしも簡単とは限りませんでした。たとえば、（ようやく）ぴったりのホリデーギフトを見つけて購入手続きを始めても、そのデバイスで Chrome の同期をオンにしていない限り、Password Manager に保存したログイン認証情報や、アカウントに追加した支払い方法を使うことはできませんでした。 

昨年この点を変更し、Google アカウントの支払い方法に簡単にアクセスできるようにしました。その後も、Chrome から Google アカウントの情報に簡単かつ直感的にアクセスできるようにし、他の機能やユーザーに同じようなログイン体験を提供するための作業を懸命に進めています。そしてうれしいことに、今後の数週間から数か月間で、同期しているかどうかにかかわらず、ログインしているすべてのユーザーが支払いとパスワード管理をシームレスに利用できるようになることをお知らせします。

Android でのログインがさらに便利に

Google アカウントを最大限に活用してもらえるように、まもなく Android 版 Chrome でタップ 1 回でログインできるようになります。この機能は、同期を行っていない場合でも利用できます。Gmail などの Google のサービスにログインする場合は、1 回のタップで認証情報を再入力することなく、デバイスのいずれかの Google アカウントで Chrome にログインできるようになります。デバイスにアカウントを追加せずにログインしたい場合は、単純にダイアログを閉じることもできます。一時的なセッションでブラウジングしたい場合は、メニューからすばやくシークレット モードを開くことができます。



Android 版 Chrome による支払いが簡単に

近いうちに、新しいシングルタップ オプションを使って Android スマートフォンで Chrome にログインした場合に、Google アカウントに保存した支払い方法を自動入力できるようになります。これにより、ショッピング体験がさらに快適になります。Chrome は、カードの CVC の確認や生体認証を求め、その後に処理を継続できます。アカウントに新しいクレジット カードを保存し、すべてのデバイスで利用することもできます。アカウントにカードを保存すると、そのたびに確認メールが送信されます。カード情報は、アカウントの支払い方法のページからいつでも管理したり削除したりできます。



PC 版 Chrome によるパスワード管理が簡単に

Google アカウントに保存したパスワードにもっと柔軟にアクセスしたいというフィードバックが寄せられています。そこで、今後数か月間で、デバイスを問わず、安全かつ簡単にパスワードにアクセスして管理できるようにします。これは、同期を有効にしているかどうかにかかわらず、Google アカウントにログインするだけで可能になります。アカウントにパスワードを保存してあるサイトでは、そのパスワードを自動入力できます。また、新しくパスワードを保存する場合、Chrome はデバイスと Google アカウントのどちらに保存するかを確認します。アカウントを選択すると、すべてのデバイスからアクセスできるようになります。

この変更により、さらに多くのユーザーに Chrome のパスワード生成機能を使ってもらえるようになります。そのため、ユーザーが Chrome で管理している多くのオンライン アカウントで、強固な専用パスワードを作成できます。



以上の機能は今後数か月間で導入される予定ですので、ぜひご注目ください。いつものように、今後のアップデートについてのブログもお見逃しなく。

Reviewed by Eiji Kitamura - Developer Relations Team



2020 年 12 月 17 日、Chrome と Web に関する最新情報を日本語でエキスパートと Google  関係者がお話しする Chrome Dev Summit Recap 2020 を開催しました。また、リアルタイムでお寄せいただいた質問に回答する時間を設け、直接ご意見やご質問を伺うことができました。

この記事では、本イベントを振り返り、補足や Fireside Chat でご紹介した動画をまとめます。なお、イベントの配信アーカイブは約 1 ヶ月程度イベントページより視聴が可能です。イベント中に参加登録されていない方も、登録後にご覧いただけます。当日の模様は、Twitter #ChromeDevSummit（日本語）でもご確認いただけます。

Core Web Vitals

  • Core Web Vitals に最適化した UX パターン
  • Fireside Chat
  • Q & A

よりよいユーザエクスペリエンスを、Core Web Vitals に悪影響を及ぼすことのない形で提供する UX パターンについて、実践的なアプローチや事例を交えて取り上げました。Fireside Chat で取り上げた関連動画もご覧ください。（日本語字幕あり）


Web アプリ

  • 次世代のデスクトップ Web アプリ
  •  Fireside Chat
  • Q & A

Web ベースで動作するアプリを開発するためにリリースされた様々な新機能についてご説明しました。Fireside Chat でご紹介した楽天様の事例はこちらです。（英文）


開発ツール/デバッグ

  • Chrome DevTools の新機能
  • Fireside Chat
  • Q & A

Chrome DevTools の新しい機能の概要をご説明しました。Fireside Chat でご紹介した動画もご覧ください。(日本語字幕あり)

開発ツール関連

開発効率 / 開発体験の向上

Trust & Safety

  • プライバシーを強化して広告コンバージョンを測定するための方法
  • Fireside Chat
  • Q & A

サードパーティの Cookie を必要とせずに主な広告のユースケースを取得するための API、コンバージョン測定 (Conversion Measurement) を積極的に開発しています。 API の仕組みや、API がどう cookie よりもプライバシー強化に繋がるかをご説明しました。Fireside Chat で取り上げた関連動画もご覧ください。（日本語字幕あり）


その他、Chrome Dev Summit 2020 の動画を多数公開しています。すべて日本語字幕に対応していますので、こちらの再生リストからご覧ください。



Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems


この写真から、3D マッピングを活用した補正を行わない場合、GPS の結果が不安定になって通りの反対側（または誤った区画）を指す頻度が高くなることがわかります。一方、3D マッピングを活用した補正を行うと、位置は何倍も正確になります。


これまで問題が解決できなかった理由

都市部では GPS が構造的に誤った場所を指す点が今までの問題でした。その問題は、すべての GPS システムが衛星からの見通し線に基づいて位置を特定しているために引き起こされています。しかし大都市では、直接の信号は建物によって妨害されるため、ほぼすべての信号が障害物に反射した後に届くことになります。


GPS チップは信号が見通し線上にあることを仮定しているので、信号が余分な経路を通過してきた分だけ、計算に誤差が生じます。最も一般的な副作用は、位置が通りの反対側に表示されることですが、特に多くの高層ビルが建っている大都市では、誤った区画に表示されることもあります。

この問題は、10 年以上にわたって解決が試みられてきました。しかし、Android に 3D マッピングを活用した補正が搭載されるまでは、大規模な解決策は存在しませんでした。 


3D マッピングを活用した補正の仕組み


Google Play サービスの 3D マッピングを活用した補正モジュールには、Google が保持している世界中の 3,850 以上の都市の 3D 建造物モデルのタイルが含まれています。現在、Google Play サービスの 3D マッピングを活用した補正は、歩行者による利用のみをサポートしています。歩きながらデバイスの GPS を使うと、Android の Activity Recognition API が今歩行していることを認識します。さらに、3,850 以上の都市のいずれかにいる場合、その都市の 3D モデルのタイルがダウンロードされ、スマートフォンにキャッシュされます。キャッシュのサイズは約 20 MB で、写真 6 枚程度の大きさです。

このモジュールでは、3D マッピングを活用した補正アルゴリズムが難問を解決します。つまり、GPS の位置が正しくない場合、どうすれば信号を妨害したり反射したりしている建物を知ることができるかという、卵が先か鶏が先かわからないような問題です。この問題は、3D マッピングを活用した補正によって解決され、FLP には一連の補正済みの位置が渡されます。システム API はこの情報を GPS チップに渡し、チップがそれ以降の GPS 精度を改善できるようにします。

12 月の Pixel Feature Drop では、Pixel 5 と Pixel 4a(5G) を対象に、3D マッピングを活用した補正のバージョン 2 をリリースします。これにより、通りの反対側を指すという現象の発生率が約 75% 減少します。Android 8 以降を使っているその他の Android スマートフォンでは、FLP にバージョン 1 が実装されており、通りの反対側を指すという現象の発生率が約 50% 減少します。2021 年初頭には、Android エコシステム全体（Android 8 以降）でバージョン 2 を利用できるようになる予定です。

Android の 3D マッピングを活用した補正は、米国の Global Positioning System（GPS）に加え、その他の Global Navigation Satellite System（GNSS）の信号にも対応しています。具体的には、GLONASS、Galileo、BeiDou、QZSS の信号です。

GPS チップ パートナーは、それぞれのテクノロジーにおけるこの作業の重要性について、次のように述べています。


「ユーザーは、モバイル スマートフォンの位置情報やナビゲーション機能の精度に依存しています。位置情報テクノロジーは、お気に入りのレストランを見つけたり、タイミングよくライドシェア サービスを利用したりする際に非常に重要ですQualcomm Technologies は、Google の 3D マッピングを活用した補正を組み込んだ最新のQualcomm® Location Suite テクノロジーによるユーザー エクスペリエンスの改善で、主導的な役割を果たしています。今回の Google との共同作業は、歩道レベルの精度の位置情報実現に向けた重要なマイルストーンです」

―― Qualcomm Technologies, Inc. プロダクト管理担当副社長、Francesco Grilli 氏


「Broadcom は、BCM47765 二周波 GNSS チップのナビゲーション エンジンに Google の 3D マッピングを活用した補正を組み込みました。二周波の L1 および L5 信号と 3D マッピングを活用した補正を組み合わせることで、アーバン キャニオンでこれまでにない精度を実現できます。L5 と Google の補正を組み合わせれば、都市部での GNSS の活用に革命を起こすことができます」

――Broadcom Inc. エンジニアリング担当シニア ディレクター、Charles Abraham 氏


「Google の 3D マッピングを活用した補正によって、スマートフォン ユーザーが都市環境で歩行しているときの個人の位置情報の精度が大きく進展しました。MediaTek Dimensity 5G ファミリーは、3D マッピングを活用した補正に対応しています。これにより、高精度デュアルバンド GNSS や業界トップレベルのデッドレコニング パフォーマンスに加えて、最高精度のグローバル位置情報を 5G スマートフォン ユーザーに提供できます」

―― MediaTek


3D マッピングを活用した補正を利用する方法

Android 8 以降を実行しているスマートフォンでは、3,850 以上の都市で GPS をオンにして歩行しているときに、Android の 3D マッピングを活用した補正が自動的に作動します。デベロッパーがこの改善を活用する最適な方法は、FLP を使って位置情報を取得することです。GPS チップによるさらに高度な 3D マッピングを活用した補正は、現在のところ、Pixel 5 と Pixel 4a 5G で利用できます。また、今後数週間のうちに、Android エコシステム全体（Android 8 以降）に対してロールアウトされる予定です。今後、運転中などの他のモードもサポートする予定です。

Android の 3D マッピングを活用した補正は、以下を含む 3,850 以上の都市で利用できます。 

  • アジア: 日本と台湾のすべての主要都市

  • 北米: 米国、カナダ、メキシコのすべての主要都市

  • ヨーロッパ: すべての主要都市（ロシアとウクライナを除き 100%）

  • その他: ブラジル、アルゼンチン、オーストラリア、ニュージーランド、南アフリカのすべての主要都市

Google Earth 3D モデルの拡張とともに、3D マッピングを活用した補正の範囲も広がります。

Google マップにもアップデートが行われます。これにより、一部の都市で、歩道、横断歩道、安全地帯などの歩行者向けの街区レベルの情報の精度が向上します。2021 年には、Google Maps Platform を使っているアプリにもこのアップデートが提供されます。3D マッピングを活用した補正による位置情報の精度向上と合わせて、皆さんのようなデベロッパーが、世界中で Android を使っている 20 億人の歩行者のユースケースのサポートを向上させてくださることを期待しています。


位置情報の継続的な改善


私たちは 3D マッピングを活用した補正の他にも、位置情報の精度と利便性を向上させる努力を懸命に続けています。Fused Location Provider API（FLP）の最新の改善項目は、以下のとおりです。

  • デベロッパーは、現在の位置情報を取得する簡単な方法を求めていました。新しい getCurrentLocation() API を使えば、1 回のリクエストで現在の位置情報を取得できます。位置情報の変化を継続的に取りにいくする必要はありません。この新しい API は、必要なときだけ位置情報をリクエストできるようにすることで（また、自動的にタイムアウトしてオープンな位置情報リクエストをクローズすることで）、電池の寿命も改善します。最新の Kotlin サンプルもご覧ください。

  • Android 11 の Data Access Auditing API は、アプリやその依存関係からのユーザーのプライベートなデータ（位置情報など）へのアクセスについて、透明性を高めます。この API では、FusedLocationProviderClient で属性タグが新しくサポートされているので、デベロッパーは今まで以上に簡単に、アプリの位置情報サブスクリプションや定期的な位置情報リクエストを監査できるようになります。詳しくは、こちらの Kotlin サンプルをご覧ください。


Qualcomm および Snapdragon は、Qualcomm Incorporated の商標または登録商標です。Qualcomm Snapdragon および Qualcomm Location Suite は、Qualcomm Technologies, Inc. および/またはその子会社の製品です。


Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC


2020 年は、予想もつかない事態が続く中で、困難な状況をポジティブに変える取り組みに多くのデベロッパーの皆さまが精力を傾けてこられました。世界保健機関（WHO）と世界中のゲーム関連事業者が提唱した #PlayApartTogether （離れていっしょに遊ぼう）キャンペーンを日本でも立ち上げ推進した、株式会社ミラティブと株式会社ミクシィの取り組みもその 1 つです。

Google Play では Play ストアに特集ページを設け、賛同デベロッパーのゲームを掲載しました。詳細をまとめた動画をご覧ください。



Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

アプリユーザーの離脱を防ぐには


手遅れになる前に対処する

アプリのユーザーは、3 つの基本的なグループに分けることができます。それは、エンゲージメントがない（獲得戦略によって新たに引き寄せられたグループ）、エンゲージメントが増加中（利用維持戦略によって利用が促進されたグループ）、エンゲージメントが減少中（離脱阻止戦略によってつなぎ留められているグループ）の 3 つです。これらはすべて異なる戦略が関わっているので、獲得、維持、離脱阻止をまったく別の領域として考えることは理にかなっています。しかし、離脱との闘いは軽視されることが多く、獲得の増加や、エンゲージメントの高いユーザーの維持率を上げることで、相殺できたりするものと見なされがちです。

前回の記事（英語）では、どうすればデベロッパーが効果的な維持戦略を策定できるかについて説明しました。これは、エンゲージメントの高いユーザーを維持する可能性を高めることを狙った戦略です（さらに細かく掘り下げたレポート全文をご覧ください）。しかし、戦略やアプリがどれほど素晴らしいものであっても、いくらかのユーザーは離脱してしまうものです。

ユーザーの離脱は、目先の収益以上の損失を会社にもたらします。例えば、早い段階でユーザーが離脱すれば、そのユーザーの獲得コストは完全に無駄であったということになります。また、離脱したユーザーを再定着させることは可能ですが、それには新しいユーザーを獲得するよりも費用も時間もかかる可能性が高いです。

ユーザーを再定着させるには、そもそもユーザーの離脱を引き起こした問題を直接的に克服しなければなりません。そのコストを考えると、ユーザーを再定着させるよりも、最初からユーザーが離脱しないようにあらかじめ手を打っておくほうがはるかに効果的です。

それでは、どうすれば手遅れになる前に行動できるのでしょうか。


明確な離脱予測を確立する

離脱を防ぐということは、離脱が起こる前に対処するということです。すなわち、警告システムを作り、離脱の兆候を特定して早い段階で行動するのです。ユーザーは一夜にして離れるわけではありません。離脱する前には、アプリの使い方が変わり始めます。そしてそれは、計測して特定することが可能です。この危険信号を特定するには、以下の様なデータを確認し、離脱するユーザーがどのような行動をとっているのかを調べます。

  • 離脱ポイント: 通常、ユーザーが離脱する前に、どのくらいの期間休眠状態になるかを調べます。離脱したユーザーと過去の利用状況のデータを調査し、アプリに関係するパターンを特定します。

  • 利用パターンの変化: 離脱前には、利用の頻度や時間が減少し始めるのが一般的です。離脱を示すその他の一般的なパターンとして、表面的な使用になる、セッション時間が短くなる、主要機能を使わなくなる、「キャンセル方法」のページを見るなどがあります。

  • 使用率: 利用の低下率を調べることも重要です。使用時間が突然減った場合は、迅速な対応が必要です。一方、徐々に低下した場合は、もう少し時間をかけて対策を取ることができます。

Quickbooks は、詳細なモデリングによって最近離脱したユーザーの行動を分析し、高い離脱率と相関性のある行動に注目した「ユーザー リスク プロフィール」を作っています。

これは 200～300 種類のアプリ内行動をまとめたもので、機能を使用しない、休眠の日数、重要指標を達成できない、などが含まれています。詳しい方法について知りたい方は、こちらの記事（英語）をご覧ください。 

Quickbooks は、このような「点検」を行うことで、即座に介入して独自の方法で望ましい行動を促し、離脱のリスクを軽減できるようにしています。 


アプリの価値を高める

離脱を予測できるようになったら、離脱する可能性が高いユーザーを特定してアプリに呼び戻すことを試みます。そのためには、ユーザーにアプリの価値を再認識してもらわなければなりません。既に使っている機能についてのリマインダーを表示したり、近くリリースされる機能に期待してもらったりすることも効果的です。

これを行う方法の 1 つは、ユーザーがアプリを使って既に実現したことを思い出してもらうことです。Yazio は、ユーザーの進捗を目に見える形で継続的に追跡し、離脱を防ぐ方策として、頻繁にお祝いの言葉を贈っています。進行状況バーと祝福の画面を使ってユーザーのモチベーションを上げ、目標の達成を促します。

可能な限りコンテンツをパーソナライズし、ユーザーに自分が大事にされていると感じてもらえるようにするのも効果的です。Mobills は、使用率が低下したユーザーに対し、そのユーザーに合わせたメッセージを送り、ギフトを提供したり応援するようにしています。

Lifesum も、ユーザーに合わせたメッセージを送っています。ただし、ユーザーが見落としている可能性があるものを強調します。つまり、重要な機能のリマインダーを重視し、ユーザーの使用率を維持できるように、あまり知られていない機能についてお知らせしています。


定期購入の期限切れに注目する

アプリで定期購入を導入している場合、その更新期間には常にリスクがつきまといます。ここで最も重要なことは、適切なタイミングで適切な兆候に基づいて行動することです。そのためには、定期購入期間が終了する数週間前または数か月前、まさに離脱を示す行動が起きているときに、その行動を特定する必要があります。兆候は思ったよりも早く見つかるかもしれません。

続いて、キャンセル以外の選択肢を確実に示して、そのことをユーザーにはっきりと伝えます。ユーザーは、より手頃な価格、または広告をベースにしたオプションが存在することを知らないかもしれません。ユーザーにキャンセルの理由を与えないようにしましょう。

オファーを行うときは、価値の見せ方を工夫してみましょう。定期購入の更新をユーザーに促すのは、難しいものです。どんなメッセージがユーザーの共感を得るかを判断するために、異なるメッセージを試してみてもよいかもしれません。コストやメリット、オプションを明確に提示すれば、ユーザーは選択肢を与えられたように感じて選びやすくなる可能性があります。また、実世界の同等なものとコストを比べれば、視野を広げて価値を見直してもらえるかもしれません。Yazio は、定期購入の月間コストが 1 日 1 杯のコーヒーや他のダイエット製品よりも安いことをアピールしています。

また、常に言えることですが、パーソナライズしたメッセージを送れば、ユーザーは自分が大事にされていると感じます。Quickbooks は、定期購入のキャンセル フローの途中で、ユーザーがアプリで実現したこと（1,000 マイルを移動したなど）や、費用を払ったにもかかわらずまだ使っていなかった機能を提示しています。 

まとめ

上記のステップを通して、注目すべきユーザー グループとそれらのグループの障壁を表す、離脱につながるさまざまな行動パターンを発見できるかもしれません。もちろん、一部のグループでは、離脱は避けられない可能性もあります。アプリが提供するサービスの価値を誤解したユーザーや、単にそのアプリでは事足りなくなったユーザーがそういったグループに当てはまるでしょう。そういったケースもあるので、再定着に向けたさまざまな努力をしているにもかかわらず活動のレベルが低いままであるユーザー グループではなく、価値をもたらしてくれるグループに注目するようにしましょう。完全に離脱をなくすことは不可能であることを忘れないでください。

この記事が、離脱を最低限に抑える戦略の立案にお役に立つことを願っています。ここでご紹介した戦略は、「どっちつかず」のユーザーを定着させるために役立ち、獲得戦略や維持戦略とともに、アプリを継続的に成長させるために欠かせないものです。  この内容についてもっと知りたい方は、以下の関連情報をご覧ください。


Reviewed by Hidenori Fujii - Google Play Developer Marketing APAC

スキームフル Same-Site は、「サイト」の定義を、「登録可能ドメイン」のみから、「スキーム＋登録可能ドメイン」に変えるものです。詳細や例は、「同一サイト」と「同一オリジン」を理解するをご覧ください。

重要な用語: つまり、http://website.example のような安全でない HTTP バージョンのサイトと、https://website.example のような安全な HTTPS バージョンのサイトが、お互いにクロスサイトと見なされるということです。

うれしいのは、すべてのウェブサイトを既に HTTPS にアップグレードしている場合、何も心配することはない点です。その場合、何も変わることはありません。

まだウェブサイトを完全に HTTPS にアップグレードしていない場合は、この作業の優先度を上げる必要があります。ただし、サイトにアクセスするユーザーが HTTP と HTTPS を行き来している場合は、一般的なシナリオとその SameSite Cookie の動作について、以下をお読みください。

警告: 長期的に計画されているのは、サードパーティ Cookie のサポートを完全に廃止し、プライバシーを保護できる手法に置き換えることです。Cookie に SameSite=None; Secure を設定してスキームをまたいで送信できるようにする方法は、完全な HTTPS への移行に向けた一時的なソリューションとしてのみ検討してください。

以下の変更を有効化すると、Chrome と Firefox でテストできます。

  • Chrome 86 以降で、chrome://flags/#schemeful-same-site を有効にします。進捗状況は、Chrome ステータス ページでトラッキングしてください。
  • Firefox 79 以降で、about:config から network.cookie.sameSite.schemeful を true に設定します。進捗状況は、Bugzilla の問題でトラッキングしてください。

Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つに、クロスサイト リクエスト フォージェリ（CSRF）に対する保護がありました。しかし、安全でない HTTP トラフィックが存在する場合、ネットワーク攻撃者が Cookie を改ざんし、それを使って安全な HTTPS バージョンのサイトに侵入するチャンスが残ることになります。スキーム間にクロスサイト境界を追加することで、このような攻撃に対する保護を強化できます。

一般的なクロススキーム シナリオ

重要な用語: 以下の例では、すべての URL で site.example などの同じ登録可能ドメインを使用していますが、http://site.example と https://site.example のようにスキームが異なっています。これを、お互いにクロススキームであるといいます。

これまで、クロススキームなウェブサイト間のナビゲーション（たとえば、http://site.example から https://site.example へのリンク）では、SameSite=Strict Cookie の送信が許可されていました。今後、これはクロスサイト ナビゲーションとして扱われます。つまり、SameSite=Strict Cookie はブロックされます。

安全でない HTTP バージョンのサイトから安全な HTTPS バージョンへのリンクを開くことによって発生するクロススキーム ナビゲーションSameSite=Strict Cookie はブロック、SameSite=Lax および SameSite=None; Secure Cookie は許可される。
HTTP から HTTPS へのクロススキーム ナビゲーション
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック ⛔ ブロック
SameSite=Lax ✓ 許可 ✓ 許可
SameSite=None;Secure ✓ 許可 ⛔ ブロック

サブリソースの読み込み

警告: すべての主要ブラウザは、スクリプトや iframe などのアクティブな Mixed Contents をブロックします。さらに、Chrome や Firefox などのブラウザでは、パッシブな Mixed Contents のアップグレードやブロックに向けた作業が進んでいます。

ここで行う変更は、完全な HTTPS へのアップグレードを進める間の一時的な修正としてのみ検討してください。

サブリソースの例として、イメージ、iframe、XHR や Fetch によるネットワーク リクエストなどがあげられます。

これまで、ページでクロススキーム サブリソースを読み込んだ場合、SameSite=Strict または SameSite=Lax の Cookie の送信や設定が許可されていました。今後、これは他のサードパーティまたはクロスサイトのサブリソースと同じように扱われます。つまり、SameSite=Strict や SameSite=Lax の Cookie はすべてブロックされます。

加えて、ブラウザが安全なページで安全でないスキームからのリソースの読み込みを許可したとしても、サードパーティまたはクロスサイト Cookie には Secure が必須なので、リクエストの Cookie はすべてブロックされます。

安全でない HTTP バージョンに、安全な HTTPS バージョンのサイトのリソースからのクロススキーム サブリソースが含まれている。SameSite=Strict および SameSite=Lax Cookie はブロック、SameSite=None; Secure Cookie は許可される。
HTTPS によるクロススキーム サブリソースを含む HTTP ページ
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック ⛔ ブロック
SameSite=Lax ⛔ ブロック ⛔ ブロック
SameSite=None;Secure ✓ 許可 ⛔ ブロック

フォームの POST

これまでは、クロススキーム バージョンのウェブサイト間で POST を行った場合、SameSite=Lax または SameSite=Strict が設定された Cookie の送信は許可されていました。今後、これはクロスサイト POST として扱われ、SameSite=None Cookie のみ送信できるようになります。このシナリオは、デフォルトで安全でないバージョンを表示し、ログインまたはチェックアウト用のフォームを送信する際にユーザーを安全なバージョンにアップグレードするサイトで使われている可能性があります。

サブリソースと同じく、リクエストが安全な HTTPS などのコンテキストから安全でない HTTP などのコンテキストに向かう場合、サードパーティまたはクロスサイトの Cookie には Secure が必要になるので、リクエストの Cookie はすべてブロックされます。

警告: ここでの最適なソリューションは、フォームのページと送信先ページの両方で HTTPS などの安全な接続を使うことです。この点は、ユーザーがフォームに機密性の高い情報を入力する場合に特に重要になります。

クロススキームでのフォーム送信。安全でない HTTP バージョンのサイトのフォームが安全な HTTPS バージョンに送信されている。SameSite=Strict および SameSite=Lax Cookie はブロック、SameSite=None; Secure Cookie は許可される。
HTTP から HTTPS へのクロススキーム フォーム送信
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック ⛔ ブロック
SameSite=Lax ⛔ ブロック ⛔ ブロック
SameSite=None;Secure ✓ 許可 ⛔ ブロック

サイトをテストする方法

Chrome と Firefox では、デベロッパー ツールやメッセージを利用できます。

Chrome 86 以降では、DevTools の [Issue] タブにスキームフル Same-Site の問題が表示されます。サイトで以下の問題が表示される可能性があります。

ナビゲーションに関する問題:

  • "Migrate entirely to HTTPS to continue having cookies sent on same-site requests"—将来のバージョンの Chrome で Cookie がブロックされる予定であることを示す警告。
  • "Migrate entirely to HTTPS to have cookies sent on same-site requests"—Cookie がブロックされたことを示す警告。

サブリソースの読み込みに関する問題:

  • "Migrate entirely to HTTPS to continue having cookies sent to same-site subresources" または "Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources"—将来のバージョンの Chrome で Cookie がブロックされる予定であることを示す警告。
  • "Migrate entirely to HTTPS to have cookies sent to same-site subresources" または "Migrate entirely to HTTPS to allow cookies to be set by same-site subresources"—Cookie がブロックされたことを示す警告。後者の警告は、フォームを POST した場合にも表示される可能性があります。

詳しい内容は、スキームフル Same-Site のテストとデバッグに関するヒントにも掲載されています。

Firefox 79 以降で about:config から network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトで以下の内容が表示される可能性があります。

  • "Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match."
  • "Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match."

FAQ

私のサイトは完全に HTTPS が利用できるようになっていますが、ブラウザの DevTools に問題が表示されるのはなぜですか？

一部のリンクやサブリソースが安全でない URL を指している可能性があります。

この問題を修正する方法の 1 つは、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使うことです。HSTS と includeSubDomain を使うと、ページに安全でないリンクが意図せずに含まれる場合でも、ブラウザが自動的に安全なバージョンを使ってくれます。

HTTPS にアップグレードできない場合はどうすればよいでしょうか？

サイトを完全に HTTPS にアップグレードしてユーザーを保護することを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談してアップグレードのオプションを提供できるかを確認してください。セルフホストの場合は、Let's Encrypt が証明書をインストールして設定するためのさまざまなツールを提供しています。また、HTTPS 接続を提供できる CDN やその他のプロキシを経由してサイトにアクセスするように移行することも検討できます。

それでも難しい場合は、影響を受ける Cookie の SameSite 保護の緩和を試します。

  • SameSite=Strict Cookie のみがブロックされる場合は、保護を Lax に下げます。
  • Strict と Lax の両方の Cookie がブロックされ、Cookie が安全な URL に送信される（または安全な URL で設定される）場合は、保護を None に下げます。
    • この回避策は、Cookie の送信先 URL（または設定元 URL）が安全でない場合、失敗します。これは、SameSite=None の Cookie には Secure 属性が必要だからです。つまり、このような Cookie を安全でない接続で送信、設定することは許可されていません。この場合、サイトを HTTPS にアップグレードしなければ Cookie にアクセスすることはできません。
    • サードパーティ Cookie は将来的に廃止される予定なので、これは一時的な対策に過ぎないことを忘れないでください。

SameSite 属性を指定していない場合、Cookie にどのような影響が発生しますか？

SameSite 属性のない Cookie は、SameSite=Lax を指定した場合と同じように扱われ、それと同じクロススキーム動作が適用されます。なお、安全でない手法も一時的に例外として許可されています。詳しくは、SameSite FAQ の Chromium における Lax＋POST 対処法をご覧ください。

WebSocket はどのような影響を受けますか？

ページと同じ安全性が確保されている場合、WebSocket 接続は今後も同一サイトと見なされます。

同一サイト:

  • https:// からの wss:// 接続
  • http:// からの ws:// 接続

クロスサイト:

  • http:// からの wss:// 接続
  • https:// からの ws:// 接続

Reviewed by Eiji Kitamura - Developer Relations Team

Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は App Bundle、マテリアル デザイン コンポーネント、新しいターゲット API 要件、新しい Fragment とフローのドキュメント、最近公開されたブログ記事・動画・関連ドキュメント、ポッドキャスト エピソードなどをご紹介します。

MAD Skills: App Bundle とマテリアル デザイン コンポーネント


最先端の Android 開発に関する新しい技術コンテンツを扱う連載 MAD Skills シリーズが続いています。

App Bundle のミニシリーズは、Google Developer Expert の Angelica Oliveira からのヒント、続いて私（質問役）と Ben Weiss、Wojtek Kaliciński、 Iurii Makhno（回答役）によるリアルタイム Q&A とアーカイブで終了しました。App Bundle の全エピソード（動画と記事）は、まとめのブログ記事（英語）からリンクしています。

続いて MAD Skills は、マテリアル デザイン コンポーネント（MDC）についての新しいミニシリーズに入りました。マテリアル デザイン コンポーネントは、マテリアル デザイン ガイドラインを使ってアプリの構築を簡単にするライブラリです。

初回は Nick Butcher が、Android デベロッパーにマテリアル デザイン コンポーネントの使用を推奨する理由を説明しています。この動画には、テーマのサポート、組み込みの画面遷移、デフォルトのマテリアル スタイルのコンポーネントなど、MDC が提供するさまざまな機能の概要が含まれています。このコンテンツは、以前にブログ記事（英語）も掲載しています。


次に、Nick Rout がマテリアル テーマについてのエピソードを投稿しました。MaterialThemeBuilder サンプル プロジェクトについて説明しつつ、マテリアル テーマの使い方とカスタマイズの方法を紹介しています。


この動画に加えて、色、書体、形状について取り上げた記事（英語）もそれぞれご覧ください。

12 月第一週にかけて、Chris Banes が 3 つ目のエピソードを投稿しました。Android 10 の Force Dark 機能と MDC の DayNight テーマの両方を使い、MDC でダークテーマを作成する方法について説明しています。また、Chris はこのコンテンツをブログ記事形式（英語）でも公開しました。


引き続き、ほかにも MDC 関連のコンテンツを公開する予定です。さらに、日本時間 12 月 11 日午前 3 時から、もう一度リアルタイム Q&A （英語）を行います。詳細は MDC プレイリストをご覧ください。

連載中の MAD コンテンツは、YouTube の MAD Skills プレイリスト、Medium のブログ記事（英語）、またはすべてのリンクが掲載されているランディング ページからご覧ください。


App Bundle とターゲット API 要件

2021 年後半には、ターゲット API（新規アプリとアプリのアップデート）と App Bundle の両方の要件が追加されます。Hoi Lam が、これについて詳しく説明したブログ記事（日本語）を投稿しました。簡潔にまとめると、次のようになります。

2021 年 8 月:

  • 新規アプリで API レベル 30 の指定が必須になります。

  • 新規アプリを Play Store に公開する場合、App Bundle の使用が必須になります。

  • 150 MB を超えるアセットや機能がある新規アプリは、Play Asset Delivery や Play Feature Delivery を使った配信が必須になります。新しいアプリでは、拡張ファイル（OBB）はサポートされません。

2021 年 11 月:

  • アプリのアップデートで API レベル 30 の指定が必須になります。


最近公開された関連ドキュメント


Fragment のドキュメント

Fragment は、UI デベロッパーに重要なアーキテクチャ要素を提供し、アプリの UI の小さな塊を自己完結的な形で管理できるようにします。Fragment と Navigation を組み合わせている方も、単独で Fragment を使っている方も、アプリで最も効果的に Fragment を使う方法を確認することをおすすめします。ツールや API の使い方を理解するために、最新の綿密なドキュメントを公開することが重要であると考えています。サポートが終了した API の利用は避けるべきですが、関連ドキュメントでは、正しい方向性を示したり、ベスト プラクティスを説明しています。

そこで、Fragment のドキュメントを大きく改訂し、ライフサイクル、状態、テストなど、Fragment のさまざまな側面について説明している最新のガイドを公開しました。こちらから、最新のドキュメントをご確認ください。

AndroidX で Fragment の修正や拡張を行っている Ian Lake が、Twitter のフィードで今回のドキュメントの変更に触れています。

Kotlin フロー

Kotlin のフローについての新しいドキュメントも公開しました。ここには、フローの基本的な使用方法から、新しい StateFlow および SharedFlow API のテスト方法まで、あらゆる情報が掲載されています。また、フローの使用についての動画も忘れずにご覧ください。


最近公開されたブログ記事と動画


起動時のパフォーマンスをテストする

先週私は、アプリの起動時のパフォーマンスに関するいくつかの処理を自動化する方法について、ブログ記事（英語）を投稿しました。私は、起動時のパフォーマンス全般に注目しており、何度も繰り返して連続実行する際に、起動時間を求める処理を自動化する妥当な方法を見つけたいと考えてきました。同じように起動時のパフォーマンス テストに興味がある方のために、私が利用したアプローチを公開しています。

Dagger -> Hilt

Manuel Vivo は、Dagger から Hilt への移行というブログ記事（英語）で、「その価値はあるのか？」という疑問を投げかけています。このブログ記事では、移行を検討すべきいくつかの重要な理由に触れています。たとえば、API のテスト、整合性、AndroidX 拡張機能との統合などです。

Hilt を使ってみる

Hilt を使い始めるデベロッパーの皆さんに役立ててもらうため、Filip Stanis がKotlin による Hilt 実践ガイド（英語）を投稿しました。依存性注入や Dagger を使ったことがない方でも大丈夫です。まったく初めてという方も、ぜひお読みください。

タイトルからは、この記事が Kotlin デベロッパー向けのように思えるかもしれませんが、これは記事のコード スニペットに Kotlin を使っているからです。記事で紹介している一般的なアプローチやテクニックは、Java プログラミング言語を使っているデベロッパーにも当てはまります。

フローを使う

Manuel Vivo が Kotlin Vocabulary シリーズに新しい動画を投稿しました。Kotlin フローを使ってデータのストリームを発行する方法について説明しています。これは、以前公開した動画、コルーチンの ABC が元になっているので、先にそちらを見てからフローを学ぶのもよいでしょう。

Kotlin Extensions: View Binding と Synthetics

David Winer が Kotlin Synthetics と View Binding についてのブログ記事を投稿しました。この 2 つはどちらも、厄介な findViewById() 呼び出しをコードから無くすためのメカニズムです。このブログ記事では、Kotlin プラグインの今後のバージョンで Synthetics のサポートが終了することをお伝えしています。また、今後も推奨とサポートが継続される @Parcelize エクステンションについても触れています。

バックグラウンド位置情報

最近の Android リリースでは、ユーザーデータの保護、データアクセスへのコントロール、透過性向上に関して、多くの変更が行われています。特に重視されている領域が位置情報です。ユーザーは、アプリの位置情報へのアクセスを望まない場合や、そのアクセスを非常に注意深く制御したい場合があるからです。

そのため、Google Play ポリシーにより、バックグラウンドでの実行中に位置情報にアクセスするアプリでは、（Play Store から）アクセス許可をリクエストする操作が必須になります。このブログ記事では、そのリクエスト方法について詳しく説明しています。

またお会いしましょう

今回は以上です。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。


Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC


Back/Forward Cache は、Chrome で長く望まれていた機能リクエストです。現在の Chrome 87 で、Android 版 Chrome のユーザーに徐々にロールアウトします。Chrome のマルチプロセス アーキテクチャにどのようにして Back/Forward Cache を追加したのかについて詳しく知りたい方は、こちらの技術記事をご覧ください。ウェブ デベロッパーの方は、ウェブサイトで Back/Forward Cache を最大限に活用する方法も学ぶことができます。 

データの出典: Chrome の安定版より前のチャンネルから匿名で収集した実データ

Reviewed by Eiji Kitamura - Developer Relations Team

2020 年 12 月 1 日（日本時間12 月 2 日 ）、Android Studio 4.3 の初めての Canary 版がリリースされ、それとともに Android Gradle プラグイン（AGP）バージョン 7.0.0-alpha01 もリリースされました。Gradle プラグインのバージョン番号の付け方は、Android Studio のバージョン番号のスキームから切り離した上で改めて調整したので、番号を一気に 2 つも飛ばしています。このブログ投稿では、この変更の理由について説明するとともに、インキュベーション状態になっている新しい Android Gradle プラグインの API と DSL について、いくつかの重要な変更点を簡単にご紹介します。


新しいバージョン番号のスキーム 

AGP 7.0.0 では、セマンティック バージョニングの考え方を採用しています。つまり、API の互換性がない変更が発生するのは、メジャー バージョンが変更された場合のみです。メジャー バージョンは、Gradle で年に 1 回のメジャー リリースが行われるタイミングで、毎年 1 つずつ上げることを想定しています。

さらに、互換性のない変更が行われる場合は、1 年ほど前から削除される API に @Deprecated を付け、それと同時期に削除される機能に代わる方法を提供することを保証します。これによりデベロッパーには約 1 年の猶予が与えられ、古い API が削除される前に新しい API を使ってプラグインのテストと移行を行えるようになります。

バージョン 5 と 6 を飛ばして直接 AGP 7.0.0 に変わったのは、Gradle のバージョンに合わせるという理由もあります。つまり、AGP 7.x は Gradle 7.x の API で動作するということです。Gradle 8.x でも動作するかもしれませんが、それは保証されていません。AGP が利用する API が 8.x で削除されていないかどうか次第です。

この変更に伴い、AGP のバージョン番号は Android Studio のバージョン番号とは切り離されます。ただし、当面の間、Android Studio と Android Gradle プラグインは同じタイミングでリリースする予定です。

Android Studio と Android Gradle プラグインとの互換性には、変更はありません。一般的なルールとして、AGP の安定版を使うプロジェクトはそれより新しいバージョンの Android Studio で開くことができます。


Java 11 要件

AGP 7.0.0-alpha01 では依然として Java プログラミング言語バージョン 8 を使用できますが、現在、最低限必要な Java プログラミング言語のバージョンを Java 11 に変更する作業を行っています。これは AGP 7.0.0-alpha02 から適用される予定です。この変更については、デベロッパーの皆さんが余裕を持って準備できるように、Canary 版のスケジュールという早い段階で、安定版リリースの何か月も前にお知らせしています。


インキュベーション状態の API と重要な API の変更点

今回の AGP のリリースでは、いくつかの API が変更されます。なお、AGP 4.1 で導入されたたくさんの API はインキュベーション状態としてマークされ、変更の可能性がありました。そして実際、AGP 4.2 で一部の API が変更されました。現在インキュベーション状態になっている API は、先ほど説明したサポート終了サイクルには従いません。

いくつかの重要な API の変更について、概要をまとめました。

  • バージョン 4.2 ベータ版では、onVariants、onProperties、onVariantProperties ブロックが削除されます。

  • これらの API は、新しい androidComponents ブロックの beforeVariants および onVariants で置き換えられます。beforeVariants と onVariants を利用すると、省略可能な VariantSelector を使って、コールバックを実行するバリアントの数を減らすことができます。これは、ビルドタイプ、名前、フレーバーのいずれかに基づいて行うことができ、それぞれ withBuildType、withName、withFlavor を使います。onVariants および beforeVariants が受け取るラムダは、AGP が afterEvaluate でバリアントの組み合わせを計算した後に実行されます。onVariants 内のプロパティのネストは削除されます。

  • 同様の API が androidComponents にも追加され、バリアント内にテストをネストする代わりに、UnitTests 用（beforeUnitTest と unitTest）と AndroidTests 用（beforeAndroidTest と androidTest）に別々のブロックが許可されるようになります。

  • 古い方法と新しい方法の両方でバリアントのアクションの登録に使われていた 2 つのクラスは、名前が変更されました。Variant は VariantBuilder になり、beforeVariants で使われます。VariantProperties は Variant になり、新しい onVariants ブロックに渡されます。

いくつかの変更について確認してみましょう。以下のコードは、リリースビルドをターゲットとするサンプルの onVariants ブロックです。onVariants ブロックは beforeVariants に変更され、次の例のバリアント セレクタを使用します。


```
android {
…
//onVariants.withName("release") {
// ...
//}
…
}
androidComponents {
val release = selector().withBuildType(“release”)
beforeVariants(release) { variant ->
...
}
}
```


同様に、onVariantProperties ブロックも onVariants に変更されます。


```
android {
...
//onVariantProperties {
// ...
\
//}
…
}
androidComponents.onVariants { variant ->
   ...
}
```


なお、このカスタマイズは通常はプラグインで行うもので、build.gradle に配置すべき内容ではありません。レシーバのある関数の使用は避けています。これは DSL 構文には適していますが、プラグインのコードには必要ありません。

これらの API は、AGP 7.0.0 で安定版になる予定です。また、すべてのプラグイン作成者は、新しい androidComponents に移行する必要があります。このような変更に対処するのを避けたい方は、プラグインで安定版の API のみ使用し、インキュベーション状態の API は使わないでください。

今回のリリースに含まれるその他の変更点の詳細については、リリースノートをご覧ください。

Java は Oracle および/またはその関連会社の登録商標です。


Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC