依存関係のバージョンをアップグレードする

依存関係をアップグレードすると、最新の機能、バグの修正、改善を利用できます。依存関係をアップグレードするには、リクエストしたバージョンが Gradle でどのように解決されるか、それに伴うリスク、リスクを軽減するための手順を理解する必要があります。

注: アップグレードによってビルドやアプリが予期しない方法で破損しないようにするには、優れたアプリテストが重要です。

アップグレード戦略を検討する

アップグレードで最も重要なステップはリスク分析です。アップグレードする各依存関係の信頼度を判断します。アップグレード戦略を定義する際には、次のような多くの点を考慮する必要があります。

ライブラリを作成する	ユーザーがデバイスにダウンロードして実行するアプリを作成していますか？それとも、他のデベロッパーのアプリケーション開発を支援するライブラリを構築するのでしょうか。 アプリケーションを構築する場合は、アプリケーションを最新の状態に保ち、安定させることに重点を置く必要があります。 ライブラリを作成する場合は、他のデベロッパーのアプリに焦点を当てる必要があります。アップグレードはコンシューマに影響します。いずれかの依存関係をアップグレードすると、そのバージョンは Gradle の依存関係解決の候補になり、アプリケーションでその依存関係が使用できなくなる可能性があります。 まず、可能な限りライブラリの依存関係を最小限に抑えます。依存関係が少ないほど、コンシューマの依存関係解決への影響は少なくなります。 セマンティック バージョニングに沿って、変更の種類を明記してください。たとえば、AndroidX ではセマンティック バージョニングが採用されており、プレリリース版のバージョニング スキームが追加されています。コンシューマに問題が発生しないように、major バージョンのアップグレードは避けてください。 ユーザーが早期にテストできるように、ライブラリのリリース候補版（RC）を作成することを検討してください。 ライブラリのアプリケーション バイナリ インターフェース（ABI）の互換性を維持する方法については、ライブラリ デベロッパー向けの下位互換性ガイドラインをご覧ください。統合テストとバイナリ互換性検証ツールを使用して、ABI の変更が意図したバージョン変更と一致していることを確認します。 ライブラリの下位バージョンの patch で修正をリリースする場合、ユーザーは新しい機能を必要としない限り、ライブラリを次の major バージョンまたは minor バージョンにアップグレードする必要はありません。これらのアップグレードでは、推移的依存関係をアップグレードしないでください。 ユーザーにとって特に負担となるような互換性を損なう変更が必要になった場合は、古いバージョンと新しいバージョンを共存させ、より段階的なロールアウトを行えるように、それらを新しいアーティファクトとしてリリースすることを検討してください。 注: 依存関係のアップグレードに API の大きな変更が含まれている場合は、major リリースまたは minor リリースでアップグレードし、必要な変更を加える必要があります。これを行わないと、ライブラリのユーザーがそうした結果、ライブラリとその依存関係の間で互換性が失われる可能性があります。これは、ライブラリに変更がない場合でも適用されることがあります。依存関係をアップグレードするためだけに、新しいバージョンをリリースすることもできます。
リリース サイクル	アプリやライブラリをリリースする頻度はどれくらいですか？ 開発サイクルとリリース サイクルの短縮 アップグレードに使える時間が短くなります。 すぐに遅れを取る可能性があります。 頻繁に小規模なアップグレードを行うと、ワークロードを軽減できます。 ライブラリのアップグレードに問題が発生した場合は、そのアップグレードを迅速にロールバックできます。 Dependabot や Renovate などのツールを使用するとワークロードを軽減できますが、結果を分析してリスクを確認してください。 開発とリリースのサイクルが長くなる アップグレードの作成とテストに十分な時間があります。 依存関係の新しいバージョンは、サイクル中にリリースされる可能性が高くなります。 アップグレードをロールバックしてアプリケーションまたはライブラリをリリースするには、さらに時間がかかる。
最新の機能を常に把握する	利用可能な最新の機能と API を使用しますか？それとも、機能やバグの修正が必要なときにだけアップグレードしますか？ 頻繁なアップグレードのトレードオフを考慮してください。将来のアップグレードは簡単になります（統合する変更が少なくなります）。ただし、アップグレードのリスクは頻繁に発生します。 ライブラリのプレリリース版（アルファ版、ベータ版、リリース候補版）へのアップグレードをテストすると、安定版が利用可能になったときに準備を整えることができます。
新しい依存関係	新しい依存関係を追加する場合は、すべてのリスク基準についてライブラリを調査し、適切に評価されていることを確認する強力なレビュー プロセスを検討してください。審査なしで新しい依存関係を追加できないようにします。
専任チーム	専任のビルドチームはありますか？ソフトウェア エンジニアがビルドを維持していますか？専任チームは、エンジニアが新しいバージョンを使用する前に、アップグレードのリスクの分析や新しいバージョンのテストに多くの時間を費やして、ビルドが適切に機能することを確認できます。
アップグレードの種類	重要度の高いアップグレードもあります。最も重要な項目について考えてみましょう。 Gradle や Gradle プラグインなどのビルドツールのアップグレードは、通常、ユーザーへの影響が少なく、リスクの多くはビルド内部にあります。ビルド自体が、これらの変更の検証に役立ちます。ライブラリと SDK のアップグレードは検証が難しく、ユーザーにとってのリスクも高くなります。 Android Gradle プラグイン（AGP） - Android アプリやライブラリのビルドに使用されるツール。パフォーマンスの改善、バグの修正、新しい lint ルール、新しい Android プラットフォーム バージョンのサポートが含まれることが多く、最も重要なアップグレードです。 Gradle - AGP や他の Gradle プラグインをアップグレードするときに、Gradle をアップグレードすることがよくあります。 その他の Gradle プラグイン - Gradle のプラグイン API が変更されることがあります。Gradle をアップグレードする際は、使用しているプラグインのアップグレードを確認します。 Kotlin と Java - 一部のライブラリやプラグインでは、Kotlin または Java の最小バージョンが必要な場合や、新しい言語機能や API を利用したり、パフォーマンスを向上させたりする場合に適しています。 Android プラットフォーム - Google Play ストアでは、Android SDK の定期的なアップグレードが必要です。新しいバージョンの Android SDK は、できるだけ早くテストする必要があります。一部の SDK アップグレードでは、新しい権限や新しい API の使用など、アプリケーションの変更が必要になります。 ライブラリ - ライブラリの優先度を、全体的なアーキテクチャとの近さに基づいて設定しますか？ AndroidX などのプラットフォームとアーキテクチャに関連するライブラリは、新しい機能を使用したり、プラットフォームの変更を抽象化したりするために、頻繁に変更されます。少なくとも、Android プラットフォームやその他のアーキテクチャ関連のライブラリをアップグレードするたびに、これらのライブラリをアップグレードしてください。 新機能や特定のバグ修正が必要な場合を除き、他のライブラリのアップグレードは分散または遅らせることができます。 Android Studio - Android Studio を最新の状態に保つことで、基盤となる IntelliJ IDEA プラットフォームとツールの最新機能やバグ修正を利用し、最新の Android SDK を操作できます。
利用可能なツール	アップグレードに役立つツールやプラグインは多数ありますが、Dependabot や Renovate などのツールを使うと、ビルドのライブラリ バージョンが自動的にアップグレードされますが、必ず結果を分析してリスクがないか確認してください。

