この記事は 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 を使ってそれらを組み合わせています。
ナビゲーション グラフはディープリンク 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’ グリッドを移行できました。
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 つのバージョンのアプリを比較します。
ユーザーが最も気にする指標は、APK サイズです。
以下の結果は、リソース圧縮を有効にし、R8 を使って最小化した release APK を APK Analyzer で測定したものです。
‘adjusted’（調整済み）の値と ‘Pre-Compose’ を比較すると、Compose を使った場合は APK サイズが 41%、メソッド数は 17% 削減されていることがわかります。
Compose を使った場合は、APK サイズが 41%、メソッド数は 17% 削減されていることがわかる
この数から、AppCompat や MDC などがアプリ内でどれほどの容量を占めているかがわかります。それだけではなく、レイアウト ファイルで使われる場合に備えてすべての View クラスを保持しなければならない場合には、最小化ツールはほとんど役に立たないこともわかります。
ソフトウェア プロジェクトを比較する場合、ソースの行数を数えても特に役立つ統計情報にはならないことは承知していますが、この比較によって、どのような変化が起きているのかは確実に把握できます。
このテストでは、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 は現在アルファ版なので、すべての成果物は開発中のスナップショットになります。来年 1.0 の安定版になったとき、これらのテストを再実行して違いが出るかを見るのが楽しみです。
結果と注意点を見る限り、リンゴ 🍎 とリンゴ 🍏 を比較しているわけではない（同じ条件で比較しているわけではない）ので、あまり多くの結論を出すべきではありません。これは、リンゴ 🍎 とそれよりも少し甘いナシ 🍐 を比べているようなものです。
果物の例はさておき、最大のポイントは Compose がほとんどのデベロッパー指標で良好な（または中立的な）影響を示していることです。この点と Compose でデベロッパーの生産性が大幅に向上することを踏まえれば、いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
個人や小規模グループでゲームを開発するデベロッパーの情熱やイノベーションを称えるため、今年 3 年目となる Google Play | Indie Games Festival 2020 を開催しました。例年のようにファイナルイベントを公開対面形式で実施できないため、オンラインでの最終選考会をデベロッパーや、株式会社 Sisilala 安藤様を始めとする業界のさまざまな方からのご協力のもと開催することができました。
多くの取り組みが変更を余儀なくされる中でも、従来のイベントでは実現できなかった Top 20 全作品のプレゼンテーション枠の確保など、オンラインだからこそ実現できることに取り組みました。動画内では、Top 3 に入賞した合同会社リビルドゲームスの「METBOY!」様からイベントに対する感想も頂戴しています。
Google Play | Indie Games Festival 2020 の詳細をまとめた動画をご覧ください。
この記事は Nick Rout による Android Developers Blog の記事 "MAD Skills Material Design Components: Wrap-Up" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Modern Android Development（最先端の Android 開発）について取り上げる連載シリーズ MAD Skills の動画と記事の 3 番目のトピックが完結しました。今回は、マテリアル デザイン コンポーネント（MDC）についてご説明しました。このライブラリは、マテリアル コンポーネントを Android ウィジェットとして提供します。これを使うと、マテリアル テーマ、ダークテーマ、モーションなど、material.io で使われているデザイン パターンを簡単に実装できます。
説明した内容については、下記にまとめた各エピソードからご確認ください。これらの動画では、MDC についての最新の記事や、既存のサンプルアプリ、Codelab を詳しく説明しています。また、MCD チームのエンジニアによる Q&Aセッションも含まれています 。
最初のエピソードは、Nick Butcher が、なぜ私たちが MDC の利用を推奨するのかなど、今回の MAD Skills シリーズ全体の概要を説明しています。その後、マテリアル テーマ、ダークテーマ、モーションについて詳しく掘り下げていきます。また、MDC を Jetpack Compose と合わせて使う方法、MDC やテーマ、スタイルのベスト プラクティスを含むようにアップデートされた Android Studio のテンプレートについてもお話ししています。
エピソード 2 では、Nick Rout がマテリアル テーマについて説明し、Android で MDC を使ってこれを実装するチュートリアルについて解説しています。主な内容は、Theme.MaterialComponents.* アプリのテーマを設定し、material.io のツールを使用して色や種類、形状の属性を選択し、最終的にそれらをテーマに追加して、ウィジェットがどのように自動的に反応して UI を適応させるかを確認します。また、テーマカラー属性を解決する、イメージに図形を適用するなど、MDC が特定のシナリオ向けに提供している便利なユーティリティ クラスについても説明します。
Theme.MaterialComponents.*
Chris Banes が、Android アプリで MDC を使ってダークテーマを実装する方法を紹介しています。説明する内容は、Force Dark を使って短時間で変換しビューを除外する方法、デザインを選んでダークテーマを手動で作成する方法、`.DayNight` MDC アプリテーマ、`.PrimarySurface` MDC ウィジェット スタイル、そしてシステム UI を扱う方法などです。
エピソード 4 では、Nick Rout がマテリアルのモーション システムについて解説しています。また、既存の「Android でマテリアル モーションを使って美しい画面遷移を構築する」Codelab の手順を詳しくフォローしています。この Codelab では、Reply サンプルアプリを使って、コンテナ変換、共有軸、フェードスルー、フェードという遷移パターンを活用してスムーズでわかりやすいユーザー エクスペリエンスを実現する方法を紹介しています。また、Fragment（Navigation コンポーネントを含む）、Activity、View を使うシナリオについて説明しています。
エピソード 5 は、Android コミュニティから Google Developer Expert (GDE) の Zarah Dominguez さんが、MDC カタログアプリをウィジェットの機能や API の例として参考にしながら紹介してくれました。そのほか、異なる画面やフローにまたがる一貫したデザイン言語を確保するために、彼女が取り組んでいるアプリに「テーマショーケース」ページを構築することが、どのように有益であるかを説明しています。
最後のまとめとして、Chet Haase が MDC エンジニアリング チームの Dan Nizri と Connie Shi と一緒に Q&A セッションを行い、Twitter や YouTube で寄せられた皆さんからの質問に回答しました。このセッションでは MDC の起源、AppCompat との関係、今までの改善点について解説したほか、テーマやリソースを整理するためのベストプラクティス、さまざまなフォントやタイポグラフィ スタイルの使用方法、シェイプ テーミングなどについてお話しました。また、私たちはお気に入りの Material コンポーネントをすべて公開し、最後に、将来的に MDCと Jetpack Compose という Androidの次世代 UI ツールキットでは、デフォルトで Material Design が組み込まれる新しいコンポーネントが登場することについて議論しました。
このシリーズでは、MDC のデモとして、次の 2 つのサンプルアプリを使いました。
これらは、もう 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
この記事は Chris Banes による Android Developers Blog の記事 "MAD Skills — Become an Android App Bundle expert" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Modern Android Development（最先端の Android 開発）の Android App Bundle ミニシリーズが最終回のリアルタイム Q&A セッションで完結しました。私は Chet Haase、Wojtek Kaliciński、Iurii Makhno とともに、Twitter の #AskAndroid ハッシュタグやライブ ストリームのチャットから寄せられたたくさんの質問にお答えしました。
ここで少し時間を巻き戻して、最初から振り返ってみることにしましょう。
最初のエピソードでは Wojtek が、なぜデベロッパーやアプリにとって App Bundle が重要なのかを説明し、このシリーズの方向性を示しました。
このエピソードでは、Wojtek が Play Console について詳しく解説しました。Play App Signing をオプトインする方法を学習でき、Play App Signing をオプトインする際に利用できるオプションについて理解できるはずです。
この動画と合わせて、 ブログ記事 Answers to common questions about Play App Signing やアプリ署名についての Android ドキュメント、Play Console のヘルプページの Google Play アプリ署名を使用する も参照することをおすすめします。
次に、初めての Android App Bundle をビルドしてアップロードする方法を学びました。このエピソードでは、Android Studio とコマンドライン インターフェースを使ってバンドルをビルドする手順について、私がご説明しています。
このエピソードはブログ記事（英語）で読むこともできます。合わせて、App Bundle のドキュメントもご覧ください。
このエピソードでは、配信オプションについて学ぶことができます。インストール時の配信に加え、条件付き配信やオンデマンド配信など、あらゆることを解説しています。また、 GitHub のサンプルについても説明しています。
このエピソードもブログ記事（英語）で読むことができます。さらに、重要な参考資料として Play Core ガイドも準備しています。
App Bundle のテスト方法について疑問に思ったことはないでしょうか。もうその必要はありません。Wojtek が ご説明する App Bundle をローカルと Play Console でテストする方法についての動画をご覧ください。
このエピソードのコンテンツは、ブログ記事（英語）やガイド Android App Bundle のテスト で読むこともできます。
さらに、Play Console のデベロッパー ツールにガイドを掲載しており、Play Console のヘルプページでは内部アプリ共有の説明も確認できます。
また、bundletool をダウンロードしたい方は、こちらをご覧ください。
Android GDE の Angélica Oliveira さんが、Android App Bundle への切り替えを行った手順と、そのときに経験した大幅なサイズの削減について解説しています。
Twitter で質問を募集したところ、皆さんから #AskAndroid ハッシュタグ付きの返信をいただき、リアルタイム Q&A セッションの間も質問は続きました。Chet と Wojtek、Iurii、そして私がカメラの前に立ち、皆さんの質問にお答えしました。
詳しくは 2021 年の新しい Android App Bundle とターゲット API レベル要件をご覧ください。
Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
この記事は Frank van Diggelen による Android Developers Blog の記事 "Improving urban GPS accuracy for your app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android では、デベロッパーの皆さんがユーザーにとって、便利なアプリをできる限り簡単に作成できるようにしたいと考えています。そのため、Fused Location Provider API（FLP）などの API では、位置情報を最大限に活用できるようにすることを目指しています。しかし、密集した都市部では、通りの反対側や誤った区画を指すなど、その位置情報の精度が低いというご指摘をこれまで多くの方からいただいておりました。
ライドシェアやナビゲーションなど、特によく利用されている位置情報アプリでは、この点が非常に重要になります。たとえば、街でユーザーがライドシェアをリクエストしても、GPS エラーのためアプリが簡単に位置を特定できない場合があります。
誤って通りの反対側を指してしまうエラーが起こる主な原因は、都市では GPS シグナルが反射しやすいためです。この大きな GPS 問題の解決に役立てるため、私たちは新しいプロジェクトを立ち上げました。そのソリューションは、3D マッピングを活用して補正を行うという方法です。これには、建物の 3D モデル、未加工の GPS 測定データ、機械学習を組み合わせる必要があるため、Google のような企業の規模でしか実現できません。
12 月の Pixel Feature Drop では、Pixel 5 と Pixel 4a5G に 3D マッピングを活用した GPS 補正が追加されます。Pixel で使われている Qualcomm® Snapdragon™ 5G Mobile Platform にフィードバックを提供するシステム API により、都市部（ビルの谷間、いわゆる「アーバン キャニオン」）での精度が大幅に向上します。
この写真から、3D マッピングを活用した補正を行わない場合、GPS の結果が不安定になって通りの反対側（または誤った区画）を指す頻度が高くなることがわかります。一方、3D マッピングを活用した補正を行うと、位置は何倍も正確になります。
都市部では GPS が構造的に誤った場所を指す点が今までの問題でした。その問題は、すべての GPS システムが衛星からの見通し線に基づいて位置を特定しているために引き起こされています。しかし大都市では、直接の信号は建物によって妨害されるため、ほぼすべての信号が障害物に反射した後に届くことになります。
GPS チップは信号が見通し線上にあることを仮定しているので、信号が余分な経路を通過してきた分だけ、計算に誤差が生じます。最も一般的な副作用は、位置が通りの反対側に表示されることですが、特に多くの高層ビルが建っている大都市では、誤った区画に表示されることもあります。
この問題は、10 年以上にわたって解決が試みられてきました。しかし、Android に 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
Android 8 以降を実行しているスマートフォンでは、3,850 以上の都市で GPS をオンにして歩行しているときに、Android の 3D マッピングを活用した補正が自動的に作動します。デベロッパーがこの改善を活用する最適な方法は、FLP を使って位置情報を取得することです。GPS チップによるさらに高度な 3D マッピングを活用した補正は、現在のところ、Pixel 5 と Pixel 4a 5G で利用できます。また、今後数週間のうちに、Android エコシステム全体（Android 8 以降）に対してロールアウトされる予定です。今後、運転中などの他のモードもサポートする予定です。
Android の 3D マッピングを活用した補正は、以下を含む 3,850 以上の都市で利用できます。
Google Earth 3D モデルの拡張とともに、3D マッピングを活用した補正の範囲も広がります。
Google マップにもアップデートが行われます。これにより、一部の都市で、歩道、横断歩道、安全地帯などの歩行者向けの街区レベルの情報の精度が向上します。2021 年には、Google Maps Platform を使っているアプリにもこのアップデートが提供されます。3D マッピングを活用した補正による位置情報の精度向上と合わせて、皆さんのようなデベロッパーが、世界中で Android を使っている 20 億人の歩行者のユースケースのサポートを向上してくださることを期待しています。
私たちは 3D マッピングを活用した補正の他にも、位置情報の精度と利便性を向上する努力を懸命に続けています。Fused Location Provider API（FLP）の最新の改善項目は、以下のとおりです。
getCurrentLocation
FusedLocationProviderClient
Qualcomm および Snapdragon は、Qualcomm Incorporated の商標または登録商標です。Qualcomm Snapdragon および Qualcomm Location Suite は、Qualcomm Technologies, Inc. および/またはその子会社の製品です。
2020 年は、予想もつかない事態が続く中で、困難な状況をポジティブに変える取り組みに多くのデベロッパーの皆さまが精力を傾けてこられました。世界保健機関（WHO）と世界中のゲーム関連事業者が提唱した #PlayApartTogether （離れていっしょに遊ぼう）キャンペーンを日本でも立ち上げ推進した、株式会社ミラティブと株式会社ミクシィの取り組みもその 1 つです。
Google Play では Play ストアに特集ページを設け、賛同デベロッパーのゲームを掲載しました。詳細をまとめた動画をご覧ください。
この記事は Vesna Doknic による Google Play Developers - Medium の記事 "Churn: acting before it’s too late" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
アプリのユーザーは、3 つの基本的なグループに分けることができます。それは、エンゲージメントがない（獲得戦略によって新たに引き寄せられたグループ）、エンゲージメントが増加中（利用維持戦略によって利用が促進されたグループ）、エンゲージメントが減少中（離脱阻止戦略によってつなぎ留められているグループ）の 3 つです。これらはすべて異なる戦略が関わっているので、獲得、維持、離脱阻止をまったく別の領域として考えることは理にかなっています。しかし、離脱との闘いは軽視されることが多く、獲得の増加や、エンゲージメントの高いユーザーの維持率を上げることで、相殺できたりするものと見なされがちです。
前回の記事（英語）では、どうすればデベロッパーが効果的な維持戦略を策定できるかについて説明しました。これは、エンゲージメントの高いユーザーを維持する可能性を高めることを狙った戦略です（さらに細かく掘り下げたレポート全文をご覧ください）。しかし、戦略やアプリがどれほど素晴らしいものであっても、いくらかのユーザーは離脱してしまうものです。
ユーザーの離脱は、目先の収益以上の損失を会社にもたらします。例えば、早い段階でユーザーが離脱すれば、そのユーザーの獲得コストは完全に無駄であったということになります。また、離脱したユーザーを再定着させることは可能ですが、それには新しいユーザーを獲得するよりも費用も時間もかかる可能性が高いです。
ユーザーを再定着させるには、そもそもユーザーの離脱を引き起こした問題を直接的に克服しなければなりません。そのコストを考えると、ユーザーを再定着させるよりも、最初からユーザーが離脱しないようにあらかじめ手を打っておくほうがはるかに効果的です。
それでは、どうすれば手遅れになる前に行動できるのでしょうか。
離脱を防ぐということは、離脱が起こる前に対処するということです。すなわち、警告システムを作り、離脱の兆候を特定して早い段階で行動するのです。ユーザーは一夜にして離れるわけではありません。離脱する前には、アプリの使い方が変わり始めます。そしてそれは、計測して特定することが可能です。この危険信号を特定するには、以下の様なデータを確認し、離脱するユーザーがどのような行動をとっているのかを調べます。
Quickbooks は、詳細なモデリングによって最近離脱したユーザーの行動を分析し、高い離脱率と相関性のある行動に注目した「ユーザー リスク プロフィール」を作っています。
これは 200～300 種類のアプリ内行動をまとめたもので、機能を使用しない、休眠の日数、重要指標を達成できない、などが含まれています。詳しい方法について知りたい方は、こちらの記事（英語）をご覧ください。
Quickbooks は、このような「点検」を行うことで、即座に介入して独自の方法で望ましい行動を促し、離脱のリスクを軽減できるようにしています。
離脱を予測できるようになったら、離脱する可能性が高いユーザーを特定してアプリに呼び戻すことを試みます。そのためには、ユーザーにアプリの価値を再認識してもらわなければなりません。既に使っている機能についてのリマインダーを表示したり、近くリリースされる機能に期待してもらったりすることも効果的です。
これを行う方法の 1 つは、ユーザーがアプリを使って既に実現したことを思い出してもらうことです。Yazio は、ユーザーの進捗を目に見える形で継続的に追跡し、離脱を防ぐ方策として、頻繁にお祝いの言葉を贈っています。進行状況バーと祝福の画面を使ってユーザーのモチベーションを上げ、目標の達成を促します。
可能な限りコンテンツをパーソナライズし、ユーザーに自分が大事にされていると感じてもらえるようにするのも効果的です。Mobills は、使用率が低下したユーザーに対し、そのユーザーに合わせたメッセージを送り、ギフトを提供したり応援するようにしています。
Lifesum も、ユーザーに合わせたメッセージを送っています。ただし、ユーザーが見落としている可能性があるものを強調します。つまり、重要な機能のリマインダーを重視し、ユーザーの使用率を維持できるように、あまり知られていない機能についてお知らせしています。
アプリで定期購入を導入している場合、その更新期間には常にリスクがつきまといます。ここで最も重要なことは、適切なタイミングで適切な兆候に基づいて行動することです。そのためには、定期購入期間が終了する数週間前または数か月前、まさに離脱を示す行動が起きているときに、その行動を特定する必要があります。兆候は思ったよりも早く見つかるかもしれません。
続いて、キャンセル以外の選択肢を確実に示して、そのことをユーザーにはっきりと伝えます。ユーザーは、より手頃な価格、または広告をベースにしたオプションが存在することを知らないかもしれません。ユーザーにキャンセルの理由を与えないようにしましょう。
オファーを行うときは、価値の見せ方を工夫してみましょう。定期購入の更新をユーザーに促すのは、難しいものです。どんなメッセージがユーザーの共感を得るかを判断するために、異なるメッセージを試してみてもよいかもしれません。コストやメリット、オプションを明確に提示すれば、ユーザーは選択肢を与えられたように感じて選びやすくなる可能性があります。また、実世界の同等なものとコストを比べれば、視野を広げて価値を見直してもらえるかもしれません。Yazio は、定期購入の月間コストが 1 日 1 杯のコーヒーや他のダイエット製品よりも安いことをアピールしています。
また、常に言えることですが、パーソナライズしたメッセージを送れば、ユーザーは自分が大事にされていると感じます。Quickbooks は、定期購入のキャンセル フローの途中で、ユーザーがアプリで実現したこと（1,000 マイルを移動したなど）や、費用を払ったにもかかわらずまだ使っていなかった機能を提示しています。
上記のステップを通して、注目すべきユーザー グループとそれらのグループの障壁を表す、離脱につながるさまざまな行動パターンを発見できるかもしれません。もちろん、一部のグループでは、離脱は避けられない可能性もあります。アプリが提供するサービスの価値を誤解したユーザーや、単にそのアプリでは事足りなくなったユーザーがそういったグループに当てはまるでしょう。そういったケースもあるので、再定着に向けたさまざまな努力をしているにもかかわらず活動のレベルが低いままであるユーザー グループではなく、価値をもたらしてくれるグループに注目するようにしましょう。完全に離脱をなくすことは不可能であることを忘れないでください。
この記事が、離脱を最低限に抑える戦略の立案にお役に立つことを願っています。ここでご紹介した戦略は、「どっちつかず」のユーザーを定着させるために役立ち、獲得戦略や維持戦略とともに、アプリを継続的に成長させるために欠かせないものです。 この内容についてもっと知りたい方は、以下の関連情報をご覧ください。
この記事は Chet Haase による Android Developers - Medium の記事 "Now in Android #30" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は App Bundle、マテリアル デザイン コンポーネント、新しいターゲット API 要件、新しい Fragment とフローのドキュメント、最近公開されたブログ記事・動画・関連ドキュメント、ポッドキャスト エピソードなどをご紹介します。
最先端の 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 のブログ記事（英語）、またはすべてのリンクが掲載されているランディング ページからご覧ください。
2021 年後半には、ターゲット API（新規アプリとアプリのアップデート）と App Bundle の両方の要件が追加されます。Hoi Lam が、これについて詳しく説明したブログ記事を投稿しました。簡潔にまとめると、次のようになります。
2021 年 8 月:
2021 年 11 月:
Fragment は、UI デベロッパーに重要なアーキテクチャ要素を提供し、アプリの UI の小さな塊を自己完結的な形で管理できるようにします。Fragment と Navigation を組み合わせている方も、単独で Fragment を使っている方も、アプリで最も効果的に Fragment を使う方法を確認することをおすすめします。ツールや API の使い方を理解するために、最新の綿密なドキュメントを公開することが重要であると考えています。サポートが終了した API の利用は避けるべきですが、関連ドキュメントでは、正しい方向性を示したり、ベスト プラクティスを説明しています。
そこで、Fragment のドキュメントを大きく改訂し、ライフサイクル、状態、テストなど、Fragment のさまざまな側面について説明している最新のガイドを公開しました。こちらから、最新のドキュメントをご確認ください。
AndroidX で Fragment の修正や拡張を行っている Ian Lake が、Twitter のフィードで今回のドキュメントの変更に触れています。
Kotlin のフローについての新しいドキュメントも公開しました。ここには、フローの基本的な使用方法から、新しい StateFlow および SharedFlow API のテスト方法まで、あらゆる情報が掲載されています。また、フローの使用についての動画も忘れずにご覧ください。
StateFlow
SharedFlow
先週私は、アプリの起動時のパフォーマンスに関するいくつかの処理を自動化する方法について、ブログ記事（英語）を投稿しました。私は、起動時のパフォーマンス全般に注目しており、何度も繰り返して連続実行する際に、起動時間を求める処理を自動化する妥当な方法を見つけたいと考えてきました。同じように起動時のパフォーマンス テストに興味がある方のために、私が利用したアプローチを公開しています。
Manuel Vivo は、Dagger から Hilt への移行というブログ記事（英語）で、「その価値はあるのか？」という疑問を投げかけています。このブログ記事では、移行を検討すべきいくつかの重要な理由に触れています。たとえば、API のテスト、整合性、AndroidX 拡張機能との統合などです。
Hilt を使い始めるデベロッパーの皆さんに役立ててもらうため、Filip Stanis がKotlin による Hilt 実践ガイド（英語）を投稿しました。依存性注入や Dagger を使ったことがない方でも大丈夫です。まったく初めてという方も、ぜひお読みください。
タイトルからは、この記事が Kotlin デベロッパー向けのように思えるかもしれませんが、これは記事のコード スニペットに Kotlin を使っているからです。記事で紹介している一般的なアプローチやテクニックは、Java プログラミング言語を使っているデベロッパーにも当てはまります。
Manuel Vivo が Kotlin Vocabulary シリーズに新しい動画を投稿しました。Kotlin フローを使ってデータのストリームを発行する方法について説明しています。これは、以前公開した動画、コルーチンの ABC が元になっているので、先にそちらを見てからフローを学ぶのもよいでしょう。
David Winer が Kotlin Synthetics と View Binding についてのブログ記事を投稿しました。この 2 つはどちらも、厄介な findViewById() 呼び出しをコードから無くすためのメカニズムです。このブログ記事では、Kotlin プラグインの今後のバージョンで Synthetics のサポートが終了することをお伝えしています。また、今後も推奨とサポートが継続される @Parcelize エクステンションについても触れています。
findViewById()
@Parcelize
最近の Android リリースでは、ユーザーデータの保護、データアクセスへのコントロール、透過性向上に関して、多くの変更が行われています。特に重視されている領域が位置情報です。ユーザーは、アプリの位置情報へのアクセスを望まない場合や、そのアクセスを非常に注意深く制御したい場合があるからです。
そのため、Google Play ポリシーにより、バックグラウンドでの実行中に位置情報にアクセスするアプリでは、（Play Store から）アクセス許可をリクエストする操作が必須になります。このブログ記事では、そのリクエスト方法について詳しく説明しています。
今回は以上です。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
この記事は Murat Yener による Android Developers Blog の記事 "AGP 7.0: Next major release for the Android Gradle plugin" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
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 を使ってプラグインのテストと移行を行えるようになります。
@Deprecated
バージョン 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 で開くことができます。
AGP 7.0.0-alpha01 では依然として Java プログラミング言語バージョン 8 を使用できますが、現在、最低限必要な Java プログラミング言語のバージョンを Java 11 に変更する作業を行っています。これは AGP 7.0.0-alpha02 から適用される予定です。この変更については、デベロッパーの皆さんが余裕を持って準備できるように、Canary 版のスケジュールという早い段階で、安定版リリースの何か月も前にお知らせしています。
今回の AGP のリリースでは、いくつかの API が変更されます。なお、AGP 4.1 で導入されたたくさんの API はインキュベーション状態としてマークされ、変更の可能性がありました。そして実際、AGP 4.2 で一部の API が変更されました。現在インキュベーション状態になっている API は、先ほど説明したサポート終了サイクルには従いません。
いくつかの重要な API の変更について、概要をまとめました。
onVariants
onProperties
onVariantProperties
androidComponents
beforeVariants
VariantSelector
withBuildType
withName
withFlavor
afterEvaluate
beforeUnitTest
unitTest
beforeAndroidTest
androidTest
Variant
VariantBuilder
VariantProperties
いくつかの変更について確認してみましょう。以下のコードは、リリースビルドをターゲットとするサンプルの onVariants ブロックです。onVariants ブロックは beforeVariants に変更され、次の例のバリアント セレクタを使用します。
```android {…//onVariants.withName("release") {// ...//}…}androidComponents {val release = selector().withBuildType(“release”)beforeVariants(release) { variant ->...}}```
```
android {
…//onVariants.withName("release") {// ...//}…
…
//onVariants.withName("release") {
// ...
//}
}
androidComponents {
val release = selector().withBuildType(“release”)beforeVariants(release) { variant ->...
val release = selector().withBuildType(“release”)
beforeVariants(release) { variant ->
...
同様に、onVariantProperties ブロックも onVariants に変更されます。
```android {...//onVariantProperties {// ...\//}…}androidComponents.onVariants { variant -> ...}```
...//onVariantProperties {// ...\//}…
//onVariantProperties {
androidComponents.onVariants { variant ->
なお、このカスタマイズは通常はプラグインで行うもので、build.gradle に配置すべき内容ではありません。レシーバのある関数の使用は避けています。これは DSL 構文には適していますが、プラグインのコードには必要ありません。
これらの API は、AGP 7.0.0 で安定版になる予定です。また、すべてのプラグイン作成者は、新しい androidComponents に移行する必要があります。このような変更に対処するのを避けたい方は、プラグインで安定版の API のみ使用し、インキュベーション状態の API は使わないでください。
今回のリリースに含まれるその他の変更点の詳細については、リリースノートをご覧ください。
Java は Oracle および/またはその関連会社の登録商標です。
この記事は Jamal Eason による Android Developers Blog の記事 "Announcing Android Studio Arctic Fox & Android Gradle plugin 7.0!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2020 年 12 月 1 日（日本時間 12 月 2 日）、Android Studio Arctic Fox（2020.3.1） の初めてのバージョンが Canary チャンネルでリリースされ、それとともに Android Gradle プラグイン（AGP）バージョン 7.0.0-alpha01 もリリースされました。今回のリリースでは、Android Studio と Gradle プラグインのバージョン番号の付け方を調整しています。この変更で、Android Studio のバージョン番号スキームから Gradle プラグインを切り離し、Android Studio のそれぞれのリリースがどの年に行われて、どの IntelliJ バージョンに一致しているかを明らかにします。
Android Studio Arctic Fox（2020.3.1）では、Android Studio のベースとなっている IDE である IntelliJ IDEA との整合性を高めるため、年に基づいた採番に移行します。バージョン番号スキームは、年、ベースとなった IntelliJ のバージョン、機能およびパッチレベルという重要な属性を組み込んだものに移行します。この名称変更により、Android Studio で使っている IntelliJ プラットフォームのバージョンがすぐにわかるようになります。さらに、メジャー バージョンごとに正規のコードネームを割り当てます。最初のコードネームは Arctic Fox で、以降はどのバージョンが新しいのかが簡単にわかるように、アルファベット順に進めます。
デベロッパーの皆さまには、最新の機能と品質改善を利用できるように、最新バージョンの Android Studio を使うことをおすすめします。バージョンを簡単に最新に保つことができるように、Android Studio のバージョンと Android Gradle プラグインのバージョンは明確に切り離します。覚えておくべき重要な点は、IDE をアップデートしても、ビルドシステムがアプリをコンパイルしたりパッケージングしたりする方法は何も変わらないことです。逆に、アプリのビルドプロセスの変更や APK / バンドルは、プロジェクトの AGP バージョンによって決まります。したがって、開発サイクルの後半であっても、Android Studio のバージョンは安全にアップデートできます。プロジェクトの AGP バージョンは、Android Studio のバージョンとは異なるタイミングでアップデートできるからです。また、新しいバージョンのシステムでは、安定版リリースの AGP バージョンを使っている限り、個人やチームのアプリ プロジェクトで安定版とプレビュー版の Android Studio を両方同時に実行することがこれまで以上に簡単になります。
これまでのバージョン番号システムで言えば、今回のリリースは Android Studio 4.3 になります。新しい番号システムでは、Android Studio Arctic Fox（2020.3.1）Canary 1、または単に Arctic Fox となります。
今後、Android Studio のバージョン番号スキームは次のようになります。
AGP 7.0.0 では、セマンティック バージョニングの考え方を採用し、AGP に必要な Gradle バージョンと一致させます。 Android Studio と Android Gradle プラグインとの互換性には、変更はありません。AGP の安定版を使うプロジェクトはそれより新しいバージョンの Android Studio で開くことができます。
近日中には更に、AGP のバージョン番号の考え方と、今回の新しいメジャー リリースである AGP 7.0 の新機能について詳しく説明したブログ記事を公開する予定です。
現在は Arctic Fox の機能開発フェーズの初期段階ですが、コードエディタ、アプリ インスペクション ツール、Layout Editor、組み込みエミュレータなど、IDE のさまざまな領域にわたる 200 以上の品質改善とバグの対応を行いました。具体的なバグの修正については、リリースノートをご覧ください。
Jetpack Compose を使っている方のために、デバイスやエミュレータへの @Preview Composable のデプロイなど、多くの新しいアップデートを行っています。
@Preview
新しい Layout Validation ツールもお使いください。さまざまな画面サイズ、フォントサイズ、Android Color Correction / Color Blind Mode にレイアウトがどう反応するかを確認できます。この機能には、Layout Editor を使っているときに [Layout Validation] ツール ウィンドウからアクセスできます。
最後に、MacOS（その他のプラットフォームも近日中に対応予定）で最新の Android プラットフォーム ツールと Android 11 デバイスを使っている方は、Run ボタンのデバイス選択ダイアログ → [Pair Devices Using Wi-Fi] から、IDE に組み込まれた Wireless ADB 機能を使うことができます。
Android Studio と Android Gradle プラグインの今回のリリースに含まれるその他の詳しい変更点については、リリースノートをご覧ください。
この記事は Hoi Lam による Android Developers Blog の記事 "New Android App Bundle and target API level requirements in 2021" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年も、毎年継続しているターゲット API レベルのアップデートを行います。2021 年 8 月からは新しいアプリで、2021 年 11 月からはすべてのアプリのアップデートでターゲット API レベル 30（Android 11）が必須になります。さらに、今年既にお知らせしたように、新しいアプリは、Google Play で Android App Bundle 公開フォーマットを使うことが必須になります。この形式により、アプリサイズは小さくなり、リリースが簡単になるなど、メリットを受けられるユーザーやデベロッパーが増え、最新のアプリ配信方法に対する継続的な投資をサポートします。
App Bundle は、Google Play で公開されている 75 万個以上のアプリやゲームで利用されています。切り替えを済ませたトップアプリは、ユニバーサル APK と比べて平均 15% のファイルサイズの縮小に成功しました。ユーザーにはダウンロードのファイルサイズが小さくなるメリットがあり、Netflix や Riafy などのデベロッパーではアプリのインストール成功率が上がっています。普及しているデバイスがエントリレベルであったり、データ転送速度が遅いデバイスが多い地域では、特に大きな効果があります。切り替えを済ませたデベロッパーは、Play Asset Delivery や Play Feature Delivery などの高度な配布機能を使うこともできます。また、私たちは、皆さんのフィードバックを重視しており、それに基づいて切り替えの前には、Google Play アプリ署名 や Android App Bundle にさらに機能やオプションを導入する予定です。
2021 年 8 月より、Google Play Console のすべての新しいアプリで以下の条件を満たすことが必須になります。
2021 年 11 月より、既存アプリのアップデートでターゲット API レベル 30 以上および Android 11 の動作の変更点への対応が必須になります。アップデートのない既存のアプリは影響を受けず、今後も Play ストアからダウンロードできます。
Android App Bundle による配信に切り替えると、従来の Instant App の ZIP フォーマットを使った Instant エクスペリエンスにも影響します。2021 年 8 月以降は、新しい Instant エクスペリエンスへの対応 と 既存の Instant エクスペリエンスのアップデートを行わないと、 Instant 対応 App Bundle を公開することはできません。
すべての変更点の概要を改めて示します。
リリースの種類
変更前
2021 年 8 月に必須
Google Play 上の
新規アプリ
APK
Android App Bundle（AAB）
ターゲット API レベルを 29 以上に設定
ターゲット API レベルを 30 以上に設定
拡張ファイル（OBB）
Play Asset Delivery または
Play Feature Delivery
2021 年 11 月に必須
既存アプリのアップデート
新しい公開フォーマット要件はなし
Wear OS アプリには、新しいターゲット API レベル要件は適用されません。minSdkVersion は任意のものを使うことができるので、古い Android バージョンを対象にアプリを作成できる点は変わりません。
App Bundle への移行の詳細については、新しい動画シリーズ Modern Android Development（MAD）Skills をご覧ください。
既に App Bundle と API レベル 30 に採用しているすべてのデベロッパーの皆さん、本当にありがとうございます。皆さんとともに Android プラットフォームをさらに進化させるのを楽しみにしています。
2020 年もあと一ヶ月となりました。今年は、想像できない年となりました。Google Play は、デベロッパーの皆さまが必要とされているサポートを提供するために、Indie Games Festival や Android 11 Meetups をはじめとしたデベロッパー向けの各種イベントのオンラインへの移行、 Android Developers Japanブログの開設を始めとするオンラインでの情報発信と精度の強化を行ってきました。その一方で、デベロッパーのみなさまは、様々な困難の中、ユーザーファーストの精神を忘れず、この 1 年の変化に対応するために多くの工夫と努力を続けてこられました。前例のない一年となった 2020 年の総括として、日本の Android デベロッパーによる多くの取り組みの中からその一部をピックアップし、動画としてまとめました。どうぞ、ご覧ください。
今年、日本で人気を集めた Google Play のコンテンツを紹介する Google Play ベスト オブ 2020 のアプリ、ゲームにおける部門賞および各部門の大賞と最優秀賞を本日発表しました。
2020 年は、特に大変だった 1 年にも関わらず、デベロッパーのみなさまの努力によって新しい世界観を持った意欲的なアプリやゲームが登場した 1 年でもありました。
そんな 2020年という年に、日本のGoogle Play ベストオブ 2020を受賞した作品をご紹介します。受賞された皆様、おめでとうございます！
