この記事は Diana Wong による Android Developers Blog の記事 "Testing app compatibility in Android 11" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
このブログ投稿は、 Android 11 に関する重要な内容を毎週取り上げる #11WeeksOfAndroid シリーズの一部です。第 4 週は、Android 11 の互換性がテーマです。
今週の 11 Weeks of Android では、Android 11 の互換性を特集しています。このテーマはすべてのデベロッパーにとって重要です。Android での アプリの互換性 とは、特定のバージョンの Android（通常は最新版）でアプリが問題なく動作することを意味します。
互換性テストに便利な関連情報をこちらで共有しています。また、Twitter や YouTube で Android Developers をフォローすると、この分野に役立つコンテンツや資料を入手できます。
私たちはリリースのたびに、アプリの準備に必要な作業を減らすよう努めています。Android 11 では、プラットフォームのアップデートによる影響を最低限にとどめ、簡単にアプリの互換性を維持できるようにするため、新しいプロセスやデベロッパー ツール、リリース マイルストーンを追加しました。
今週全体を通して、このようなトピックをさらにお届けします。まずはこの続きを読み、Android 11 でアプリのテストやデバッグがどのように簡単になったのかをご確認ください。
新しい Android リリースでアプリをテストするタスクは、難しいものになる場合もあります。アプリに影響するプラットフォームの変更点が複数あるような場合は、特にそう言えるでしょう。特に次のような疑問が浮上するかもしれません。
targetSDKVersion,
このような疑問について、デベロッパー コミュニティから多くのフィードバックをいただいています。Android 11 では、テストプロセスを簡単にできるように、プラットフォームに新しいツールを追加し、Android Studio に新機能を導入しています。
これまでのリリースと同様、Android 11 には Android プラットフォームに関するいくつかの変更点が含まれています。これにより、アプリが影響を受けるかもしれません。このような変更はプラットフォームの改善に不可欠ですが、プラットフォームの最新 targetSDKVersion のみを対象にする変更点をできる限り多くすることで、アプリで早急に対応しなければならない変更を極力少なくするよう努めています。また、Android 11 では、こういったプラットフォームの変更点の多くを新しい互換性フレームワークに追加しています。
targetSDKVersion
変更点が互換性フレームワークに含まれる場合、新しいデベロッパー ツールを利用すると、アプリでその変更点のテストやデバッグがしやすくなります。
たとえば、互換性フレームワークに含まれる変更点は切り替え可能であるため、端末の開発者向けオプションや ADB（Android Debug Bridge）から個々に変更を強制的に有効化または無効化することができます。Android プラットフォームは自動的に内部 API のロジックに適応するので、targetSDKVersion を変更したり、アプリを再コンパイルしたりすることなく、基本的なテストを行えます。さらに、他に影響を与えることなく個々の変更を個別に有効化できるので、アプリで問題を見つけてデバッグする時間が短くなります。
実際に変更点をオンまたはオフにする前に、動作の変更点リストに目を通し、アプリがどの変更点によって影響を受ける可能性があるかを確認してください。互換性フレームワークに含まれる変更点には、詳しい説明の前に対応する Change ID と Change Name が記載されています。
Change ID
Change Name
通常は、すべてのアプリに影響する動作の変更点のテストから始めることを推奨しています。このような変更点は、targetSDKVersion にかかわらずアプリに影響する可能性があります。ただし、影響を受ける targetSDKVersion が限られている変更点もご覧ください。また、アプリを異なるターゲット SDK で再コンパイルすることなく変更点をテストする方法も確認いただけます。
バックグラウンド位置情報アクセスに関する変更を確認してください。この変更は、バックグラウンド位置情報への常時アクセスをリクエストするアプリに影響します。アプリがこの変更によって影響を受ける場合、ここからテストを始めることをおすすめします。この変更の名前は BACKGROUND_RATIONALE_CHANGE_ID で、ID は 147316723 です。この情報を使って変更を有効化してから、アプリをテストしてください。
BACKGROUND_RATIONALE_CHANGE_ID
147316723
どの変更をテストするかを決めたら、開発者向けオプションを使ってその変更をオンまたはオフします。開発者向けオプションを開くには、端末の [Settings] アプリを開き、[System] > [Advanced] > [Developer options] > [App Compatibility Changes] に移動します。
この例では、BACKGROUND_RATIONALE_CHANGE_ID が有効になっている唯一の変更点です。こうすることで、アプリで問題が発生する可能性がある原因の範囲を最小限にとどめることができます。
また、logcat や ADB を使って有効になっている変更点を確認したり、ADB を使って変更点をオンまたはオフにしたりすることもできます。なお、変更点の切り替えができるのは、デバッグ可能なアプリを使っている場合のみです。
変更を有効にした後は、通常のテスト ワークフローを使ってアプリのテストやデバッグを行えます。問題を見つけたら、ログをチェックして問題の原因の判別に役立てます。有効にしたプラットフォームの変更点によって問題が発生したのかどうかわからない場合は、変更を無効にしてアプリを再テストしてください。
Android 11 でのプラットフォームの変更点のテストについて取り上げた今週の動画で、別の例をご覧ください。また、developer.android.com のドキュメントもご確認ください。
新しいプラットフォームでの手動テストに加えて、Android Studio を使った最新 OS の自動テストも簡単に実行できるようにしています。
Android Studio 4.2 以降では、複数の物理端末や仮想端末でインスツルメンテーション テストを並列実行できます。テストを実行する際に、ターゲット端末のドロップダウン メニューに複数の端末を選べるオプションが追加されています。
この機能は、開発サイクルでできる限り早く問題を発見し、異なる Android ビルド間で違いを比較できるように設計されています。テストの結果は、[View] > [Tool Windows] > [Run] にある新しいテスト マトリクスで確認できます。
Android Studio を使ったアプリの互換性テストに関する今週の動画をご覧ください。また、developer.android.com のドキュメントもお読みください。
「このデザイン システムは読んだり調べたりしやすく、タイポグラフィとスペースを活用してセクションを明確に表現し、シンプルな情報階層を実現しました。一連のスタイルやコンポーネントには一貫性があり、慎重に検討されているので、初めて目にした方にとっても最大限に直感的で使いやすい機能になっています」
