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. Twoje ulepszenia wpływają na konsumentów. Jeśli uaktualnisz jedną z zależności, ta wersja stanie się kandydatem do rozwiązania zależności Gradle, co może spowodować przerwanie korzystania z tej zależności 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 wydaniem. 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 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 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 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 programowania i publikowania;

  • 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 ulepszeniami. 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 jest wewnętrzna dla 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 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 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.

Tworzenie zależności i ich relacji
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 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 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 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.

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 używa tej samej wersji co kompilator Kotlin lub uruchamia się z wymaganym kompilatorem Kotlin. 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 zobaczysz w edytorze Android Studio lub jeśli korzystasz z niektórych narzędzi i wtyczek do obsługi zależności.

Niektóre biblioteki określają minimalną liczbę compileSdk lub minSdk wymaganą do korzystania z biblioteki. Jeśli nie użyjesz co najmniej określonej wartości compileSdk, kompilacje nie powiedzą się. Jednak minSdk aplikacji jest automatycznie ustawiana 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ć opóźnione w rozwoju, 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 momencie instalacji lub w czasie 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, takie jak 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 w dowolnym momencie zaktualizować Android Studio. 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, te opcje znajdziesz w menu Narzędzia:

Java

Jeśli w aplikacji na Androida masz kod źródłowy w języku Java, możesz skorzystać z nowszych 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 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 kompilacji 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 też zaktualizowane wersje swoich zależności. Może to szybko doprowadzić do ogromnego zbioru 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 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 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 zrzutu ekranu przed i po oraz ich porównanie.

Konfigurowanie i tworzenie pierwszego punktu odniesienia

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

W idealnej sytuacji należy wyeliminować jak najwięcej ostrzeżeń lub utworzyć wartości bazowe, aby śledzić, które ostrzeżenia już się pojawił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. Zapisz go w systemie kontroli wersji (VCS).

Pamiętaj, że Dependency Guard rejestruje tylko listę zależności bibliotek. W plikach kompilacji znajdują się inne zależności, np. wersje pakietu SDK Androida i JDK. Złożenie w VCS przed zmianą zależności pozwala 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 do rejestrowania wartości bazowych ostrzeżeń używasz innych narzędzi, takich jak Kotlin Warning Baseline czy Kotlin Warnings Baseline Generator, zaktualizuj też ich wartości bazowe.

Aby zaktualizować raport podstawowy, uruchom ./gradlew dependencyGuard. Następnie uruchom narzędzie VCS diff, aby zobaczyć zmiany nie związane z 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:

Aktualizacje 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 taki komunikat, 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, nad którymi trwają prace lub które 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 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 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 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 skupił się na zgodności i rozwiązaniu problemów z aktualizacją.

Informacje o wersji

Sprawdź informacje o wersji (jeśli są dostępne) każdej zmienionej biblioteki. Sprawdź, czy nie ma żadnych zmian, które powodują przerwanie działania aplikacji lub nowych wymagań, takich jak dodane uprawnienia.

Pliki README

Niektóre pliki README dla 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ącego 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 bazy danych 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ą rozwiązywane zgodnie z oczekiwaniami? Sprawdź, czy nie ma konfliktów, zwłaszcza dużych 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 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 publicznymi repozytoriami:

  • 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, łatwiej będzie Ci debugować problemy 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 zapewnij 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 dodatkowe przypadki testowe, 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ć wycofane funkcje, aby wiedzieć, czy zostały później 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 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 na linii poleceń, chyba że używasz celów 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.

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 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.
  • odrzucać niektóre 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 musisz dokonać selekcji, skup się na aktualizacjach, które są niezbędne do naprawienia 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.

Dokumentuj swoje decyzje. 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.

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 liberalne i często wymagają tylko 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ą 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 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.