Uaktualnianie wersji zależności

Uwaga: zanim zaktualizujesz zależności, rozważ włączenie weryfikacji zależności, aby sprawdzić pobrane i dołączone do projektu zależności.

Aktualizowanie zależności daje dostęp do ich najnowszych funkcji, poprawek i ulepszeń. Aby uaktualnić zależności, musisz wiedzieć, jak Gradle rozwiązuje wersje, których potrzebujesz, jakie są związane z tym zagrożenia i jak możesz je zminimalizować.

Uwaga: prawidłowe testy aplikacji są kluczowe, aby aktualizacje nie powodowały nieoczekiwanego uszkodzenia kompilacji lub aplikacji.

Zastanów się nad strategią uaktualniania

Najważniejszym krokiem w przypadku każdego uaktualnienia jest analiza ryzyka. Określ, jak dobrze znasz każdą zależność, którą aktualizujesz. Przy określaniu strategii uaktualniania należy wziąć pod uwagę wiele kwestii, w tym:

Tworzenie biblioteki	Czy tworzysz aplikację, którą użytkownicy pobierają i uruchamiają na urządzeniu? A może tworzysz bibliotekę, aby ułatwić innym deweloperom tworzenie aplikacji? Jeśli tworzysz aplikację, skup się na jej aktualizowaniu i utrzymywaniu stabilności. Jeśli tworzysz bibliotekę, skup się na aplikacjach innych deweloperów. Twoje ulepszenia wpływają na konsumentów. Jeśli uaktualnisz jeden z elementów zależnych, ta wersja stanie się kandydatem do rozwiązania zależności Gradle, co może spowodować przerwanie korzystania z tego elementu przez aplikację. Po pierwsze – w miarę możliwości ograniczaj zależności biblioteki. Im mniej zależności, tym mniejszy wpływ na rozwiązywanie zależności przez użytkownika. Aby wskazać typy wprowadzanych zmian, stosuj się do semantycznego numerowania wersji. Na przykład AndroidX stosuje semantyczne wersjonowanie i dodaje schemat wersji przedpremierowych. Aby uniknąć problemów u użytkowników, staraj się unikać aktualizacji wersji major. Rozważ utworzenie wersji kandydata do wydania (RC) biblioteki, aby użytkownicy mogli ją wcześnie przetestować. Szczegółowe informacje o zachowaniu zgodności z interfejsem binarnym aplikacji (ABI) biblioteki znajdziesz w wytycznych dotyczących zgodności wstecznej dla autorów bibliotek. Aby mieć pewność, że zmiany ABI są zgodne z zamierzoną zmianą wersji, użyj testów integracyjnych i narzędzi takich jak walidator zgodności binarnej. Jeśli wprowadzisz poprawki w wersji patch biblioteki, użytkownicy nie będą musieli aktualizować biblioteki do kolejnej wersji major lub minor, chyba że będą chcieli skorzystać z nowych funkcji. Unikaj uaktualniania pośrednich zależności w ramach tych uaktualnień. Jeśli uaktualnienie biblioteki wymaga wprowadzenia zmian, które mogą być szczególnie uciążliwe dla użytkowników, rozważ opublikowanie ich jako nowego artefaktu, aby stare i nowe wersje mogły współistnieć i umożliwić stopniowe wdrażanie. Uwaga: jeśli uaktualnienie jednej z zależnych bibliotek zawiera istotną zmianę interfejsu API, warto je przeprowadzić w wersji major lub minor i wprowadzić niezbędne zmiany. Jeśli tego nie zrobisz, użytkownicy biblioteki mogą to zrobić, co spowoduje niezgodność biblioteki z tą zależnością. Może się tak zdarzyć nawet wtedy, gdy nie wprowadzisz zmian w swojej bibliotece. Możesz wydać nową wersję tylko po to, aby uaktualnić tę zależność.
Cykl premierowy	Jak często publikujesz aplikację lub bibliotekę? Krótsze cykle rozwoju i publikacji Czas na przeprowadzenie aktualizacji jest krótszy. Możesz szybko zgubić kontakt z grupą. Częste drobne uaktualnienia mogą ułatwić Ci pracę. Jeśli uaktualnienie biblioteki spowoduje problemy, możesz szybciej przywrócić poprzednią wersję. Jeśli używasz wtyczek lub narzędzi, które pomagają automatyzować aktualizacje zależności, pamiętaj, aby przeanalizować wyniki i sprawdzić, czy nie ma w nich zagrożeń. dłuższe cykle rozwoju i publikacji, Masz więcej czasu na wprowadzenie i przetestowanie ulepszeń. Nowsze wersje zależności są częściej publikowane w ramach cyklu. Cofania ulepszeń i publikowania aplikacji lub biblioteki zajmuje więcej czasu.
Bądź na bieżąco z najnowszymi funkcjami	Czy wolisz korzystać z najnowszych funkcji i interfejsów API, czy aktualizujesz tylko wtedy, gdy potrzebujesz nowej funkcji lub poprawki błędu? Zastanów się nad kompromisami związanymi z częstymi aktualizacjami. Przyszłe uaktualnienia są łatwiejsze (mniej zmian do zintegrowania), ale wiążą się z częstszym podejmowaniem ryzyka. Testowanie uaktualnień do wersji przedpremierowych (alfa, beta, kandydat do wydania) bibliotek może pomóc w przygotowaniu się na wersje stabilne.
Nowa zależność	Jeśli dodajesz nową zależność, rozważ przeprowadzenie rygorystycznego procesu weryfikacji, który sprawdza tę bibliotekę pod kątem wszystkich kryteriów ryzyka, aby upewnić się, że zostały one prawidłowo ocenione. Nie zezwalaj na dodawanie nowych zależności bez sprawdzenia.
Zespół ds. współpracy z partnerami	Czy masz specjalny zespół zajmujący się kompilacją? Czy inżynierowie oprogramowania zajmują się konserwacją kompilacji? Specjalny zespół może poświęcić więcej czasu na analizowanie ryzyka związanego z aktualizacją i testowanie nowych wersji, aby upewnić się, że kompilacja działa prawidłowo, zanim inżynierowie zaczną używać nowych wersji.
Typ uaktualnienia	Niektóre ulepszenia są ważniejsze od innych. Zastanów się, które z nich są dla Ciebie najważniejsze. Uaktualnienia narzędzi do kompilacji, takich jak Gradle i wtyczki Gradle, zwykle mają mniejszy wpływ na użytkowników, a duża część ryzyka dotyczy wewnętrznych aspektów kompilacji. Sama kompilacja pomaga weryfikować te zmiany. Uaktualnienia bibliotek i SDK są trudniejsze do zweryfikowania i stanowią większe zagrożenie dla użytkowników. Wtyczka Androida do obsługi Gradle (AGP) – narzędzia używane do kompilowania aplikacji lub biblioteki na Androida. To najważniejsza aktualizacja, ponieważ często obejmuje lub umożliwia ulepszenia wydajności, poprawki błędów, nowe reguły lint oraz obsługę nowych wersji platformy Android. Gradle – często musisz uaktualnić Gradle, gdy aktualizujesz AGP lub inną wtyczkę Gradle. Inne wtyczki Gradle – czasami interfejs API wtyczki Gradle ulega zmianie. Gdy aktualizujesz Gradle, sprawdź, czy są dostępne aktualizacje używanych wtyczek. Kotlin i Java – niektóre biblioteki i wtyczki wymagają minimalnych wersji języka Kotlin lub Java albo chcesz korzystać z nowych funkcji języka, interfejsów API lub ulepszeń wydajności. Platforma Android – Sklep Play wymaga regularnych aktualizacji pakietu Android SDK. Nowe wersje pakietu SDK Androida należy przetestować jak najszybciej. Niektóre uaktualnienia pakietu SDK wymagają wprowadzenia zmian w aplikacji, takich jak nowe uprawnienia lub użycie nowych interfejsów API. Biblioteki – czy chcesz nadawać priorytety bibliotekom na podstawie ich bliskości do ogólnej architektury? Biblioteki związane z platformą i architekturą, takie jak AndroidX, często się zmieniają, aby korzystać z nowych funkcji lub pomagać w abstrakcyjnych zmianach na platformie. Aktualizuj te biblioteki co najmniej przy każdej aktualizacji platformy Android lub innych bibliotek związanych z architekturą. Inne uaktualnienia biblioteki można rozłożyć w czasie lub opóźnić, chyba że potrzebujesz nowej funkcji lub konkretnych poprawek błędów. Android Studio – aktualizowanie Android Studio zapewnia dostęp do najnowszych funkcji i poprawek błędów w podstawowej platformie IntelliJ IDEA oraz narzędzi do pracy z najnowszymi pakietami SDK Androida.
Dostępne narzędzia	Jeśli używasz wtyczek lub narzędzi, które pomagają automatyzować aktualizacje zależności, pamiętaj, aby przeanalizować wyniki i sprawdzić, czy nie ma w nich zagrożeń.

