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.

Upgradestrategie überlegen

Der wichtigste Schritt bei jeder Umstellung ist die Risikoanalyse. Überlegen Sie, wie sicher Sie sich bei jeder Abhängigkeit sind, die Sie aktualisieren. Bei der Definition Ihrer Upgrade-Strategie sind viele Aspekte zu berücksichtigen, darunter:

Bibliothek erstellen

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

Wenn Sie eine Anwendung entwickeln, sollten Sie darauf achten, dass sie immer auf dem neuesten Stand und stabil ist.

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 Vorabversionsschema hinzu. Vermeiden Sie major-Versionsupgrades, um Probleme für Ihre Nutzer zu vermeiden.

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ührt. Das kann auch dann passieren, wenn sich Ihre Bibliothek nicht geändert hat. Sie können eine neue Version nur veröffentlichen, um diese Abhängigkeit zu aktualisieren.

Release-Zyklus

Wie oft veröffentlichen Sie Ihre Anwendung oder Bibliothek?

Kürzere Entwicklungs- und Releasezyklen

  • Es bleibt weniger Zeit für ein Upgrade.
  • Sie können schnell ins Hintertreffen geraten.
  • Häufige kleine Upgrades können die Arbeitslast erleichtern.
  • Wenn ein Bibliotheksupgrade zu Problemen führt, können Sie dieses Upgrade 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

  • Es bleibt mehr Zeit, Upgrades vorzunehmen 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 eine umfassende Überprüfung durchführen, bei der die Bibliothek auf alle Risikokriterien geprüft wird, um sicherzustellen, dass sie richtig bewertet 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.

Upgradetyp

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 Plugin (AGP): Das Tool, mit dem Ihre Android-Anwendung oder ‑Bibliothek erstellt wird. 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: Sie müssen Gradle häufig aktualisieren, wenn Sie AGP oder ein anderes Gradle-Plug-in 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 Anwendung, 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 an 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 ihre 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 Plugin (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:

Weitere Informationen finden Sie in den AGP-Versionshinweisen.

Aktualisieren Sie Gradle auf mindestens die aufgeführte Version.

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 den SDK Build Tools, dem NDK und dem 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 von AGP eingestellt und später entfernt, was zu Inkompatibilitäten mit vorherigen Plug-ins führt.

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:
  • 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 unter Compiler-Plug-ins aufgeführt ist, müssen Sie dieselbe Version wie den 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.

Gelegentlich ändern sich auch die Kotlin-Sprachstandards, 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 richtig erstellt wird, sehen Sie in den Kotlin-Releasenotizen nach, ob es Sprachänderungen oder Fehler in der Laufzeitbibliothek gibt.

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 lautet, 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. Der minSdk Ihrer Anwendung wird jedoch automatisch auf das Maximum 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, führen Sie möglichst bald ein Upgrade auf die neue Version durch, insbesondere wenn das Plug-in öffentlich ist.

Bei einigen Gradle-Upgrades müssen Sie neue Versionen der von Ihnen verwendeten Plug-ins finden. Beachten Sie, dass die Entwicklung dieser Plug-ins ins Stocken geraten kann, da sie auf die neuesten Gradle-Plug-in-APIs umgestellt werden.

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

In aktualisierten Gradle-Plug-ins werden manchmal neue oder geänderte Gradle-APIs verwendet, 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 eine Inkompatibilität hinweisen.

Wenn Sie Plugins aktualisieren, aktualisieren Sie auch Gradle.

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, Fehlerkorrekturen und Verhaltensänderungen. Sie müssen Ihre targetSdk im Play Store aktualisieren. Wir empfehlen Ihnen jedoch, targetSdk vor den Fristen zu aktualisieren, damit Sie genügend Zeit für die erforderlichen Änderungen haben.

Lesen Sie sich vor dem Upgrade des Android SDK die Versionshinweise sorgfältig durch. Achten Sie besonders auf den Abschnitt zu Verhaltensänderungen. Dazu gehören:

  • 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. Einige Bibliotheken wie AndroidX haben eine Mindestanforderung an compileSdk.

Wenn Sie neue SDK-Funktionen während der Entwicklung nutzen und die Kompatibilität während des Builds gewährleisten 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 Sie das Android SDK aktualisieren, aktualisieren Sie auch alle verwendeten AndroidX-Bibliotheken. 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 verwenden möchten, um AGP oder das Android SDK zu aktualisieren, 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 im Android-Build.

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. Müssen Sie beispielsweise:

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

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. Angenommen, nach diesen automatischen Upgrades funktioniert alles ordnungsgemäß.

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 bei der Analyse des Upgrades besteht darin, festzustellen, 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 Baseline 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.

Anhand dieser Warnungsgrundlagen können Sie leichter neue Warnungen erkennen, die beim Aktualisieren Ihrer Abhängigkeiten auftreten.

Erstellen Sie eine Abhängigkeits-Baseline, 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")
}

