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

依存関係をアップグレードすると、最新の機能、バグの修正、改善を利用できます。依存関係をアップグレードするには、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 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 コンパイラ プラグイン 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 を 1 つ以上使用しないと、ビルドは失敗します。ただし、アプリケーションの 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 または 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 をアップグレードする場合は、[ツール] メニューで次のオプションを使用できます。

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 プラグインを使用して、変更をすばやく確認します。目的は、前と後のスナップショットを作成して比較することです。

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

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

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

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

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 警告ベースラインや Kotlin 警告ベースライン ジェネレータなど、他のツールを使用して警告ベースラインをキャプチャした場合は、新しい警告に対処し、ベースラインも更新します。

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

リスクを分析する

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

考慮事項:

メジャー バージョンのアップグレード

メジャー バージョン番号は変更されましたか？

セマンティック バージョニングでは、最初の数字がメジャー バージョンと呼ばれます。たとえば、ライブラリのバージョンが 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 コンポーネント（アクティビティやブロードキャスト レシーバなど）を追加できます。

ランタイムの更新

一部のライブラリでは、アプリケーションの制御外で更新される機能が使用されています。ライブラリが Google 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 と照合します。

Dependency Check を使用するには、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 エディタで実行され、変更を加えると問題を報告します。ただし、通常、Studio でのビルドの一部として、またはコマンドライン ビルドを実行するときには、build ターゲットまたは lint ターゲットを使用しない場合は実行されません。

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

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

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

リスクの軽減

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

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

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

ライセンスを検証する

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

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

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

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