Strategie dotyczące określonych typów uaktualnień

Uaktualnianie niektórych typów zależności może mieć efekt kaskadowy i wymagać uaktualnienia innych typów zależności. Relacje między elementami tworzenia omawiamy w artykule Wzajemne zależności między narzędziami a bibliotekami.

Rysunek 1. budować relacje.

Podczas uaktualniania poszczególnych typów komponentów zastanów się, jak to wpłynie na inne komponenty w kompilacji.

Wtyczka Android Gradle (AGP)	Android Studio zawiera asystenta uaktualniania AGP, który może pomóc w wykonywaniu tych zadań. Jeśli korzystasz z asystenta lub ręcznie przekształcasz konto, pamiętaj o tych kwestiach: Przeczytaj informacje o wersji AGPL. Uaktualnij Gradle do co najmniej podanej wersji. Zaktualizuj Android Studio do wersji obsługującej wybraną wersję AGP. Używaj wersji Android Studio i AGP, które obsługują pakiet Android SDK, którego chcesz użyć. Sprawdź zgodność z narzędziami kompilacji pakietu SDK, NDK i JDK. Jeśli opracowujesz wtyczkę Gradle (do użytku wewnętrznego lub publicznego), która rozszerza dane z AGP lub korzysta z nich, sprawdź, czy musisz ją uaktualnić. Czasami AGP wycofuje interfejsy API, a potem je usuwa, co powoduje niezgodność z poprzednimi wtyczkami.
Kompilator, język i czas wykonywania Kotlin	Informacje o znanych problemach i niezgodnościach związanych z Kotlinem znajdziesz w informacjach o wersji Kotlina. Jeśli używasz Jetpack Compose: Jeśli nowa wersja Kotlina jest starsza niż 2.0.0: Znajdź zgodną wtyczkę kompilatora Compose. Zaktualizuj kotlinCompilerExtensionVersion w build.gradle.kts w dowolnych modułach, w których się pojawia. Jeśli nowa wersja Kotin to 2.0.0 lub nowsza: Skonfiguruj wtyczkę Gradle do kompilatora Compose w tej samej wersji co kompilator Kotlina. Jeśli używasz Kotlin Symbol Processing (KSP), zapoznaj się z krótkim wprowadzeniem do KSP, aby dowiedzieć się, jak skonfigurować tę funkcję, oraz z dostępnymi wersjami KSP. Pamiętaj, że musisz użyć wersji KSP zgodnej z wersją Kotlina. Jeśli np. używasz Kotlina w wersji 2.0.21, możesz użyć dowolnej wersji wtyczki KSP, która zaczyna się od 2.0.21, np. 2.0.21-1.0.25. Zwykle nie trzeba aktualizować procesorów KSP (takich jak kompilator Room, który pojawia się jako zależność ksp w plikach kompilacji). Wtyczka KSP abstrakcyjnie obsługuje większość interfejsów API kompilatora, a interfejs KSP używany przez procesory jest stabilny. Uaktualnij wszystkie używane przez siebie wtyczki kompilatora Kotlin. Interfejs API wtyczki kompilatora Kotlina często się zmienia w kolejnych wersjach, a wtyczki muszą używać zgodnego interfejsu API. Jeśli wtyczka jest wymieniona w sekcji Wtyczki kompilatora, musisz użyć tej samej wersji co kompilator Kotlin. W przypadku innych wtyczek kompilacji zapoznaj się z ich dokumentacją, aby znaleźć odpowiednie mapowanie. Pamiętaj, że wtyczki kompilatora, które nie są aktualizowane wraz z kompilatorem Kotlin, często są opóźniane, ponieważ czekają na stabilizację interfejsu API wtyczki kompilatora. Zanim zaktualizujesz Kotlina, sprawdź, czy wszystkie używane przez Ciebie wtyczki kompilatora mają dostępne odpowiednie uaktualnienia. W niektórych przypadkach język Kotlin ulega zmianom, co wymaga zaktualizowania kodu. Zdarza się to najczęściej, gdy testujesz funkcje eksperymentalne. Jeśli po uaktualnieniu kompilatora Kotlina kod nie jest prawidłowo kompilowany, sprawdź notatki do wersji Kotlina, aby dowiedzieć się, czy nie nastąpiły zmiany w języku lub czy nie doszło do uszkodzenia biblioteki czasu wykonywania.
Wtyczki kompilatora Kotlin	Jeśli musisz uaktualnić wtyczkę kompilatora Kotlin, zaktualizuj ją do wersji zgodnej z używaną wersją Kotlina. Większość wtyczek kompilatora Kotlin używa tej samej wersji co kompilator Kotlin lub uruchamia się z wymaganym kompilatorem Kotlin. Jeśli np. wersja wtyczki to 2.0.21-1.0.25, musisz użyć wersji kompilatora Kotlin 2.0.21. Zmiana wersji kompilatora Kotlina może wymagać innych zmian.
Biblioteki	Biblioteki to najczęściej aktualizowane zależności w kompilacji. Dostępne uaktualnienia znajdziesz w edytorze Android Studio. Niektóre biblioteki wymagają minimalnej ilości compileSdk lub minSdk, aby można było z nich korzystać. Jeśli nie użyjesz co najmniej określonej wartości compileSdk, kompilacje nie powiedzą się. Jednak minSdk aplikacji jest automatycznie ustawiany na maksymalną wartość wszystkich wartości minSdk określonych w plikach zależności biblioteki i plikach kompilacji. Niektóre biblioteki określają też minimalną wersję Kotlina, której należy używać. Zaktualizuj wersję Kotlina w plikach kompilacji, aby była co najmniej równa określonej wersji.
Gradle	Czasami nowe wersje Gradle wycofują istniejące interfejsy API, usuwając je w przyszłej wersji. Jeśli opracowujesz wtyczkę Gradle, jak najszybciej ją zaktualizuj, zwłaszcza jeśli jest ona publiczna. Niektóre uaktualnienia Gradle wymagają znalezienia nowych wersji używanych wtyczek. Pamiętaj, że te wtyczki mogą być rozwijane z opóźnieniem, ponieważ są one aktualizowane, aby odpowiadały najnowszym interfejsom API wtyczek Gradle. Aby uaktualnić Gradle: Przeczytaj informacje o wersji, której chcesz użyć. Uaktualnij wersję Gradle w pliku gradle/wrapper/gradle-wrapper.properties. Zaktualizuj plik jar owijarki Gradle i skrypty, uruchamiając ./gradlew wrapper --gradle-version latest. Zaktualizuj wtyczki Gradle. Zaktualizuj JDK używany do uruchamiania Gradle.
Wtyczki Gradle	Uaktualnione wtyczki Gradle czasami używają nowych lub zmienionych interfejsów API Gradle, które z kolei wymagają uaktualnienia Gradle lub ewentualnie wprowadzenia zmian w ich konfiguracji w plikach kompilacji. W obu przypadkach zobaczysz ostrzeżenia lub błędy kompilacji wskazujące na niezgodność. Podczas aktualizowania wtyczek zawsze aktualizuj Gradle.
SDK na Androida	Android Studio zawiera Asystenta aktualizacji pakietu SDK Androida, który może pomóc w wykonywaniu tych zadań. Jeśli korzystasz z asystenta lub ręcznie przekształcasz konto, pamiętaj o tych kwestiach: Każda wersja pakietu Android SDK zawiera nowe funkcje i interfejsy API, poprawki błędów oraz zmiany w działaniu. Sklep Play wymaga zaktualizowania targetSdk, ale rozważ zaktualizowanie targetSdk wcześniej niż w terminie, aby mieć więcej czasu na wprowadzenie niezbędnych zmian. Przed uaktualnieniem pakietu Android SDK przeczytaj informacje o wersji. Zwróć szczególną uwagę na sekcję dotyczącą zmian w zachowaniu, która obejmuje: Nowe uprawnienia, o które musisz poprosić w czasie instalacji lub działania aplikacji. Wycofane interfejsy API i ich zamienniki. Zmiany w interfejsach API lub ich działaniu, które mogą spowodować przerwanie działania aplikacji. nowe interfejsy API Kotlin lub Java, które mogą mieć wpływ na Twój kod. Sekcja „Zmiany zachowania” może być dość długa, ale przeczytaj ją uważnie, ponieważ często zawiera ważne zmiany, które musisz wprowadzić w aplikacji. Aby spełnić wymagania Sklepu Play, musisz uaktualnić targetSdk. Uaktualnianie interfejsu compileSdk jest opcjonalne i daje Ci dostęp do nowych interfejsów API. Pamiętaj, że niektóre biblioteki, np. AndroidX, wymagają co najmniej compileSdk. Aby korzystać z nowych funkcji pakietu SDK podczas tworzenia aplikacji i zapewnić zgodność podczas kompilacji, zaktualizuj wtyczkę Android Gradle (AGP) i Android Studio. Obejmuje to nowe i ulepszone narzędzia do nowych pakietów SDK. Zobacz minimalne wersje narzędzi dla poziomu interfejsu API Androida. Podczas aktualizacji pakietu Android SDK zaktualizuj wszystkie używane biblioteki AndroidX. AndroidX często używa nowych i zaktualizowanych interfejsów API, aby zapewnić lepszą zgodność i wydajność w różnych wersjach pakietu SDK Androida.
Android Studio	W ogóle możesz zaktualizować Android Studio w dowolnym momencie. Możesz zobaczyć komunikaty z prośbą o zaktualizowanie AGP lub pakietu Android SDK. Te uaktualnienia są zdecydowanie zalecane, ale nie są wymagane. Jeśli później chcesz użyć Android Studio do uaktualnienia AGP lub pakietu Android SDK, możesz znaleźć te opcje w menu Narzędzia: Asystent przejścia na AGP… Asystent uaktualniania pakietu SDK na Androida…
Java	Jeśli w aplikacji na Androida masz kod źródłowy w języku Java, możesz skorzystać z nowych interfejsów API w tym języku. Każda wersja pakietu Android SDK obsługuje podzbiór interfejsów API Java i funkcji językowych. AGP zapewnia zgodność z niższymi wersjami pakietu SDK Androida za pomocą procesu zwanego desugaringiem. Informacje o wersji pakietu SDK Androida zawierają informacje o tym, który poziom Java jest obsługiwany, oraz o potencjalnych problemach. Niektóre z tych problemów mogą też dotyczyć kodu źródłowego Kotlina, ponieważ Kotlin ma dostęp do tych samych interfejsów API Javy. Zwróć szczególną uwagę na sekcje interfejsu JDK API, które pojawiają się w sekcji „Zmiany w działaniu” w informacjach o wersji, nawet jeśli nie masz kodu źródłowego w Javie. Korzystanie z JDK jest określone w kilku miejscach w skryptach kompilacji. Więcej informacji znajdziesz w artykule Java w wersji Androida.

