Afhankelijk van de tijd van het jaar kan het pas een paar maanden nadat je een app hebt uitgebracht zijn dat er een nieuwe versie van Android wordt aangekondigd. Wat betekent dat echter voor uw app – gaat alles kapot?

U zult blij zijn te weten dat voorwaartse compatibiliteit een belangrijk aandachtspunt van Android is – bestaande apps die tegen eerdere SDK’s zijn gebouwd, mogen niet kapotgaan wanneer de gebruiker een update naar een nieuwe versie van Android uitvoert. Dit is waar compileSdkVersion, minSdkVersion, en targetSdkVersion in het spel komen: zij bepalen welke API’s beschikbaar zijn, wat het vereiste API niveau is, en welke compatibiliteitsmodi worden toegepast, respectievelijk.

compileSdkVersion is uw manier om Gradle te vertellen met welke versie van de Android SDK uw app moet worden gecompileerd. Het gebruik van de nieuwe Android SDK is een vereiste om een van de nieuwe API’s te gebruiken die in dat niveau zijn toegevoegd.

Het moet worden benadrukt dat het veranderen van uw compileSdkVersion het runtime gedrag niet verandert. Terwijl nieuwe compiler waarschuwingen/fouten aanwezig kunnen zijn wanneer u uw compileSdkVersion verandert, wordt uw compileSdkVersion niet opgenomen in uw APK: het wordt alleen gebruikt tijdens het compileren. (Je zou die waarschuwingen echt moeten oplossen – ze zijn niet voor niets toegevoegd!)

Daarom wordt het sterk aangeraden om altijd te compileren met de nieuwste SDK. U krijgt alle voordelen van nieuwe compilatiecontroles op bestaande code, vermijdt onlangs afgeschreven API’s, en bent klaar om nieuwe API’s te gebruiken.

Merk op dat als u de ondersteuningsbibliotheek gebruikt, compileren met de nieuwste SDK een vereiste is voor het gebruik van de nieuwste ondersteuningsbibliotheekversies. Bijvoorbeeld, om de 23.1.1 Support Library te gebruiken, moet u een compileSdkVersion van minstens 23 hebben (die eerste nummers moeten overeenstemmen!). In het algemeen wordt een nieuwe versie van de ondersteuningsbibliotheek uitgebracht samen met een nieuwe platformversie, die compatibiliteitshims biedt voor nieuw toegevoegde API’s, evenals nieuwe functies.

minSdkVersion

Als compileSdkVersion de nieuwste API’s instelt die voor u beschikbaar zijn, is minSdkVersion de ondergrens voor uw app. De minSdkVersion is een van de signalen die de Google Play Store gebruikt om te bepalen op welke apparaten van een gebruiker een app kan worden geïnstalleerd.

Het speelt ook een belangrijke rol tijdens de ontwikkeling: standaard loopt lint tegen uw project en waarschuwt u wanneer u API’s gebruikt die boven uw minSdkVersion liggen, zodat u het runtime probleem kunt voorkomen van een poging om een API aan te roepen die niet bestaat. Het controleren van de systeemversie tijdens runtime is een gebruikelijke techniek wanneer API’s alleen op nieuwere platformversies worden gebruikt.

Bedenk dat bibliotheken die je gebruikt, zoals de ondersteuningsbibliotheken of Google Play services, hun eigen minSdkVersion kunnen hebben – de minSdkVersion van je app moet minstens even hoog zijn als de minSdkVersion van je afhankelijkheden – als je bibliotheken hebt die 4, 7 en 9 vereisen, moet je minSdkVersion ten minste 9 zijn. In zeldzame gevallen waarin u een bibliotheek wilt blijven gebruiken met een hogere minSdkVersion dan uw app (en omgaan met alle randgevallen/ervoor zorgen dat de bibliotheek alleen wordt gebruikt op nieuwere platformversies), kunt u de tools:overrideLibrary-markering gebruiken, maar zorg ervoor dat u grondig test!

Bij het bepalen van de minSdkVersion moet u rekening houden met de statistieken op de Dashboards, die u een globaal overzicht geven van alle apparaten die de Google Play Store in de afgelopen 7 dagen hebben bezocht – dat is uw potentiële publiek wanneer u een app op Google Play zet. Het is uiteindelijk een zakelijke beslissing of het ondersteunen van een extra 3% van de apparaten de ontwikkelings- en testtijd waard is die nodig is om de beste ervaring te garanderen.

