Wersjonowanie jest kluczowym elementem strategii uaktualniania i konserwacji aplikacji. Wersjonowanie jest ważne, ponieważ:
- Użytkownicy muszą mieć konkretne informacje o wersji aplikacji zainstalowanej na ich urządzeniach oraz o wersjach aktualizacji dostępnych do zainstalowania.
- Inne aplikacje – w tym inne aplikacje, które publikujesz jako pakiet – muszą wysyłać do systemu zapytania o wersję Twojej aplikacji, aby określić zgodność i zidentyfikować zależności.
- Usługi, w których publikujesz aplikacje, mogą też wysyłać do nich zapytania o wersję, aby wyświetlać ją użytkownikom. Usługa publikowania może też sprawdzać wersję aplikacji, aby określić zgodność i ustalić relacje między uaktualnieniem a obniżeniem wersji.
System Android używa informacji o wersji aplikacji, aby chronić ją przed obniżeniem wersji. System nie używa informacji o wersji aplikacji do egzekwowania ograniczeń dotyczących uaktualnień ani zgodności aplikacji innych firm. Aplikacja musi egzekwować wszelkie ograniczenia wersji i informować o nich użytkowników.
System Android wymusza zgodność wersji systemu, co jest wyrażone przez ustawienie minSdk
w plikach kompilacji. To ustawienie
umożliwia aplikacji określenie minimalnego interfejsu API systemu, z którym jest zgodna.
Więcej informacji o wymaganiach dotyczących interfejsu API znajdziesz w artykule Określanie wymagań dotyczących poziomu interfejsu API (wersji pakietu SDK).
Wymagania dotyczące wersji różnią się w zależności od projektu. Wielu programistów uważa jednak, że wersjonowanie semantyczne jest dobrym punktem wyjścia do opracowania strategii wersjonowania.
Ustawianie informacji o wersji aplikacji
Aby zdefiniować informacje o wersji aplikacji, ustaw wartości dla ustawień wersji w plikach kompilacji Gradle:
Groovy
android { namespace 'com.example.testapp' compileSdk 33 defaultConfig { applicationId "com.example.testapp" minSdk 24 targetSdk 33 versionCode 1 versionName "1.0" ... } ... } ...
Kotlin
android { namespace = "com.example.testapp" compileSdk = 33 defaultConfig { applicationId = "com.example.testapp" minSdk = 24 targetSdk = 33 versionCode = 1 versionName = "1.0" ... } ... } ...
Ustawienia wersji
Określ wartości obu dostępnych ustawień wersji: versionCode
i versionName
.
versionCode
- Dodatnia liczba całkowita używana jako wewnętrzny numer wersji.
Ta liczba pomaga określić, czy jedna wersja jest nowsza od drugiej. Wyższe liczby oznaczają nowsze wersje. Nie jest to numer wersji widoczny dla użytkowników. Jest on określany przez ustawienie
versionName
. System Android używa wartościversionCode
, aby chronić przed obniżeniem wersji, uniemożliwiając użytkownikom instalowanie pliku APK z wartościąversionCode
niższą niż wersja zainstalowana obecnie na urządzeniu.Wartość jest dodatnią liczbą całkowitą, dzięki czemu inne aplikacje mogą ją oceniać programowo, np. sprawdzać relację uaktualnienia lub obniżenia wersji. Możesz ustawić dowolną dodatnią liczbę całkowitą. Pamiętaj jednak, aby każda kolejna wersja aplikacji miała większą wartość.
Uwaga: największa wartość, jaką dopuszcza Google Play, to 2100000000.
versionCode
Nie możesz przesłać do Sklepu Play pliku APK z kodem wersji
versionCode
, który został już użyty w poprzedniej wersji.Uwaga: w niektórych sytuacjach możesz przesłać wersję aplikacji z numerem
versionCode
niższym niż najnowsza wersja. Jeśli na przykład publikujesz wiele plików APK, możesz mieć wstępnie ustawioneversionCode
zakresy dla poszczególnych plików APK. Więcej informacji o przypisywaniu wartościversionCode
do wielu plików APK znajdziesz w sekcji Przypisywanie kodów wersji.Zwykle pierwsza wersja aplikacji ma wartość
versionCode
ustawioną na 1, a potem jest ona zwiększana monotonicznie z każdą kolejną wersją, niezależnie od tego, czy jest to wersja główna czy pomocnicza. Oznacza to, że wartośćversionCode
nie musi odpowiadać wersji aplikacji widocznej dla użytkownika. Aplikacje i usługi publikacyjne nie powinny wyświetlać użytkownikom tej wartości. versionName
Ciąg znaków używany jako numer wersji wyświetlany użytkownikom. To ustawienie można określić jako surowy ciąg znaków lub jako odwołanie do zasobu ciągu znaków.
Wartość jest ciągiem znaków, dzięki czemu możesz opisać wersję aplikacji jako ciąg znaków <major>.<minor>.<point> lub jako dowolny inny typ bezwzględnego lub względnego identyfikatora wersji. Wartość
versionName
jest jedyną wartością wyświetlaną użytkownikom.
Określanie wartości wersji
Możesz zdefiniować wartości domyślne tych ustawień, umieszczając je w bloku defaultConfig {}
, który jest zagnieżdżony w bloku android {}
w pliku build.gradle
lub build.gradle.kts
modułu. Możesz zastąpić te wartości domyślne w przypadku różnych wersji aplikacji, definiując osobne wartości dla poszczególnych typów kompilacji lub wersji produktu. Poniższy plik pokazuje ustawienia versionCode
i versionName
w bloku defaultConfig {}
oraz blok productFlavors {}
.
Te wartości są następnie scalane z plikiem manifestu aplikacji podczas procesu kompilacji.
Groovy
android { ... defaultConfig { ... versionCode 2 versionName "1.1" } productFlavors { demo { ... versionName "1.1-demo" } full { ... } } }
Kotlin
android { ... defaultConfig { ... versionCode = 2 versionName = "1.1" } productFlavors { create("demo") { ... versionName = "1.1-demo" } create("full") { ... } } }
W bloku defaultConfig {}
w tym przykładzie wartość versionCode
oznacza, że bieżący plik APK zawiera drugą wersję aplikacji, a ciąg znaków versionName
określa, że użytkownicy zobaczą ją jako wersję 1.1. Ten plik definiuje też 2 wersje produktu: „demo” i „full”. Ponieważ wersja produktu „demo” definiuje versionName
jako „1.1-demo”, kompilacja „demo” używa tego versionName
zamiast wartości domyślnej.
Blok „full” nie definiuje versionName
, więc używa wartości domyślnej „1.1”.
Uwaga: jeśli aplikacja definiuje wersję bezpośrednio w elemencie<manifest>
, wartości wersji w pliku kompilacji Gradle zastępują ustawienia w manifeście. Dodatkowo zdefiniowanie tych ustawień w plikach kompilacji Gradle umożliwia określenie różnych wartości dla różnych wersji aplikacji. Aby zwiększyć elastyczność i uniknąć potencjalnego nadpisania podczas scalania manifestu, usuń te atrybuty z elementu <manifest>
i zamiast tego zdefiniuj ustawienia wersji w plikach kompilacji Gradle.
Platforma Android udostępnia interfejs API, który umożliwia wysyłanie zapytań do systemu o informacje o wersji aplikacji. Aby uzyskać informacje o wersji, użyj metody
PackageManager.getPackageInfo(java.lang.String, int)
.
Określanie wymagań dotyczących poziomu interfejsu API (wersji pakietu SDK)
Jeśli Twoja aplikacja wymaga określonej minimalnej wersji platformy Android, możesz określić to wymaganie dotyczące wersji jako ustawienia poziomu interfejsu API w pliku build.gradle
lub build.gradle.kts
aplikacji. Podczas procesu kompilacji te ustawienia są scalane z plikiem manifestu aplikacji. Określenie wymagań dotyczących poziomu API zapewnia, że aplikację można zainstalować tylko na urządzeniach z kompatybilną wersją platformy Android.
Uwaga: jeśli wymagania dotyczące poziomu interfejsu API określisz bezpośrednio w pliku manifestu aplikacji, odpowiednie ustawienia w plikach kompilacji zastąpią ustawienia w pliku manifestu. Dodatkowo zdefiniowanie tych ustawień w plikach kompilacji Gradle umożliwia określenie różnych wartości dla różnych wersji aplikacji. Aby zwiększyć elastyczność i uniknąć potencjalnego nadpisania podczas scalania pliku manifestu, usuń te atrybuty z elementu <uses-sdk>
i zamiast tego zdefiniuj ustawienia poziomu interfejsu API w plikach kompilacji Gradle.
Dostępne są 2 ustawienia poziomu interfejsu API:
minSdk
– minimalna wersja platformy Android, na której będzie działać aplikacja, określona przez identyfikator poziomu interfejsu API platformy.targetSdk
– poziom interfejsu API powiązany ze stałą<SDK_INT>
, na którym ma działać aplikacja. W niektórych przypadkach umożliwia to aplikacji korzystanie z elementów manifestu lub zachowań zdefiniowanych na docelowym poziomie interfejsu API, zamiast ograniczać się do używania tylko tych zdefiniowanych na minimalnym poziomie interfejsu API.
Nie można określić, że aplikacja jest przeznaczona dla pomocniczej wersji pakietu SDK lub jej wymaga. Aby bezpiecznie wywoływać nowe interfejsy API, które wymagają wyższej wersji głównej lub podrzędnej pakietu SDK niż minSdkVersion
, możesz zabezpieczyć blok kodu za pomocą sprawdzenia wersji podrzędnej lub głównej przy użyciu stałej SDK_INT_FULL
.
if (SDK_INT_FULL >= VERSION_CODES_FULL.[MAJOR or MINOR RELEASE]) { // Use APIs introduced in a major or minor SDK version }
Aby określić domyślne wymagania dotyczące poziomu API w pliku build.gradle
lub build.gradle.kts
, dodaj co najmniej 1 ustawienie poziomu API do bloku defaultConfig{}
zagnieżdżonego w bloku android {}
. Możesz też zastąpić te wartości domyślne w przypadku różnych wersji aplikacji, dodając ustawienia do typów kompilacji lub wersji produktu.
Poniższy plik określa domyślne ustawienia minSdk
i targetSdk
w bloku defaultConfig {}
oraz zastępuje ustawienie minSdk
w przypadku jednego wariantu produktu:
Groovy
android { ... defaultConfig { ... minSdk 21 targetSdk 33 } productFlavors { main { ... } afterNougat { ... minSdk 24 } } }
Kotlin
android { ... defaultConfig { ... minSdk = 21 targetSdk = 33 } productFlavors { create("main") { ... } create("afterNougat") { ... minSdk = 24 } } }
Podczas przygotowywania się do instalacji aplikacji system sprawdza wartości tych ustawień i porównuje je z wersją systemu. Jeśli wartość minSdk
jest większa niż wersja systemu, system uniemożliwia instalację aplikacji.
Jeśli nie określisz tych ustawień, system założy, że aplikacja jest zgodna ze wszystkimi wersjami platformy. Jest to odpowiednik ustawienia wartości minSdk
na 1
.
Więcej informacji znajdziesz w artykule Co to jest poziom API?. Ustawienia kompilacji Gradle znajdziesz w artykule Konfigurowanie wariantów kompilacji.