Analiza uaktualnienia

Uaktualnianie zależności może wiązać się z ryzykiem w postaci zmian w interfejsie API i zachowaniu, nowych wymagań dotyczących użycia, nowych problemów z bezpieczeństwem, a nawet zmian licencji. Czy na przykład musisz:

• Czy należy zmienić kod, aby wprowadzić zmiany w interfejsie API?
• Dodać nowe kontrole uprawnień?
• Utworzyć dodatkowe testy lub zmodyfikować istniejące testy, aby sprawdzić zmiany zachowania?

Pamiętaj, że zaktualizowana wersja zależności ma zaktualizowane wersje swoich zależności. Może to szybko doprowadzić do ogromnego zestawu zmian.

Jeśli używasz wtyczek lub narzędzi, które pomagają automatyzować uaktualnianie zależności, pamiętaj, że nie wykonują one żadnej analizy. Zamiast tego aktualizują biblioteki do najnowszych wersji. Nie zakładaj, że wszystko będzie działać prawidłowo po automatycznym uaktualnieniu.

Kluczem do udanego przejścia na nowszą wersję jest analiza uaktualnienia:

1. Określ różnice w zależnościach przed i po uaktualnieniu.
2. Sprawdź każdą zmianę i ustal związane z nią zagrożenia.
3. Zmniejszanie ryzyka lub akceptowanie lub odrzucanie zmian.