特定のタイプのアップグレード戦略

一部のタイプの依存関係をアップグレードすると、他のタイプの依存関係のアップグレードが必要な連鎖的な影響が生じる可能性があります。ビルド要素間の関係については、ツールとライブラリの相互依存関係をご覧ください。

図 1. 関係を築く。

各タイプのコンポーネントをアップグレードする場合は、アップグレードがビルド内の他のコンポーネントに与える影響を考慮してください。

Android Gradle プラグイン（AGP）	Android Studio には、これらのタスクを支援する AGP アップグレード アシスタントが含まれています。 アシスタントを使用するか、手動でアップグレードする場合は、次の点を考慮してください。 AGP リリースノートをご覧ください。 少なくとも記載されているバージョンに Gradle をアップグレードします。 選択した AGP バージョンをサポートするバージョンに Android Studio をアップグレードします。 使用する Android SDK をサポートしている Android Studio と AGP のバージョンを使用します。 SDK ビルドツール、NDK、JDK との互換性を確認します。 AGP のデータを拡張または使用する Gradle プラグイン（内部または一般公開）を開発する場合は、プラグインをアップグレードする必要があるかどうかを確認します。AGP が非推奨になり、その後 API が削除されることがあります。その場合、以前のプラグインとの互換性が失われます。
Kotlin コンパイラ、言語、ランタイム	既知の問題と互換性については、Kotlin リリースノートをご覧ください。 Jetpack Compose を使用する場合: 新しい Kotlin のバージョンが 2.0.0 より前の場合: 互換性のある Compose コンパイラ プラグインを見つけます。 kotlinCompilerExtensionVersion が存在するモジュールの build.gradle.kts で kotlinCompilerExtensionVersion をアップグレードします。 新しい Kotin のバージョンが 2.0.0 以降の場合: Kotlin コンパイラと同じバージョンの Compose Compiler Gradle プラグインを設定します。 Kotlin Symbol Processing（KSP）を使用している場合は、設定については KSP クイックスタート、利用可能なバージョンについては KSP リリースをご覧ください。Kotlin のバージョンと一致する KSP のバージョンを使用する必要があります。たとえば、Kotlin 2.0.21 を使用している場合は、2.0.21 で始まる KSP プラグインの任意のバージョン（2.0.21-1.0.25 など）を使用できます。通常、KSP プロセッサ（ビルドファイルに ksp 依存関係として表示される Room コンパイラなど）をアップグレードする必要はありません。KSP プラグインはコンパイラ API の大部分を抽象化しており、プロセッサで使用される KSP API は安定しています。 使用している他のすべての Kotlin コンパイラ プラグインをアップグレードします。Kotlin Compiler Plugin API はリリース間で頻繁に変更されるため、プラグインでは互換性のある API を使用する必要があります。プラグインが [コンパイラ プラグイン] に表示されている場合は、Kotlin コンパイラと同じバージョンを使用する必要があります。他のコンパイル プラグインについては、適切なマッピングについてドキュメントを確認してください。 Kotlin コンパイラ自体と一緒にメンテナンスされていないコンパイラ プラグインは、コンパイラ プラグイン API が安定するまで待機するため、リリースが遅れることがあります。Kotlin をアップグレードする前に、使用しているすべてのコンパイラ プラグインに対応するアップグレードを利用できることを確認してください。 最後に、Kotlin 言語が変更され、コードを更新しなければならない場合もあります。この現象は、試験運用版の機能を試している場合によく発生します。Kotlin コンパイラをアップグレードした後にコードが正しくビルドされない場合は、Kotlin リリースノートで言語の変更やランタイム ライブラリの破損を確認してください。
Kotlin コンパイラ プラグイン	Kotlin コンパイラ プラグインをアップグレードする必要がある場合は、使用している Kotlin の一致するバージョンにアップグレードしてください。 ほとんどの Kotlin コンパイラ プラグインは、Kotlin コンパイラと同じバージョンを使用するか、必要なバージョンの Kotlin コンパイラから開始します。たとえば、プラグインのバージョンが 2.0.21 ～ 1.0.25 の場合、Kotlin コンパイラのバージョン 2.0.21 を使用する必要があります。 Kotlin コンパイラ バージョンを変更する際に、他の変更が必要になることがあります。
ライブラリ	ライブラリは、ビルドで最も頻繁にアップグレードされる依存関係です。利用可能なアップグレードは、Android Studio エディタまたは依存関係ツールとプラグインを使用している場合に表示されます。 一部のライブラリでは、ライブラリの使用に必要な最小の compileSdk または minSdk が指定されています。少なくとも指定された compileSdk を使用しないと、ビルドは失敗します。ただし、アプリケーションの minSdk は、ライブラリの依存関係とビルドファイルで指定されたすべての minSdk 値の最大値に自動的に設定されます。 一部のライブラリでは、使用する Kotlin の最小バージョンも指定されています。ビルドファイル内の Kotlin のバージョンを、少なくとも指定されたバージョンに更新します。
Gradle	Gradle の新しいバージョンで既存の API が非推奨になり、今後のリリースで削除される場合があります。Gradle プラグインを開発する場合、特にそのプラグインが公開されている場合は、できるだけ早くプラグインをアップグレードしてください。 Gradle のアップグレードによっては、使用しているプラグインの新しいバージョンを探す必要があります。これらのプラグインは、最新の Gradle プラグイン API に合わせてプラグインをアップグレードするため、開発が遅れる場合があります。 Gradle をアップグレードするには: 使用するバージョンのリリースノートをご覧ください。 gradle/wrapper/gradle-wrapper.properties の Gradle バージョンをアップグレードします。 ./gradlew wrapper --gradle-version latest を実行して、Gradle ラッパー jar とスクリプトをアップグレードします。 Gradle プラグインをアップグレードします。 Gradle の実行に使用される JDK をアップグレードします。
Gradle プラグイン	アップグレードされた Gradle プラグインは、新しい Gradle API または変更された Gradle API を使用することがあります。その場合、Gradle のアップグレードが必要になる場合や、ビルドファイルの構成を変更する必要がある場合があります。いずれの場合も、非互換性を示すビルドの警告またはエラーが表示されます。 プラグインをアップグレードするときは、必ず Gradle もアップグレードしてください。
Android SDK	Android Studio には、これらのタスクに役立つ Android SDK アップグレード アシスタントが含まれています。 アシスタントを使用する場合や、アップグレードを手動で行う場合は、次の点を考慮してください。 Android SDK の各リリースには、新機能と API、バグの修正、動作の変更が含まれています。Google Play ストアではtargetSdk の更新が必要ですが、必要に応じて変更を行う時間を確保できるよう、期限より前に targetSdk を更新することをおすすめします。 Android SDK をアップグレードする前に、リリースノートをよくお読みください。以下のような動作変更のセクションに注意してください。 インストール時または実行時にリクエストする必要がある新しい権限。 非推奨の API とその代替 API。 API または動作の互換性を破る変更。 新しい Kotlin API または Java API。コードに影響する可能性があります。 [動作の変更] セクションは非常に長くなることがありますが、アプリに行う必要がある重要な変更が含まれていることが多いので、注意深く確認してください。 Google Play ストアの要件を満たすように targetSdk をアップグレードする必要があります。compileSdk のアップグレードは任意で、新しい API にアクセスできるようになります。なお、AndroidX などの一部のライブラリには、compileSdk の最小要件が含まれています。 開発中に新しい SDK 機能を活用し、ビルド中に互換性を確保するには、Android Gradle プラグイン（AGP）と Android Studio をアップグレードしてください。これには、新しい SDK 向けの新しいツールや改善されたツールが含まれます。Android API レベルをサポートするツールの最小バージョンをご覧ください。 Android SDK をアップグレードする際は、使用している AndroidX ライブラリもアップグレードしてください。AndroidX では、Android SDK バージョン間の互換性とパフォーマンスを向上させるために、新しい API と更新された API を頻繁に使用します。
Android Studio	通常、Android Studio はいつでもアップグレードできます。AGP をアップグレードまたは Android SDK をアップグレードするよう求めるメッセージが表示されることがあります。これらのアップグレードは強く推奨されますが、必須ではありません。 後で Android Studio を使用して AGP または Android SDK をアップグレードする場合は、[ツール] メニューで次のオプションを使用できます。 AGP Upgrade Assistant… Android SDK Upgrade Assistant
Java	Android アプリに Java ソースコードがある場合は、新しい Java API を利用できます。 各 Android SDK バージョンは、Java API のサブセットと言語機能をサポートしています。AGP は、脱糖と呼ばれるプロセスを使用して、以前の Android SDK バージョンとの互換性を提供します。 Android SDK のリリースノートには、サポートされている Java レベルと潜在的な問題が記載されています。Kotlin は同じ Java API にアクセスできるため、これらの問題の一部は Kotlin ソースコードにも影響する可能性があります。Java ソースコードがなくても、リリースノートの動作の変更に関するセクションに記載されている JDK API のセクションに注意してください。 JDK の使用は、ビルド スクリプトの複数の場所で指定されます。詳細については、Android ビルドの Java バージョンをご覧ください。

