Abhängigkeitsversionen upgraden

Wenn Sie Ihre Abhängigkeiten aktualisieren, erhalten Sie Zugriff auf die neuesten Funktionen, Fehlerkorrekturen und Verbesserungen. Wenn Sie Ihre Abhängigkeiten aktualisieren möchten, müssen Sie wissen, wie Gradle die von Ihnen angeforderten Versionen auflöst, welche Risiken damit verbunden sind und welche Schritte Sie unternehmen können, um diese Risiken zu minimieren.

Umstellungsstrategie berücksichtigen

Der wichtigste Schritt bei jeder Umstellung ist die Risikoanalyse. Überlegen Sie, wie sicher Sie sich bei jeder Abhängigkeit sind, die Sie aktualisieren. Beim Definieren der Upgradestrategie sind viele Überlegungen zu beachten, darunter:

Bibliothek erstellen

Erstellen Sie eine Anwendung, die Nutzer herunterladen und auf einem Gerät ausführen können? Oder erstellen Sie eine Bibliothek, um anderen Entwicklern beim Erstellen ihrer Anwendungen zu helfen?

Bei der Entwicklung einer Anwendung liegt der Fokus darauf, sie aktuell und stabil zu halten.

Wenn Sie eine Bibliothek erstellen, sollten Sie sich auf die Anwendungen anderer Entwickler konzentrieren. Ihre Upgrades wirken sich auf Ihre Kunden aus. Wenn Sie eine Ihrer Abhängigkeiten aktualisieren, wird diese Version für die Abhängigkeitsauflösung von Gradle als Kandidat ausgewählt. Dies kann dazu führen, dass die Anwendung diese Abhängigkeit nicht mehr verwenden kann.

Minimieren Sie zuerst nach Möglichkeit die Abhängigkeiten Ihrer Bibliothek. Je weniger Abhängigkeiten Sie haben, desto geringer ist die Auswirkung auf die Abhängigkeitsauflösung Ihrer Verbraucher.

Beachten Sie das semantische Versionskontrollsystem, um die Art der Änderungen anzugeben. AndroidX folgt beispielsweise der semantischen Versionsverwaltung und fügt ein Schema zur Versionsverwaltung vor der Veröffentlichung hinzu. Vermeide Upgrades der major-Version, damit deine Kunden nicht gestört werden.

Sie können einen Release-Kandidaten (RC) Ihrer Bibliothek erstellen, den Nutzer frühzeitig testen können.

Weitere Informationen zur Abwärtskompatibilität der Application Binary Interface (ABI) Ihrer Bibliothek finden Sie in den Richtlinien zur Abwärtskompatibilität für Bibliotheksautoren. Verwenden Sie Integrationstests und Tools wie den Binary Compatibility Validator, um sicherzustellen, dass Ihre ABI-Änderungen mit der beabsichtigten Versionsänderung übereinstimmen.

Wenn Sie Fehlerkorrekturen in einer patch-Version für niedrigere Versionen Ihrer Bibliothek veröffentlichen, müssen Ihre Nutzer die Bibliothek nicht auf die nächste major- oder minor-Version aktualisieren, es sei denn, sie benötigen neue Funktionen. Führen Sie bei diesen Upgrades keine transitiven Abhängigkeiten ein.

Wenn für das Upgrade Ihrer Bibliothek bahnbrechende Änderungen erforderlich sind, die für Ihre Nutzer besonders schwierig sein können, sollten Sie sie als neues Artefakt veröffentlichen, damit die alte und die neue Version nebeneinander existieren und ein allmählicher Roll-out möglich ist.

Hinweis: Wenn ein Upgrade auf eine Ihrer Abhängigkeiten eine größere API-Änderung enthält, sollten Sie es in einer major- oder minor-Version durchführen und alle erforderlichen Änderungen vornehmen. Andernfalls tun dies möglicherweise Nutzer Ihrer Bibliothek, was zu Inkompatibilitäten zwischen Ihrer Bibliothek und dieser Abhängigkeit führen kann. Das kann auch dann passieren, wenn sich Ihre Bibliothek nicht geändert hat. Sie können eine neue Version veröffentlichen, nur um diese Abhängigkeit zu aktualisieren.

Release-Zyklus

Wie oft veröffentlichen Sie Ihre Anwendung oder Bibliothek?

Kürzere Entwicklungs- und Veröffentlichungszyklen

  • Schnellere Umstellung.
  • Sie können schnell ins Hintertreffen geraten.
  • Häufige kleine Upgrades können die Arbeitslast entlasten.
  • Wenn ein Bibliotheksupgrade zu Problemen führt, können Sie es schneller rückgängig machen.
  • Tools wie Dependabot und Renovate können den Arbeitsaufwand verringern. Analysieren Sie die Ergebnisse jedoch unbedingt auf Risiken.

Längere Entwicklungs- und Releasezyklen

  • Sie haben jetzt mehr Zeit, Upgrades durchzuführen und zu testen.
  • Neuere Versionen von Abhängigkeiten werden mit höherer Wahrscheinlichkeit während Ihres Zyklus veröffentlicht.
  • Das Zurückrollen von Upgrades und das Veröffentlichen Ihrer Anwendung oder Bibliothek dauert länger.

