Uaktualnianie wersji 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ć.

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. Wprowadzone przez Ciebie zmiany wpływają na Twoich klientó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 wersjonowania przed wersją beta. Staraj się unikać uaktualnień wersji major, aby nie pogorszyć klientów.

Rozważ utworzenie listy kwalifikacyjnej do publikacji (RC) w swojej bibliotece, aby użytkownicy mogli ją wcześniej przetestować.

Szczegółowe informacje o zapewnianiu 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 lub starszych wersjach 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 tych uaktualnieniach.

Jeśli uaktualnienie biblioteki wymaga zmian powodujących niezgodność, które mogą być szczególnie uciążliwe dla klientów, rozważ opublikowanie ich jako nowego artefaktu, aby umożliwić współistnienie starej i nowej wersji i umożliwić bardziej stopniowe wdrożenie.

Uwaga: jeśli uaktualnienie do jednej z zależności powoduje znaczną zmianę interfejsu API, warto uaktualnić ją 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 je cofnąć.
  • Narzędzia takie jak Dependabot i Renovate zmniejszają natężenie pracy, ale pamiętaj, aby przeanalizować wyniki i sprawdzić, czy nie ma w nich zagrożeń.

Dłuższe cykle tworzenia i publikowania

  • Masz więcej czasu na wprowadzenie i przetestowanie ulepszeń.
  • Nowsze wersje zależności są częściej publikowane w ramach cyklu.
  • Wycofywanie uaktualnień i publikowanie aplikacji lub biblioteki trwa dłużej.

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 ulepszeniami. Przyszłe uaktualnienia są łatwiejsze (mniej zmian do zintegrowania), ale wiążą się z częstszym podejmowaniem ryzyka.

Testowanie uaktualnień bibliotek do wersji przedpremierowych (alfa, beta, kandydująca do wydania) może ułatwić gotowość do udostępnienia wersji stabilnych.

Nowa zależność

Jeśli dodajesz nową zależność, rozważ przeprowadzenie szczegółowej weryfikacji, która polega na sprawdzeniu tej biblioteki pod kątem wszystkich kryteriów ryzyka, aby mieć pewność, że zostały prawidłowo ocenione. Nie zezwalaj na dodawanie nowych zależności bez sprawdzenia.

Zespół ds. współpracy z partnerami

Czy masz specjalny zespół budowlany? Czy kompilację zajmują się inżynierowie oprogramowania? 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 tworzenia, takie jak wtyczki Gradle i Gradle, zwykle mają mniejszy wpływ na użytkowników, a duże ryzyko jest wewnętrzne w kompilacji. Sama kompilacja pomaga potwierdzić 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ą minimalnej wersji Kotlin lub Javy albo chcesz skorzystać z nowych funkcji językowych, 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 nadać priorytet bibliotekom na podstawie bliskości 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 w 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

Dostępnych jest wiele narzędzi i wtyczek, które ułatwiają uaktualnienia. Narzędzia takie jak Dependabot i Renovate automatycznie aktualizują wersje bibliotek w Twoim kompilacie, ale 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, który 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.

Tworzenie zależności i relacji między nimi
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 przejścia na AGP, który może pomóc w wykonywaniu tych zadań.

Jeśli korzystasz z Asystenta lub przeprowadzasz uaktualnienie ręcznie, pamiętaj o tych kwestiach:

Przeczytaj informacje o wersji AGPL.

Uaktualnij Gradle do co najmniej podanej wersji.

Uaktualnij Android Studio do wersji, która obsługuje 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 SDK Build Tools, 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 korzystasz z Jetpack Compose:

Jeśli używasz Kotlin Symbol Processing (KSP), zapoznaj się z krótkim wprowadzeniem do KSP, aby dowiedzieć się, jak je skonfigurować, oraz z dostępnymi wersjami KSP. Pamiętaj, że musisz użyć wersji KSP, która jest zgodna 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 musisz uaktualniać procesorów KSP (np. kompilatora sal, który pojawia się jako zależność ksp w plikach kompilacji). Wtyczka KSP pobiera znaczną część interfejsu API kompilatora, a interfejs KSP API używany przez procesory jest stabilny.