Natuurlijk, als een nieuwe API de sleutel is tot uw hele app, dan maakt dat de minSdkVersion-discussie een stuk eenvoudiger. Vergeet niet dat zelfs 0,7% van 1,4 miljard apparaten is een heleboel apparaten.

targetSdkVersion

De meest interessante van de drie, echter, is targetSdkVersion. targetSdkVersion is de belangrijkste manier waarop Android voorwaartse compatibiliteit biedt door het niet toepassen van gedragsveranderingen, tenzij de targetSdkVersion wordt bijgewerkt. Dit stelt u in staat om nieuwe API’s te gebruiken (zoals u hebt bijgewerkt uw compileSdkVersion toch?) voorafgaand aan het werken door middel van de gedragswijzigingen.

Veel van de gedragswijzigingen die targetSdkVersion impliceert zijn direct gedocumenteerd in de VERSION_CODES, maar alle van de bloederige details zijn ook vermeld op de elke releases ‘platform hoogtepunten, mooi gekoppeld in de API-niveaus tabel.

Bijvoorbeeld, de Android 6.0 veranderingen praten door hoe targeting API 23 uw app overzet naar het runtime permissiemodel en de Android 4.4 gedragsveranderingen in detail hoe targeting API 19 of hoger verandert hoe alarmen ingesteld met set() en setRepeating() werken.

Met een aantal van de gedragsveranderingen die zeer zichtbaar zijn voor gebruikers (de afschrijving van de menuknop, runtime permissies, enz.), moet het bijwerken om de nieuwste SDK te targeten een hoge prioriteit zijn voor elke app. Dat betekent niet dat je elke nieuwe functie moet gebruiken, noch dat je blindelings je targetSdkVersion moet updaten zonder te testen – alsjeblieft, alsjeblieft test voordat je je targetSdkVersion update! Uw gebruikers zullen u dankbaar zijn.

Gradle en SDK versies

Dus het instellen van de juiste compileSdkVersion, minSdkVersion, en targetSdkVersion is belangrijk. Zoals je je zou kunnen voorstellen in een wereld met Gradle en Android Studio, zijn deze waarden geïntegreerd in het tools systeem door opname in het build.gradle bestand van je module (ook beschikbaar via de Project Structure optie in Android Studio):

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

De compileSdkVersion, zijnde een compileertijd ding (wie had dat gedacht!), is een van de android instellingen samen met je build tools versie. De andere twee zijn iets anders in die zin dat ze worden gedeclareerd op het niveau van de build variant – de defaultConfig is de basis voor alle build varianten en waar zou je standaard waarden voor deze, maar je zou kunnen voorstellen een meer gecompliceerd systeem waar specifieke versies van uw app hebben een andere minSdkVersion bijvoorbeeld.

minSdkVersion en targetSdkVersion verschillen ook van compileSdkVersion in die zin dat ze worden opgenomen in je uiteindelijke APK – als je naar de gegenereerde AndroidManifest.xml zou kijken, zou je een tag zien zoals:

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

Je zult merken dat als je dit handmatig in je manifest zet, het zal worden genegeerd wanneer je bouwt met Gradle (hoewel andere bouwsystemen er zeker op kunnen vertrouwen dat het er is).

Het allemaal samenvoegen

Als je door de vetgedrukte notities heen bent gekomen, zul je een relatie tussen de drie waarden opmerken:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Dit is intuïtief logisch – als compileSdkVersion je ‘maximum’ is en minSdkVersion je ‘minimum’, dan moet je maximum minstens zo hoog zijn als je minimum en het doel moet daar ergens tussenin liggen.

Eigenlijk zou de relatie er in de stabiele toestand meer als volgt uitzien:

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

U bereikt het grootste publiek met een lage minSdkVersion en ziet er het beste uit en gedraagt zich het beste door te targeten en te compileren met de nieuwste SDK – een geweldige manier om #BuildBetterApps te maken.

Discussieer mee op de Google+-post en volg de Android Development Patterns Collection voor meer!