Über die neuesten Funktionen auf dem Laufenden bleiben

Verwenden Sie lieber die neuesten verfügbaren Funktionen und APIs oder führen Sie nur ein Upgrade durch, wenn Sie eine Funktion oder Fehlerkorrektur benötigen?

Berücksichtigen Sie die Vor- und Nachteile häufiger Upgrades. Künftige Upgrades sind einfacher (weniger Änderungen müssen integriert werden), aber Sie gehen häufiger Risiken ein.

Wenn Sie Upgrades auf Vorabversionen (Alpha-, Beta- oder Release-Kandidat) von Bibliotheken testen, können Sie besser vorbereitet sein, wenn stabile Releases verfügbar sind.

Neue Abhängigkeit

Wenn Sie eine neue Abhängigkeit hinzufügen, sollten Sie einen soliden Überprüfungsprozess in Betracht ziehen, bei dem diese Bibliothek auf alle Risikokriterien untersucht wird, um sicherzustellen, dass sie ordnungsgemäß evaluiert wurden. Neue Abhängigkeiten dürfen nicht ohne Überprüfung hinzugefügt werden.

Ein engagiertes Team

Haben Sie ein eigenes Build-Team? Pflegen Ihre Softwareentwickler den Build? Ein spezielles Team kann oft mehr Zeit darauf verwenden, die Risiken von Upgrades zu analysieren und neue Versionen zu testen, um sicherzustellen, dass der Build ordnungsgemäß funktioniert, bevor die Entwickler die neuen Versionen verwenden.

Art des Upgrades

Einige Upgrades sind wichtiger als andere. Überlegen Sie, welche für Sie am wichtigsten sind.

Upgrades von Build-Tools wie Gradle und Gradle-Plug-ins haben in der Regel weniger Auswirkungen auf Ihre Nutzer und die meisten Risiken sind intern für Ihren Build. Der Build selbst hilft dabei, diese Änderungen zu validieren. Bibliotheks- und SDK-Upgrades sind schwieriger zu validieren und stellen ein höheres Risiko für Ihre Nutzer dar.

Android-Gradle-Plug-in (AGP): Das Tool, mit dem Sie Ihre Android-App oder -Bibliothek erstellen können. Dies ist das wichtigste Upgrade, da es oft Leistungsverbesserungen, Fehlerkorrekturen, neue Lint-Regeln und Unterstützung für neue Android-Plattformversionen enthält oder aktiviert.

Gradle: Wenn Sie AGP oder ein anderes Gradle-Plug-in aktualisieren, müssen Sie häufig Gradle aktualisieren.

Andere Gradle-Plug-ins: Manchmal ändert sich die Plug-in-API von Gradle. Wenn Sie Gradle aktualisieren, prüfen Sie, ob es Upgrades für die von Ihnen verwendeten Plug-ins gibt.

Kotlin und Java: Für einige Bibliotheken und Plug-ins sind Mindestversionen von Kotlin oder Java erforderlich oder Sie möchten neue Sprachfunktionen, APIs oder Leistungsverbesserungen nutzen.

Android-Plattform: Für den Play Store sind regelmäßige Android SDK-Upgrades erforderlich. Sie sollten neue Versionen des Android SDK so schnell wie möglich testen. Einige SDK-Upgrades erfordern Änderungen an Ihrer App, z. B. neue Berechtigungen oder die Verwendung neuer APIs.

Bibliotheken: Sollen Bibliotheken anhand ihrer Nähe zur Gesamtarchitektur priorisiert werden?

  • Plattform- und architekturbezogene Bibliotheken wie AndroidX ändern sich häufig, um neue Funktionen zu nutzen oder Änderungen auf der Plattform zu abstrahieren. Aktualisieren Sie diese Bibliotheken mindestens dann, wenn Sie die Android-Plattform oder andere architektonische Bibliotheken aktualisieren.
  • Andere Bibliotheksupgrades können auf mehrere Zeiträume verteilt oder verzögert werden, es sei denn, Sie benötigen eine neue Funktion oder bestimmte Fehlerkorrekturen.

Android Studio: Wenn Sie Android Studio auf dem neuesten Stand halten, erhalten Sie Zugriff auf die neuesten Funktionen und Fehlerkorrekturen in der zugrunde liegenden IntelliJ IDEA-Plattform und auf Tools zur Arbeit mit den neuesten Android SDKs.

Verfügbare Tools

Es gibt viele Tools und Plug-ins, die Sie bei Upgrades unterstützen können. Mit Tools wie Dependabot und Renovate werden Bibliotheksversionen in Ihrem Build automatisch aktualisiert. Sie sollten die Ergebnisse jedoch auf Risiken prüfen.

Strategien für bestimmte Arten von Upgrades

Das Upgrade einiger Abhängigkeitstypen kann eine Kaskade auslösen, bei der auch andere Abhängigkeitstypen aktualisiert werden müssen. Beziehungen zwischen Build-Elementen werden unter Tool- und Bibliotheksabhängigkeiten erläutert.

Abhängigkeiten und deren Beziehungen aufbauen
Abbildung 1: Beziehungen aufbauen.

