この記事は Jonathan Koren による Android Developers - Medium の記事 " Trackr comes to the Big Screen " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Trackr は、タスク管理のサンプルアプリです。Trackr の主な用途は、ユーザー補助をサポートする観点で一般的な UI パターンを確認できるようにすることですが、最先端の Android 開発におけるベスト プラクティスの実例にもなっています。先日、このアプリを大画面対応にしました。その際にマテリアル デザインやレスポンシブ パターンを適用することで、大画面デバイスで洗練された直感的なユーザー エクスペリエンスをどのように実現したのかをご紹介します。
変更前 : タスク一覧画面の下部にあるアプリバーのメニューから、アーカイブと設定にアクセスできました。大画面では、タッチのターゲットとなるメニュー コントロールが小さく、不便な場所にありました。また、下のアプリバーが伸びすぎていました。
左: スマートフォンのナビゲーション。右: タブレットのナビゲーション
変更後 : 画面が広い場合は、ナビゲーション レール (英語) を表示します。さらに、ナビゲーション レールにフローティング アクション ボタン（新規タスク画面を開きます）を表示し、下のアプリバーは完全になくしました。
大画面のナビゲーション レール
この変更は大画面デバイスを念頭に行いましたが、スマートフォンの横表示でも有効で、タスク一覧を表示する縦のスペースを広く使えるようになります。
横向きのスマートフォンのナビゲーション レール
変更前 : タスク一覧画面とアーカイブ画面が横幅いっぱいに広がり、項目をタップすると、一覧が項目の詳細に置き換わっていました。大画面では、UI 要素が引き伸ばされるか、片側に寄ってしまい、画面のバランスが悪く感じられました。
スマートフォンでは自然に見えるが、大画面では最適な形でスペースを利用できていない
変更後 : タスク一覧画面とアーカイブ画面の両方で、SlidingPaneLayout (英語) を使って一覧/詳細 UI を表示します。これを行う方法は、Google I/O アプリに対して行った変更に関する以前の記事 (英語) で解説していますので、技術的な詳しい説明に興味がある方は、ぜひご覧ください。
タスク詳細画面にもフローティング アクション ボタン（タスク編集画面を開きます）がありますが、ナビゲーション レールがある場合に 2 つのフローティング アクション ボタンが表示されることになるので、理想的ではありません。そこで、2 つ目のフローティング アクション ボタンは非表示にし、右上のツールバーに編集ボタンを追加します。
2 ペイン化で画面スペースを活用
変更前 : タスクを編集すると、タスク編集 UI がタスク詳細の代わりに表示され、画面全体を覆っていました。タスク詳細と同じく、画面のバランスが悪く感じられます。新規タスク UI でも同じ問題が発生していました（実は、新規タスクとタスク編集は、ナビゲーション グラフで同じ遷移先になっています）。
左: スマートフォンのタスク編集。右: タブレットのタスク編集
変更後 : 大画面では、DialogFragment を使って他のコンテンツの上にタスク編集 UI を表示します。
ユーザーが現在の目的に集中できるようにするフローティング UI
最初は、タスク詳細の代わりにこの UI を詳細ペインに表示することを考えました。その方が単純でしたが、次の理由により、このアプローチでは納得できないとすぐに感じました。
新規タスク UI は、タスク編集と同じパターンを利用
ここでの学びは、何も考えずにシンプルにデザインしてしまうと、実装してみると機能的におかしい可能性があるということです。そうなったときは、一歩下がってユーザー エクスペリエンスに注目し、ユーザー エクスペリエンスを向上させるデザイン パターンを探しましょう。
タブレットや折りたたみ式デバイスの人気は上昇しています。そのため、レスポンシブな UI を作ることの重要性がこれまでになく高まっています。ナビゲーション レールを追加したり、SlidingPaneLayout を使ったりすると、Trackr アプリの見栄えがよくなるだけでなく、ユーザビリティが劇的に向上し、スマートフォンにはないエクスペリエンスを実現できることをお見せしました。さらに、単に画面のスペースだけではなく、ユーザビリティに注目し、ユーザーのニーズを最大限に満たすことができるようなデザインの再考が必要になる場合があることもお伝えしました。
新たに改善された Trackr が気に入ってもらえることを期待しています。コードは github.com/android/trackr から確認できます。
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
この記事は Dave Burke による Android Developers Blog の記事 " Android 12 Beta 5 update, official release is next! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
まもなく Android 12 が公式リリースを迎えます。現在、新バージョンの Android で最終調整を行っているところですが、皆さんのテストや開発に役立てていただくため、ベータ版の最終アップデートをお届けします。公式リリースに間に合うように、互換性のあるアプリやゲームへのアップデート準備をお願いいたします。
Beta 5 は 2021 年 9 月 8 日（日本時間 9 月 9 日) より、5G 対応の Pixel 5a を含む Pixel デバイスで利用できます。こちらから登録 (英語) すると、OTA（無線）アップデートを受け取ることができます。以前登録している方は、自動的に今回のアップデートを受け取ります。シャープなど、いくつかの主要メーカーの一部のデバイスでも Android 12 Beta 5 を試すことができます。使用を開始する方法についての詳細は、Android 12 デベロッパー サイトにアクセスしてください。
以下では、リリースが近づいてきた Android 12 公式版に関する情報をお伝えします。
2021 年 9 月 8 日（日本時間 9 月 9 日) のアップデートには、Pixel などのデバイスと Android Emulator 向けの Android 12 のリリース候補ビルドが含まれています。Beta 4 でプラットフォームの安定版に到達しているので、SDK や NDK API、アプリに面するシステムの動作、非 SDK インターフェースの制限など、アプリに面する部分はすべて完了しています。Beta 5 には、これらの機能と最新の修正および最適化が含まれており、テストを終えるために必要なものがすべてそろっています。
次に予定されているのは、Android 12 の公式リリースです。そのため、すべてのアプリやゲームのデベロッパーの皆さんに、最終リリース前に最終の互換性テストを終え、互換性アップデートを公開することをお願いします。SDK、ライブラリ、ツール、ゲームエンジン デベロッパーの皆さんは、できる限り早く互換性アップデートをリリースすることが重要です。下流のアプリやゲームのデベロッパーは、皆さんのアップデートを受け取るまで作業できないかもしれません。
アプリの互換性をテストするには、Android 12 Beta 5 が動作するデバイスにインストールし、アプリのフローを確認して機能や UI の問題を探します。Android 12 でのすべてのアプリが対象となる動作の変更点を確認し、影響を受ける可能性がある領域を集中的にテストしてください。特にテストしておくべき変更点は、以下のとおりです。
アプリのライブラリや SDK の互換性テストも忘れずに行ってください。SDK の問題を見つけた場合は、最新バージョンの SDK にアップデートするか、デベロッパーに連絡してサポートを受けるようお願いします。
現在のアプリの互換性のあるバージョンを公開したら、アプリの targetSdkVersion をアップデートするプロセスを開始できます。Android 12 をターゲットとするアプリの動作の変更点を確認し、互換性フレームワークを使って問題をすばやく検知します。
Android 12 には、優れたユーザー エクスペリエンスを構築する際に役立つたくさんの新機能が含まれています。Google I/O での Android 12 関連のセッションに関するまとめとリンクについては、Android 12 Beta 2 の投稿をご覧ください。すべての新しい機能と API の詳しい説明は、Android 12 デベロッパー サイトをご覧ください。
Android 12 の開発やテストには、ぜひ Android Studio Arctic Fox もお試しください。Android 12 の変更点によって影響を受ける可能性があるコードを特定しやすいように、lint チェックも追加しています。たとえば、スプラッシュ画面のカスタム宣言、高精度の位置情報の使用がリクエストされた際の大まかな位置情報の権限、メディア フォーマット、高センサー サンプリング レートの権限などです。ダウンロード (英語) と設定を行うと、最新版の Android Studio を試すことができます。
今回の Beta 5 のリリースには、Android 12 の機能を試し、アプリをテストしてフィードバックを提供するために必要なすべてのものが含まれています。サポート対象となっている Pixel デバイスを登録するだけで、OTA（無線）でアップデートを入手できます。また、Android 12 に対応したアプリの開発を行うために、Android 12 SDK をセットアップしてください。
シャープなど、いくつかの主要メーカーのデバイスでも、Beta 5 を試すことができます。さらに幅広くテストしたい場合は、Android GSI イメージで Beta 5 をお試しください。デバイスをお持ちでない場合は、Android Emulator でテストできます。今回のアップデートは Android TV でも利用できる (英語) ので、最新の TV 機能を確認したり、新しくなった Google TV エクスペリエンスでアプリをテストしたりできます。
もうすぐ予定されているAndroid 12 公式版リリースにご期待ください！それまでの間は、引き続きフィードバックをお寄せください。プラットフォームの問題、アプリの互換性の問題、サードパーティ SDK の問題の送信には、各ホットリストを使うことができます。
Android 12 リリースを形作ることに貢献してくださっているデベロッパー コミュニティの皆さんに深い感謝を捧げます。皆さんから寄せられたたくさんのバグレポートや、皆さんが共有してくれた知見は、API の調整や機能の改善、重大なバグの修正、そしてユーザーやデベロッパーにとってよりよいプラットフォームの実現に役立っています。ありがとうございます。
Android 12 に対応した皆さんのアプリを楽しみにしています。
この記事は Ting-Yuan Huang による Android Developers Blog の記事 " Accelerated Kotlin build times with Kotlin Symbol Processing 1.0 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Kotlin で軽量コンパイラ プラグインを作成する新ツール、Kotlin Symbol Processing（KSP）が安定版になりました。KSP は、Kotlin Annotation Processing Tool（KAPT）(英語) と同様の機能を提供しますが、最大 2 倍高速であるうえ、Kotlin 言語の構造に直接アクセスでき、マルチプラットフォーム ターゲットもサポートしています。
ここ数か月間で、KSP は 32 回のリリースを経て、コミュニティから報告された 162 以上のバグを修正しました。導入を見合わせていた方も、ぜひこのタイミングでご確認ください。
Android チームは、いつもデベロッパーの皆さんに「アプリを書くときに一番困っていることは何か」と問いかけています。特によく上がってくる問題が、ビルド速度です。Android のビルド ツールチェーンには長年にわたって着実に改良を重ねてきましたが、今回はその改善に KSP を加えています。KSP は、次世代の Kotlin アノテーション処理を行い、Kotlin デベロッパーのためにビルド速度を劇的に向上させます。また、KAPT とは違い、Kotlin/Native と Kotlin/JS のサポートを提供します。
Kotlin Annotation Processing Tool（KAPT）(英語) は、Java のアノテーション処理インフラストラクチャと連携し、Kotlin でほとんどの Java 言語アノテーション プロセッサがそのまま動作するようにしています。これを行うために、KAPT は Kotlin コードをコンパイルし、Java アノテーション プロセッサに必要な情報を保持した Java スタブに変換しています。しかし、このスタブを作成する処理にはコストがかかります。また、コンパイラは、プログラム内にあるすべてのシンボルを複数回解決しなければならないことになります（1 回はスタブ生成のため、もう 1 回は実際のコンパイルのため）。
KSP は Kotlin コンパイラ プラグインとして動作することで、スタブ生成モデルから脱却します。アノテーション プロセッサは、Java アノテーション処理インフラストラクチャに頼ることなく、Kotlin のソース プログラムやリソースを直接読み取って分析します。そのため、ビルド速度が劇的に短縮される（Room の Kotlin テストアプリでは最大 2 倍高速）だけでなく、Kotlin/Native や Kotlin/JS といった Android 以外の環境や JVM 以外の環境でも KSP を利用できるようになります。
KSP を使ってみるには、GitHub から KSP Playground プロジェクト (ZIP ファイル 3.1MB)をダウンロードします。このプロジェクトでは、アノテーション プロセッサとして KSP を使う方法と、利用者向けのアプリやライブラリとして使う方法の両方を示しています。
test-processor
workload
アプリ デベロッパーの方は、サポートされているライブラリの一覧と、モジュールを KAPT から KSP に移行するためのクイックスタート ガイドをご覧ください。
プロジェクトで Moshi や Room を使っている方は、モジュールのビルドファイルを少し変更するだけで、すぐに KSP を試すことができます。たとえば、Gradle モジュールで KAPT プラグインを KSP プラグインに置き換えて KSP の依存関係を入れ替えるだけで、KSP 版の Room を使うことができます。
apply plugin: 'com.google.devtools.ksp'dependencies { ... implementation "androidx.room:room-runtime:$room_version" kapt "androidx.room:room-compiler:$room_version" ksp "androidx.room:room-compiler:$room_version"}
dependencies {
...
implementation "androidx.room:room-runtime:$room_version"
kapt "androidx.room:room-compiler:$room_version"
ksp "androidx.room:room-compiler:$room_version"
}
詳細は、Room のリリースノートをご覧ください。
KSP が 1.0 リリースを迎えたので、KAPT ベースのライブラリから移行すれば、皆さんの Kotlin プロジェクトでもビルド時間を短縮できます。また、たくさんの Android 固有のライブラリもアップデートしています。パフォーマンスが大幅に改善されており、本日から試すことができます。
この記事は Tom Grinsted, Scott Lin, and Tat Yang Koh による Android Developers Blog の記事 " Making Ratings and Reviews better for users and developers " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
評価とレビューは重要です。皆さんが提供しているアプリやゲーム、その他さまざまなサービスについて、ユーザーが体験したことを報告してもらえるため、貴重な定量的、定性的フィードバックです。そしてそれは、ユーザーが Google Play で何をダウンロードするかを決める際の指標の 1 つにもなります。
Google Play ストアを利用しているユーザーとデベロッパーの皆さまから、評価とレビューの有用性をさらに向上させることができるという声をいただいています。特に、ある地域からの評価が全体に不当な影響を与える場合です。たとえば、1 つの国にのみ悪影響を及ぼすバグが全体の評価に影響してしまう場合や、タブレットでの体験が向上しているにもかかわらず、スマートフォンのユーザー数が多いため見落とされている場合などです。そこで、評価をパーソナライズして個々のユーザーに想定される体験を表せるように、またデベロッパーが簡単に評価を確認して利用できるように、今後数四半期にわたる改善プログラムを進めています。
多くのデベロッパーが、潜在的なユーザーが目にする評価を注視していることを私たちも理解しているので、今後の変更について皆さんに十分な案内を行うようにします。また、Google Play Console の機能強化も行い、特にフォーム ファクタ間の違いという点でも、評価やレビューを理解しやすくしました。
デベロッパーの皆さんが、ユーザーへのサポートをさまざまな種類のデバイスに拡大することは、ユーザー インターフェースにとって特に重要で影響の大きい変更です。タブレットに最適なレイアウトを追加したり、Chrome OS でマウスやキーボードのサポートを強化したりすると、ユーザー エクスペリエンスの質が段階的に変化し、それが評価やレビューに影響する可能性があります。
Google Play Console の評価の概要と内訳のページに、デバイスの種類による評価分析を新しく追加
さまざまなデバイス間でのチャンスを見つけやすくするため、また機能改善による変化を観測するため、デバイスの種類のディメンションを評価のページに新設しました。さらに、レビューにもデバイスの種類によるフィルタを追加し、タブレットのユーザーによる評価や、Chrome OS のユーザーによるレビューのコメントを簡単に確認できるようにしました。
多くのデベロッパーの方々から、これまで選択できたものよりも細かいデータにアクセスしたいという声が寄せられました。そこで、セグメンテーションのオプションを細かくし、さらに使いやすくしました。現在は、プロットしたい期間（直近 28 日からアプリの全期間まで）や評価データの集計方法（日ごと、週ごと、28 日ごと）を個別に選択できるようになっています。これにより、長期にわたる細かいデータを確認できるようになっています。
任意の時間範囲と集計期間を個別に選択し、必要な評価データを検索
加えて、平均データと評価の分布を CSV でダウンロードできるようにしました。これを新しいデータ選択オプションと組み合わせれば、多くのデータを簡単に照会してダウンロードし、オフラインで分析できます。たとえば、日ごとの評価の分布の履歴データをすべてダウンロードし、スプレッドシートでカスタマー サービスの連絡回数と関連付けることもできます。
概要ページから、評価の内訳を含む全データに直接アクセスしてダウンロードすることが可能
以上の変更点は、現時点ですべて Google Play Console に反映されています。評価の概要やレビューにアクセスすると、実際に確認できます。*
評価は、ユーザーがどのアプリをダウンロードするかを決める上で役立ちます。また、Google Play ストアでのおすすめや配置を決める上でも利用されます。しかし、アプリを通したエクスペリエンスはユーザーの地域やデバイスの種類によって異なる可能性があり、評価の総計が常に全体像を表すとは限りません。そこで、2021 年 11 月より、個々のユーザーに表示される評価を、ユーザーが登録した国や地域に応じた評価に変更する予定です。さらに今年中には、ユーザーが使用しているデバイスも考慮されます。
つまり、11 月以降、スマートフォンのユーザーには、自分が居住している国や地域に合わせた評価が表示されます。一例を上げると、日本のユーザーには、他の日本のユーザーが送信した情報から生成されたアプリの評価が表示されます。
来年初頭には、さらに評価をアップデートし、タブレット、折りたたみ式デバイス、Chrome OS、Wear、Auto など、ユーザーが Google Play を表示しているデバイスの種類が反映されます。これにより、ユーザーが使っているデバイスで想定されるエクスペリエンスについての情報が提供されるようになります。そのため、早い段階でフォーム ファクタの評価を確認することをお勧めします。特に、成長が著しいタブレットに注目し、ユーザー エクスペリエンスを最適化する投資を行うべきかを確認しましょう。
ユーザーに表示される評価が大きく変わる場合、デベロッパーの皆さんはそれを理解して先手を打ちたいと思うはずです。そのため、Google Play ストアで行われるすべての変更について、少なくとも 10 週間前に皆さんのアプリで想定される変更を自動分析し、主要なマーケット（ストアの掲載情報にアクセスしたユーザーが 5% を超えるマーケット）でいずれかの種類のデバイスの星が 0.2 個以上変化するデベロッパーに対して連絡いたします。これにより、アプリに大きな変更を加えたい場合でも、十分な時間を確保できればと考えています。
以上の Google Play 上の変更は、2021 年 11 月よりロールアウトし、国や地域に合わせた評価が表示されるようになります。これから年末までの期間中は、Google Play Console の受信トレイでの、評価に関するメッセージに注目してください。現在、既に国やデバイスの種類ごとで評価を確認できるようになっていることも忘れないようにしましょう。*
* リンクにアクセスするには、Google Play Console アカウントが必要です。
Reviewed by Naoki Oyama - Developer Support Lead, Google Play, APAC and Tamao Imura - Developer Marketing Manager, Google Play
2021 年 9 月 4 日 (土) に 4 回目を迎えた Indie Games Festival の、トップ 3、トップ 10、特別賞を決定するファイナル イベントが、オンラインで開催されました。
本記事ではスペースの都合上 、トップ 3 と特別賞のみご紹介しますが、トップ 20 各作品への審査員全員のコメントは、後日開発者の皆さんへ個別にイベント事務局からご連絡いたします。受賞された皆さま、改めておめでとうございます！
※（五十音順、敬称略）
安藤 武博
株式会社シシララ 代表取締役 ゲームDJ
成沢 理恵
monoAI technology株式会社、モリカトロン株式会社、ちゅらっぷす株式会社、株式会社ArAtA、RingZero株式会社、Amusement Asset Associates株式会社 / 取締役
株式会社モバイルファクトリー / 社外取締役
Zen Chao
Asobu / Founder
Makers Fund / Japan Lead
簗瀬 洋平
ユニティ・テクノロジーズ・ジャパン株式会社 クリエイター・アドボケイト（学術）
森 通治【集英社ゲームクリエイターズCAMP賞審査員】
株式会社集英社 新規事業開発部 ゲーム事業・映像事業開発課 ゲームクリエイターズCAMP プロデューサー
大島 孝幸【TOHO Games 賞審査員】
東宝株式会社 映像本部 映像事業部 部長
UUUM所属クリエイター SKJ Village【UUUM 賞審査員】
五十嵐 郁
Google Play Partnerships ゲーム部門 パートナー デベロップメント マネージャー
キム チョンサ
Google Play Partnerships ゲーム部門 日本統括部長
『サバイバーズ・ギルト』 への審査員からのコメント : 𥱋瀨 洋平
ゲーム開発は人の命に関わらないので気楽に最高の技術を注ぎ込めるのが良いところと思っていましたが、この作品でそれだけではない、むしろゲームというエンターテイメントには人の命を救うポテンシャルがあるのだと感じさせられました。
『時空運送』 への審査員からのコメント : 安藤 武博
令和の倉庫番！！操作のひとつひとつが小気味よくきもちがよく、1ターンずつ素早くアンドゥできるところもテンポ感を増していました。じっくり向き合いたいゲームです！
『ねずみバスターズ！』 への審査員からのコメント : 成沢 理恵
もし採点に「愛」という項目があったら、100点満点だと思います。セリフの言い回し、ありそうな日常風景と人物像、どこか癒されるグラフィック、すごく楽しませていただきました。
※（敬称略）
Odencat 株式会社
審査員からのコメント : 五十嵐 郁
この賞のポイントは世界で成功することを目標としているタイトルを後押しすることなので、作品として世界に通用するポテンシャルや、海外ユーザーを意識したゲーム作りの姿勢などが決め手となりました。
HAKOT
学生賞の審査の基準はトップ 20 と同じくゲームの楽しさやデザイン品質等を見ていますが、その意味でとてもクオリティが高く、非常に細かいところまでこだわっていてリアリティがありとても楽しめる作品でした。
審査員からのコメント : 大島 孝幸
総合的なクオリティが非常に高く、タワーディフェンス＋トランプゲームの組み合わせの発想も秀逸でした。ゲームサイクルも綺麗に繋がっており、操作感も良かったです。プレイヤーに与える報酬と試練のバランスも良く、チュートリアルも良く出来ているので、幅広いユーザーを獲得できる作品だと感じました。キャラクターやインターフェースのデザインも統一感があり、可愛いらしく魅力的な世界観を演出していて、ゲーム性も適度に複雑でやり込めるので、ユーザーの継続性も良いのではと感じました。
審査員からのコメント : 森 通治
シンプルなビジュアルで進むアドベンチャーで、まずストーリーが面白く、動きがまとまっているので、安心感を持って集中して進めてしまう。１時間で遊んでもらいたいという潔さもとても良いと思います。このチームの才能をどうマネタイズにしていくのかなど、一緒に考えていきたいです。
審査員からのコメント : SKJ Village
人狼と将棋を組み合わせる独創性・実際にアプリで戦っていく中でわかった中毒性、広がっていく未来があるゲームでした。ゲームがおもしろく、課金要素、大会など今後の展望が見えました。
『DroidKaigi』は、Android 技術情報の共有とコミュニケーションを目的に開催する、エンジニアが主役の Android カンファレンスです。Android 技術情報の共有とコミュニケーションを目的に、2021 年10 月 19 日(火)、20 日(水)、21 日(木)の 3 日間開催します。
『DroidKaigi 前夜祭』 では、2021 年に発表した Android/Google Play 関連の製品のお話や、I/O 以降に発表された製品・技術関連の最新情報などについてお話をします。参加人数に制限を設けておりませんので、お誘い合わせの上ご参加ください。
日時: 10 月 18 日 19 時〜 20 時 30 分
参加登録はこちら
MC：
日高 正博 一般社団法人DroidKaigi 代表理事・株式会社メルペイ エキスパートチーム・技術書典 主宰
スピーカー:
荒木 佑一 Android Developer Programs Engineer (Google)
萩倉 健支 Android Developer Programs Engineer (Google)
Saryong Kang Developer Advocate (Google)
DroidKaigi 本イベントへも併せてご登録・ご参加ください！
日時: 2021 年 10 月 19 日(火)、20 日(水)、21 日(木)の 3 日間
Written by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Jeremy Walker による Android Developers Blog の記事 " Sharing Tiles with your smartwatch users: " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
タイル (英語) は、ウォッチフェイスのホーム画面をスワイプするだけで情報やアクションにすばやくアクセスする機能を提供いたします。これにより、スマートウォッチ ユーザーはどんな情報やアクションを表示するかを細かく制御できます。Wear OS を実行するスマートウォッチで、タイルが特に便利で役立つ機能の 1 つとなっていることも不思議ではないでしょう。
2021 年 8 月 11 日（日本時間 8 月 12 日）に、スマートウォッチ ユーザーとタイルを共有できることを発表いたしました。Jetpack Tiles API の最新のアルファ リリースをダウンロードすると、カスタムタイルを作成できます。作成したタイルを含むアプリを Google Play にアップロードすると、ユーザーはタイルをダウンロードして使い始めることができます。新しい体験を試せるようになったことをユーザーにもお知らせしましょう。Google Play Console で、Google Play ストアのプレビュー 用アセットにタイルのスクリーンショットをアップロードすることもできます。
Calm や 睡眠サイクル などのアプリは、既にカスタムタイルの作成を始めています。
「API はわかりやすく、ドキュメントもとても明確でした。そのため、わずか数時間で、実データを使って最初のタイルを動作させることができました。気軽に使ってみることができる最新の API だと感じています」 - 睡眠サイクル のTechnical Lead、Viktor Åkerskog
ディベロッパーの皆さんからのアルファ版ライブラリへのフィードバックには大変感謝しています。皆さんから頂いた多くのリクエストやパフォーマンスの改善を今回の API に含めました。追加のフィードバックはこちら (英語)からお送りください。今後のリリースに向けて、API の改善の優先順位を決めるうえで役立ちますので、ご協力をお願いいたします。
まだ API を試していない方はこちらのガイドをチェックしてください。チュートリアルを体験してみたい方はタイルの Codelab をお試しください。
それでは、コーディングをお楽しみください。
Reviewed by Saryong Kang - Partner Developer Advocate, Developer Relations Team
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 賞
学生部門賞
TOHO Games 賞
集英社ゲームクリエイターズ CAMP 賞
UUUM賞
Google Play | Indie Games Festival 2021 の開催に際し、多大なるご協力をいただいた、社外審査員、特別賞審査員の皆さま、ありがとうございました！各受賞作品への審査員の方々からのコメントや受賞理由は後日こちらのブログに掲載させていただきます。
このイベントでは、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. アプリを使ううえで、それぞれのユーザーが体験する一連の手順を「ユーザー ジャーニー」と呼びます。ユーザー ジャーニーのステージの例として、インストール、オンボーディング、エンゲージメント、リテンションなどがあります
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
