この記事は Hoi Lam による Android Developers Blog の "Quality to match with your user’s expectations" を元に翻訳・加筆したものです。詳しくは元記事をご確認ください。
10 年以上前に Android がリリースされてから、このプラットフォームは成長を続け、ユーザーの期待も高まるばかりです。それに伴い、ユーザー エクスペリエンスから、マテリアル デザイン、プライバシーの重要性と進化に至るまで、さまざまな改善が行われてきました。その一方でデベロッパーの皆さんが、常にアプリでよりすばらしいユーザー エクスペリエンスを提供していきたいと考えていることは承知しています。同時に、どの領域に最初に取り組むべきかを判断するのが難しいことも、私たちは把握しています。そこで、Android Developers の Web サイトにアプリの品質セクションを新たに設けて、アプリの品質の重要な内容についての最新情報や関連リソースを提供します。
今回の最初のリリースでは、Android の最新リリースや、アプリ エコシステムの現在のトレンドを踏まえて、アプリの中核品質チェックリストを更新しました。このアップデートのいくつかのポイントを示します。
常に最新の状態を保てるように、今後は四半期ごとにこのリストを更新したいと考えています。また、他のフォーム ファクタの品質チェックリストも更新する予定です。
現在は、Android で高品質なアプリを簡単に構築できるように、追加のツールやベスト プラクティスに関する作業を進めています。引き続き改善を続けていきます。ご期待ください。
この記事は 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 フォーマットを使ったインスタント エクスペリエンスにも影響します。2021 年 8 月以降は、新しいインスタント エクスペリエンスへの対応 と 既存のインスタント エクスペリエンスのアップデートを行わないと、インスタント対応 App Bundle を公開することはできません。
すべての変更点の概要を改めて示します。
Wear OS アプリには、新しいターゲット API レベル要件は適用されません。minSdkVersion は任意のものを使うことができるので、古い Android バージョンを対象にアプリを作成できる点は変わりません。
App Bundle への移行の詳細については、新しい動画シリーズ Modern Android Development（MAD）Skills をご覧ください。
既に App Bundle と API レベル 30 に採用しているすべてのデベロッパーの皆さん、本当にありがとうございます。皆さんとともに Android プラットフォームをさらに進化させるのを楽しみにしています。
Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
ロック画面と認証の改善点について詳しく説明する前に、いくつかの背景情報をお伝えします。この情報は、今回の改善点における相互の関連性を把握するために役立ちます。今回の変更は、階層化認証モデルのフレームワークに当てはめてみるとイメージしやすいはずです。階層化認証モデルとは、Android に搭載されているすべての認証方式を概念的に分類し、相互の関連性や、この分類に基づく制約をまとめたものです。
信頼できる場所や信頼できるデバイス（そして一般的な第 3 の方式）を使うと、便利な方法でデバイスの内容にアクセスできます。しかし、これらに共通する根本的な問題は、最終的にユーザーの身元確認機能の精度の低さに集約されます。たとえば、信頼できる場所を使っているスマートフォンのロックは、ユーザーの自宅のそばを通り過ぎるだけで解除できるかもしれません。また、既製のソフトウェア無線と多少のスクリプトを使えば、比較的簡単に GPS シグナルを偽装することもできます。信頼できるデバイスも同様で、許可リストに登録された Bluetooth デバイスにアクセスできれば、ユーザーのスマートフォン内のすべてのデータにアクセスできることになります。
そこで、Android 10 の環境階層に大幅な改善が加えられ、第 3 階層は積極的にロックを解除する仕組みからロック解除を延長する仕組みに変わっています。この新しいモードでは、第 3 階層でデバイスのロックを解除できなくなりました。その代わり、最初に第 1 の方式か第 2 の方式を使ってデバイスのロックを解除している場合、最大 4 時間にわたってロック解除状態を継続します。
生体認証の実装には、幅広いセキュリティ特性があります。そこで、次にあげる 2 つの重要な要素を利用して特定の実装のセキュリティを判定しています。
各クラスには、一連の制約が紐付いています。この制約は、それぞれの使いやすさとセキュリティのレベルのバランスをとることを目指したものです。
制約は、生体認証が第 1 階層の認証にフォールバックするまでの時間と、許可されているアプリ統合で表されています。たとえば、クラス 3 の生体認証はタイムアウトまでの時間が最も長く、すべてのアプリ統合オプションを利用できます。一方、クラス 1 の生体認証はタイムアウトまでの時間が最も短く、アプリ統合オプションは提供されません。概要を下の表に示します。完全版を確認したい方は Android Compatibility Definition Document（CDD）をご覧ください。
1 App Integration（アプリ統合）とは、API をアプリに公開すること（例: BiometricPrompt/BiometricManager、androidx.biometric、FIDO2 API などの統合によって）を意味します。
2 Keystore Ingegration（キーストア統合）とは、キーストアを組み込むこと（例: アプリの認証バインドキーをリリースするなど）を意味します。
生体認証を利用すると、高レベルのセキュリティを維持しつつ、ユーザーに利便性を提供できます。ユーザーは生体認証を利用するために第 1 の認証方式を設定する必要があるので、ロック画面の採用が促進されます（生体認証を提供しているデバイスは、そうでないデバイスに比べてロック画面の採用が平均 20% 高くなっています）。これにより、ロック画面が提供するセキュリティ機能のメリットを活用できるユーザーが増えます。具体的には、ユーザーの機密データへの認証されていないアクセスを防ぐことができ、暗号化バックアップなどの第 1 の認証方式によるその他のメリットも受けることができます。さらに、生体認証は、肩越しにのぞき見るショルダー サーフィン攻撃によって PIN やパターン、パスワードを入力するのを見た攻撃者が認証情報を再現しようとする試みを減らすうえでも役立ちます。
ただし、生体認証を使うことによるトレードオフ（発生し得るリスク）をユーザーが理解することが重要です。特に大切なのは、完璧な生体認証システムはないということです。これは Android だけでなく、すべてのオペレーティング システム、フォームファクタ、テクノロジーに対して言えることです。たとえば顔を使った生体認証の実装なら、ユーザーに似た家族やユーザーの 3D マスクでロックが解除できてしまうかもしれません。指紋を使った生体認証の実装なら、ユーザーの潜在指紋を使ってなりすませるかもしれません。このようななりすまし攻撃を緩和するため、なりすまし対策や Presentation Attack Detection（PAD）テクノロジーの開発が進められていますが、これらは緩和策であり、予防策ではありません。
生体認証の利用による潜在的なリスクを緩和するための Android の取り組みとして、Android P で導入されたロックダウン モードがあります。必要な場合、Android ユーザーはこの機能を使って一時的に生体認証や Smart Lock（信頼できる場所や信頼できるデバイスなど）、ロック画面の通知を無効化できます。
ロックダウン モードを使うには、まず第 1 の認証方式を設定し、その後に設定でロックダウン モードを有効化する必要があります。ロックダウン モードを有効化するための厳密な設定はデバイスのモデルによって異なりますが、Google Pixel 4 デバイスでは [Settings] > [Display] > [Lock screen] > [Show lockdown option] にあります。これを有効化すると、ユーザーは電源ボタンを押して電源ボタン メニューのロックダウン アイコンをクリックすることで、ロックダウン モードを起動できます。ロックダウン モードのデバイスは、第 1 の認証方式（PIN、パターン、パスワードなど）を使ってデバイスのロックを解除すると、ロックダウン解除状態に戻ります。
BiometricPrompt API を使用すると、さまざまなメリットが得られます。最も重要なことは、この API を使うと、アプリのデベロッパーが方式を意識せずに、さまざまな Android デバイスで生体認証を利用できることです（つまり、BiometricPrompt は、デバイスでサポートされているさまざまな生体認証方式の単一統合ポイントとして利用できます）。一方で、認証が提供する必要があるセキュリティ保証（フォールバックとしてのデバイス認証情報と合わせてクラス 3 またはクラス 2 の生体認証を必須とするなど）を制御することもできます。これにより、（ロック画面の他に）防御の第 2 階層でアプリデータを保護できることに加え、ユーザーの機密データを尊重することにもつながります。さらに、さまざまな Android デバイスのさまざまな方式の生体認証で一貫したユーザー エクスペリエンスを提供するため、BiometricPrompt は永続的な UI を提供しています。一部の情報（タイトルや説明など）をカスタマイズするオプションも存在します。
次のアーキテクチャ図に示すように、フレームワーク API やサポート ライブラリ（下位互換性を確保するための androidx.bitmetric）のどちらかを通して、Android デバイスのアプリに生体認証を組み込むことができます。注意すべき点は、FingerprintManager が非推奨になっていることです。デベロッパーには、方式を意識しない認証としてBiometricPrompt に移行することが推奨されています。
Android 11 では、BiometricManager.Authenticators インターフェースなどの新機能が導入されています。これを使うと、デベロッパーはアプリで受け入れる認証タイプを指定したり、BiometricPrompt クラスで利用ごとの認証キーをサポートしたりできます。
詳しくは、Android 11 プレビューと Android 生体認証システムのドキュメントをご覧ください。BiometricPrompt API の詳しい使用方法については、ブログ記事 Using BiometricPrompt with CryptoObject: how and why や、Codelab Login with Biometrics on Android をご覧ください。