Sprawdzanie różnic w zależnościach

Pierwszym krokiem w analizie uaktualnienia jest określenie, jak zmienią się zależności. Aby szybko sprawdzać zmiany, korzystaj z kontroli wersji (VCS, np. Git) i wtyczki Dependency Guard. Twoim celem jest utworzenie zrzutu ekranu przed i po oraz ich porównanie.

Uwaga: Dependency Guard to zewnętrzny wtyczek Gradle. Złośliwi użytkownicy mogą skompromitować zewnętrzne wtyczki za pomocą ataków typu „man-in-the-middle” lub przez zhakowany serwer programistyczny. Zdecydowanie zalecamy włączenie weryfikacji zależności, aby sprawdzić pobrane zależności i uwzględnić je w projekcie.

Konfigurowanie i tworzenie pierwszego punktu odniesienia

Zanim rozpoczniesz uaktualnianie, upewnij się, że projekt został skompilowany.

W idealnej sytuacji należy usunąć jak najwięcej ostrzeżeń lub utworzyć wartości bazowe, aby śledzić, które ostrzeżenia już się pojawiły.

• Lint

  • Uwzględnij ostrzeżenia jako błędy, dodając

  android {
      // ...
      lint {
          warningsAsErrors = true
      }
  }
  

  do build.gradle.kts w każdym module.

  • Jeśli masz już wiele ostrzeżeń, utwórz podstawę referencyjną Androida lint. Z czasem usuń istniejące ostrzeżenia (lub wyłącz te, które Cię nie interesują).

