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 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 Veröffentlichungszyklen
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 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?
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-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 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 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 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:
|
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 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:
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 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:
- 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 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.
- Lint: Prüfen Sie die vorhandenen Lint-Warnungen und erstellen Sie eine Android-Lint-Referenz.
- Kotlin-Compiler:
- Aktivieren Sie
-Werror, um alle Warnungen als Fehler zu behandeln. Siehe Optionen definieren. - Sie können Plug-ins wie Kotlin Warning Baseline oder Kotlin Warnings Baseline Generator verwenden.
- Aktivieren Sie
- Weitere Tools: Wenn Sie andere statische Analysetools wie Detekt verwenden, die das Referenz-Tracking unterstützen, müssen Sie deren Referenzwerte einrichten.
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? 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.
|
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 |
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 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 |
Für Bibliotheken mit öffentlichen Repositories:
|
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.