Zależnie od pory roku, może to być tylko kilka miesięcy po wydaniu aplikacji, że nowa wersja Androida jest ogłoszona. Co to jednak oznacza dla twojej aplikacji – czy wszystko się zepsuje?

Będziesz szczęśliwy wiedząc, że kompatybilność w przód jest mocnym punktem Androida – istniejące aplikacje zbudowane w oparciu o wcześniejsze SDK nie powinny się zepsuć, gdy użytkownik zaktualizuje je do nowej wersji Androida. Tutaj właśnie wkraczają compileSdkVersion, minSdkVersion i targetSdkVersion: kontrolują one, jakie API są dostępne, jaki jest wymagany poziom API i jakie tryby kompatybilności są stosowane, odpowiednio.

compileSdkVersion jest twoim sposobem na powiedzenie Gradle, z jaką wersją SDK Androida skompilować twoją aplikację. Używanie nowego Android SDK jest wymogiem do korzystania z dowolnego z nowych API dodanych w tym poziomie.

Należy podkreślić, że zmiana wersji compileSdkVersion nie zmienia zachowania runtime. Podczas gdy nowe ostrzeżenia/błędy kompilatora mogą być obecne przy zmianie wersji compileSdkVersion, twoja wersja compileSdkVersion nie jest zawarta w twoim APK: jest używana tylko w czasie kompilacji. (Powinieneś jednak naprawić te ostrzeżenia – zostały dodane nie bez powodu!)

Dlatego zdecydowanie zaleca się, aby zawsze kompilować z najnowszym SDK. Uzyskasz wszystkie korzyści z nowych kontroli kompilacji istniejącego kodu, unikniesz nowo przestarzałych API i będziesz gotowy do użycia nowych API.

Zauważ, że jeśli używasz Biblioteki Wsparcia, kompilacja z najnowszym SDK jest wymagana do użycia najnowszych wydań Biblioteki Wsparcia. Na przykład, aby używać Biblioteki Wsparcia 23.1.1, musisz mieć wersję compileSdkVersion co najmniej 23 (te pierwsze liczby muszą się zgadzać!). Ogólnie rzecz biorąc, nowa wersja Biblioteki Wsparcia jest wydawana wraz z nową wersją platformy, zapewniając podkładki kompatybilności do nowo dodanych API, jak również nowe funkcje.

minSdkVersion

Jeśli compileSdkVersion ustawia najnowsze API dostępne dla Ciebie, minSdkVersion jest dolną granicą dla Twojej aplikacji. MinSdkVersion jest jednym z sygnałów używanych przez Google Play Store do określenia, na którym z urządzeń użytkownika można zainstalować aplikację.

Odgrywa również ważną rolę podczas rozwoju: domyślnie lint działa przeciwko twojemu projektowi, ostrzegając cię, gdy używasz jakichkolwiek API powyżej minSdkVersion, pomagając ci uniknąć problemu runtime związanego z próbą wywołania API, które nie istnieje. Sprawdzanie wersji systemu podczas uruchamiania jest powszechną techniką podczas korzystania z interfejsów API tylko na nowszych wersjach platformy.

Pamiętaj, że biblioteki, których używasz, takie jak dowolna z bibliotek wsparcia lub usług Google Play, mogą mieć własne minSdkVersion – minSdkVersion twojej aplikacji musi być co najmniej tak wysoka, jak minSdkVersion twoich zależności – jeśli masz biblioteki, które wymagają 4, 7 i 9, twoja minSdkVersion musi być co najmniej 9. W rzadkich przypadkach, gdy chcesz nadal używać biblioteki z wyższą minSdkVersion niż twoja aplikacja (i radzić sobie ze wszystkimi przypadkami brzegowymi / upewnić się, że biblioteka jest używana tylko na nowszych wersjach platformy), możesz użyć znacznika tools:overrideLibrary, ale upewnij się, że dokładnie przetestowałeś!

Podejmując decyzję o minSdkVersion, powinieneś rozważyć statystyki na Dashboardach, które dają ci globalne spojrzenie na wszystkie urządzenia, które odwiedziły Sklep Google Play w ciągu ostatnich 7 dni – to jest twoja potencjalna publiczność podczas umieszczania aplikacji w Google Play. Jest to ostatecznie decyzja biznesowa o tym, czy wspieranie dodatkowych 3% urządzeń jest warte czasu rozwoju i testowania wymaganego do zapewnienia najlepszego doświadczenia.