• Kompilator Kotlina: włącz -Werror, aby traktować wszystkie ostrzeżenia jako błędy. Zobacz Jak definiować opcje.

• Inne narzędzia: jeśli używasz innych narzędzi do analizy statycznej, które obsługują śledzenie linii bazowych, skonfiguruj ich linie bazowe.

Wartości graniczne ostrzeżeń ułatwiają wyświetlanie nowych ostrzeżeń wprowadzanych podczas aktualizacji zależności. Za pomocą Dependency Guard możesz sprawdzać zmiany w zależnościach i ich wersjach.

W katalogu wersji gradle/libs.versions.toml dodaj:

[versions]
dependencyGuard = "0.5.0"

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

Dodaj do pliku kompilacji aplikacji te informacje:

Kotlin

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

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

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

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

Konfiguracja releaseRuntimeClasspath jest prawdopodobnie celem, ale jeśli chcesz użyć innej konfiguracji, uruchom ./gradlew dependencyGuard bez wymienionej konfiguracji w pliku kompilacji, aby wyświetlić wszystkie dostępne konfiguracje.

Po zakończeniu konfiguracji uruchom ./gradlew dependencyGuard, aby wygenerować raport w app/dependencies/releaseRuntimeClasspath.txt. To jest raport podstawowy. Zapisz go w systemie kontroli wersji (VCS).

Pamiętaj, że Dependency Guard rejestruje tylko listę zależności biblioteki. W plikach kompilacji występują też inne zależności, np. wersje pakietu SDK Androida i wersje JDK. Zmiany w VCS przed zmianami zależności umożliwiają VCS diff wyróżnienie tych zmian.

Uaktualnianie i porównywanie z wartością odniesienia

Gdy masz już punkt odniesienia, zaktualizuj zależności i inne zmiany w kompilacji, które chcesz przetestować. Na tym etapie nie aktualizuj kodu źródłowego ani zasobów.