Berücksichtigen Sie beim Upgrade der einzelnen Komponenten, wie sich das Upgrade auf andere Komponenten im Build auswirkt.

Android-Gradle-Plug-in (AGP)

Android Studio enthält einen AGP-Upgrade-Assistenten, der Sie bei diesen Aufgaben unterstützen kann.

Wenn Sie den Assistenten verwenden oder das Upgrade manuell durchführen, beachten Sie Folgendes:

Sehen Sie sich die AGP-Versionshinweise an.

Führen Sie ein Upgrade von Gradle auf mindestens die angegebene Version durch.

Führen Sie ein Upgrade von Android Studio auf eine Version durch, die die ausgewählte AGP-Version unterstützt.

Verwenden Sie Versionen von Android Studio und AGP, die das von Ihnen verwendete Android SDK unterstützen.

Prüfen Sie die Kompatibilität mit SDK Build Tools, NDK und JDK.

Wenn Sie ein Gradle-Plug-in (für interne oder öffentliche Nutzung) entwickeln, das Daten aus AGP erweitert oder verwendet, prüfen Sie, ob Sie Ihr Plug-in aktualisieren müssen. Manchmal werden APIs verworfen und später entfernt. Dies führt zu Inkompatibilitäten mit früheren Plug-ins.

Kotlin-Compiler, -Sprache und -Laufzeit

In den Kotlin-Versionshinweisen finden Sie Informationen zu bekannten Problemen und Inkompatibilitäten.

Wenn Sie Jetpack Compose verwenden:

  • Wenn die neue Kotlin-Version niedriger als 2.0.0 ist:
    • Suchen Sie das kompatible Compose-Compiler-Plug-in.
    • Führen Sie ein Upgrade von kotlinCompilerExtensionVersion in den build.gradle.kts aller Module durch, in denen es angezeigt wird.
  • Wenn die neue Kotin-Version 2.0.0 oder höher ist:

Wenn Sie Kotlin Symbol Processing (KSP) verwenden, finden Sie unter KSP-Schnellstart Informationen zur Einrichtung und unter KSP-Releases Informationen zu den verfügbaren Versionen. Sie müssen eine Version von KSP verwenden, die mit der Kotlin-Version übereinstimmt. Wenn Sie beispielsweise Kotlin 2.0.21 verwenden, können Sie jede Version des KSP-Plug-ins verwenden, die mit 2.0.21 beginnt, z. B. 2.0.21-1.0.25. Normalerweise müssen Sie die KSP-Prozessoren nicht aktualisieren (z. B. den Room-Compiler, der in Ihren Build-Dateien als ksp-Abhängigkeit angezeigt wird). Das KSP-Plug-in abstrahiert einen Großteil der Compiler-API und die von den Prozessoren verwendete KSP-API ist stabil.

Führen Sie ein Upgrade für alle anderen von Ihnen verwendeten Kotlin-Compiler-Plug-ins durch. Die Kotlin Compiler Plugin API ändert sich häufig zwischen den Releases und die Plug-ins müssen eine kompatible API verwenden. Wenn das Plug-in in den Compiler-Plug-ins aufgeführt ist, müssen Sie dieselbe Version wie der Kotlin-Compiler verwenden. Informationen zur Zuordnung für andere Kompilierungs-Plug-ins finden Sie in der jeweiligen Dokumentation.

Compiler-Plug-ins, die nicht zusammen mit dem Kotlin-Compiler selbst gepflegt werden, werden oft verzögert veröffentlicht, da auf die Stabilisierung der Compiler-Plug-in-API gewartet werden muss. Prüfen Sie vor dem Upgrade von Kotlin, ob für alle verwendeten Compiler-Plug-ins entsprechende Upgrades verfügbar sind.

Schließlich ändert sich die Kotlin-Sprache manchmal, sodass Sie Ihren Code aktualisieren müssen. Das passiert am häufigsten, wenn Sie experimentelle Funktionen ausprobieren. Wenn Ihr Code nach dem Upgrade des Kotlin-Compilers nicht ordnungsgemäß erstellt wird, prüfen Sie in den Kotlin-Versionshinweisen, ob Änderungen an der Sprache oder Fehler in der Laufzeitbibliothek funktionieren.

Kotlin-Compiler-Plug-ins

Wenn Sie ein Kotlin-Compiler-Plug-in aktualisieren müssen, führen Sie ein Upgrade auf die entsprechende Version von Kotlin aus.

Die meisten Kotlin-Compiler-Plug-ins verwenden entweder dieselbe Version wie der Kotlin-Compiler oder sie starten mit der erforderlichen Version des Kotlin-Compilers. Wenn die Plug-in-Version beispielsweise 2.0.21-1.0.25 ist, müssen Sie Version 2.0.21 des Kotlin-Compilers verwenden.

Wenn Sie die Kotlin-Compilerversion ändern, sind manchmal weitere Änderungen erforderlich.

Bibliotheken

Bibliotheken sind die am häufigsten aktualisierte Abhängigkeit in Ihrem Build. Verfügbare Upgrades werden im Android Studio-Editor oder bei Verwendung einiger Abhängigkeitstools und ‑Plug-ins angezeigt.