アップグレード分析

依存関係をアップグレードすると、API や動作の変更、新しい使用要件、新しいセキュリティ問題、ライセンスの変更などのリスクが生じる可能性があります。たとえば、次のようなことをする必要がありますか？

• API の変更に合わせてコードを変更する必要があるか
• 新しい権限チェックを追加する
• 動作変更のために追加のテストを作成するか、既存のテストを変更する

アップグレードした依存関係が、その依存関係のバージョンをアップグレードしたことを検討してください。これにより、すぐに大規模な変更にまで及ぶことがあります。

Renovate や Dependabot などのツールを使用してアップグレードを自動化する場合は、分析は行われないことに注意してください。これらのツールは最新のライブラリ バージョンにアップグレードされます。このような自動アップグレード後にすべてが正常に動作すると想定しないでください。

アップグレードを成功させる鍵は、アップグレード分析です。

1. アップグレード前後の依存関係の違いを特定します。
2. 各変更を調べ、関連するリスクを特定します。
3. リスクを軽減する、変更を承認または拒否する。

依存関係の違いを確認する

アップグレード分析の最初のステップは、依存関係の変更方法を特定することです。バージョン管理（VCS、Git など）と Dependency Guard プラグインを使用して、変更をすばやく確認します。目標は、変更前と適用後のスナップショットを作成して比較することです。