Uruchom ./gradlew lint, aby wyświetlić nowe ostrzeżenia lub błędy lint. Rozwiąż wszystkie ważne problemy, a następnie zaktualizuj wartości odniesienia ostrzeżenia, wykonując ./gradlew lint -Dlint.baselines.continue=true. Jeśli do rejestrowania wartości progowych używasz innych narzędzi, musisz też zaktualizować ich wartości.

Aby zaktualizować raport podstawowy, uruchom ./gradlew dependencyGuard. Następnie uruchom narzędzie VCS diff, aby zobaczyć zmiany poza biblioteką. Prawdopodobnie zawiera ona znacznie więcej uaktualnień biblioteki, niż Ci się wydaje.

Analizowanie zagrożeń

Gdy już poznasz zmiany, zastanów się nad możliwymi zagrożeniami związanymi z każdą zaktualizowaną biblioteką. Pomoże Ci to skoncentrować się na testowaniu lub dokładniejszym badaniu zmian. Aby zapewnić spójność analizy, określ zestaw zagrożeń, które mają być analizowane w przypadku Twojego projektu.

Uwagi:

Zmiany wersji głównej	Czy numer wersji głównej się zmienił? W semantycznym wersjionowaniu pierwsza liczba to wersja główna. Jeśli np. wersja biblioteki została podniesiona z 1.2.3 na 2.0.1, zmieniła się główna wersja. Zwykle oznacza to, że deweloper biblioteki wprowadził niezgodne zmiany między wersjami, np. usunął lub zmienił części interfejsu API. Gdy zobaczysz ten komunikat, zwróć szczególną uwagę na biblioteki, których dotyczy problem, i rozważ poniższe kwestie. Jeśli Twój kod korzysta z jakichkolwiek eksperymentalnych interfejsów API (które często wymagają akceptacji za pomocą adnotacji lub specyfikacji pliku kompilacji), nawet zmiany w wersjach podrzędnych lub poprawek, np. przejście z 1.2.3 na 1.3.1 lub z 1.2.3 na 1.2.5, mogą wiązać się z dodatkowymi zagrożeniami.
Niestabilny interfejs API	Niektóre wersje bibliotek mogą zawierać niestabilne interfejsy API. Zwykle są to interfejsy API, które są w trakcie tworzenia lub zależą od innego niestabilnego interfejsu API. Zwykle są one ograniczone do wersji wstępnych, takich jak wersje alfa, deweloperskie lub eksperymentalne, ale niektóre biblioteki zawierają interfejsy API oznaczone jako eksperymentalne lub niestabilne. Jeśli to możliwe, unikaj takich interfejsów API. Jeśli musisz ich używać, odnotuj ich użycie i sprawdź, czy w późniejszych wersjach nie zostały one zmienione lub usunięte.
Dynamiczne działanie	Niektóre biblioteki działają inaczej w zależności od czynników zewnętrznych. Na przykład biblioteka, która komunikuje się z serwerem, zależy od zmian na tym serwerze. Czy biblioteka musi być zgodna z konkretną wersją serwera? Czy biblioteka może łączyć się z różnymi wersjami serwera? Czy jakiś inny czynnik zewnętrzny wpływa na prawidłowe działanie biblioteki?
scalanie plików manifestu,	Biblioteki opublikowane jako archiwa Androida (AAR) mogą zawierać zasoby i pliki manifestu, które są scalane z aplikacją. Mogą one dodawać nowe uprawnienia i komponenty Androida, takie jak aktywności lub odbiorniki transmisji, które działają pośrednio.
Aktualizacje w czasie działania	Niektóre biblioteki korzystają z funkcji, które można aktualizować poza kontrolą aplikacji. Biblioteka może używać Usług Play, które są aktualizowane niezależnie od pakietu SDK Androida. Inne biblioteki mogą być powiązane z usługami w aplikacji zewnętrznej aktualizowanej niezależnie (często za pomocą AIDL).
Ile wersji pomijasz?	Im dłużej czekasz na uaktualnienie biblioteki, tym większe potencjalne ryzyko. Jeśli widzisz, że wersja zmieniła się znacząco, np. z 1.2.3 na 1.34.5, zwróć szczególną uwagę na tę bibliotekę.
Przewodniki dotyczące migracji	Sprawdź, czy biblioteka udostępnia przewodnik po migracji. Może to znacznie skrócić czas analizy ryzyka i planowania działań zapobiegających. Pamiętaj, że obecność takiego przewodnika jest dobrym wskaźnikiem tego, że deweloper zwraca uwagę na zgodność i rozważa możliwość łagodzenia skutków aktualizacji.
Informacje o wersji	Sprawdź informacje o wersji (jeśli są dostępne) każdej zmienionej biblioteki. Sprawdź, czy nie ma zmian, które powodują przerwanie działania aplikacji lub nowych wymagań, np. dodanych uprawnień.
Pliki README	Niektóre pliki README biblioteki zawierają informacje o potencjalnych zagrożeniach, zwłaszcza jeśli biblioteka nie zawiera informacji o wersji. Poszukaj _znanych problemów_, zwłaszcza znanych problemów z bezpieczeństwem.
Sprawdzanie znanych luk w zabezpieczeniach	Platforma Google Play SDK Index śledzi luki w zabezpieczeniach wielu popularnych pakietów SDK. Konsola Play informuje, czy używasz któregoś z wymienionych pakietów SDK zawierających znane luki w zabezpieczeniach. Podczas edytowania plików kompilacji w Android Studio IDE sprawdza indeks pakietu SDK i oznacza użycie podatnych wersji bibliotek. Narodowy Instytut Standaryzacji i Technologii (NIST) prowadzi dużą narodową bazę danych o lukach w zabezpieczeniach (NVD). Wtyczka Gradle Dependency Check sprawdza używane zależności pod kątem NVD. Aby korzystać z Dependency Check, poproś o klucz interfejsu NVD API, skonfiguruj wtyczkę Gradle i uruchom ./gradlew dependencyCheckAnalyze. Pamiętaj, że może to zająć dużo czasu. Uwaga: Sprawdzanie zależności to zewnętrzny wtyczka Gradle. Możliwe jest, że osoby o złośliwych zamiarach skompromitują zewnętrzne wtyczki za pomocą ataków typu „man-in-the-middle” lub przez zhakowany serwer programistyczny. Stanowczo zalecamy włączenie weryfikacji zależności, aby sprawdzić pobrane zależności i ich uwzględnienie w projekcie.
Konflikty wersji	Czy wersje są rozwiązywane zgodnie z oczekiwaniami? Poszukaj konfliktów, zwłaszcza znaczących różnic między wersjami. Szczegółowe informacje o szukaniu konfliktów znajdziesz w artykule Rozwiązywanie zależności w Gradle. W szczególności w raporcie ./gradlew app:dependencies wyszukaj ->. W miarę możliwości współpracuj z autorami zależności, aby rozwiązać konflikty. Jeśli Twoja firma na to pozwala, wprowadź zmiany w bibliotece (przesyłanie w górę), aby zwiększyć jej zgodność.
Sprawdzanie licencji	Podczas uaktualniania biblioteki sprawdź, czy zmieniły się licencje. Biblioteka może zmienić licencję na taką, która nie będzie już zgodna z Twoją aplikacją lub biblioteką. Nowe zależności pośrednie mogą też wprowadzać niezgodne licencje. Szczegółowe informacje o sprawdzaniu bieżącego zestawu licencji w zależności od zależności znajdziesz w artykule Weryfikowanie licencji.
Ryzyko związane z konserwacją i jakością	Biblioteki z repozytoriami publicznymi: Ilu autorów obsługuje bibliotekę? Kiedy miała miejsce ostatnia aktualizacja i jak często zmienia się biblioteka? Jak wygląda lista oczekujących problemów (jeśli jest dostępna)? Przejrzyj go pobieżnie, aby poznać potencjalne problemy i zobowiązania techniczne biblioteki. Jak dobrze testy jednostkowe obejmują bibliotekę? Czy w kodzie źródłowym występują znane wzorce nieprawidłowego działania? Czy biblioteka jest dobrze udokumentowana? Czy w kodzie źródłowym jest wiele komentarzy _fixme_?
Oprogramowanie open source a closed source	Jeśli biblioteka jest typu open source, debugowanie problemów będzie łatwiejsze niż w przypadku biblioteki zamkniętej, niezależnie od tego, czy problemy występują w Twoim kodzie, czy w kodzie biblioteki. Zminimalizuj zależności od zamkniętych źródeł i przeprowadź dodatkową kontrolę podczas ich oceny. Czy istnieją dobre alternatywy pasujące do Twojego przypadku użycia? Jakie gwarancje jakości usług są dostępne w przypadku bibliotek z zamkniętym kodem źródłowym? Jeśli zdecydujesz się użyć zależności ze źródłem zamkniętym, przygotuj się na napisanie dodatkowych przypadków testowych, aby ograniczyć ryzyko.