Für einige Bibliotheken ist ein Mindestwert für compileSdk oder minSdk erforderlich, um die Bibliothek verwenden zu können. Wenn Sie nicht mindestens die angegebene compileSdk verwenden, schlagen Ihre Builds fehl. Für minSdk Ihrer Anwendung wird jedoch automatisch der Maximalwert aller minSdk-Werte festgelegt, die in Ihren Bibliotheksabhängigkeiten und Build-Dateien angegeben sind.

Einige Bibliotheken geben auch eine Mindestversion von Kotlin an, die verwendet werden muss. Aktualisieren Sie die Kotlin-Version in Ihren Build-Dateien auf mindestens die angegebene Version.

Gradle

Manchmal werden in neuen Versionen von Gradle vorhandene APIs eingestellt und in einer zukünftigen Version entfernt. Wenn Sie ein Gradle-Plug-in entwickeln, sollten Sie so schnell wie möglich ein Upgrade Ihres Plug-ins durchführen, insbesondere wenn es öffentlich ist.

Bei einigen Gradle-Upgrades müssen Sie neue Versionen der von Ihnen verwendeten Plug-ins finden. Die Entwicklung dieser Plug-ins kann sich verzögern, wenn sie die Plug-ins so aktualisieren, dass sie den neuesten Gradle-Plug-in-APIs entsprechen.

So führen Sie ein Gradle-Upgrade durch:

  • Lesen Sie die Versionshinweise für die Version, die Sie verwenden möchten.
  • Aktualisieren Sie die Gradle-Version in gradle/wrapper/gradle-wrapper.properties.
  • Führen Sie ./gradlew wrapper --gradle-version latest aus, um das Gradle-Wrapper-JAR und die Scripts zu aktualisieren.
  • Aktualisieren Sie Ihre Gradle-Plug-ins.
  • Führen Sie ein Upgrade des JDK aus, mit dem Gradle ausgeführt wird.

Gradle-Plug-ins

Aktualisierte Gradle-Plug-ins verwenden manchmal neue oder geänderte Gradle APIs, die wiederum ein Gradle-Upgrade oder möglicherweise Änderungen an der Konfiguration in Ihren Build-Dateien erfordern. In beiden Fällen werden Build-Warnungen oder -Fehler angezeigt, die auf Inkompatibilität hinweisen.

Führen Sie immer ein Upgrade von Gradle durch, wenn Sie Plug-ins aktualisieren.

Android SDK

Android Studio enthält einen Android SDK-Upgradeassistenten, der bei diesen Aufgaben helfen kann.

Wenn Sie den Assistenten verwenden oder das Upgrade manuell durchführen, beachten Sie Folgendes:

Jede Version des Android SDK enthält neue Funktionen und APIs sowie Fehlerkorrekturen und Verhaltensänderungen. Sie müssen Ihre targetSdk im Play Store aktualisieren. Wir empfehlen Ihnen, dies vor den Fristen zu tun, damit Sie genügend Zeit für die erforderlichen Änderungen haben.targetSdk

Lesen Sie sich vor dem Upgrade des Android SDK die Versionshinweise sorgfältig durch. Beachten Sie den Abschnitt zu Änderungen des Verhaltens, der Folgendes enthält:

  • Neue Berechtigungen, die Sie bei der Installation oder Laufzeit anfordern müssen.
  • Eingestellte APIs und ihre Ersatz-APIs
  • Funktionsgefährdende Änderungen an APIs oder am Verhalten
  • Neue Kotlin- oder Java-APIs, die sich auf Ihren Code auswirken können.

Der Abschnitt zu Verhaltensänderungen kann ziemlich lang sein. Achten Sie jedoch genau darauf, da er oft wichtige Änderungen enthält, die Sie an Ihrer Anwendung vornehmen müssen.

Sie müssen targetSdk aktualisieren, um die Play Store-Anforderungen zu erfüllen. Das Upgrade auf compileSdk ist optional und bietet Zugriff auf neue APIs. Beachten Sie, dass einige Bibliotheken wie AndroidX eine Mindestanforderung compileSdk enthalten.

Wenn Sie während der Entwicklung die neuen SDK-Funktionen nutzen und die Kompatibilität während des Builds sicherstellen möchten, aktualisieren Sie das Android-Gradle-Plug-in (AGP) und Android Studio. Dazu gehören neue und verbesserte Tools für neue SDKs. Weitere Informationen finden Sie unter Mindestversionen von Tools für Android-API-Level.

Wenn du das Android SDK aktualisierst, führe ein Upgrade aller von dir verwendeten AndroidX-Bibliotheken durch. AndroidX verwendet häufig neue und aktualisierte APIs für eine bessere Kompatibilität und Leistung bei allen Android SDK-Versionen.

Android Studio

Sie können Android Studio grundsätzlich jederzeit aktualisieren. Möglicherweise werden Sie aufgefordert, ein Upgrade auf AGP oder ein Upgrade auf das Android SDK durchzuführen. Diese Upgrades werden dringend empfohlen, sind aber nicht erforderlich.