最初のベースラインを設定して作成する

アップグレードを開始する前に、プロジェクトが正常にビルドされていることを確認します。

理想的には、できるだけ多くの警告を解決するか、ベースラインを作成して、すでに表示された警告を追跡します。

• Lint: 既存の lint 警告を調べて、Android lint ベースラインを作成します。
• Kotlin コンパイラ:
  • -Werror を有効にして、すべての警告をエラーとして扱います。オプションを定義する方法をご覧ください。
  • Kotlin Warning Baseline や Kotlin Warnings Baseline Generator などのプラグインの使用を検討してください。
• その他のツール: ベースライン トラッキングをサポートする他の静的分析ツール（Detekt など）を使用している場合は、ベースラインを設定します。

これらの警告ベースラインにより、依存関係のアップグレード時に導入された新しい警告を簡単に確認できます。

Dependency Guard を設定して実行し、依存関係ベースラインを作成します。gradle/libs.versions.toml バージョン カタログに、以下を追加します。

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

アプリのビルドファイルに次のコードを追加します。

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

releaseRuntimeClasspath 構成がターゲットの可能性がありますが、別の構成を使用する場合は、リストされている構成をビルドファイルに含めずに ./gradlew dependencyGuard を実行すると、使用可能なすべての構成が表示されます。