Uruchamianie kompilacji

Utwórz projekt. Sprawdź, czy nie pojawiły się nowe błędy lub ostrzeżenia. Jeśli uda Ci się ustalić, która biblioteka powoduje problemy, zaznacz to jako ryzyko związane z aktualizacją tej biblioteki.

Jeśli zobaczysz nowe ostrzeżenia o obniżeniu wartości, dodaj je jako konkretne zagrożenia dla biblioteki, która je wygenerowała. Mogą one zostać usunięte w kolejnych wersjach. Jeśli chcesz nadal korzystać z tej biblioteki, musisz poświęcić czas na przekształcenie kodu z wykorzystującego wycofane interfejsy API na korzystający z ich zamienników. Możesz też śledzić wycofania, aby wiedzieć, kiedy funkcje zostaną usunięte.

Wykrywanie problemów z interfejsem API za pomocą lint

Android Lint może wykrywać wiele problemów w aplikacji, w tym te, które są wynikiem zmiany wersji zależności lub pakietu Android SDK. Jeśli na przykład uaktualnisz pakiet compileSdk i użyjesz nowych interfejsów API, lint zgłosi te, które nie są dostępne w poprzednich wersjach pakietu SDK.

Lint działa w edytorze Android Studio i zgłasza problemy, gdy wprowadzasz zmiany. Zwykle nie jest ona jednak wykonywana w ramach kompilacji w Studio ani podczas kompilacji w wierszu poleceń, chyba że używasz celu build lub lint.

