Afhængigt af årstiden kan det kun være et par måneder efter, at du har udgivet en app, at en ny version af Android bliver annonceret. Men hvad betyder det for din app – går alting i stykker?

Du vil være glad for at vide, at fremadrettet kompatibilitet er et stærkt fokus i Android – eksisterende apps, der er bygget med tidligere SDK’er, bør ikke gå i stykker, når brugeren opdaterer til en ny version af Android. Det er her, at compileSdkVersion, minSdkVersion og targetSdkVersion kommer ind i billedet: De styrer henholdsvis hvilke API’er der er tilgængelige, hvilket API-niveau der kræves, og hvilke kompatibilitetstilstande der anvendes.

compileSdkVersion er din måde at fortælle Gradle, hvilken version af Android SDK’et, der skal kompilere din app med. Brug af det nye Android SDK er et krav for at kunne bruge nogen af de nye API’er, der er tilføjet i dette niveau.

Det skal understreges, at ændring af din compileSdkVersion ikke ændrer køretidsadfærd. Selv om der kan forekomme nye compileradvarsler/fejl, når du ændrer din compileSdkVersion, er din compileSdkVersion ikke inkluderet i din APK: den bruges udelukkende på kompileringstidspunktet. (Du bør dog virkelig rette disse advarsler – de blev tilføjet af en grund!)

Det anbefales derfor på det kraftigste, at du altid kompilerer med den nyeste SDK. Du får alle fordelene ved de nye kompileringskontroller på eksisterende kode, undgår nyligt deprecated API’er og er klar til at bruge nye API’er.

Bemærk, at hvis du bruger supportbiblioteket, er det et krav at kompilere med det nyeste SDK for at kunne bruge de nyeste udgivelser af supportbiblioteket. Hvis du f.eks. vil bruge 23.1.1.1 Support Library, skal du have en compileSdkVersion på mindst 23 (de første tal skal stemme overens!). Generelt udgives en ny version af supportbiblioteket sammen med en ny platformversion, hvilket giver kompatibilitetsskiver til nyligt tilføjede API’er samt nye funktioner.

minSdkVersion

Hvis compileSdkVersion indstiller de nyeste API’er, der er tilgængelige for dig, er minSdkVersion den nedre grænse for din app. MinSdkVersion er et af de signaler, som Google Play Store bruger til at bestemme, hvilke af en brugers enheder en app kan installeres på.

Det spiller også en vigtig rolle under udviklingen: Som standard kører lint mod dit projekt og advarer dig, når du bruger API’er over din minSdkVersion, hvilket hjælper dig med at undgå problemet med at forsøge at kalde et API, som ikke findes. Kontrol af systemversionen ved kørselstid er en almindelig teknik, når du kun bruger API’er på nyere platformversioner.

Husk, at de biblioteker, du bruger, f.eks. et af supportbibliotekerne eller Google Play-tjenesterne, kan have deres egen minSdkVersion – din app’s minSdkVersion skal være mindst lige så høj som dine afhængigheders minSdkVersion – hvis du har biblioteker, der kræver 4, 7 og 9, skal din minSdkVersion være mindst 9. I sjældne tilfælde, hvor du fortsat ønsker at bruge et bibliotek med en højere minSdkVersion end din app (og håndtere alle edge cases/sikre at biblioteket kun bruges på nyere platformversioner), kan du bruge tools:overrideLibrary-markøren, men sørg for at teste grundigt!

Når du beslutter dig for en minSdkVersion, bør du overveje statistikkerne på Dashboards, som giver dig et globalt overblik over alle enheder, der har besøgt Google Play Store i de foregående 7 dage – det er din potentielle målgruppe, når du lægger en app på Google Play. Det er i sidste ende en forretningsmæssig beslutning om, hvorvidt understøttelse af yderligere 3 % af enhederne er den udviklings- og testtid værd, der kræves for at sikre den bedste oplevelse.

Selvfølgelig, hvis et nyt API er nøglen til hele din app, så gør det diskussionen om minSdkVersion en hel del lettere. Husk blot, at selv 0,7 % af 1,4 milliarder enheder er mange enheder.

targetSdkVersion

Den mest interessante af de tre er dog targetSdkVersion. targetSdkVersion er den vigtigste måde, hvorpå Android sikrer fremadrettet kompatibilitet ved ikke at anvende adfærdsændringer, medmindre targetSdkVersion er opdateret. Dette giver dig mulighed for at bruge nye API’er (da du jo opdaterede din compileSdkVersion, ikke sandt?), før du arbejder dig igennem adfærdsændringerne.

Meget af de adfærdsændringer, som targetSdkVersion indebærer, er dokumenteret direkte i VERSION_CODES, men alle de blodige detaljer er også anført på de enkelte udgivelsers platformshøjdepunkter, der er fint forbundet i tabellen API Levels.

For eksempel er Android 6.0-ændringer gennemgår, hvordan målretning af API 23 overgår din app til runtime-tilladelsesmodellen, og Android 4.4-adfærdsændringer beskriver detaljeret, hvordan målretning af API 19 eller højere ændrer, hvordan alarmer, der er indstillet med set() og setRepeating(), fungerer.

Med nogle af adfærdsændringerne, der er meget synlige for brugerne (nedlæggelse af menuknappen, runtime-tilladelser osv.), bør opdatering til målretning af det nyeste SDK være en høj prioritet for enhver app. Det betyder ikke, at du skal bruge alle nye funktioner, der indføres, og du bør heller ikke blindt opdatere din targetSdkVersion uden at teste – vær venlig, vær venlig at teste, før du opdaterer din targetSdkVersion! Dine brugere vil takke dig.

Gradle- og SDK-versioner

Så det er vigtigt at indstille den korrekte compileSdkVersion, minSdkVersion og targetSdkVersion. Som du måske kan forestille dig i en verden med Gradle og Android Studio, er disse værdier integreret i værktøjssystemet ved at indgå i dit moduls build.gradle-fil (også tilgængelig via indstillingen Project Structure i Android Studio):

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

Den compileSdkVersion er en af android-indstillingerne sammen med din version af byggeværktøjerne, da den er en kompileringstidspunktet ting (hvem ville have gættet det!). De to andre er lidt anderledes, idet de er deklareret på buildvariantniveau – defaultConfig er basen for alle buildvarianter, og hvor ville du sætte standardværdier for disse, men du kunne forestille dig et mere kompliceret system, hvor specifikke versioner af din app f.eks. har en anden minSdkVersion.

minSdkVersion og targetSdkVersion adskiller sig også fra compileSdkVersion ved at de indgår i din endelige APK – hvis du kigger på den genererede AndroidManifest.xml, vil du se et tag som:

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

Du vil opdage, at hvis du manuelt sætter dette i dit manifest, vil det blive ignoreret, når du bygger med Gradle (selvom andre byggesystemer helt sikkert kan stole på, at det er der).

Sammensætning af det hele

Hvis du klarede dig igennem de fedtrykte noter, vil du bemærke et forhold mellem de tre værdier:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Dette giver intuitivt mening – hvis compileSdkVersion er dit “maksimum” og minSdkVersion er dit “minimum”, så skal dit maksimum være mindst lige så højt som dit minimum, og målet skal ligge et sted midt imellem.

Idealt ville forholdet se mere sådan ud i den stabile tilstand:

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

Du rammer det største publikum med en lav minSdkVersion og ser ud og opfører dig bedst ved at målrette og kompilere med det nyeste SDK – en god måde at #BuildBetterApps på.

Deltag i diskussionen på Google+-oplægget og følg Android Development Patterns Collection for mere!