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 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 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 |
Release-Zyklus |
Wie oft veröffentlichen Sie Ihre Anwendung oder Bibliothek? Kürzere Entwicklungs- und Releasezyklen
Längere Entwicklungs- und Releasezyklen
|
Ü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?
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.
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 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 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 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:
|
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 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:
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 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:
- Abhängigkeitsunterschiede vor und nach den Upgrades ermitteln
- Prüfen Sie jede Änderung und ermitteln Sie die damit verbundenen Risiken.
- 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.
- Lint: Prüfen Sie Ihre vorhandenen Lint-Warnungen und erstellen Sie eine Android Lint-Baseline.
- Kotlin-Compiler:
- Aktivieren Sie
-Werror, um alle Warnungen als Fehler zu behandeln. Weitere Informationen - Sie können Plug-ins wie Kotlin Warning Baseline oder Kotlin Warnings Baseline Generator verwenden.
- Aktivieren Sie
- Andere Tools: Wenn Sie andere Tools zur statischen Analyse wie Detekt verwenden, die das Baseline-Tracking unterstützen, richten Sie die Baselines ein.
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? 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.
|
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 |
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 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 |
Für Bibliotheken mit öffentlichen Repositories:
|
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.