設定後、./gradlew dependencyGuard を実行して app/dependencies/releaseRuntimeClasspath.txt にレポートを生成します。これがベースライン レポートです。これをバージョン管理システム（VCS）に commit して保存します。

Dependency Guard はライブラリの依存関係のリストのみをキャプチャします。ビルドファイルには、Android SDK や JDK のバージョンなど、他の依存関係もあります。依存関係が変更される前に VCS に commit すると、VCS の diff でそれらの変更もハイライト表示されます。

アップグレードしてベースラインと比較する

ベースラインができたら、テストする依存関係とその他のビルド変更をアップグレードします。この時点では、ソースコードやリソースをアップグレードしないでください。

./gradlew lint を実行して、新しい lint の警告またはエラーを確認します。重要な問題に対処したら、./gradlew lint -Dlint.baselines.continue=true を実行して警告ベースラインを更新します。Kotlin Warning Baseline や Kotlin Warnings Baseline Generator など、他のツールを使用して警告ベースラインをキャプチャしている場合は、新しい警告に対処し、ベースラインも更新します。

./gradlew dependencyGuard を実行してベースライン レポートを更新します。次に、VCS の diff を実行して、ライブラリ以外の変更を確認します。想定よりも多くのライブラリのアップグレードが含まれる可能性があります。

