デバイスを特定する共通の基準を導入することになりました。基本的な要件からさらに進んだ高度な性能を定義します。クラスの要件を満たすデバイスは、より厳しい条件のユースケースに対応し、より質の高いコンテンツを提供できます。クラスを確認することで、デバイスのパフォーマンスを最大限に活かした高度なエクスペリエンスを確実に提供できます。み取りと書き込みのパフォーマンスなどの要件を定義したパフォーマンスクラスを提供します。詳しくはこちらをご覧ください。私たちは常にプライバシーを念頭に置いています。引き続き、ユーザーのデバイスとデータのセキュリティを保護しながら、透明性と制御性を高めることに努めています。追加されたプライバシー機能は以下のとおりです。権限の自動リセット機能を追加しました。アプリが権限をリセットされています。権限の自動リセットをさらに発展させ、長期間使用されなかったアプリを自動的に休止状態に切り替え、デバイスのストレージ容量、パフォーマンス、安全性をより改善する機能を導入します。休止状態はユーザーが以前に許可した権限を取り消すだけでなく、アプリを強制停止してメモリやストレージ、その他の一時リソースを解放します。この状態になると、アプリがバックグラウンドでジョブを実行したりプッシュ通知を受け取ったりできなくなるため、ユーザーのデータが安全に保たれます。この機能を無効にするようユーザーに通知してください。詳しくはこちらをご覧ください。スキャンを行うには位置情報を取得する権限が必要で、近くのデバイスとペア設定する必要があるけれどもデバイスの位置情報は必要としないアプリにとっては問題になっていました。スキャンを実行して近くのデバイスを探せるようになりました。権限を使用してスキャンを実行できます。権限を使用して通信を開始できます。これらの権限を使用することで、プライバシーに配慮した設計を採用しながら、アプリを利用する際のユーザーの抵抗感を減らすことができます。詳しくはこちらをご覧ください。最近、フォアグラウンドでのアクセスとバックグラウンドでのアクセスを別々に管理する設定や、「今回のみ」アクセスを許可するオプションなど、位置情報へのアクセスをきめ細かく管理する方法をいくつか導入しています。ターゲットとするアプリでは、「おおよその位置」を選択できるオプションが導入され、よりきめ細かい管理が可能になりました。アプリが正確な位置情報を要求した際に正確な位置情報とおおよその位置情報のどちらの取得を許可するかユーザーが選択できます。いつでも変更できます。アプリで正確な位置情報(ACCESS_FINE_LOCATION)を要求する場合は、この変更点を考慮し、おおよその位置情報だけでもアプリが問題なく機能するようにしてください。一般的な用途で位置情報を利用するのであれば、通常はおよその位置情報(ACCESS_COARSE_LOCATION)のみを要求することをお勧めします。詳しくはこちらをご覧ください。アプリの互換性をまだテストしていない方は、ぜひ、早めに着手することをお勧めします。デバイスやほかのデバイスで、先行登録したユーザーと、デベロッパーの皆さんが利用可能です。上でより多くのユーザーが利用し、問題点を報告してくる可能性があるということです。実行するデバイスまたはエミュレータにインストールし、アプリのすべてのフローで動作を検証してください。動作の変更点を改めて確認することで、的を絞ったテストを実施できます。問題を解決したら、できるだけ早くアップデートを公開しましょう。達成に一歩近付きました。リストが最終的に決定されます。この時点で互換性の最終テストを完了し、完全な互換性が確認されたアプリ、SDK、ライブラリのバージョンをリリースできるようにしましょう。デベロッパー向けのスケジュールの詳細については、こちらをご覧ください。機能を試し、アプリをテストし、フィードバックを送信するために必要なすべてのものが揃っています。アップデートを受け取ってください。アップデートが自動で送信されます。使用できるものがあります。パートナーの一覧と、サポート対象のデバイスの詳細を説明したサイトへのリンクが記載されています。アップデートもパートナーから直接提供されます。テストを実行できます。イメージをダウンロードしてください。サイトをご覧ください。さんに寄稿いただいたゲスト記事です。System)はプロダクト開発において重要な役割を担うようになっています。オープンソースのデザインシステムを採用する例や、自社のデザインシステムを構築する例は多くみられます。使ったデザインシステムの実装をしました。今回は、その実装方法をご紹介します。いうデザインシステムがすでに存在しているのに、「なぜ別で構築する必要があるのだろうか?」という疑問を持つ方もいらっしゃるのではないでしょうか。スペックがフィットしないケースが多々あります。ある程度カスタマイズし、拡張することが必要になります。:本記事はデザインシステムそのものに関する説明ではありません。略称で、コードのコンフリクトを避けるために、プレフィックスとして使われています。デザイン技術的観点に集中するために、とてもシンプルなデザインシステムを用意しました。プロダクトレベルのデザインシステムとの違いは規模感(スタイルの数と種類)だけで、基本の考え方は変わりません。種類のスタイルを用意しました。これから実装していきます。Style(Token)まず使用する色を定義します。これらをまとめたカラーパレットを用意することで、テーマやブランドに応じて配色を切り替えられるようにします。Color(0xFFFF3D71)}次にカラーパレットのインターフェースを定義します。色をオーバーライドするために用意しました。Colors}定義したカラーパレットを実装することで、実際の配色を定義します。カラーをオーバーライドすることは必須ではありません。実装時に色を指定するコードを減らすことができます。同様にダークモード用のカラーパレットも用意します。色が入れ変わっています。プロダクトレベルのデザインシステムでは、カラーテーマごとに違うパレットを用意するといった構築方法も利用されます。サイズ指定サイズの定義はとてもシンプルです。デバイス画面のサイズによってサイズを変更するといった複数のバリエーションを持つ必要がある場合は、カラーパレットと同様の方法で対応できます。64.dp)Typographyタイポグラフィもサイズの定義と同様、シンプルに定義します。テーマに応じてフォントを使い分ける必要がある場合、また言語によって使用するフォントを切り替えたい場合など、複数のフォントバリアントのサポートが必要な場合があります。その場合は、配色と同様に実装することで対応できます。フォントをオーバーライドするために用意しました。追加する必要があります。テーマ(ブランド)によって変化する可能性のあるスタイルを外から受け取れます。