Zaktualizuj wszystkie używane 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 sprawdź ich dokumentację, aby dowiedzieć się, jak prawidłowo je mapować.

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 korzysta z tej samej wersji co kompilator Kotlin lub zaczyna od wymaganej wersji. Jeśli na przykład 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 będą widoczne w edytorze Android Studio lub w przypadku korzystania z narzędzi i wtyczek.

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 tworzysz wtyczkę do Gradle, uaktualnij ją jak najszybciej, zwłaszcza jeśli jest ona publiczna.

Niektóre uaktualnienia Gradle wymagają znalezienia nowych wersji używanych wtyczek. Pamiętaj, że opracowanie tych wtyczek może opóźnić się z powodu uaktualnienia ich do najnowszych interfejsów 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.
  • Uaktualnij 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 SDK na Androida zawiera nowe funkcje i interfejsy API, poprawki błędów oraz zmiany w działaniu. Sklep Play wymaga zaktualizowania elementu targetSdk, ale warto zaktualizować targetSdk wcześniej niż wyznaczone terminy, aby dać Ci 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ć podczas instalacji lub działania.
  • 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, takie jak AndroidX, wymagają co najmniej compileSdk.

Aby korzystać z nowych funkcji pakietu SDK w trakcie programowania i zapewnić zgodność podczas kompilacji, uaktualnij wtyczkę Android Gradle (AGP) i Android Studio. Obejmują one nowe i ulepszone narzędzia do obsługi 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 w dowolnym momencie zaktualizować Android Studio. Możesz zobaczyć komunikaty z prośbą o uaktualnienie AGP lub uaktualnienie 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:

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 podają, który poziom języka Java jest obsługiwany, oraz potencjalne problemy. 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 zachowaniu w informacji o wersji, nawet jeśli nie masz kodu źródłowego w języku Java.

Korzystanie z JDK jest określone w kilku miejscach w skryptach kompilacji. Więcej informacji znajdziesz w sekcji Wersje Java w kompilacji na Androida.

Analiza uaktualnienia

Uaktualnianie zależności może wiązać się z ryzykiem związanym ze zmianami interfejsu API i działań, nowymi wymaganiami dotyczącymi użytkowania, nowymi problemami z zabezpieczeniami, a nawet zmianami licencji. Czy na przykład musisz:

  • Zmienić kod zmian w interfejsie API?
  • Dodać nowe kontrole uprawnień?
  • Utworzyć dodatkowe testy lub zmodyfikować istniejące testy, aby uwzględnić zmiany zachowania?

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

Jeśli używasz narzędzia takiego jak Renovate lub Dependabot do automatyzacji uaktualnień, pamiętaj, że nie wykonuje ono żadnej analizy. Zamiast tego uaktualnia biblioteki do najnowszych wersji. Nie zakładaj, że wszystko będzie działać prawidłowo po takich automatycznych uaktualnieniach.

Kluczem do udanego przekształcenia jest analiza uaktualnień:

  1. Określ różnice w zależnościach przed i po uaktualnieniu.
  2. Należy przeanalizować każdą zmianę i określić związane z nią ryzyko.
  3. Zmniejszanie ryzyka lub akceptowanie i 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 i porównanie zrzutów przed i po.

Skonfiguruj i utwórz pierwszy element bazowy

Przed rozpoczęciem aktualizacji upewnij się, że projekt został skompilowany.

Najlepiej wyeliminuj jak najwięcej ostrzeżeń lub utwórz punkty odniesienia, które pozwolą Ci monitorować, które ostrzeżenia już się wyświetlały.

Te ostrzeżenia ułatwiają zauważanie nowych ostrzeżeń wprowadzanych podczas aktualizacji zależności.

Utwórz bazę danych zależności, konfigurując i uruchamiając Dependency Guard. 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 konfiguracji wymienionej 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. Aby zapisać plik, zatwierdź go w systemie kontroli wersji (VCS).

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

Uaktualnianie i porównywanie z wartością odniesienia

Gdy masz już wartości bazowe, 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 używasz innych narzędzi do rejestrowania wartości bazowych ostrzegawczych, takich jak Kotlin Ostrzeżenie Baseline lub Generator ostrzeżeń Kotlin, rozwiąż nowe ostrzeżenia i zaktualizuj też ich wartości bazowe.

Aby zaktualizować raport podstawowy, uruchom raport ./gradlew dependencyGuard. Następnie uruchom różnice w VCS, aby zobaczyć zmiany niezwiązane z biblioteką. Prawdopodobnie zawiera ona znacznie więcej uaktualnień biblioteki, niż Ci się wydaje.