リスクを分析する

変更内容を確認したら、アップグレードされた各ライブラリに潜在的なリスクがあるかどうかを検討します。これにより、テストの対象を絞ったり、変更を詳しく調査したりできます。プロジェクトで分析する一連のリスクを定義して、一貫した分析を実現します。

考慮事項:

メジャー バージョンのアップグレード	メジャー バージョン番号は変更されましたか？ セマンティック バージョニングでは、最初の数字がメジャー バージョンと呼ばれます。たとえば、ライブラリのバージョンが 1.2.3 から 2.0.1 にアップグレードされた場合、メジャー バージョンは変更されます。これは通常、ライブラリ デベロッパーがバージョン間で互換性のない変更（API の一部を削除または変更するなど）を加えたことを意味します。 この場合、次の考慮事項を確認する際に、影響を受けるライブラリに特に注意してください。 試験運用版の API（多くの場合、アノテーションやビルドファイルの仕様を使用してオプトインする必要があります）をコードで使用している場合、1.2.3 から 1.3.1 や 1.2.3 から 1.2.5 へのアップグレードなど、マイナー バージョンの変更やパッチ バージョンの変更でさえ、さらにリスクが生じる可能性があります。
安定性のない API	一部のライブラリ リリースには、安定性のない API が含まれている場合があります。通常、これらは開発中または別の不安定な API に依存する API です。 通常はアルファ版、開発版、試験運用版などのプレビューに限定されますが、一部のライブラリには試験運用版または不安定な API が含まれています。 可能であれば、このような API は使用しないでください。使用が必要な場合は、使用状況を記録し、今後のリリースでの変更や削除に注意してください。
動的動作	一部のライブラリは、外部要因によって動作が異なります。たとえば、サーバーと通信するライブラリは、そのサーバーの変更に依存します。 ライブラリは特定のサーバー バージョンと一致する必要がありますか？ ライブラリは異なるバージョンのサーバーに接続できますか？ ライブラリの適切な動作に影響するその他の外部要因はありますか？
マニフェストのマージ	Android アーカイブ（AAR）として公開されたライブラリには、アプリに統合されるリソースとマニフェストを含めることができます。これにより、新しい権限や、間接的に実行される Android コンポーネント（アクティビティやブロードキャスト レシーバーなど）を追加できます。
ランタイムの更新	一部のライブラリでは、アプリケーションの制御外で更新される機能が使用されています。ライブラリで Play 開発者サービスを使用できます。Play 開発者サービスは、Android SDK とは独立してアップグレードされます。他のライブラリは、独立して更新される外部アプリケーションのサービスにバインドする場合があります（多くの場合、AIDL を使用）。
スキップするバージョンの数	ライブラリのアップグレードを遅らせれば遅らせるほど、潜在的なリスクは高まります。バージョンが大幅に変更されている場合（1.2.3 から 1.34.5 など）は、このライブラリに特に注意してください。
移行ガイド	ライブラリに移行ガイドがあるかどうかを確認します。これにより、リスク分析とリスク軽減計画を大幅に削減できます。 このようなガイドがあれば、デベロッパーが互換性を重視しており、アップグレードの軽減を検討していることを示す良い指標となります。
リリースノート	変更された各ライブラリについては、リリースノート（提供されている場合）をご覧ください。互換性を破る変更や、追加された権限などの新しい要件の兆候を探します。
README	ライブラリの README ファイルには、ライブラリにリリースノートが提供されていない場合など、潜在的なリスクが記載されている場合があります。既知の問題（特に既知のセキュリティ上の懸念事項）を確認します。
既知の脆弱性を確認する	Play SDK Index では、一般的な多くの SDK の脆弱性を追跡しています。Google Play Console には、既知の脆弱性があるリスト内の SDK のいずれかを使用しているかどうかが表示されます。Android Studio でビルドファイルを編集すると、IDE は SDK インデックスをチェックし、脆弱性のあるライブラリ バージョンの使用を報告します。 米国国立標準技術研究所（NIST）は、大規模なNational Vulnerability Database（NVD）を維持しています。Dependency Check Gradle プラグインは、使用されている依存関係を NVD と照合します。 依存関係チェックを使用するには、NVD API キーをリクエストし、Gradle プラグインを設定して、./gradlew dependencyCheckAnalyze を実行します。実行には時間がかかることがあります。
バージョンの競合	バージョンは想定どおりに解決されますか？競合、特にメジャー バージョンの違いがないか確認します。競合を検索する方法について詳しくは、Gradle の依存関係解決をご覧ください。特に、./gradlew app:dependencies レポートで -> を検索します。 可能であれば、依存関係の作成者と協力して、依存関係の競合を回避します。可能な場合は、ライブラリの変更（アップストリーム）を行って、ライブラリの互換性の向上にご協力ください。
ライセンスをチェックする	ライブラリをアップグレードする際に、ライセンスの変更がないか確認してください。ライブラリ自体が、アプリやライブラリと互換性がなくなったライセンスに変更される可能性があります。新しい伝播依存関係によって、互換性のないライセンスが導入される可能性もあります。依存関係全体の現在のライセンス セットを確認する方法については、ライセンスを検証するをご覧ください。
メンテナンスと 品質のリスク	公開リポジトリがあるライブラリの場合: 何人の寄稿者がライブラリを管理しているか。 前回アップグレードしたのはいつですか？また、ライブラリはどのくらいの頻度で変更されていますか？ 問題のバックログ（利用可能な場合）はどのようなものですか？ざっと目を通して、ライブラリの潜在的な問題と技術的負債を把握します。 単体テストがライブラリをどれだけカバーしているか コードベースに既知のアンチパターンはありますか？ ライブラリは適切に文書化されていますか？ コードベースに _fixme_ コメントが多数含まれていますか？
オープン ソースとクローズド ソースの比較	ライブラリがオープンソースであれば、問題がコード内にあるかライブラリ コード内にあるかにかかわらず、クローズドソースの場合よりも問題をデバッグしやすくなります。 クローズドソースの依存関係を最小限に抑え、評価時に追加の精査を適用します。ユースケースに適した代替手段はありますか？クローズドソース ライブラリで利用できるサービスレベル契約は何ですか？クローズドソースの依存関係を使用する場合は、リスクを軽減するために追加のテストケースを作成できるようにしてください。