Jeśli używasz ciągłej integracji (CI), uruchom gradlew build lub gradlew lint podczas kompilacji CI (lub co najmniej podczas kompilacji nocnych), aby wykrywać tego typu błędy.

Jeśli nie używasz CI, pamiętaj, aby co jakiś czas uruchamiać gradlew lint.

Uwaga: ogólne reguły lintingu na poziomie pakietu Android SDK są dostarczane z AGP, a reguły dotyczące konkretnych bibliotek są pakowane z odpowiednimi bibliotekami. Upewnij się, że AGP i biblioteki, od których zależy Twój projekt, są jak najbardziej aktualne, aby mieć pewność, że do Twojego kodu są stosowane najnowsze reguły lint. Jest to szczególnie ważne w przypadku nowych reguł lint, które zostały dodane lub ulepszone w nowej wersji pakietu SDK Androida.

Zwróć szczególną uwagę na błędy i ostrzeżenia lint. Niektóre biblioteki są dostarczane z własnymi mechanizmami kontroli lint, które pomagają zapewnić prawidłowe korzystanie z ich interfejsów API. Niektóre nowe wersje bibliotek zawierają nowe ostrzeżenia i błędy lint, które powodują, że podczas kompilacji pojawiają się nowe raporty.

Zmniejszanie ryzyka

Po określeniu zagrożeń związanych z ulepszeniami zdecyduj, jak je ograniczyć:

• Akceptowanie niektórych zagrożeń takimi, jakie są. Niektóre zagrożenia są na tyle niewielkie, że można je zaakceptować, zwłaszcza gdy czas i zasoby na uaktualnienie są ograniczone.
• odrzucać niektóre ryzyka; Niektóre ulepszenia mogą wydawać się zbyt ryzykowne, zwłaszcza jeśli masz ograniczony czas lub zasoby, które mogą Ci pomóc w ich złagodzeniu. Jeśli musisz dokonać selekcji, skup się na aktualizacjach niezbędnych do usunięcia napotkanych błędów lub nowych funkcji, których potrzebujesz.
• Minimalizowanie pozostałych zagrożeń
  • Rozważ grupowanie uaktualnień w mniejsze, niezależne zestawy zmian. Pozwala to zmniejszyć ogólne ryzyko i umożliwia częściowe cofnięcie zmian.
  • szczegółowo analizować zmiany;
  • Testuj aplikację, aby sprawdzić, czy nie ma w niej nieoczekiwanych zmian. Dodaj nowe testy w miejscach, w których są potrzebne, aby zwiększyć pewność siebie podczas aktualizacji.
  • Jeśli znajdziesz coś wątpliwego, sprawdź źródło (jeśli jest dostępne).
  • Wprowadź wymagane zmiany w źródle lub kompilacji.

Dokumentowanie decyzji. Jeśli zagrożenia związane z aktualizacją stają się problemem podczas uruchamiania aplikacji, udokumentowanie analizy ryzyka może ograniczyć niezbędną analizę błędów.

Sprawdzanie licencji

Deweloperzy bibliotek udzielają licencji na korzystanie z bibliotek. Musisz przestrzegać warunków licencji, w przeciwnym razie nie będziesz mieć dostępu do biblioteki. Niektóre licencje są bardzo liberalne i często wymagają jedynie przypisania autorstwa biblioteki i wyświetlenia tekstu licencji użytkownikom. Niektóre z nich są uważane za wirusowe. Jeśli używasz takich bibliotek, musisz zastosować tę samą licencję do swojej aplikacji lub biblioteki.

Licencje mogą się zmieniać w dowolnym wydaniu. Podczas aktualizacji sprawdź, czy używane przez Ciebie zależności są objęte licencją zgodną z Twoją aplikacją lub biblioteką.

Jeśli licencja jest niezgodna (lub stała się niezgodna), nie możesz używać tej wersji biblioteki. Możesz:

• Skontaktuj się z właścicielem biblioteki i poproś o przedłużenie obecnej licencji lub o przyznanie podwójnej licencji, aby umożliwić korzystanie ze starej licencji.
• Skontaktuj się z zespołem prawnym, aby ustalić, czy możesz zmienić licencję na zgodną.
• Znajdź inną bibliotekę z kompatybilną licencją i w razie potrzeby zmodyfikuj aplikację.
• Utwórz odgałęzienie ostatniej zgodnej wersji biblioteki (jeśli licencja na to zezwala i jeśli zmiany nie mają charakteru wstecznego) i wprowadź własne zmiany.