Analizowanie zagrożeń

Gdy dowiesz się, co się zmieniło, zastanów się nad możliwymi zagrożeniami związanymi z każdą uaktualnioną 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.

O czym warto pamiętać:

Główne wzrosty wersji

Czy zmienił się numer wersji głównej?

W obsłudze wersji semantycznych pierwsza numer jest nazywana wersją główną. Na przykład po uaktualnieniu biblioteki z 1.2.3 do 2.0.1 wersja główna uległa zmianie. Zwykle oznacza to, że deweloper biblioteki wprowadził niezgodne zmiany między wersjami, np. usunął lub zmienił części interfejsu API.

W takiej sytuacji zwracaj szczególną uwagę na biblioteki, których dotyczy problem.

Jeśli Twój kod korzysta z jakiegokolwiek eksperymentalnego interfejsu API (który często wymaga użycia adnotacji lub specyfikacji pliku kompilacji), nawet zmiany wersji w ramach wersji podrzędnej lub poprawki, 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 nastąpiły zmiany lub usunięcia.

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 scalone z Twoją 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 Google Play, które są aktualizowane niezależnie od pakietu Android SDK. 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 zauważysz, ż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

Zapoznaj się z informacjami o wersji (jeśli zostały udostępnione) w przypadku każdej zmienionej biblioteki. Sprawdź, czy nie ma zmian, które powodują przerwanie działania aplikacji lub nowych wymagań, takich jak dodane uprawnienia.

Pliki README

Niektóre pliki README biblioteki zawierają informacje o potencjalnych zagrożeniach, zwłaszcza jeśli biblioteka nie zawiera informacji o wersji. Sprawdź _znane problemy_, zwłaszcza znane problemy 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 jednego 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 zgodności z 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.

Konflikty wersji

Czy wersje są rozpoznawane zgodnie z oczekiwaniami? Sprawdź, czy nie ma konfliktów, zwłaszcza dużych różnic między wersjami. Szczegółowe informacje o tym, jak wyszukiwać konflikty, znajdziesz w artykule Rozwiązywanie zależności Gradle. W szczególności w raporcie ./gradlew app:dependencies wyszukaj ->.

W miarę możliwości współpracuj z autorami zależności, aby rozwiewać ich zależności. 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 zostać zastąpiona licencją, 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 zaległości dotyczą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, łatwiej będzie debugować problemy niż w przypadku źródeł zamkniętych, niezależnie od tego, czy są one zawarte w kodzie czy w kodzie biblioteki.

Zminimalizuj zależności między zamkniętymi źródłami i poddaj 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ę na użycie zależności open source, przygotuj dodatkowe przypadki testowe, które pomogą 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 jest przyczyną tych problemów, zaznacz ją jako bibliotekę, której nie należy aktualizować.

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 interfejsami 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 compileSdk i zaczniesz używać nowych interfejsów API, lint będzie zgłaszać te, które są niedostępne w poprzednich wersjach pakietu SDK.

Lint działa w edytorze Android Studio, zgłaszając problemy podczas wprowadzania zmian. Zwykle nie uruchamia się jednak w ramach kompilacji w Studio ani w ramach kompilacji z poziomu wiersza poleceń, chyba że używasz wartości docelowych 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 najmniej od czasu do czasu uruchamiać gradlew lint.

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 biblioteki zawierają nowe ostrzeżenia i błędy dotyczące lintowania, co powoduje generowanie nowych raportów podczas kompilacji.

Zmniejszanie ryzyka

Po określeniu zagrożeń związanych z aktualizacją 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.
  • Od razu odrzucaj zagrożenia. 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 trzeba je uporządkować, skup się na uaktualnieniach niezbędnych w przypadku napotkanych błędów i nowych funkcji.
  • Minimalizowanie pozostałych zagrożeń
    • Rozważ zgrupowanie 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. W razie potrzeby dodaj nowe testy, aby zwiększyć wiarygodność uaktualnienia.
    • Jeśli znajdziesz coś podejrzanego, sprawdź źródło (jeśli jest dostępne).
    • Wprowadź wymagane zmiany w źródle lub kompilacji.

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

Weryfikowanie 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 rygorystyczne i często wymagają jedynie podania informacji o bibliotece i wyświetlenia jej tekstu 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ą licencjonowane w sposób zgodny 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 obowiązywania dotychczasowej 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 zgodną 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.