Abhängig von der Jahreszeit kann es sein, dass nur wenige Monate nach der Veröffentlichung einer App eine neue Android-Version angekündigt wird. Was bedeutet das für Ihre App – wird alles kaputt gehen?

Sie werden froh sein, zu wissen, dass Vorwärtskompatibilität ein starker Fokus von Android ist – bestehende Apps, die mit früheren SDKs erstellt wurden, sollten nicht kaputt gehen, wenn der Benutzer auf eine neue Version von Android aktualisiert. Hier kommen compileSdkVersion, minSdkVersion und targetSdkVersion ins Spiel: Sie steuern, welche APIs verfügbar sind, welches API-Level erforderlich ist und welche Kompatibilitätsmodi angewandt werden.

compileSdkVersion ist Ihr Weg, Gradle mitzuteilen, mit welcher Version des Android SDK Ihre App kompiliert werden soll. Die Verwendung des neuen Android SDK ist eine Voraussetzung für die Nutzung der neuen APIs, die in diesem Level hinzugefügt wurden.

Es sollte betont werden, dass das Ändern der compileSdkVersion das Laufzeitverhalten nicht verändert. Während neue Compiler-Warnungen/Fehler auftreten können, wenn Sie Ihre compileSdkVersion ändern, ist Ihre compileSdkVersion nicht in Ihrer APK enthalten: Sie wird nur zur Kompilierzeit verwendet. (Sie sollten diese Warnungen jedoch wirklich beheben – sie wurden aus einem bestimmten Grund hinzugefügt!)

Daher wird dringend empfohlen, dass Sie immer mit dem neuesten SDK kompilieren. Sie erhalten alle Vorteile der neuen Kompilierungsprüfungen für bestehenden Code, vermeiden neu veraltete APIs und sind bereit, neue APIs zu verwenden.

Bitte beachten Sie, dass, wenn Sie die Support Library verwenden, die Kompilierung mit dem neuesten SDK eine Voraussetzung für die Verwendung der neuesten Versionen der Support Library ist. Um zum Beispiel die Support Library 23.1.1 zu verwenden, müssen Sie eine compileSdkVersion von mindestens 23 haben (die ersten Zahlen müssen übereinstimmen!). Im Allgemeinen wird eine neue Version der Support Library zusammen mit einer neuen Plattformversion veröffentlicht und bietet Kompatibilitäts-Shims für neu hinzugefügte APIs sowie neue Funktionen.

minSdkVersion

Wenn compileSdkVersion die neuesten verfügbaren APIs festlegt, ist minSdkVersion die untere Grenze für Ihre Anwendung. Die minSdkVersion ist eines der Signale, die der Google Play Store verwendet, um zu bestimmen, auf welchen Geräten eines Benutzers eine App installiert werden kann.

Sie spielt auch eine wichtige Rolle bei der Entwicklung: Standardmäßig wird lint gegen Ihr Projekt ausgeführt und warnt Sie, wenn Sie APIs verwenden, die über Ihrer minSdkVersion liegen, und hilft Ihnen, das Laufzeitproblem zu vermeiden, dass Sie versuchen, eine API aufzurufen, die nicht existiert. Die Überprüfung der Systemversion zur Laufzeit ist eine gängige Technik, wenn APIs nur auf neueren Plattformversionen verwendet werden.

Denken Sie daran, dass die von Ihnen verwendeten Bibliotheken, wie z. B. die Support-Bibliotheken oder Google Play-Dienste, ihre eigene minSdkVersion haben können – die minSdkVersion Ihrer App muss mindestens so hoch sein wie die minSdkVersion Ihrer Abhängigkeiten – wenn Sie Bibliotheken haben, die 4, 7 und 9 benötigen, muss Ihre minSdkVersion mindestens 9 sein. In den seltenen Fällen, in denen Sie weiterhin eine Bibliothek mit einer höheren minSdkVersion als Ihre Anwendung verwenden möchten (und alle Randfälle behandeln / sicherstellen, dass die Bibliothek nur auf neueren Plattformversionen verwendet wird), können Sie den Marker tools:overrideLibrary verwenden, aber stellen Sie sicher, dass Sie gründlich testen!

Wenn Sie sich für eine minSdkVersion entscheiden, sollten Sie die Statistiken in den Dashboards berücksichtigen, die Ihnen einen globalen Überblick über alle Geräte geben, die den Google Play Store in den letzten 7 Tagen besucht haben – das ist Ihre potenzielle Zielgruppe, wenn Sie eine App in Google Play einstellen. Letztendlich ist es eine geschäftliche Entscheidung, ob die Unterstützung von zusätzlichen 3 % der Geräte die Entwicklungs- und Testzeit wert ist, die erforderlich ist, um die beste Erfahrung zu gewährleisten.