Wenn Sie später Android Studio zum Aktualisieren des AGP oder des Android SDK verwenden möchten, finden Sie die folgenden Optionen im Menü Tools:

Java

Wenn Ihre Android-Anwendung Java-Quellcode enthält, sollten Sie die Vorteile neuerer Java APIs nutzen.

Jede Android SDK-Version unterstützt eine Untergruppe von Java APIs und Sprachfeatures. AGP bietet mithilfe eines Prozesses namens Desugaring Kompatibilität mit niedrigeren Android SDK-Versionen.

In den Versionshinweisen zum Android SDK wird angegeben, welche Java-Ebene unterstützt wird und welche potenziellen Probleme auftreten können. Einige dieser Probleme können sich auch auf Kotlin-Quellcode auswirken, da Kotlin auf dieselben Java-APIs zugreift. Lesen Sie sich die Abschnitte zur JDK-API im Abschnitt zu Verhaltensänderungen der Release Notes sorgfältig durch, auch wenn Sie keinen Java-Quellcode haben.

Die Verwendung des JDK wird an mehreren Stellen in Ihren Build-Scripts angegeben. Weitere Informationen finden Sie unter Java-Versionen in Android-Builds.

Upgrade-Analyse

Das Upgrade einer Abhängigkeit kann Risiken in Form von API- und Verhaltensänderungen, neuen Nutzungsanforderungen, neuen Sicherheitsproblemen oder sogar Lizenzänderungen mit sich bringen. Gehen Sie zum Beispiel wie folgt vor:

  • Code aufgrund von API-Änderungen ändern?
  • Neue Berechtigungsprüfungen hinzufügen?
  • Zusätzliche Tests erstellen oder vorhandene Tests auf Verhaltensänderungen hin ändern?

Beachten Sie, dass durch das Upgrade der Abhängigkeit auch die Versionen ihrer Abhängigkeiten aktualisiert wurden. Das kann schnell zu einer großen Anzahl von Änderungen führen.

Wenn Sie ein Tool wie Renovate oder Dependabot verwenden, um Ihre Upgrades zu automatisieren, werden keine Analysen für Sie durchgeführt. Es wird nur auf die neuesten Bibliotheksversionen umgestellt. Gehen Sie nicht davon aus, dass nach solchen automatischen Upgrades alles ordnungsgemäß funktioniert.

Der Schlüssel zu erfolgreichen Upgrades ist die Upgrade-Analyse:

  1. Abhängigkeitsunterschiede vor und nach den Upgrades ermitteln
  2. Prüfen Sie jede Änderung und ermitteln Sie die damit verbundenen Risiken.
  3. Sie können Risiken minimieren oder Änderungen akzeptieren oder ablehnen.

Abhängigkeitsunterschiede ermitteln

Der erste Schritt der Upgrade-Analyse besteht darin, zu bestimmen, wie sich Ihre Abhängigkeiten ändern. Nutzen Sie die Versionskontrolle (VCS, z. B. Git) und das Plug-in Dependency Guard, um Änderungen schnell zu sehen. Sie möchten einen Vorher- und einen Nachher-Snapshot erstellen und vergleichen.

Erste Referenz einrichten und erstellen

Bevor Sie mit dem Upgrade beginnen, prüfen Sie, ob Ihr Projekt erfolgreich erstellt wurde.

Beheben Sie idealerweise so viele Warnungen wie möglich oder erstellen Sie Baselines, um zu verfolgen, welche Warnungen Sie bereits erhalten haben.

Diese Warnreferenzen machen es einfacher, neue Warnungen zu sehen, die beim Upgrade Ihrer Abhängigkeiten eingeführt werden.

Erstellen Sie eine Abhängigkeitsreferenz, indem Sie Dependency Guard einrichten und ausführen. Fügen Sie im Versionskatalog gradle/libs.versions.toml Folgendes hinzu:

[versions]
dependencyGuard = "0.5.0"

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

Fügen Sie der Build-Datei Ihrer App Folgendes hinzu:

Kotlin

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

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Cool

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

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

Die releaseRuntimeClasspath-Konfiguration ist ein wahrscheinliches Ziel. Wenn Sie jedoch eine andere Konfiguration verwenden möchten, führen Sie ./gradlew dependencyGuard ohne eine aufgeführte Konfiguration in Ihrer Build-Datei aus, um alle verfügbaren Konfigurationen zu sehen.

Führen Sie nach der Einrichtung ./gradlew dependencyGuard aus, um einen Bericht in app/dependencies/releaseRuntimeClasspath.txt zu generieren. Dies ist Ihr Basisbericht. Speichern Sie die Änderungen in Ihrem Versionskontrollsystem (VCS).

Beachten Sie, dass Dependency Guard nur die Liste der Bibliotheksabhängigkeiten erfasst. In Ihren Build-Dateien gibt es andere Abhängigkeiten, z. B. das Android SDK und die JDK-Versionen. Wenn Sie einen Commit an Ihre VCS senden, bevor die Abhängigkeitsänderungen vorgenommen werden, kann die VCS-Differenz diese Änderungen ebenfalls hervorheben.

Upgrade durchführen und mit Baseline vergleichen