ビルドを実行する

プロジェクトをビルドします。新しいエラーや警告がないか確認します。どのライブラリが原因となっているか特定できる場合は、そのライブラリのアップグレードのリスクとして記録します。

新しい非推奨警告が表示された場合は、それらを生成したライブラリの特定のリスクとして追加します。これらの機能は、今後のリリースで削除される可能性があります。そのライブラリを引き続き使用する場合、非推奨の API から置き換え API への変換に時間を割くか、非推奨の API をメモして、それらの関数と後で削除されるかどうかを常に確認してください。

lint を使用して API の問題を検出する

Android lint は、依存関係や Android SDK のバージョン変更が原因の一部の問題など、アプリの多くの問題を検出できます。たとえば、compileSdk をアップグレードして新しい API を使用すると、以前の SDK バージョンでは使用できない API が lint によって報告されます。

lint は Android Studio エディタで動作し、変更を加えると問題を報告します。 ただし、build ターゲットまたは lint ターゲットを使用しない限り、通常は Studio のビルドの一部として実行されません。また、コマンドライン ビルドの実行時にも、ビルドは実行されません。

継続的インテグレーション（CI）を使用している場合は、CI ビルド中（または少なくともナイトリー ビルド中）に gradlew build または gradlew lint を実行して、このようなエラーを検出します。

