Beroende på vilken tid på året det är, kan det vara så att det bara är några månader efter att du släppt en app som en ny version av Android tillkännages. Vad betyder det för din app – kommer allt att gå sönder?

Du kommer att vara glad att veta att kompatibilitet framåt är ett starkt fokus för Android – befintliga appar som byggts med tidigare SDK:er bör inte gå sönder när användaren uppdaterar till en ny version av Android. Det är här som compileSdkVersion, minSdkVersion och targetSdkVersion kommer in: de styr vilka API:er som är tillgängliga, vilken API-nivå som krävs och vilka kompatibilitetslägen som tillämpas.

compileSdkVersion är ditt sätt att tala om för Gradle vilken version av Android SDK:n som din app ska kompileras med. Att använda den nya Android SDK är ett krav för att kunna använda något av de nya API:er som läggs till i den nivån.

Det bör understrykas att ändring av din compileSdkVersion inte ändrar körtidsbeteendet. Även om nya kompilervarningar/fel kan förekomma när du ändrar din compileSdkVersion ingår inte din compileSdkVersion i din APK: den används enbart vid kompileringstiden. (Du borde dock verkligen åtgärda dessa varningar – de lades till av en anledning!)

Det rekommenderas därför starkt att du alltid kompilerar med den senaste SDK:n. Du får alla fördelar av nya kompileringskontroller på befintlig kod, undviker nyligen föråldrade API:er och är redo att använda nya API:er.

Observera att om du använder supportbiblioteket är det ett krav att du kompilerar med den senaste SDK:n för att kunna använda de senaste supportbiblioteksutgåvorna. Om du till exempel vill använda supportbiblioteket 23.1.1 måste du ha en compileSdkVersion på minst 23 (de första siffrorna måste stämma!). I allmänhet släpps en ny version av supportbiblioteket tillsammans med en ny plattformsversion, vilket ger kompatibilitetssimuleringar till nyligen tillkomna API:er samt nya funktioner.

minSdkVersion

Om compileSdkVersion ställer in de nyaste API:erna som är tillgängliga för dig är minSdkVersion den nedre gränsen för din app. MinSdkVersion är en av de signaler som Google Play Store använder för att avgöra vilken av en användares enheter en app kan installeras på.

Den spelar också en viktig roll under utvecklingen: som standard körs lint mot ditt projekt och varnar dig när du använder API:er som är högre än din minSdkVersion, vilket hjälper dig att undvika körtidsproblem när du försöker anropa ett API som inte finns. Att kontrollera systemversionen vid körning är en vanlig teknik när du använder API:er endast på nyare plattformsversioner.

Tänk på att bibliotek som du använder, t.ex. något av supportbiblioteken eller Google Play-tjänsterna, kan ha sin egen minSdkVersion – din apps minSdkVersion måste vara minst lika hög som dina beroendes minSdkVersion – om du har bibliotek som kräver 4, 7 och 9 måste din minSdkVersion vara minst 9. I sällsynta fall där du vill fortsätta att använda ett bibliotek med en högre minSdkVersion än din app (och hantera alla kantfall/säkerställa att biblioteket endast används på nyare plattformsversioner) kan du använda tools:overrideLibrary-markören, men se till att du testar noggrant!

När du bestämmer dig för en minSdkVersion bör du ta hänsyn till statistiken på Dashboards, som ger dig en övergripande bild av alla enheter som besökt Google Play Store under de föregående sju dagarna – det är din potentiella publik när du lägger ut en app på Google Play. Det är i slutändan ett affärsbeslut om huruvida stöd för ytterligare 3 % av enheterna är värt den utvecklings- och testtid som krävs för att säkerställa den bästa upplevelsen.

Och om ett nytt API är nyckeln till hela din app gör det förstås diskussionen om minSdkVersion ganska mycket enklare. Kom bara ihåg att även 0,7 % av 1,4 miljarder enheter är många enheter.

targetSdkVersion

Den mest intressanta av de tre är dock targetSdkVersion. targetSdkVersion är det viktigaste sättet för Android att tillhandahålla framåtgående kompatibilitet genom att inte tillämpa beteendeförändringar om inte targetSdkVersion uppdateras. Detta gör att du kan använda nya API:er (eftersom du uppdaterade din compileSdkVersion, eller hur?) innan du arbetar igenom beteendeförändringarna.

En stor del av de beteendeförändringar som targetSdkVersion innebär dokumenteras direkt i VERSION_CODES, men alla blodiga detaljer listas också i varje utgåvas plattformshöjdpunkter, som är snyggt länkade till tabellen API Levels.

Till exempel är Android 6.0-ändringarna talar om hur målinriktning på API 23 gör att din app övergår till modellen för körtidsbehörigheter och beteendeändringarna för Android 4.4 beskriver i detalj hur målinriktning på API 19 eller högre ändrar hur larm som ställs in med set() och setRepeating() fungerar.

Med tanke på att några av beteendeändringarna är mycket synliga för användarna (avskaffandet av menyknappen, körtidsbehörigheter, etc.) bör uppdatering av målinriktningen på den senaste SDK:n ha hög prioritet för alla appar. Det betyder inte att du måste använda varje ny funktion som introduceras och du bör inte heller blint uppdatera din targetSdkVersion utan att testa – snälla, snälla testa innan du uppdaterar din targetSdkVersion! Dina användare kommer att tacka dig.

Gradle och SDK-versioner

Det är alltså viktigt att ställa in rätt compileSdkVersion, minSdkVersion och targetSdkVersion. Som du kanske kan föreställa dig i en värld med Gradle och Android Studio integreras dessa värden i verktygssystemet genom att de inkluderas i din moduls build.gradle-fil (även tillgänglig via alternativet 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, som är en kompileringstidsgrej (vem skulle ha gissat det!), är en av androidinställningarna tillsammans med din version av byggverktyget. De andra två är något annorlunda i och med att de deklareras på byggvariantnivå – defaultConfig är basen för alla byggvarianter och där skulle du sätta standardvärden för dessa, men du kan tänka dig ett mer komplicerat system där specifika versioner av din app har en annan minSdkVersion till exempel.

minSdkVersion och targetSdkVersion skiljer sig också från compileSdkVersion genom att de ingår i din slutliga APK – om du skulle titta på den genererade AndroidManifest.xml skulle du se en tagg som:

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

Du kommer att märka att om du manuellt lägger in detta i ditt manifest, kommer det att ignoreras när du bygger med Gradle (även om andra byggsystem säkerligen kan förlita sig på att det är där).

Sätt ihop det hela

Om du tog dig igenom de fetstilade noterna kommer du att märka ett samband mellan de tre värdena:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Det här är intuitivt logiskt – om compileSdkVersion är ditt ”maximum” och minSdkVersion är ditt ”minimum” måste ditt maximum vara minst lika högt som ditt minimum och målet måste ligga någonstans däremellan.

Idealt skulle förhållandet se ut mer så här i stabilt tillstånd:

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

Du når den största publiken med en låg minSdkVersion och ser bäst ut och agerar bäst genom att sikta in dig på och kompilera med den senaste SDK:n – ett bra sätt att #BuildBetterApps.

Deltag i diskussionen på Google+ inlägget och följ Android Development Patterns Collection för mer!