Sobald Sie eine Referenz haben, führen Sie ein Upgrade von Abhängigkeiten und anderen Build-Änderungen durch, die Sie testen möchten. Aktualisieren Sie zu diesem Zeitpunkt weder Ihren Quellcode noch Ihre Ressourcen.

Führen Sie ./gradlew lint aus, um neue Lint-Warnungen oder ‐Fehler zu sehen. Beheben Sie alle wichtigen Probleme und aktualisieren Sie dann den Warnwert, indem Sie ./gradlew lint -Dlint.baselines.continue=true ausführen. Wenn Sie andere Tools zum Erfassen von Warnungsgrenzwerten verwendet haben, z. B. Kotlin Warning Baseline oder Kotlin Warnings Baseline Generator, beheben Sie neue Warnungen und aktualisieren Sie auch die zugehörigen Grenzwerte.

Führen Sie ./gradlew dependencyGuard aus, um den Bericht zum Vergleich zu aktualisieren. Führen Sie dann die VKS-Unterschiede aus, um Änderungen von Nichtbibliotheken zu sehen. Es ist wahrscheinlich, dass viele mehr Bibliotheksupgrades erforderlich sind, als Sie dachten.

Risiken analysieren

Sobald Sie wissen, was sich geändert hat, sollten Sie die möglichen Risiken der einzelnen aktualisierten Bibliotheken berücksichtigen. So können Sie Ihre Tests besser ausrichten oder Änderungen genauer untersuchen. Definieren Sie eine Reihe von Risiken, die für Ihr Projekt analysiert werden sollen, um eine einheitliche Analyse zu ermöglichen.

Einige Überlegungen:

Hauptversionsaktualisierungen

Hat sich die Hauptversionsnummer geändert?

Bei der semantischen Versionsverwaltung wird die erste Zahl als Hauptversion bezeichnet. Wenn die Version einer Bibliothek beispielsweise von 1.2.3 auf 2.0.1 aktualisiert wurde, hat sich die Hauptversion geändert. Dies ist in der Regel ein Hinweis darauf, dass der Bibliotheksentwickler zwischen den Versionen inkompatible Änderungen vorgenommen hat, z. B. Teile der API entfernt oder geändert hat.

Achten Sie in diesem Fall bei den folgenden Punkten besonders auf die betroffenen Bibliotheken.

Wenn Ihr Code experimentelle APIs verwendet (die häufig eine Aktivierung über Annotationen oder Build-Dateispezifikationen erfordern), können selbst kleinere Änderungen oder Patchversionsänderungen wie ein Upgrade von 1.2.3 auf 1.3.1 oder 1.2.3 auf 1.2.5 zu zusätzlichen Risiken führen.

Unstabile API

Einige Bibliotheksversionen enthalten möglicherweise nicht stabile APIs. Das sind in der Regel APIs, die sich noch in der Entwicklungsphase befinden oder von einer anderen instabilen API abhängen.

In der Regel sind sie auf Vorabversionen wie Alpha-, Entwickler- oder experimentelle Releases beschränkt. Einige Bibliotheken enthalten jedoch APIs, die als experimentell oder instabil gekennzeichnet sind.

Vermeiden Sie nach Möglichkeit solche APIs. Wenn Sie sie verwenden müssen, sollten Sie ihre Nutzung erfassen und in späteren Releases auf Änderungen oder Entfernungen achten.

Dynamisches Verhalten

Einige Bibliotheken verhalten sich aufgrund externer Faktoren unterschiedlich. Eine Bibliothek, die mit einem Server kommuniziert, ist beispielsweise von Änderungen an diesem Server abhängig.

  • Muss die Bibliothek mit einer bestimmten Serverversion übereinstimmen?
  • Kann die Bibliothek eine Verbindung zu verschiedenen Versionen eines Servers herstellen?
  • Beeinflusst ein anderer externer Faktor das ordnungsgemäße Verhalten der Bibliothek?

Manifestzusammenführung

Als Android-Archive (AAR) veröffentlichte Bibliotheken können Ressourcen und Manifeste enthalten, die in Ihre Anwendung eingefügt werden. Diese können neue Berechtigungen und Android-Komponenten wie Aktivitäten oder Übertragungsempfänger hinzufügen, die indirekt ausgeführt werden.

Laufzeitaktualisierungen

Einige Bibliotheken verwenden Funktionen, die außerhalb der Kontrolle Ihrer Anwendung aktualisiert werden können. Eine Bibliothek kann Play-Dienste verwenden, die unabhängig vom Android SDK aktualisiert werden. Andere Bibliotheken können mit Diensten in unabhängig aktualisierten externen Anwendungen verbunden werden (häufig mithilfe von AIDL).

Wie viele Versionen überspringen Sie?

Je länger Sie mit dem Upgrade einer Bibliothek warten, desto größer sind die potenziellen Risiken. Wenn Sie feststellen, dass sich eine Version erheblich ändert, z. B. 1.2.3 auf 1.34.5, achten Sie besonders auf diese Bibliothek.

Migrationsanleitungen

Prüfen Sie, ob die Bibliothek einen Migrationsleitfaden hat. Dies kann die Risikoanalyse und die Planung zur Risikobewältigung erheblich vereinfachen.

