2018 年より開催している Google Play 主催の Indie Games Festival は、インディー ゲームとそのデベロッパーの革新性や独自性を称えるイベントです。2021 年に 4 回目を迎えた Indie Games Festival の、トップ 3、トップ 10、特別賞を決定するファイナル イベントを、9 月 4 日 (土) にオンラインで開催しました。
今年は、初めてバーチャル化し、全国から多くの方がイベントに参加されました。また、1 日限りのオンライン展示・交流プラットフォーム、”Adventure” をオープンし、日本だけでなく、韓国やヨーロッパのファイナリストとの貴重な交流や作品のダウンロード、ファイナル イベントをプラットフォーム内のステージ上で視聴するなど、Twitter などの SNS でも盛り上がりをみせていました。
作品のクオリティは、年々高くなっており、カジュアル ゲームから作家性の高いものまで多様な作品が並びました。
審査員は予め全作品をプレイし、事前収録したファイナリストたちの 5 分間のプレゼンテーション動画を視聴後、審査に挑みました。ファイナル イベントではファイナリストたちが 1 分間のアピールタイムと質疑応答に対応。その後、各審査員による協議を経てトップ 3、トップ 10、各特別賞の受賞者を発表、表彰しました。
そして今回、Google Play | Indie Games Festival 2021 のトップ 3、トップ 10 ならびに特別賞の受賞作品を審査員からのコメントと合わせて発表いたします。
受賞された皆さま、おめでとうございます！
※（五十音順、敬称略）
※上記 3 作品を除く（五十音順、敬称略）
※（敬称略）
Indie Games Accelerator 賞
Odencat 株式会社
学生部門賞
HAKOT
TOHO Games 賞
集英社ゲームクリエイターズ CAMP 賞
UUUM賞
Google Play | Indie Games Festival 2021 の開催に際し、多大なるご協力をいただいた、社外審査員、特別賞審査員の皆さま、ありがとうございました！各受賞作品への審査員の方々からのコメントや受賞理由は後日こちらのブログに掲載させていただきます。
Written by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
このイベントでは、Android/Google Play のゲーム向け製品開発の責任者である Greg Hartrell の基調講演の内容を中心に日本の Google 関係者が解説を行いました。
この記事では、イベント内で解説した内容とご紹介した関連動画やリソースをまとめます。
その他にも、イベント内では、海外デベロッパーの事例が聞けるセッションのご紹介も行いました。
なお、イベントのアーカイブ配信は、こちらのウェブサイトから登録後、いつでもご視聴いただけます。イベントを見逃した方は、ぜひアーカイブ配信もご活用ください。ウェブサイト上では、イベント内でご紹介した URL も多数公開していますので、こちらのリンク集からご確認ください。
この記事は Jacob Lehrbaum による Android Developers Blog の記事 " Working Towards Android App Excellence " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
すばらしいアプリ体験は、ビジネスにもすばらしい成果をもたらします。実際、Google Play に5 つ星の評価を残した Android アプリユーザーの約 3 分の 1 が、アプリ体験の質*1つまり、スピードやデザイン、ユーザビリティに触れています。Google では、すべてのデベロッパーが優れたアプリの開発を実現し、ユーザーの獲得、維持、収益化を果たせるようなサポートを提供したいと考えています。
では、「優れたアプリ」とは何でしょうか。これは遠い目標のように聞こえるかもしれませんが、多くのアプリでも手が届くところにあります。その第一歩となるのは、ユーザーにフォーカスし続けることです。具体的には、直感的なユーザー エクスペリエンスでアプリの主要機能にできる限り早く到達できるようにすることです。しかし、これはまだ始まりに過ぎません。優れたアプリにはすべての画面や操作に一貫性があり、使うデバイスによらず快適に動作します。アプリ開発に携わっているあらゆるメンバーがアプリ体験に集中すれば、優れたアプリの開発が実現できます。
優れたアプリの開発を阻むものの 1 つが、曖昧で不明確な責任分担です。クラッシュや読み込み時間など、アプリの質を測る主な指標の中には、エンジニアリング チームなどの社内の 1 グループの責任であると見なされるものがあります。しかし、業界のトップクラスの組織の方々にどのようにして優れたアプリの開発を実現しているか聞いたところ、*2エンジニアリング、デザイン、プロダクト、ビジネスの各チームが共通の目的に向かって連携する、部門間の協力的なアプローチが重要であることが明確になりました。
では、優れたアプリ開発のための裏側にある内部的なベスト プラクティスはどのようなものでしょうか。
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。クロス プラットフォーム アプリのソフトウェア エンジニア
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。
クロス プラットフォーム アプリのソフトウェア エンジニア
優れたアプリは、ビジネスの成果につながります。新機能の追加はすばらしいことですが、それでアプリの起動時間が遅くなったり、デバイスの容量を使いすぎたりすると、アプリの使用頻度が減り、やがて削除される結果をうみます。多くの場合、エンジニアは品質問題がビジネスの成果に与える影響を定量化することで、全社的に品質を重視する体制を構築しています。具体的には、次の方法で定量化しています。
機能（ユーザー ジャーニーの各ステージ）を担当するチームを編成している企業は、サポートするそれぞれのオペレーティング システム全体で一貫した操作を提供し、新しいアプリや機能を市場に投入するまでの時間が短くなり、すべてのお客様に優れたアプリ体験を提供できる可能性が高くなります。多くの場合、このようなチームは、エンジニア、マーケティング、UX、プロダクトなどの機能を横断するグループです。そして、あらゆるデバイスやプラットフォームで、機能やユーザー ジャーニーのステージ*3を成功させる責任を担います。この構造により、優れた体験や機能レベルが実現できるだけでなく、機能領域を超えた統一目標ができます。また、縦割りを減らして、特定の目標に集中的に対処することにもつながります。
ビジネス目標を重視するチーム構成により、ユーザーに対するフォーカスが高まる
ユーザーの大半が特定の種類のデバイスを使っている場合、主なデバイスとして同じスマートフォンやタブレット、スマートウォッチを使えば、ユーザーがどのような体験をしているか理解が深まるでしょう。特にこれが当てはまるのは、多くユーザーの日々の体験に影響を与える意思決定が求められる組織の経営幹部です。たとえば、Duolingo はこれを自社の DNA に組み込んでいます。ユーザー ベースの大部分と同様の環境を作り出すために、CEO も含む、すべての Duolingo の社員は、エントリーレベルの Android デバイスのみを使っているか、あるいは使える状態にあります。
ビジネスを成長させるうえで、品質および優れたアプリの開発に対するユーザー中心のアプローチは欠かせません。優れたアプリの開発を実現する方法を詳しく学びたい方は、実用的なヒントを含むケーススタディをご覧ください。また、Android App Excellence (英語) のページにアクセスし、ぜひ App Excellence Summit に参加してください。（事前登録制です）
今後のブログ投稿では、優れたアプリの開発を実現する 2 つの要素について詳しく取り上げる予定です。具体的には、アプリ パフォーマンスとそれによるユーザー行動への影響、そして複数のデバイス間のシームレスなユーザー エクスペリエンスの開発です。こちらのページから Android デベロッパー向け ニュースレターに登録すると、次号の発行時に通知が届き、Android チームからの最新ニュースや知見を得られますので、ぜひご登録ください。
注
1. 2021 年の Google Play 内部データ
2. 2021 年の Google App Quality Research
3. アプリを使ううえで、それぞれのユーザーが体験する一連の手順を「ユーザー ジャーニー」と呼びます。ユーザー ジャーニーのステージの例として、インストール、オンボーディング、エンゲージメント、リテンションなどがあります
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
2021 年 9 月 4 日 (土) に開催される、Google Play l Indie Games Festival 2021 ファイナル イベントに向けて、ファイナリストたちのプレゼンテーション動画を公開しています。各ゲームの詳細や、 開発者の皆さんのゲーム開発に対する熱い思いを語っていただきましたので、ぜひファイナル イベント前にご視聴ください。
各プレゼンテーション動画へのリンクは、以下よりご確認ください。
Google Play Indie Games Festival 2021’ トップ 20 :
（アイウエオ順）
*「クトゥルフと夢の階段」の動画は都合により公開しておりません。
この機会に、トップ 20 作品をダウンロードして、あなたのお気に入りのゲームを見つけてみてください。各ゲームは、イベント Web サイトのこちらのページからダウンロードしていただけます。各ゲームの感想や応援コメントを投稿される際はハッシュタグ #indiegamesfestivaljp をご活用ください。
Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Dave Burke による Android Developers Blog の記事 " Android 12 Beta 4 and Platform Stability " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
デベロッパーの皆さんにとって、Beta 4 は プラットフォームの安定版 を意味します。つまり、Android 12 の API とアプリに面する動作がすべて確定します。アプリやゲームにとっては、互換性と品質に注力していただく時期です。今年後半の公式リリースに間に合うように、互換性のあるアプリやゲームへのアップデート準備をお願いいたします。
Beta 4 は、Pixel デバイスで試すことができます。こちらから登録 (英語) するとOTA (無線)アップデートを受け取ることができます。以前登録している方は、自動的に今回のアップデートを受け取ります。ASUS、OnePlus、Oppo、realme、シャープ、ZTE など、いくつかのパートナーの一部のデバイスでも Android 12 Beta 4 を試すことができます。詳しくは android.com/beta をご覧ください。使用を開始する方法についての詳細は、Android 12 デベロッパー サイトにアクセスしてください。
Android 12 Beta 4 は、プラットフォームの安定版 に到達しました。これは、Android 12 のアプリに面する部分とその動作がすべて確定したことを示すマイルストーンです。公式の SDK と NDK API だけでなく、アプリに影響する可能性がある非 SDK インターフェースでも、アプリに面するシステム動作や制限が確定します。Beta 4 以降では、プラットフォームが変更されないことがわかっているので、安心して互換性アップデートをリリースできます。スケジュールの詳細はこちらをご覧ください。
すべてのアプリとゲームのデベロッパーは、最終リリース前にできるだけ早く最終の互換性テストを開始し、互換性アップデートを公開する準備をしてください。
すべての SDK、ライブラリ、ツール、ゲームエンジン デベロッパーの皆さんは、今すぐテストを始めて、できる限り早く互換性アップデートをリリースすることが非常に重要です。下流のアプリやゲームのデベロッパーは、皆さんのアップデートを受け取るまで作業できないかもしれません。互換性アップデートをリリースしたら、デベロッパーに向けてアナウンスしてください。
Android アプリの互換性とは、新しいバージョンのプラットフォームでアプリが意図したとおりに動作することを意味します。アプリの互換性は、デバイスかエミュレータに公開版のアプリをインストールしてテストするだけで確認できます。アプリの表示が問題なく、正しく動作すれば、それで終了です。そのアプリには互換性があります。
アプリの互換性テストは重要です。なぜなら、リリースごとにプラットフォームに必要な変更を行い、プライバシーやセキュリティを改善したり、OS 全体のユーザー エクスペリエンスを向上させたりしているからです。これにより、アプリに影響が生じる可能性もあります。そのため、すべてのアプリの動作の変更点についてのドキュメントを確認してテストし、ユーザーに互換性アップデートを公開する必要があります。アプリで優れたユーザー エクスペリエンスを確保するために、このレベルの品質は基本的かつ不可欠です。
デバイスを Android 12 にアップデートしたユーザーは、最新バージョンの Android やお気に入りのアプリやゲームを試してみたくなるでしょう。アプリやゲームが正しく動作しないと、大きな問題になり、結果的にアンインストールにつながります。
利用できる新しい API や機能はたくさんありますが、まずは現在のアプリをテストし、互換性アップデートをリリースするところから始めましょう。
Android 12 でのアプリの互換性テストは、Android 12 Beta 4 を実行しているデバイスに Google Play や他のソースから公開版のアプリをインストールするだけで行うことができます。そしてアプリのすべてのフローを試し、機能や UI の問題を探します。すべてのアプリが対象となる Android 12 の動作の変更点を確認し、集中的にテストを行ってください。特に注意すべき変更点は、以下のとおりです。
アプリのライブラリや SDK の互換性テストも忘れずに行ってください。問題を見つけた場合は、最新バージョンの SDK にアップデートするか、デベロッパーに連絡してサポートを受けるようお願いします。
現在のアプリの互換性のあるバージョンを公開したら、アプリの targetSdkVersion をアップデートするプロセスを開始できます。Android 12 をターゲットとするアプリの動作の変更点を確認し、互換性フレームワークを使って問題をすばやく検知します。以下に、テストが必要な変更点の一部を記載します（targetSdkVersion が 31 以上のアプリに適用されます）。
SCHEDULE_EXACT_ALARM
android:exported
テストでは、制限されている非 SDK インターフェースが使用されていないかも確認し、存在する場合は同等のパブリック SDK に移行します。制限されている API については、こちらをご覧ください。
今回のベータ版リリースには、Android 12 の機能を試し、アプリをテストしてフィードバックを提供するために必要なすべてのものが含まれています。サポート対象となっている Pixel デバイスを登録するだけで、OTA(無線)でアップデートを入手できます。また、Android 12 に対応したアプリの開発を行うために、Android 12 SDK をセットアップしてください。
ASUS、OnePlus、Oppo、realme、シャープ、ZTE など、いくつかの主要メーカーのデバイスでも Android 12 Beta 4 を試すことができます。Android 12 Beta に対応しているデバイスとパートナーの全リストは、android.com/beta に掲載されています。さらに幅広くテストしたい場合は、Android GSI イメージで Android 12 Beta 4 をお試しください。デバイスをお持ちでない場合は、Android Emulator でテストできます。
Beta 4 は Android TV でも利用できるので、ADT-3 デベロッパー キットを使って、最新の TV 機能を確認したり、新しくなった Google TV エクスペリエンスでアプリをテストしたりできます。詳しくはこちらをご覧ください。(英語)
数週間後には、最終テスト用のリリース候補として、最後のベータ版をお届けする予定です。
Android 12 Betaの詳細については、Android 12 デベロッパー サイトをご覧ください。
この記事は Krish Vitaldevara による Android Developers Blog の記事 " Announcing Policy Updates To Bolster Privacy and Security " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは常に、Google Play での体験が、デベロッパーやユーザーにとって安全で信頼性の高いものであることを目指しています。本日は、ユーザーが自身でデータをコントロールでき、プライバシー、セキュリティを高めるための新しいポリシー更新情報についてお知らせします。
Google Play に新しく「セーフティセクション」が追加されます。このセクションに関する新しいポリシーを、データの定義などの追加情報と併せて発表しました。詳細はこちらをご覧ください。
Google は長期にわたり、ユーザーが広告 ID をコントロールできる方法を提供してきました。たとえば、ID はいつでもリセットでき、ID を使った広告のカスタマイズをオプトアウトできるようにしています。今年は、さらに多くの管理方法を追加します。
2021 年 6 月 2 日にデベロッパーの皆さんに先行してお知らせしたように、Google Play 開発者サービスの更新の一環として、2021 年後半に技術的な変更を行います。ユーザーがインタレストベース広告や広告のカスタマイズをオプトアウトすると、広告 ID が削除され、ゼロの文字列が返されます。なお、この Google Play 開発者サービスの変更は、段階的にロールアウトされる予定です。2021 年後半から Android 12 デバイスで実行されるアプリに反映され、2022 年初頭には Google Play をサポートするデバイスで実行されるすべてのアプリに展開されます。また、ターゲット API レベルを Android 12 にアップデートするアプリで広告 ID を使うには、マニフェスト ファイルで新しい Google Play 開発者サービスの権限 (英語) を宣言する必要があります。
さらに、ユーザーがオプトアウトを希望することをデベロッパーと広告/分析サービス プロバイダに通知する新機能のテストも行います。この機能によりデベロッパーは、ユーザーの選択を反映し、既存のポリシー制限に、広告 ID が、どのように使用されるか追加できるようになります。ユーザーが広告 ID を削除すると、デベロッパーは通知を受け取り、使えなくなった広告 ID を速やかに消去できます。
加えて、永続デバイス ID を個人データや機密性の高いユーザーデータ、またはリセット可能なデバイス ID にリンクすることを禁止します。このポリシーは、ユーザーがデバイス ID をリセットしたり、アプリをアンインストールしたりしたときの追加のプライバシー保護のためのレイヤーとなります。
そして最後に、アプリセット ID (英語) のデベロッパー プレビューを提供します。この機能は、分析や不正防止などの重要なユースケースに活用できます。アプリセット ID は一意の ID です。任意のデバイスでこの ID を利用することにより、組織が所有する複数のアプリ間で利用状況や操作を相互に関連付けることができます。アプリセット ID は、広告のパーソナライズや広告の測定に使うことはできません。また、デバイスでそのデベロッパーのアプリがすべてアンインストールされるか、13 か月間どのアプリも ID にアクセスしなかった場合、自動的にリセットされます。
分析や不正防止のためにアプリセット ID を導入するとともに、子ども向けのプライバシーをさらに強化するための変更も行います。アプリが主に子ども向けである場合、広告 ID などの ID を送信することはできません。アプリの対象が子どもと大人の両方である場合、子どもに向けて ID を送信しないようにする必要があります。
スムーズに移行できるように、今後数か月間で詳しい情報を提供する予定です。
プラットフォーム全体のプライバシーを実現する上で、セキュリティは欠かせない要素です。ユーザーのデータを安全に保つために、いくつかのポリシーの更新をお知らせします。
まずはじめに、デベロッパーの皆さんがアプリを積極的に保守を行うことによって、Google Play は安全なエコシステムであり続けることができます。そこで、1 年間利用されていないアカウントや放置されているアカウントを閉鎖します。これには、1 年間 Google Play Console にアプリをアップロードしなかったアカウントや、アクセスがなかったアカウントも含まれます。
積極的に成長しているアプリを開発しているデベロッパーの皆さんへのサポートは継続します。1000 以上のインストールがあるアプリや、直近 90 日間にアプリ内購入があるアプリのアカウントは例外とします。アカウントが閉鎖されたデベロッパーは、その後も新しいアカウントを作ることはできますが、古いアカウント、アプリ、データを再度アクティブ化することはできません。
次に、ユーザーにとって重要なのは、安全でユーザーが利用しやすいアプリやゲーム体験です。そこで、AccessibilityService API と IsAccessibilityTool (英語) の利用方法に関する新しい要件を追加します。多くの場合、ユーザー補助機能が備わった体験を構築するには、ユーザーのデータやデバイスの機能にアクセスすることが必要です。上記のツールは、それを実現するうえで役立ちます。現在、AccessibilityService API を利用するすべてのアプリは、Google Play Console でデータへのアクセスと目的について開示し、承認を得る必要があります。詳細はこちらをご覧ください。
2021 年 7 月にお知らせしたように、ビジネスサイズの大小に関わらず様々なデベロッパーの皆さんからのフィードバックを慎重に検討した結果、お支払いポリシーに準拠する期限を 2022 年 3 月 31 日まで 6 か月間延長するリクエストを行えるようにしています。
Google Play が誰にとっても信頼できるアプリとゲームの提供元であり続けるためご協力いただきますよう、お願いいたします。
この記事は Ian Lake による Android Developers - Medium の記事 " Animations in Navigation Compose" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Jetpack Composeは、「時間があれば調整する」というアニメーションの考え方を「とても簡単なのでやらない手はない」に変えます。その際、大きな役割を果たすのが、画面レベルの遷移です。そのために次の 3 つの具体的な問題を解決する一連のソリューションを目指して Navigation Compose の開発が進められています。
上記のソリューションごとに微妙に異なるアプローチが必要になります。ここでは、その詳細について詳しく説明します。
Jetpack Compose は、最初の 0.1.0-dev01 リリースから最新の Compose 1.0.1 リリースまで、とても長い道のりを歩んできました。ビューの世界と比べて大きく改善された領域の 1 つが、アニメーションと遷移です。完璧なアニメーション API を追求し、Compose が 1.0.0 に進む中、多くの変更が行われました。
信じられないほど強力な animateTo() や animate*AsState() など、たくさんの低レベルのアニメーション API は安定版になりましたが、現時点では、Compose の土台を構成する多くの API が、@ExperimentalAnimationApi とマークされた構成要素に基づいています。
animateTo()
animate*AsState()
@ExperimentalAnimationApi
試験運用版 API（Kotlin の世界では @RequiresOptIn API を使っている API）は、今後変更される可能性がある API であることを表します。つまり、これらの API は、今後のリリースで変更、改善、置換される可能性があります。たとえば、Compose 1.1.0-alpha04 や 1.2.0-alpha08 などで変更されるかもしれません。そのため、試験運用版 API を使うライブラリでは、使っていた Compose のバージョンをアップデートする場合、そのライブラリ も 同時にアップデートしない限り、クラッシュしたり動作しなくなったりします（初期の Compose リリースを使っていた方なら、その苦しみがわかるはずです）。
@RequiresOptIn API
AndroidX リリース ページに記載されているように、Navigation や Compose を含むすべての AndroidX ライブラリは、セマンティック バージョニングに厳密 （英語）に従います。逆に、試験運用版でない API は、ライブラリがリリース候補（RC）フェーズに入ったタイミングで確定します。こういった安定版 API が互換性のない形で変更されるのは、メジャー バージョンが変更されるタイミング（「2.0」など）になります。
これは、上位互換性や下位互換性の観点で見れば素晴らしいことです。たとえば、新しいアルファ版を試すために Fragment のバージョンをアップグレードしつつ、他の依存関係は安定版リリースの状態を維持すれば、すべて問題なく動作します。
しかしながら、試験運用版 API は根底から覆る可能性もあるので、異なるアーティファクト グループにわたって試験運用版 API を使うことは厳しく禁じられています。つまり、androidx.fragment のバージョンをアップグレードしても、androidx.appcompat が動作しなくなることはありません。androidx.navigation や androidx.compose.animation も同様です。
androidx.fragment
androidx.appcompat
androidx.navigation
androidx.compose.animation
Navigation 2.4 は大きなリリースです。Navigation Compose の最初のリリースであるとともに、Navigation Compose と Fragment 対応の Navigation 、両方で複数バックスタックがサポートされた最初のリリースでもあるからです。つまり私たちは、ベータ版、RC 版を経て安定版に向かう準備として、残りの関連 API リクエストに対応する作業を行っています。
Navigation Compose では、Compose 1.0.1 を土台としつつ、Compose 1.1.0-alpha01 以降を利用するために移行したい人（または既に移行した人）のために上位互換性を持たせることが目的となります。
この上位互換性要件が意味するのは、Navigation Compose 2.4.0 のコードが安定版の Compose Animation API しか利用できないということです。私たちはこのようにして、Navigation 2.4.0-alpha05 にクロスフェードのサポートを追加できました。Compose の世界では、ジャンプカットは真っ先に排除すべきです。
安定版の Compose Animation API のみを使えるという制限により、Navigation 2.4 から AnimatedContent （英語）などの API を直接使うことはできないため、皆さんが Navigation 2.4 の一部として直接利用したい高度なアニメーション制御などが提供されない場合があります。ただし、Navigation は拡張可能なので、ベースとなるフレームワークは既に構築されており、それを利用できます。
AnimatedContent
今回リリースされた Navigation 2.4.0-alpha06 で Accompanist Navigation Animation を実現できたのは、このような宛先間のアニメーションがベースとしてサポートされているからです。Navigation Animation アーティファクトは、これまで利用されてきたバージョンの Navigation Compose API で実現できる一連のアニメーションを提供します。
rememberNavController()
rememberAnimatedNavController()
NavHost
AnimatedNavHost
import androidx.navigation.compose.navigation
import com.google.accompanist.navigation.animation.navigation
import androidx.navigation.compose.composable
import com.google.accompanist.navigation.animation.composable
一見、アプリの見た目は変わっていないように見えます。デフォルトのアニメーションは同じ種類の fadeIn と fadeOut のままで、Navigation 2.4 のクロスフェードがこれを行ってくれます。しかし、1 つの重要な新機能が利用できるようになります。それは、アニメーションを構成し、独自の画面遷移に置き換える機能です。
fadeIn
fadeOut
この制御は、すべての Composable の宛先に存在する 4 つの新しいパラメータを通して行います。
enterTransition
navigate()
exitTransition
popEnterTransition
popBackStack()
popExitTransition
パラメータはすべて同じ形式です。
enterTransition: ( ( initial: NavBackStackEntry, target: NavBackStackEntry ) -> EnterTransition?)? = null,
(
initial: NavBackStackEntry,
target: NavBackStackEntry
) -> EnterTransition?
)? = null,
受け取るのはラムダです。このラムダは、移動元（initial）と移動先（target）を表す NavBackStackEntry を受け取ります。たとえば enterTransition の場合、次に入る宛先が target で、それが enterTransition の適用対象となります。exitTransition はその逆で、initial 画面が exitTransition の適用対象です。
initial
target
NavBackStackEntry
つまり、宛先は次のように書くことができます。
composable( "profile/{id}", enterTransition = { _, _ -> // Let's make for a really long fade in fadeIn(animationSpec = tween(2000) }) { // Add content like normal}
"profile/{id}",
enterTransition = { _, _ ->
// Let's make for a really long fade in
fadeIn(animationSpec = tween(2000)
}
) {
// Add content like normal
または、移動元や移動先に基づいてアニメーションを制御することもできます。
composable( "friendList" exitTransition = { _, target -> when (target.destination.route) { "profile/{id}" -> ExitTransition.fadeOut( animationSpec = tween(2000) ) // slowly fade it out else -> null // use the defaults } }) { // Add content like normal}composable( "profile/{id}", enterTransition = { initial, _ -> when (initial.destination.route) { "friendList" -> slideInVertically( initialOffsetY = { 1800 } ) // slide in the profile screen else -> null // use the defaults }) { // Add content like normal
"friendList"
exitTransition = { _, target ->
when (target.destination.route) {
"profile/{id}" -> ExitTransition.fadeOut(
animationSpec = tween(2000)
) // slowly fade it out
else -> null // use the defaults
composable(
enterTransition = { initial, _ ->
when (initial.destination.route) {
"friendList" -> slideInVertically(
initialOffsetY = { 1800 }
) // slide in the profile screen
この例では、友達リスト画面は、プロフィール画面に戻る際の遷移を制御しています。また、プロフィール画面は、友達リスト画面から入ってくる際の遷移を制御しています。これにより、2 つの宛先間でカスタムのスライド オーバー アニメーションを実現しています。この例からは、null を指定すると「デフォルトを使用」という意味になることもわかります。デフォルトは、親のナビゲーション グラフ、そして親の親のナビゲーション グラフというように、ルートとなる AnimatedNavHost までの階層によって決まります。つまり、AnimatedNavHost でグローバルな enterTransition と exitTransition を変更するだけで、デフォルトのアニメーション（ここでは、クロスフェードのタイミング）を設定できます。
null
1 つのサブグラフだけのデフォルトを変更したい場合は（たとえば、ログインフローでは常に水平スライド アニメーションを使う）、ネストしたグラフのレベルでアニメーションを設定することもできます。
navigation( startDestination = "ask_username" route = "login" enterTransition = { initial, _ -> // Check to see if the previous screen is in the login graph if (initial.destination.hierarchy.any { it.route == "login" }) { slideInHorizontally(initialOffsetX = { 1000 } } else null // use the defaults } exitTransition = { _, target -> // Check to see if the new screen is in the login graph if (target.destination.hierarchy.any { it.route == "login" }) { slideOutHorizontally(targetOffsetX = { -1000 } } else null // use the defaults } popEnterTransition = { initial, _ -> // Check to see if the previous screen is in the login graph if (initial.destination.hierarchy.any { it.route == "login" }) { // Note how we animate from the opposite direction on a pop slideInHorizontally(initialOffsetX = { -1000 } } else null // use the defaults } popExitTransition = { _, target -> // Check to see if the new screen is in the login graph if (target.destination.hierarchy.any { it.route == "login" }) { // Note how we animate from the opposite direction on a pop slideOutHorizontally(targetOffsetX = { 1000 } } else null // use the defaults }) { composable("ask_username") { // Add content } composable("ask_password") { // Add content } composable("register") {
startDestination = "ask_username"
route = "login"
// Check to see if the previous screen is in the login graph
if (initial.destination.hierarchy.any { it.route == "login" }) {
slideInHorizontally(initialOffsetX = { 1000 }
} else
null // use the defaults
// Check to see if the new screen is in the login graph
if (target.destination.hierarchy.any { it.route == "login" }) {
slideOutHorizontally(targetOffsetX = { -1000 }
popEnterTransition = { initial, _ ->
// Note how we animate from the opposite direction on a pop
slideInHorizontally(initialOffsetX = { -1000 }
popExitTransition = { _, target ->
slideOutHorizontally(targetOffsetX = { 1000 }
composable("ask_username") {
// Add content
composable("ask_password") {
composable("register") {
階層拡張メソッド （英語）を使って宛先が実際にログイングラフの一部であるかどうかを判断する方法に注目してください。このようにすると、ログイングラフ への 遷移とログイングラフ からの 遷移に、デフォルトの遷移（または上位レベルで設定した遷移）を使うことができます。
水平スライドのような方向性のある遷移では、この仕組みのおかげで、enterTransition と popEnterTransition との違いが非常に役立ちます。ある画面は右にスライドし、他の画面は左にスライドするような事態を避けることができます。
Accompanist は Jetpack ライブラリのブースター ロケットとしてはたらき、Compose 1.1 の開発が進行中でも、試験運用版機能をすぐに 利用できるようにします。
Accompanist Navigation Animation は、次のようにして追加します。
implementation "com.google.accompanist:accompanist-navigation-animation:0.16.1"
implementation
"com.google.accompanist:accompanist-navigation-animation:0.16.1"
Compose 1.0.1 をベースとした Navigation 2.4 と、試験運用版 API によって Compose 1.0 の限界を押し広げる Accompanist Navigation Animation の先には、別の景色、すなわち Compose 1.1 が見えています。Compose ロードマップ （英語）を見てみると、実に重要な 1 つの機能が予定されています。
共通要素遷移のサポート
Navigation 2.5 で目指しているのは、Compose 1.1 のすべての利点を Navigation Compose に導入することです。つまり、アニメーション API が試験運用版でなくなれば、直接 Navigation Compose に組み込めるようになります。さらに、共通要素遷移が利用できるようになり、それをサポートする API も構築できます。
さらに言えば、Accompanist Navigation Animation は一時的な対応と考えるべきです。Navigation Compose 自体が同じレベルのアニメーション API を提供すれば（皆さんのフィードバックに合わせて調整します）、直接それを使うことができ、Accompanist Navigation Animation は完全に削除できます。
短時間で機能を提供できる Jetpack ライブラリとして、安定性と、私たちが自らに課している上位互換性要件、下位互換性要件のバランスを取るのは、思うほど簡単なことではありません。Jetpack Compose は、Accompanist という大きな助けを借りて勢いを増し、このブースター ロケットが必要なくなるところまで加速していきます。Accompanist に時間を費やしてくれた Chris Banes （英語）を始めとするすべてのデベロッパー、Compose を支えるすべてのチーム、そして Android 開発の未来を形作ることに貢献してくださっているすべての皆さんに感謝します。
追伸: Navigation + Accompanist のメリットをさらに知りたい方は、新しい Accompanist Navigation Material （英語）をチェックしてみてください！
Navigation-Material の紹介 🧭🎨️ （英語）
この記事は Suzanne Frey による Android Developers Blog の記事 " Preparing for Google Play’s new safety section " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
本日は、Google Play に追加されるセーフティ セクションについて、詳しい情報をお伝えします。Google では、ユーザーがオンラインで安全に過ごせるようにするために、デフォルトで安全で、プライバシーを考慮した設計となっており、ユーザーがデータをコントロールできるプロダクトを提供することが必要だと考えています。今回新たに追加されるセーフティ セクションは、デベロッパーにアプリの全体的な安全性を簡単に明示できる方法を提供します。また、ユーザーがアプリをインストールする前に、プライバシーやセキュリティの慣習に関する詳しい情報を提示したり、アプリが収集するデータやその理由を説明したりできます。
セーフティ セクションの情報は、Google Play ストアのすべてのアプリで必須になります。デベロッパーの皆さんがこの措置に対して準備をする十分な期間を設けるため、この新機能のデータの種類の定義、ユーザージャーニー、ポリシー要件について詳しくお伝えします。
これらの画像は方向性を示すものであり、変更される場合があります。
ユーザーには、アプリのストア掲載情報ページに、新しいサマリー欄が表示されます。そこには、アプリが収集または共有するデータについてのデベロッパーによる説明のほか、安全性に関連する以下のような情報が表示されます。
サマリーをタップすると、以下のような詳細情報が表示されます。
これらの機能をデザインするうえで、デベロッパーの皆さんがデータを扱う状況や、アプリがデータを自動収集するのか収集は任意なのかについて、より詳しくユーザーに伝えたいと考えておられることが、わかりました。また、ユーザーは収集されるデータが他社と共有されているかどうかや、その理由について理解したいと思っていることも、わかりました。
Google は、デベロッパーの皆さんと連携し、デベロッパーとユーザーの双方にとって最適な体験を設計できるように努めていますので、今後、最終的なデザインは変更される可能性があります。
本日、新しいユーザーデータ ポリシーについて発表しました。このポリシーは、ユーザーの透明性を向上させ、データがどのように収集、保護、利用されるかについて、十分な情報に基づいてユーザーが選択できるようにすることを念頭に置いて設計されました。
これは、Google 製アプリも含め、Google Play で公開されているすべてのアプリに適用されます。
デベロッパーの皆さんが準備をするにあたり、十分な時間とリソースを提供したいと考えています。
スケジュール(日付は変更される可能性があります)
2021 年 10 月より、デベロッパーは Google Play Console 上で情報の申告を行い、審査を受けることができます。本件に関して、デベロッパーの皆さんが作業を行っている途中で質問が生じる可能性もありますので、お早めに準備を開始されることをお勧めします。そして、2022 年初頭に、すべてのユーザーが Google Play で新しいセーフティ セクションを利用できるようになります。
この準備に向けて、アプリの確認を行ったり、複数のチームと調整を行う関係で、さらに準備に時間が必要になるデベロッパーもいらっしゃると思います。そこで、新規・既存のアプリのこのセクションの掲載情報の承認を得る期限を 2022 年 4 月とします。セクションが承認されていない場合、新しいアプリの送信やアプリのアップデートは不承認となる可能性があります。
2022 年初頭に、Google Play のセーフティ セクションがユーザーに公開される時点で、アプリの情報が承認されていない場合、掲載情報がない旨が表示されます。
今後数か月間で、具体的な日付などのガイダンスを提供する予定です。この機能をともに構築し、Google Play が誰にとっても安全で、信頼できるアプリとゲームの提供元であり続けるため、ご協力いただきますよう、お願いします。
Reviewed by Konosuke Ogura - Trust & Safety - Play & Android, Global Content Operations Lead, Naoki Oyama - Developer Support Lead, Google Play, APAC and Tamao Imura - Developer Marketing Manager, Google Play
この記事は Amanda Alexander による Android Developers Blog の記事 " Android Studio Arctic Fox (2020.3.1) Stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio Arctic Fox が、安定版リリース チャンネルでダウンロードできるようになったことをお知らせします。この最新リリースでは、Android の新しいネイティブ UI 構築ツールキットである Jetpack Compose 1.0 を利用できます。さらに、Wear OS を含むデバイスにも注力し、新しい Background Task Manager などのデベロッパーの生産性を高める機能も搭載されています。皆さんのフィードバックをもとに開発されたこの新しい Android Studio 機能のスイートは、デベロッパー コミュニティがさまざまなデバイスで動作する質の高い最先端のアプリを迅速に作るために役立つことができれば幸いです。
注 : 昨年発表した通り、Android Studio のバージョン番号体系を Android Studio のベースになっている IntelliJ IDEA の年とバージョンに一致させ、そこに独自のパッチ番号を付加するように変更しました。今後はコードネーム（アルファベット順）を利用します。最初は Arctic Fox で、次は Bumblebee（現在カナリー版）です。Android Studio Arctic Fox（2020.3.1）では、Android Studio が IntelliJ プラットフォームのバージョン 2020.3 にアップデートされます。これには、デバッガ インタラクティブ ヒント、VCS のアップデート、いくつかの新しいコードエディタの強化など、ワークフローを高速化するたくさんの新機能が含まれています。詳細はこちらをご覧ください。（英語）
最新 UI をすばやくデザインできるように、Jetpack Compose 用の追加機能も搭載しています。Compose プレビューを使うと、Compose UI の複数のコンポーネントのプレビューを作成し、さまざまな要素（テーマ、画面、フォントサイズなど）にわたって変更の影響を即座に確認できます。デバイスへのデプロイ プレビュー機能では、Compose コードのスニペットを直接デバイスやエミュレータにデプロイし、小さなコードをすばやくテストできます。レイアウトを詳しく調べたい場合は、Layout Inspector に追加された Compose サポートを使って、レイアウトがどのようにレンダリングされるかを理解できます。さらに、リテラルのリアルタイム編集を追加しました。エミュレータや実機でアプリを動作させるときに、コンパイルを行うことなく、プレビューで Compose コードの変更を即座に確認できます。
サポート対象のデバイスを増やすため、新しい Wear OS ペア設定アシスタントを構築し、Wear OS エミュレータと物理スマートフォン、仮想スマートフォンとのペア設定を簡単に行えるようにしました。Wear OS の最新バージョンを使うには、Wear OS 3 システム イメージのデベロッパー プレビューをご利用ください。Wear OS エミュレータを実行すれば、心拍数センサー API のサポートが追加されていることにも気づくはずです。Google TV をターゲットにするアプリのために、最新の Google TV リモート コントロール機能を追加し、Google TV システム イメージをアップデートして最新の UI デザインを反映しました。さらに、Automotive OS で、運転に関するユースケースをシミュレーションするため、エミュレータで自動車センサーデータを利用できるようにして開発とテストのワークフローを完成させました。タブレットをターゲットにするアプリのために、すぐに横向きをサポートできるようにすべてのテンプレートを更新しました。開発のターゲットとなるデバイス画面の大小にかかわらず、新たな方法の導入とアプリの構築を継続するうえで役立つ新機能が含まれています。
最後に、デベロッパーの皆さんの生産性を向上させるために、作業の効率化に役立つ機能の追加についてご紹介します。たとえば、次期バージョンの Android アプリを構築する際のガイドとして、Android 12 向けの lint チェックを追加しました。コードのテストに役立ててもらうため、Layout Editor に Accessibility Scanner を追加し、レイアウトのユーザー補助に関する問題を簡単に見つけられるようにしました。また、新しいテスト マトリックスを使うと、複数のデバイスで並列実行されるテスト結果をリアルタイムに確認できます。さらに、Apple Silicon（arm64）ハードウェアのプレビュー サポートを追加し、幅広いテストをサポートできるようにエミュレータのコントロールを拡張しました。加えて、デバッグ用の新しい Background Task Inspector を使うと、アプリのバックグラウンド ワーカーを分析できます。
Android Studio Arctic Fox には、たくさんの機能強化が含まれています。すべての変更点のリストを確認したい方は、Android Studio Arctic Fox（2020.3.1）Beta リリースブログとリリースノートをご覧ください。以下では、主な変更点について紹介します。
Android Studio Arctic Fox の新機能
@Preview アノテーションを使うと、Compose コードのプレビューを生成して複数のコンポーネント（デバイス、テーマなど）をさまざまな構成で表示できます。Compose プレビューを活用すれば、コードで Composable のメンタル マッピングを簡単に作成できます。
Compose プレビュー
すべて Compose で書かれたアプリでも、Compose とビューを併用したアプリでも、Layout Inspector を使えばレイアウトの詳細を確認したり、トラブルシューティングを行ったりできます。たとえば、各 Composable に渡されたパラメータや修飾子を確認できます。アプリを開発する際に、ライブ アップデートを有効にしてデバイスからデータをストリーミングすることもできます。
Compose Layout Inspector
リテラル（文字列、数値、ブール値など）をインラインで編集すると、コンパイルしなおすことなく、変更の結果を画面（プレビュー、エミュレータ、実機）ですぐに確認できます。
リテラルのライブ編集 : 文字列を編集するとプレビューに即時反映
新しい Wear OS ペア設定アシスタントは、順を追ってペア設定プロセスを案内してくれるので、Wear OS エミュレータと仮想または物理スマートフォンのペア設定が簡単になります。なお、この機能は、Wear OS 2 コンパニオンとのペア設定をサポートします。Wear OS 3 は近日中にサポートされる予定です。詳細はこちらをご覧ください。
Wear OS エミュレータ ペア設定アシスタント ダイアログ
スマートフォン + スマートウォッチ エミュレータのペア設定が成功した状態
API レベル 26 以上を実行しているデバイスで WorkManager ライブラリ 2.5.0 以上を使っている場合、新しい Background Task Inspector を使ってアプリのバックグラウンド ワーカーを視覚化、監視、デバッグできます。メニューバーから [View] > [Tool Windows] > [App Inspection] を選択してアクセスできます。詳細はこちらをご覧ください。
Background Task Inspector
まとめると、Android Studio Arctic Fox（2020.3.1）安定版には、以下の機能強化と新機能が含まれています。
詳細は、Android Studio のリリースノート、Android Gradle プラグインのリリースノート、Android Emulator のリリースノートをご覧ください。
最新バージョンの Android Studio Arctic Fox はダウンロード ページ（英語）から、Apple Silicon プレビュー ビルドはこちら（英語）からダウンロードできます。Android Studio の以前のリリースをお使いの方は、最新バージョンの Android Studio にアップデートするだけで利用できます。Android Studio の安定バージョンを保持する必要がある場合、Android Studio Arctic Fox の安定リリース バージョンとカナリー リリース バージョンを同時に実行することができます。詳細はこちらをご覧ください。
気に入った点、問題点、新機能の提案などのフィードバックをお寄せください。バグや問題が見つかった場合は、バグを報告してください。Android Studio 開発チームの Twitter と Medium もぜひフォローしてください。
この記事は Anna-Chiara Bellini, Nick Butcher による Android Developers Blog の記事 " Jetpack Compose is now 1.0: announcing Android’s modern toolkit for building native UI " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 7 月 28 日（日本時間 7 月 29 日) Jetpack Compose のバージョン 1.0 をリリースしました。Android の最新ネイティブ UI ツールキットである Jetpack Compose を使うと、優れたアプリを短時間で構築できます。このリリースは安定版で、本番環境で利用できます。Compose は、この 2 年間、Android コミュニティのフィードバックや貢献を受けつつ、オープンに開発が行われてきました。1.0 に到達した現時点で、既に Google Play ストアの 2000 以上のアプリで Compose が使われています。実は、Play ストアアプリ自体にも Compose が使われています。それだけではありません。たくさんのトップ アプリ デベロッパーと協力し、フィードバックやサポートを受けることで、1.0 リリースはさらに強固なものになっています。たとえば、Square は Compose を使うことで「宣言型 UI フレームワークの構築に関するさまざまな問題を解決することではなく、Square 独自の部分や UI インフラストラクチャに集中できる」と教えてくれました。Monzo は、Compose を使うと「質の高い画面を短時間で構築できる」と述べています。また、Twitter は「とても気に入っています！❤️」と見事に一言で言い表しています。
Compose は、ネイティブ Android アプリを短時間で簡単に作成できるように設計されています。完全に宣言的なアプローチが採用されているので、UI を記述しさえすれば、あとは Compose が対応してくれます。アプリの状態が変わると、UI が自動的に更新されるので、UI の構築がはるかにシンプルかつ高速になります。直感的な Kotlin API を使うと、美しいアプリを はるかに 少ないコードで実現できます。また、すべての既存の Android コードにネイティブでアクセスできるので、自分のペースで導入することもできます。強力なレイアウト API とコード駆動型 UI により、タブレットや折りたたみ式デバイスなど、異なるフォーム ファクタのサポートも簡単です。Compose のサポートは、Wear OS や ホーム画面 ウィジェットなども追加される予定です。
今回の 1.0 リリースは本番環境で利用でき、以下の主要機能が提供されています。
完全な宣言型アプローチを採用している Jetpack Compose によって、UI の開発方法は大きく変わります。新しいワークフローと異なる考え方をサポートするため、Compose 向けに設計された新しいツールを提供します。また、いくつかの既存のツールに Compose のサポートを追加しています。
Android Studio Arctic Fox で利用できる新しい Compose プレビューでは、異なる状態、ライトテーマやダークテーマ、異なるフォント スケーリングのコンポーザブルをすべて同時に確認できます。アプリ全体をデバイスにデプロイする必要はないので、コンポーネントの開発が簡単になります。リテラルのライブ編集機能によって機能強化されているため、プロジェクトを再コンパイルせずにアップデートを確認できます。
作業中の画面まで移動せずにデバイスで UI のパーツをテストしたいと思っていた方なら、新しいデプロイ プレビューを気に入ってくれるはずです。Composable のプレビューを作成するだけで、デバイスにデプロイしてすばやく反復できます。
Layout Inspector に Composable サポートが追加されるため、Compose と既存のビューを確実に混在させることができます。
Android Studio Arctic Fox での Compose サポートの詳細については、こちらをご覧ください。
新しいフレームワークを採用するには、評価が必要です。新しい UI ツールキットのように広範囲にわたるものでは、特にそれが重要になります。皆さんにとって今が適切なタイミングかどうかを情報に基づいて判断できるように、パブリック ロードマップ (英語) を公開して今後の Jetpack Compose の開発計画をお知らせします。
Compose を活用していただくために、皆さんや皆さんのチームが利用できる幅広いリソースを準備しました。
学ぶべきことはたくさんあります。Jetpack Compose Pathway (英語) では、主要な コードラボ、動画、ドキュメントを順番に体験できます。
Jetpack Compose は大きな飛躍であり、すばらしい UI を短時間で簡単に作れるものだと確信しています。これを使って皆さんが作るものを見ることが楽しみでなりません。Compose が 1.0 の安定版になった今こそ、実際に使うべきときです。直接コードを触るのが最善の方法です。ぜひ Compose を使ってみてください！
この記事は Dave Burke による Android Developers Blog の記事 " Android 12 Beta 3 and final APIs " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは、毎月 Android 12 の公式版リリースに近づけるための Beta 提供をを行っています。Android 12 には、革新的な機能や、ユーザーに適応する (英語) 新しい UI、パフォーマンスの向上、プライバシーの強化、セキュリティ上のメリットなどが含まれています。多くの皆さんが、Android 12 Beta プログラムを通じて既に Android 12 の開発やテストを行っています。これまでフィードバックを提供してくださった皆さん、どうもありがとうございました。
引き続き公式版のリリースを微調整する作業を継続していますが、先日 2021 年 7 月 14 日 (現地時間）にAndroid 12 Beta 3 をリリースしました。ぜひお試しください。Beta 3 には、スクロール スクリーンショット、プライバシー インジケーター API、自動回転の強化などのアップデートとともに、確定版の Android 12 API と公式 SDK も含まれています。以上の機能をもって、次回の Beta 4 での Platform Stability を待たずに、アプリのテストとアップデートを開始することができます。ぜひご自身のアプリやゲームのご準備をお願いいたします。
Beta 3 は、既に対象となる Pixel デバイスで利用でき、こちらから登録 (英語) すると OTA (無線) アップデートも行えます。Beta プログラムに登録済みの方は、自動的にアップデートを受け取ります。パートナーのデバイスメーカーである、シャープや TCL などの、一部のデバイスでも Android 12 Beta 3 を試すことができます。詳しくは android.com/beta をご覧ください。使用を開始する方法について詳しくは、Android 12 デベロッパー サイトにアクセスしてください。
Beta 3 には、機能、ユーザー エクスペリエンス、パフォーマンスを改善する様々なアップデートが含まれています。ここでは、いくつかのポイントを紹介します。
スクロール スクリーンショット - スクロールするコンテンツを簡単にキャプチャして共有できるように、スクロール スクリーンショットを追加します。Beta 3 以降では、スクロール可能なコンテンツのスクリーンショットをキャプチャする場合、[Capture more] ボタンが表示され、それを押すことでスクリーンショットを全コンテンツに拡張できます。その後、切り取る範囲を調整することもできます。
設定アプリでのスクロール スクリーンショットのキャプチャ例
スクロール スクリーンショットは、ほとんどのアプリでそのまま動作します。標準のビューベースの UI を使っているアプリでは、何の変更も必要ありません。ビューベースの UI を使わないアプリや UI ツールキット、または高度にカスタマイズされた UI でスクロール スクリーンショットをサポートするために、新しい ScrollCapture API (英語) を導入しています。この API を使うと、システムはアプリにスクロール キャプチャ リクエストを通知するとともに、UI を描画する Surface を提供します。スクロール スクリーンショットに関する反復作業はまだ続いています。Beta 4 では、スクロールする ListView など、デフォルトのサポートが改善される予定です。また、Web コンテンツなどサポート対象のコンテンツを増やすための作業も行っています。引き続き、皆さんのフィードバックをお待ちしています。
オンデバイス検索 - Beta 3 では、新しい高パフォーマンス オンデバイス検索エンジンである AppSearch がプラットフォームでサポートされます。AppSearch (英語) を使うと、アプリが構造化データをインデックスに登録したり、組み込みの全文検索機能を使って検索したりできます。非常に効率的なインデックスの登録や検索、多言語サポート、関連度ランキングなどのネイティブ機能を使うこともできます。
AppSearch には、ローカル インデックスとセントラル インデックスという 2 つの仕組みを搭載しています。ローカル インデックスはアプリで利用でき、新しい AppSearch Jetpack ライブラリを通して下位互換性も提供されます。セントラル インデックスは、Android 12（およびそれ以降のリリース）のシステム全体で維持されます。セントラル インデックスを利用すると、オプトアウトしない限り、システム UI の表層にアプリのデータが表示されます。さらに、他のアプリと安全にデータを共有し、自分のアプリのデータだけでなく他のアプリのデータも検索できるようになります。詳しくはこちらをご覧ください。（英語）
WindowInsets のプライバシー インジケーター API - Beta 2 では、アプリがデバイスのカメラまたはマイクを使っているときに、ステータスバーにプライバシー インジケーターが表示されるようになりました。アプリが没入モードのときにインジケーターが表示されると、コントロールやコンテンツが隠れてしまう可能性があるので、アプリはインジケーターを描画できる場所を把握し、有用なコンテンツが隠れないように必要な調整を行う必要があります。Beta 3 では、WindowInsets (英語) に新しくプライバシー インジケーター API (英語) を追加します。これを使うと、インジケーターの最大領域と画面上での相対的位置を取得できます。現在の画面の向きや言語設定も考慮されます。詳しくはこちらをご覧ください。
カメラとマイクの切り替えの企業設定 - Beta 2 では、新しい切り替え機能も導入し、すべてのアプリでユーザーが即座にデバイスのマイクやカメラをオフにできるようにしました。フルマネージド デバイスに必要な制限を設定できる企業の管理者は、この機能にアクセスできるようになります。詳しくはこちらをご覧ください。(英語)
CDM でペア設定され、フォアグラウンド サービスを開始するアプリの新しいパーミッション - システムの透過性を提供しつつ、コア機能を担うコンパニオン アプリのサポートを向上させるため、Companion Device Manager（CDM）とペア設定されたアプリは、新しい通常のパーミッションを宣言することで、バックグラウンドからフォアグラウンド サービスを起動できます。詳しくはこちらをご覧ください。(英語)
自動回転の向上と高速化 - 画面を回転させるタイミングを正確に認識できるように、前面カメラによる顔検出を使って Android の自動回転機能を強化しました。この機能は、ソファやベッドで横になりながらデバイスを使う場合などに特に便利です。デベロッパーにとっては、ユーザーが設定でオプトインした場合、自動回転の動作のユーザー エクスペリエンスが向上することになります。この自動回転機能の強化は、最近発表された Private Compute Core (英語) の機能です。そのため、画像が保存されたり、デバイス外に送信されたりすることはありません。Beta 3 では、この機能は Pixel 4 以降の Pixel デバイスで利用できます。
すべてのデバイスで画面の回転をできる限り高速化するため、アニメーションと再描画を最適化し、ML を利用したジェスチャー検知アルゴリズムを追加しました。その結果、ベースとなる自動回転機能の遅延が 25% 減少しました。顔検出による機能強化は、これらの改善が土台となっています。ぜひ改善された自動回転機能をお試しいただき、感想をお聞かせください。
ゲームに向けた Android 12 - Game Mode API (英語) を使うと、プレーヤーがゲームのパフォーマンス プロファイル（長時間通勤用に電池寿命を延ばす、パフォーマンス モードで最高のフレームレートを実現するなど）を選択する操作に応答できます。この API は、近日中に公開されるゲーム ダッシュボードと連携します。ダッシュボードでは、ゲームプレイ中に重要なユーティリティにすばやくアクセスできるオーバーレイ エクスペリエンスが提供されます。ゲーム ダッシュボードは、一部のデバイスで今年中に利用できるようになる予定です。
Android 12 での Touchgrind BMX の Play as you download
それまでの間は、インストール時にバックグラウンドでゲームアセットをフェッチできるようにする Play as you download (英語) を使って、プレーヤーをすばやくゲームプレイに導くことができます。
Android 12 のすべての新機能について知りたい方は、Android 12 デベロッパー Web サイトをご覧ください。
この数週間、Android 12 API を確定する作業を行ってきました。そして Beta 3 で、公式の API レベル 31 SDK と併せて確定版 API をリリースします。Beta 4 では完全な プラットフォームの安定版に到達する予定です。この段階では、API サーフェスに加えて、アプリ向けのすべてのシステム動作と非 SDK インターフェースの制限も確定します。
Android 12 API でアプリをコンパイルする場合は、今回のリリースを使って環境をアップデートし、確定版の SDK と最新ツールでアプリを再コンパイルすることをお勧めします。
Pixel などの対応デバイスで Android 12 Beta を利用するアーリー アダプターやデベロッパーが増えてきた今が、アプリを Android 12 Beta 3 に対応する絶好のタイミングです。
Beta 3 でアプリの互換性テストを行うには、Android 12 Beta を実行しているデバイスかエミュレータに、Google Play や他のソースで公開されているバージョンをインストールします。そしてアプリのすべてのフローを試し、機能や UI の問題を探します。変更によってアプリが影響を受ける領域を集中的にテストするため、動作の変更点を確認してください。この段階では、アプリの targetSdkVersion を変更する必要はありません。問題が解決できたら、Android 12 Beta のユーザー向けにできる限り早くアップデートを公開することをお勧めします。
前述のとおり、Android 12 は次のリリースとなる Beta 4 で Platform Stability に到達します。Platform Stability では、アプリに面するすべての動作、SDK/NDK API、非 SDK 制限が確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリのリリースをしてください。デベロッパー向けの Android 12 のタイムラインの詳細は、こちらをご覧ください。
今回の Andorid 12 Beta 3 リリースには、Android 12 の最新機能を試し、アプリの動作をテストしてフィードバックを提供するために必要なすべてのものが含まれています。サポート対象となっている Pixel デバイスを登録するだけで、OTA（無線）でアップデートを入手できます。また、Android 12 に対応したアプリの開発を行うために、Android 12 SDK をセットアップしてください。
Android 12 Beta 3 は、シャープや TCL などの一部の主要メーカー パートナーのデバイスでも利用できます。Android 12 Beta に対応しているデバイス パートナーの全リストは、android.com/beta に掲載されています。さらに幅広くテストしたい場合は、Android GSI イメージで Android 12 Beta をお試しください。デバイスをお持ちでない場合は、Android Emulator でテストできます。
Beta 3 は Android TV でも利用できるので、ADT-3 デベロッパーキットを使って、新しくなった Google TV エクスペリエンスで最新の TV 機能を確認したり、アプリをテストしたりできます。詳しくはこちらをご覧ください。(英語)
Android 12 Beta の詳細については、Android 12 デベロッパー Web サイトをご覧ください。
9 月 4 日（土）開催の Google Play Indie Games Festival 2021 ファイナルイベントにて、イベントを盛り上げる MC に、よしもとクリエイティブ・エージェンシーのカジサックさん、キクチウソツカナイ。さんのお二人が決定しました。
カジサック
お笑い芸人キングコング梶原雄太が、「カジサック」として 2018 年 10 月 1 日 YouTube クリエイターデビュー。 カジサックの部屋に様々なジャンルのゲストの方を招きながら、バラエティに富んだ動画を配信している。 登録者はまもなく 200 万人を超える人気 YouTube クリエイター！
キクチウソツカナイ。
本格派 MC 芸人としてお馴染みの「キクチウソツカナイ。」
様々なイベントや番組を持ち前のトーク力で盛り上げる MC 芸人として活躍中！
また、ファイナルイベントの UUUM 賞審査員は、こちらからご確認ください。
9 月 4 日、Google Play Indie Games Festival 2021 ファイナルイベントをオンラインにて開催いたします。
応募作品から選出されたトップ 20 作品のゲームをご紹介した後に、トップ 10、トップ 3 が選出されます。新設された学生部門賞の発表も、こちらのイベントにて行います。ゲーム好きな方が楽しんでいただけるコンテンツも多数ご用意しておりますので、お誘い合わせの上ご参加（ご視聴）ください。
ファイナルイベント開催概要
日時 : 9 月 4 日（土） 15:00 - 17:30 オンラインにて開催！ *
午前中は Adventure に参加しましょう！
Adventure は、オンライン上でファイナリストのゲームを体験したり、ファイナリストと直接会話ができるプラットフォームです。詳細は後日発表します。
最新情報の確認、参加（視聴）のための登録は Web サイトから。
* 開催時刻は予告なく変更になる場合がございます。