Wenn natürlich eine neue API der Schlüssel zu Ihrer gesamten App ist, dann macht das die Diskussion über die minSdkVersion um einiges einfacher. Denken Sie nur daran, dass selbst 0,7 % von 1,4 Milliarden Geräten eine Menge Geräte sind.

targetSdkVersion

Das interessanteste der drei ist jedoch targetSdkVersion. targetSdkVersion ist die wichtigste Art und Weise, wie Android Vorwärtskompatibilität bietet, indem Verhaltensänderungen erst dann angewendet werden, wenn die targetSdkVersion aktualisiert wird. Dies ermöglicht es Ihnen, neue APIs zu verwenden (da Sie Ihre compileSdkVersion aktualisiert haben, richtig?), bevor Sie sich durch die Verhaltensänderungen arbeiten.

Viele der Verhaltensänderungen, die targetSdkVersion impliziert, sind direkt in den VERSION_CODES dokumentiert, aber alle blutigen Details sind auch in den Plattform-Highlights der einzelnen Versionen aufgeführt, die schön in der API-Levels-Tabelle verlinkt sind.

Zum Beispiel werden die Android 6.0-Änderungen erläutern beispielsweise, wie Ihre App durch die Ausrichtung auf API 23 auf das Modell der Laufzeitberechtigungen umgestellt wird, und die Verhaltensänderungen von Android 4.4 beschreiben detailliert, wie sich durch die Ausrichtung auf API 19 oder höher die Funktionsweise von Alarmen ändert, die mit set() und setRepeating() gesetzt werden.

Da einige der Verhaltensänderungen für die Benutzer sehr sichtbar sind (die Veraltung der Menütaste, Laufzeitberechtigungen usw.), sollte die Aktualisierung auf das neueste SDK für jede App eine hohe Priorität haben. Das bedeutet nicht, dass Sie jede neu eingeführte Funktion nutzen müssen, noch sollten Sie Ihre targetSdkVersion blindlings aktualisieren, ohne zu testen – bitte, bitte testen Sie, bevor Sie Ihre targetSdkVersion aktualisieren! Ihre Benutzer werden es Ihnen danken.

Gradle und SDK-Versionen

Das Setzen der richtigen compileSdkVersion, minSdkVersion und targetSdkVersion ist also wichtig. Wie Sie sich vielleicht vorstellen können, sind diese Werte in einer Welt mit Gradle und Android Studio in das Toolsystem integriert, indem sie in die build.gradle-Datei Ihres Moduls aufgenommen werden (die auch über die Projektstrukturoption in Android Studio verfügbar ist):

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

Die compileSdkVersion ist eine Kompilierzeitsache (wer hätte das gedacht!) und ist eine der Android-Einstellungen zusammen mit der Version Ihrer Build-Tools. Die anderen beiden sind etwas anders, da sie auf der Ebene der Build-Variante deklariert werden – die defaultConfig ist die Basis für alle Build-Varianten und wo würdest du Standardwerte für diese setzen, aber du könntest dir ein komplizierteres System vorstellen, in dem spezifische Versionen deiner App zum Beispiel eine andere minSdkVersion haben.

minSdkVersion und targetSdkVersion unterscheiden sich auch von compileSdkVersion dadurch, dass sie in der endgültigen APK enthalten sind – wenn man sich die generierte AndroidManifest.xml ansieht, sieht man ein Tag wie:

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

Wenn man dies manuell in das Manifest einträgt, wird es ignoriert, wenn man mit Gradle baut (obwohl andere Build-Systeme sich sicherlich darauf verlassen, dass es dort ist).

Alles zusammenfassen

Wenn Sie die fettgedruckten Hinweise gelesen haben, werden Sie eine Beziehung zwischen den drei Werten feststellen:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Intuitiv macht das Sinn – wenn compileSdkVersion Ihr „Maximum“ und minSdkVersion Ihr „Minimum“ ist, dann muss Ihr Maximum mindestens so hoch wie Ihr Minimum sein und das Ziel muss irgendwo dazwischen liegen.

Im Grunde würde die Beziehung im Dauerzustand eher so aussehen:

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

Mit einer niedrigen minSdkVersion erreichst du die größte Zielgruppe und siehst am besten aus und verhältst dich am besten, wenn du mit dem neuesten SDK kompilierst – eine großartige Möglichkeit, #BuildBetterApps zu entwickeln.

Schließe dich der Diskussion auf Google+ an und folge der Android Development Patterns Collection für mehr!