Oczywiście, jeśli nowy interfejs API jest kluczem do całej aplikacji, to sprawia, że dyskusja minSdkVersion jest nieco łatwiejsza. Pamiętaj tylko, że nawet 0,7% z 1,4 miliarda urządzeń to dużo urządzeń.

targetSdkVersion

Najciekawszym z tych trzech jest jednak targetSdkVersion. targetSdkVersion to główny sposób, w jaki Android zapewnia kompatybilność w przód, nie stosując zmian w zachowaniu, chyba że targetSdkVersion zostanie zaktualizowany. Pozwala to na używanie nowych API (ponieważ zaktualizowałeś swoją wersję kompilacjiSdkVersion, prawda?) przed przejściem przez zmiany w zachowaniu.

Większość zmian w zachowaniu, które targetSdkVersion implikuje są udokumentowane bezpośrednio w VERSION_CODES, ale wszystkie krwawe szczegóły są również wymienione w każdym wydaniu „platform highlights”, ładnie połączone w tabeli Poziomy API.

Na przykład, zmiany w Androidzie 6.0 zmiany rozmawiać przez jak celowanie API 23 przechodzi swoją aplikację do modelu uprawnień runtime i Android 4.4 zmiany zachowania szczegóły, jak celowanie API 19 lub wyższe zmienia jak alarmy ustawione z set() i setRepeating() pracy.

Z niektórych zmian w zachowaniu są bardzo widoczne dla użytkowników (deprecjacja przycisku menu, uprawnienia runtime, itp.), aktualizacja do celu najnowszego SDK powinien być wysoki priorytet dla każdej aplikacji. Nie oznacza to, że musisz używać każdej nowo wprowadzonej funkcji, ani że powinieneś ślepo aktualizować swój targetSdkVersion bez testowania – proszę, przetestuj przed aktualizacją targetSdkVersion! Twoi użytkownicy będą Ci wdzięczni.

Gradle i wersje SDK

Więc ustawienie poprawnych wersji compileSdkVersion, minSdkVersion i targetSdkVersion jest ważne. Jak można sobie wyobrazić w świecie z Gradle i Android Studio, wartości te są zintegrowane z systemem narzędzi poprzez włączenie do pliku build.gradle twojego modułu (dostępnego również poprzez opcję Project Structure w Android Studio):

android {
compileSdkVersion 23
buildToolsVersion "23.0.1"
defaultConfig {
applicationId "com.example.checkyourtargetsdk"
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
}

CompileSdkVersion, będąc rzeczą czasu kompilacji (kto by przypuszczał!), jest jednym z ustawień androida wraz z twoją wersją narzędzi do budowania. Pozostałe dwa są nieco inne, ponieważ są zadeklarowane na poziomie wariantu kompilacji – defaultConfig jest bazą dla wszystkich wariantów kompilacji i gdzie umieściłbyś domyślne wartości dla nich, ale mógłbyś sobie wyobrazić bardziej skomplikowany system, w którym konkretne wersje twojej aplikacji mają różne minSdkVersion na przykład.

minSdkVersion i targetSdkVersion również różnią się od compileSdkVersion tym, że są zawarte w twoim finalnym APK – jeśli spojrzałbyś na wygenerowany AndroidManifest.xml, zobaczyłbyś tag taki jak:

<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />

Zobaczysz, że jeśli ręcznie umieścisz to w swoim manifeście, zostanie on zignorowany podczas budowania z Gradle (chociaż inne systemy budowania mogą z pewnością polegać na tym, że tam jest).

Połączenie tego wszystkiego razem

Jeśli przebrnąłeś przez pogrubione notatki, zauważysz związek między trzema wartościami:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

To intuicyjnie ma sens – jeśli compileSdkVersion jest twoim „maksimum”, a minSdkVersion jest twoim „minimum”, wtedy twoje maksimum musi być co najmniej tak wysokie jak twoje minimum, a cel musi być gdzieś pomiędzy.

Idealnie, relacja wyglądałaby bardziej jak ta w stanie ustalonym:

minSdkVersion (lowest possible) <= 
targetSdkVersion == compileSdkVersion (latest SDK)

Uderzysz w największą publiczność z niską minSdkVersion i wyglądasz i działasz najlepiej, celując i kompilując z najnowszym SDK – świetny sposób na #BuildBetterApps.

Dołącz do dyskusji w poście na Google+ i śledź kolekcję Android Development Patterns po więcej!

.