CI を使用していない場合は、少なくとも時折 gradlew lint を実行してください。

注: 一般的な lint ルールと Android SDK レベルの lint ルールは AGP で提供され、ライブラリ固有のルールはライブラリにパッケージ化されています。AGP とライブラリの依存関係をできるだけ最新の状態に保ち、最新の lint ルールがコードに適用されるようにします。これは、新しい Android SDK バージョン用に追加またはアップグレードされた新しい lint ルールの場合に特に重要です。

lint のエラーと警告には特に注意してください。一部のライブラリには、独自の lint チェックが付属しており、API の適切な使用を確保できます。新しいバージョンのライブラリには、新しい lint の警告とエラーが含まれるため、ビルド時に新しいレポートが作成されます。

リスクの軽減

アップグレードのリスクを特定したら、リスクを軽減する方法を選択します。

• リスクの一部はそのまま受け入れる。一部のリスクは、特にアップグレード時間とリソースが限られている場合は、許容できるほど低い場合があります。
• リスクによっては、完全に拒否することもできます。アップグレードによっては、特にこの時点でリスクを軽減するための時間やリソースが限られている場合は、リスクが高すぎると感じることがあります。優先度付けが必要な場合は、発生したバグや必要な新機能に必要なアップグレードに重点を置きます。
• 残りのリスクを軽減する
  • アップグレードを小さな独立した変更セットにバッチ処理することを検討してください。これにより、全体的なリスクが軽減され、部分的なロールバックが可能になります。
  • 変更を詳しく調査します。
  • アプリをテストして、予期しない変更がないか確認します。アップグレードの信頼性を高めるために必要な場合は、新しいテストを追加します。
  • 疑わしい内容が見つかった場合は、出典（利用可能な場合）を確認します。
  • ソースまたはビルドに必要な変更を加えます。

決定内容を記録します。アプリケーションの実行時にアップグレードによるリスクが問題になった場合は、リスク分析を文書化することで、必要なエラー分析を減らすことができます。

ライセンスを検証する

ライブラリ デベロッパーは、ライブラリをライセンス供与して使用できるようにしています。ライセンスの条件に準拠する必要があります。準拠していない場合、ライブラリを使用できません。一部のライセンスは非常に許容範囲が広く、多くの場合、ライブラリの帰属とライセンスのテキストをエンドユーザーに表示することのみを要求します。中にはクチコミとみなされるものもあります。そうしたライブラリを使用する場合は、アプリまたはライブラリに同じライセンスを適用する必要があります。

ライセンスはどのリリースでも変更可能です。アップグレードするときは、使用している依存関係がアプリまたはライブラリと互換性のあるライセンスになっていることを確認する必要があります。

ライセンスに互換性がない場合（または互換性が失われたライセンスの場合）、そのバージョンのライブラリは使用できません。次の設定が可能です。

• ライブラリ オーナーに連絡し、既存のライセンスの継続またはデュアル ライセンス（古いライセンスを継続して許可）をリクエストします。
• 法務チームと連携して、ライセンスを互換性のあるものに変更できるかどうかを判断します。
• 互換性のあるライセンスを持つ別のライブラリを見つけて、必要に応じてアプリを変更します。
• 互換性のある最新バージョンのライブラリをフォークし（そのライセンスが派生物を許可し、変更が遡及的でない場合に限る）、独自の変更を加えます。