Ein solcher Leitfaden ist ein guter Indikator dafür, dass der Entwickler sich auf die Kompatibilität konzentriert und Ihre Umstellungsrisiken berücksichtigt hat.

Versionshinweise

Sehen Sie sich die Versionshinweise (sofern bereitgestellt) für jede geänderte Mediathek an. Achten Sie auf Hinweise auf bahnbrechende Änderungen oder neue Anforderungen, z. B. hinzugefügte Berechtigungen.

READMEs

In einigen README-Dateien für eine Bibliothek werden potenzielle Risiken erwähnt, insbesondere wenn die Bibliothek keine Release Notes enthält. Suchen Sie nach bekannten Problemen, insbesondere nach bekannten Sicherheitsproblemen.

Bekannte Sicherheitslücken prüfen

Der Play SDK Index erfasst Sicherheitslücken für viele beliebte SDKs. Die Play Console meldet, ob Sie eines der aufgeführten SDKs mit bekannten Sicherheitslücken verwenden. Wenn Sie Builddateien in Android Studio bearbeiten, prüft die IDE den SDK-Index und meldet die Verwendung anfälliger Bibliotheksversionen.

Das National Institute of Standards and Technology (NIST) verwaltet eine große National Vulnerability Database (NVD). Das Gradle-Plug-in Dependency Check (Abhängigkeitsprüfung) prüft die verwendeten Abhängigkeiten mit dem NVD.

Wenn Sie die Abhängigkeitsprüfung verwenden möchten, fordern Sie einen NVD-API-Schlüssel an, richten Sie das Gradle-Plug-in ein und führen Sie ./gradlew dependencyCheckAnalyze aus. Beachten Sie, dass die Ausführung dieses Prozesses sehr lange dauern kann.

Versionskonflikte

Werden Versionen wie erwartet aufgelöst? Achten Sie auf Konflikte, insbesondere auf größere Versionsunterschiede. Weitere Informationen dazu, wie Sie nach Konflikten suchen, finden Sie unter Gradle-Abhängigkeitsauflösung. Suchen Sie insbesondere im Bericht ./gradlew app:dependencies nach ->.

Wenn möglich, arbeiten Sie mit den Autoren einer Abhängigkeit zusammen, um Konflikte zu beheben. Wenn Ihr Unternehmen es zulässt, können Sie Änderungen an der Bibliothek vornehmen (Upstreaming), um die Kompatibilität der Bibliothek zu verbessern.

Lizenzen prüfen

Achte auf Änderungen bei den Lizenzen, wenn du ein Upgrade für eine Mediathek durchführst. Die Bibliothek selbst könnte zu einer Lizenz wechseln, die nicht mehr mit Ihrer Anwendung oder Bibliothek kompatibel ist. Neue transitive Abhängigkeiten können auch inkompatible Lizenzen verursachen. Ausführliche Informationen zur Überprüfung des aktuellen Lizenzsatzes für alle Abhängigkeiten finden Sie unter Lizenzen validieren.

Wartungs- und
Qualitätsrisiken

Für Bibliotheken mit öffentlichen Repositories:

  • Wie viele Beitragende verwalten die Bibliothek?
  • Wann wurde das letzte Upgrade durchgeführt und wie oft wird die Bibliothek geändert?
  • Wie sieht der Backlog an Problemen aus (falls verfügbar)? Lesen Sie sich den Bericht durch, um ein Gefühl für potenzielle Probleme und die technische Schuld der Bibliothek zu bekommen.
  • Wie gut decken Einheitentests die Bibliothek ab?
  • Gibt es bekannte Anti-Muster in der Codebasis?
  • Ist die Bibliothek gut dokumentiert?
  • Gibt es viele _fixme_-Kommentare in der Codebasis?

Offene und geschlossene Quellen im Vergleich

Bei Open-Source-Bibliotheken lassen sich Probleme leichter beheben als bei Closed-Source-Bibliotheken, unabhängig davon, ob die Probleme in Ihrem Code oder im Bibliothekcode auftreten.

Closed-Source-Abhängigkeiten minimieren und während der Bewertung genauer prüfen Gibt es gute Alternativen, die zu Ihrem Anwendungsfall passen? Welche Service Level Agreements sind für Bibliotheken mit geschlossenem Quellcode verfügbar? Wenn Sie eine proprietäre Abhängigkeit verwenden, müssen Sie zusätzliche Testfälle schreiben, um die Risiken zu begrenzen.

Build ausführen

Erstellen Sie Ihr Projekt. Prüfen Sie, ob neue Fehler oder Warnungen aufgetreten sind. Wenn Sie ermitteln können, von welcher Bibliothek sie stammen, beachten Sie dies als Risiko beim Upgrade dieser Bibliothek.

Wenn Sie neue Abschreibungswarnungen sehen, fügen Sie diese als spezifische Risiken für die Bibliothek hinzu, die sie produziert. Diese können in späteren Releases entfernt werden. Wenn Sie diese Bibliothek weiterhin verwenden möchten, nehmen Sie sich Zeit, um von der Verwendung eingestellter APIs zu ihren Ersatzfunktionen überzugehen. Notieren Sie sich die Einstellung, um diese Funktionen im Auge zu behalten und zu sehen, ob sie später entfernt werden.