Groovy

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 erstellen. Das ist der Bericht mit den Ausgangsdaten. Speichern Sie diese Änderungen in Ihrem Versionskontrollsystem (VCS).

Beachten Sie, dass Dependency Guard nur die Liste der Bibliotheksabhängigkeiten erfasst. In Ihren Build-Dateien gibt es noch weitere Abhängigkeiten, z. B. die Android SDK- und JDK-Versionen. Wenn Sie Änderungen an Ihrem VCS vornehmen, bevor sich die Abhängigkeiten ändern, werden diese Änderungen auch in der VCS-Diff hervorgehoben.

Upgrade durchführen und mit der Baseline vergleichen

Sobald Sie eine Baseline haben, aktualisieren Sie die Abhängigkeiten und andere Buildänderungen, die Sie testen wollten. Aktualisieren Sie Ihren Quellcode oder Ihre Ressourcen zu diesem Zeitpunkt nicht.

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 den VCS-Diff aus, um Änderungen an Dateien außerhalb der Bibliothek 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 in Ihrem Code experimentelle APIs verwendet werden, die Sie häufig mit Anmerkungen oder Builddatei-Spezifikationen aktivieren müssen, können selbst Änderungen an Minor- oder Patch-Versionen, z. B. ein Upgrade von 1.2.3 auf 1.3.1 oder 1.2.3 auf 1.2.5, zusätzliche Risiken bergen.

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.

Verwenden Sie solche APIs nach Möglichkeit nicht. 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?

Manifeste zusammenführen

Als Android-Archive (AAR) veröffentlichte Bibliotheken können Ressourcen und Manifeste enthalten, die in Ihre Anwendung eingefügt werden. So können neue Berechtigungen und Android-Komponenten wie Aktivitäten oder Broadcast-Empfänger hinzugefügt werden, 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 sich eine Version deutlich ändert, z. B. von 1.2.3 zu 1.34.5, sollten Sie diese Bibliothek besonders im Auge behalten.

Migrationsleitfäden

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

Lesen Sie die Versionshinweise (falls vorhanden) für jede geänderte Bibliothek. 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. In der Play Console wird angegeben, 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 prüft Ihre verwendeten Abhängigkeiten anhand der NVD.

Wenn Sie Dependency Check 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 dies einige Zeit dauern kann.

Versionskonflikte

Werden Versionen wie erwartet aufgelöst? Suchen Sie nach Konflikten, insbesondere nach Unterschieden bei Hauptversionen. 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 dies zulässt, können Sie Änderungen an der Bibliothek vornehmen (Upstreaming), um die Kompatibilität der Bibliothek zu verbessern.

Lizenzen prüfen

Achte beim Upgrade einer Bibliothek auf Änderungen an den Lizenzen. 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. Unter Lizenzen prüfen finden Sie weitere Informationen dazu, wie Sie die aktuellen Lizenzen für Ihre Abhängigkeiten prüfen.

Wartungs- und
Qualitätsrisiken

Für Bibliotheken mit öffentlichen Repositories:

  • Wie viele Mitwirkende verwalten die Bibliothek?
  • Wann war das letzte Upgrade und wie oft ändert sich die Bibliothek?
  • 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 die Unit-Tests die Bibliothek ab?
  • Gibt es bekannte Anti-Muster in der Codebasis?
  • Ist die Bibliothek gut dokumentiert?
  • Enthält die Codebasis viele Kommentare vom Typ „_fixme“?

Open Source im Vergleich zu Closed Source

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.

Minimieren Sie Abhängigkeiten von proprietären Quellen und prüfen Sie diese bei der Bewertung genauer. 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 die Bibliothek identifizieren können, die das Problem verursacht, notieren Sie sich dies als Risiko für das Upgrade dieser Bibliothek.

Wenn Sie neue Warnungen zur Wertminderung sehen, fügen Sie diese als spezifische Risiken für die Bibliothek hinzu, die sie generiert. 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. Alternativ können Sie sich die Einstellung notieren, um diese Funktionen im Auge zu behalten und zu sehen, ob sie später entfernt werden.

Mit Lint API-Probleme 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, was beim Build zu neuen Berichten führt.

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 direkt 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
    • Sie können Ihre Upgrades in kleinere, unabhängige Änderungssätze aufteilen. Dadurch wird das Gesamtrisiko reduziert und ein teilweises Rollback ermöglicht.
    • 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 die Lizenzbedingungen einhalten, da Sie die Bibliothek sonst nicht verwenden können. 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 jeder Veröffentlichung ä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.
  • Erkundigen Sie sich bei Ihrer Rechtsabteilung, ob Sie Ihre Lizenz ändern können, damit 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.