Az évszakoktól függően előfordulhat, hogy csak néhány hónappal egy alkalmazás kiadása után jelentik be az Android új verzióját. Mit jelent ez azonban az alkalmazásodra nézve – minden el fog törni?
Örülni fogsz, ha tudod, hogy az Android nagy hangsúlyt fektet az előre kompatibilitásra – a korábbi SDK-k ellenében készült meglévő alkalmazások nem törhetnek el, amikor a felhasználó frissít az Android új verziójára. Itt jön a képbe a compileSdkVersion, a minSdkVersion és a targetSdkVersion: ezek szabályozzák, hogy milyen API-k állnak rendelkezésre, mi a szükséges API-szint, illetve milyen kompatibilitási módokat alkalmaznak.
AcompileSdkVersion segítségével megmondhatja a Gradle-nek, hogy az Android SDK melyik verziójával fordítsa le az alkalmazását. Az új Android SDK használata feltétele az adott szinten hozzáadott új API-k használatának.
Kiemelendő, hogy a compileSdkVersion módosítása nem változtatja meg a futásidejű viselkedést. Bár a compileSdkVersion megváltoztatásakor új fordítói figyelmeztetések/hibák jelenhetnek meg, a compileSdkVersion nem szerepel az APK-ban: pusztán fordítási időben használják. (Ezeket a figyelmeztetéseket azonban tényleg ki kellene javítanod – nem véletlenül kerültek bele!)
Ezért erősen ajánlott, hogy mindig a legújabb SDK-val fordítsd le. Így megkapja az új fordítási ellenőrzések minden előnyét a meglévő kódon, elkerülheti az újonnan elavult API-kat, és készen áll az új API-k használatára.
Megjegyezzük, hogy ha a Support Library-t használja, a legújabb SDK-val való fordítás feltétele a Support Library legújabb kiadásainak használatának. Például a 23.1.1 Support Library használatához legalább 23-as compileSdkVersionre van szükség (az első számoknak meg kell egyezniük!). Általában a Support Library új verziója az új platformverzióval együtt jelenik meg, és kompatibilitást biztosít az újonnan hozzáadott API-khoz, valamint az új funkciókhoz.
minSdkVersion
Ha a compileSdkVersion a legújabb elérhető API-kat állítja be, a minSdkVersion az alkalmazás alsó határa. A minSdkVersion az egyik olyan jel, amelyet a Google Play Áruház arra használ, hogy meghatározza, hogy a felhasználó mely eszközeire telepíthető egy alkalmazás.
A fejlesztés során is fontos szerepet játszik: alapértelmezés szerint a lint lefut a projekted ellen, és figyelmeztet, ha a minSdkVersion feletti API-kat használsz, így segít elkerülni azt a futásidejű problémát, hogy olyan API-t próbálsz meghívni, amely nem létezik. A rendszerverzió futás közbeni ellenőrzése gyakori technika, amikor API-kat csak újabb platformverziókon használunk.
Ne feledje, hogy az Ön által használt könyvtáraknak, például bármelyik támogató könyvtárnak vagy Google Play szolgáltatásnak saját minSdkVersionje lehet – az alkalmazása minSdkVersionjének legalább olyan magasnak kell lennie, mint a függőségek minSdkVersionjének – ha olyan könyvtárai vannak, amelyek 4, 7 és 9-et igényelnek, a minSdkVersionnek legalább 9-nek kell lennie. Ritka esetekben, amikor továbbra is olyan könyvtárat akarsz használni, amelynek minSdkVersionje magasabb, mint az alkalmazásodé (és az összes szélsőséges esetet kezelni/biztosítani, hogy a könyvtárat csak újabb platformverziókon használd), használhatod a tools:overrideLibrary jelölőt, de mindenképpen alaposan teszteld!
A minSdkVersion meghatározásakor figyelembe kell vennie a Dashboardok statisztikáit, amelyek átfogó képet adnak az összes olyan eszközről, amely az előző 7 napban meglátogatta a Google Play Áruházat – ez a potenciális közönsége, amikor egy alkalmazást tesz fel a Google Playre. Végső soron üzleti döntés, hogy az eszközök további 3%-ának támogatása megéri-e a legjobb élmény biztosításához szükséges fejlesztési és tesztelési időt.
Természetesen, ha egy új API kulcsfontosságú az egész alkalmazásod számára, akkor ez megkönnyíti a minSdkVersion vitát. Csak ne feledjük, hogy 1,4 milliárd eszköznek még 0,7%-a is sok eszköz.
targetSdkVersion
A három közül azonban a legérdekesebb a targetSdkVersion. targetSdkVersion a fő módja annak, hogy az Android előre kompatibilitást biztosítson azáltal, hogy nem alkalmazza a viselkedésváltozásokat, amíg a targetSdkVersion nem frissül. Ez lehetővé teszi az új API-k használatát (hiszen frissítette a compileSdkVersiont, ugye?) a viselkedésváltozások átdolgozása előtt.
A targetSdkVersion által implikált viselkedésváltozások nagy része közvetlenül a VERSION_CODES-ban van dokumentálva, de az összes véres részletet az egyes kiadások platformkiemelésekben is felsorolják, szépen összekapcsolva az API Levels táblázatban.
Például az Android 6.0 változások azt beszélik el, hogy a 23-as API megcélzása hogyan vezeti át az alkalmazást a futásidejű engedélyek modelljére, az Android 4.4 viselkedési változásai pedig azt részletezik, hogy a 19-es vagy magasabb API megcélzása hogyan változtatja meg a set() és a setRepeating() segítségével beállított riasztások működését.
Mivel néhány viselkedési változás nagyon is látható a felhasználók számára (a menügomb elavulása, futásidejű engedélyek stb.), a legújabb SDK-t célzó frissítésnek minden alkalmazás számára kiemelt prioritást kell élveznie. Ez nem jelenti azt, hogy minden bevezetett új funkciót használni kell, és nem is szabad vakon, tesztelés nélkül frissíteni a targetSdkVersiont – kérem, kérem, teszteljen, mielőtt frissíti a targetSdkVersiont! A felhasználóid meg fogják köszönni.
Gradle és SDK verziók
A helyes compileSdkVersion, minSdkVersion és targetSdkVersion beállítása tehát fontos. Ahogy azt a Gradle és az Android Studio világában elképzelhetjük, ezek az értékek a modulunk build.gradle fájljába való felvételen keresztül integrálódnak az eszközrendszerbe (az Android Studio Project Structure opcióján keresztül is elérhető):
android {
compileSdkVersion 23
buildToolsVersion "23.0.1"
defaultConfig {
applicationId "com.example.checkyourtargetsdk"
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName "1.0"
}
}
A compileSdkVersion, mivel egy fordítási idejű dolog (ki gondolta volna!), a build tools verziójával együtt az android beállítások egyike. A másik kettő kicsit másképp van, mivel a build variánsok szintjén vannak deklarálva – a defaultConfig az alapja az összes build variánsnak, és hova tennéd az alapértelmezett értékeket ezekhez, de el tudnál képzelni egy bonyolultabb rendszert, ahol az alkalmazásod bizonyos verzióinak más minSdkVersion van például.
minSdkVersion és targetSdkVersion abban is különbözik a compileSdkVersion-től, hogy ezek szerepelnek a végleges APK-dban – ha megnéznéd a generált AndroidManifest.xml-t, akkor egy olyan taget látnál, mint:
<uses-sdk android:targetSdkVersion="23" android:minSdkVersion="7" />
Ha ezt manuálisan teszed a manifesztedbe, akkor a Gradle-vel való építkezés során figyelmen kívül hagyják (bár más build rendszerek biztosan számíthatnak arra, hogy ott van).
Az egészet összerakva
Ha végigmentél a félkövérrel szedett megjegyzéseken, észre fogod venni a kapcsolatot a három érték között:
minSdkVersion <= targetSdkVersion <= compileSdkVersion
Ez intuitívan értelmes – ha a compileSdkVersion a “maximum” és a minSdkVersion a “minimum”, akkor a maximumnak legalább akkorának kell lennie, mint a minimumnak, a célnak pedig valahol a kettő között kell lennie.
Az összefüggés valójában inkább így nézne ki az állandósult állapotban:
minSdkVersion (lowest possible) <=
targetSdkVersion == compileSdkVersion (latest SDK)
Az alacsony minSdkVersionnel a legnagyobb közönséget fogod elérni, és a legjobban fogsz kinézni és viselkedni, ha a legújabb SDK-val célzol és fordítasz – ez a #BuildBetterApps nagyszerű módja.
Vegyél részt a vitában a Google+ poszton, és kövesd az Android Development Patterns Collectiont a továbbiakért!