API-Probleme mit Lint erkennen

Android lint kann viele Probleme in Ihrer Anwendung erkennen, einschließlich einiger, die auf Änderungen an Versionen von Abhängigkeiten oder dem Android SDK zurückzuführen sind. Wenn Sie beispielsweise Ihr compileSdk aktualisieren und die neuen APIs verwenden, meldet lint diejenigen, die in früheren SDK-Versionen nicht verfügbar sind.

Lint wird im Android Studio-Editor ausgeführt und meldet Probleme, während Sie Änderungen vornehmen. Normalerweise wird er jedoch nicht als Teil Ihres Builds in Studio oder bei einem Befehlszeilen-Build ausgeführt, es sei denn, Sie verwenden die Ziele build oder lint.

Wenn Sie Continuous Integration (CI) verwenden, führen Sie gradlew build oder gradlew lint während Ihrer CI-Builds (oder zumindest bei Ihren nächtlichen Builds) aus, um diese Arten von Fehlern zu erkennen.

Wenn Sie kein CI verwenden, sollten Sie gradlew lint mindestens gelegentlich ausführen.

Achten Sie dabei besonders auf Lint-Fehler und -Warnungen. Einige Bibliotheken werden mit eigenen Lint-Prüfungen geliefert, um die ordnungsgemäße Verwendung ihrer API zu gewährleisten. Einige neue Versionen einer Bibliothek enthalten neue Lint-Warnungen und -Fehler, die beim Erstellen neue Berichte zur Folge haben.

Risiken minimieren

Nachdem Sie die Upgrade-Risiken ermittelt haben, entscheiden Sie, wie Sie sie minimieren möchten:

  • Akzeptieren Sie einige Risiken so, wie sie sind. Einige Risiken sind gering genug, um akzeptabel zu sein, insbesondere wenn die Zeit und Ressourcen für das Upgrade begrenzt sind.
  • Lehnen Sie einige Risiken von vornherein ab. Einige Upgrades erscheinen Ihnen möglicherweise zu riskant, insbesondere wenn Sie derzeit nur wenig Zeit oder Ressourcen haben, um die Risiken zu minimieren. Wenn Sie eine Triage durchführen müssen, konzentrieren Sie sich auf Upgrades, die für aufgetretene Fehler oder neue Funktionen erforderlich sind.
  • Verbleibende Risiken minimieren
    • Es empfiehlt sich, Upgrades in kleinere, unabhängige Änderungssätze aufzuteilen. Dies verringert das Gesamtrisiko und ermöglicht ein teilweises Rollback.
    • Prüfen Sie die Änderungen im Detail.
    • Testen Sie Ihre App, um unerwartete Änderungen zu erkennen. Fügen Sie bei Bedarf neue Tests hinzu, um die Zuverlässigkeit des Upgrades zu erhöhen.
    • Sehen Sie sich die Quelle an (falls verfügbar), wenn Sie etwas Fragwürdiges finden.
    • Nehmen Sie die erforderlichen Änderungen an der Quelle oder dem Build vor.

Dokumentieren Sie Ihre Entscheidungen. Wenn Risiken eines Upgrades zu Problemen beim Ausführen Ihrer Anwendung führen, kann die Dokumentation Ihrer Risikoanalyse die erforderliche Fehleranalyse reduzieren.

Lizenzen prüfen

Die Bibliotheksentwickler lizenzieren die Bibliotheken für Ihre Nutzung. Sie müssen sich an die Lizenzbedingungen halten oder können die Bibliothek nicht nutzen. Einige Lizenzen sind sehr großzügig und erfordern oft nur die Quellenangabe der Bibliothek und die Bereitstellung des Lizenztexts für Endnutzer. Einige gelten als viral. Wenn Sie diese Bibliotheken verwenden, müssen Sie dieselbe Lizenz auf Ihre Anwendung oder Bibliothek anwenden.

Lizenzen können sich mit jedem Release ändern. Bei jedem Upgrade sollten Sie prüfen, ob die verwendeten Abhängigkeiten mit Ihrer Anwendung oder Bibliothek kompatibel sind.

Wenn eine Lizenz nicht kompatibel ist (oder nicht mehr kompatibel ist), können Sie diese Version der Bibliothek nicht verwenden. Sie können

  • Wenden Sie sich an den Inhaber der Bibliothek und bitten Sie um eine Fortführung der bestehenden Lizenz oder um eine Doppellizenz, damit die alte Lizenz weiterhin zulässig ist.
  • Klären Sie mit Ihrer Rechtsabteilung, ob Sie Ihre Lizenz so ändern können, dass sie kompatibel ist.
  • Suchen Sie nach einer anderen Bibliothek mit einer kompatiblen Lizenz und ändern Sie Ihre Anwendung gegebenenfalls.
  • Erstellen Sie einen Fork der letzten kompatiblen Version der Bibliothek (sofern diese Lizenz Derivate zulässt und die Änderungen nicht rückwirkend sind) und nehmen Sie Ihre eigenen Änderungen vor.