Selon la période de l’année, il se peut que ce ne soit que quelques mois après la sortie de votre application qu’une nouvelle version d’Android soit annoncée. Mais qu’est-ce que cela signifie pour votre application – est-ce que tout va se casser ?

Vous serez heureux de savoir que la compatibilité avant est un point fort d’Android – les applications existantes construites contre les SDK antérieurs ne devraient pas se casser lorsque l’utilisateur met à jour vers une nouvelle version d’Android. C’est là que compileSdkVersion, minSdkVersion et targetSdkVersion entrent en jeu : ils contrôlent respectivement quelles API sont disponibles, quel est le niveau d’API requis et quels modes de compatibilité sont appliqués.

compileSdkVersion est votre moyen d’indiquer à Gradle avec quelle version du SDK Android compiler votre application. L’utilisation du nouveau SDK Android est une exigence pour utiliser l’une des nouvelles API ajoutées dans ce niveau.

Il convient de souligner que la modification de votre compileSdkVersion ne change pas le comportement d’exécution. Alors que de nouveaux avertissements/erreurs de compilateur peuvent être présents lors du changement de votre compileSdkVersion, votre compileSdkVersion n’est pas incluse dans votre APK : elle est purement utilisée au moment de la compilation. (Vous devriez vraiment corriger ces avertissements cependant – ils ont été ajoutés pour une raison !)

C’est pourquoi il est fortement recommandé de toujours compiler avec le dernier SDK. Vous obtiendrez tous les avantages des nouvelles vérifications de compilation sur le code existant, éviterez les API nouvellement dépréciées et serez prêt à utiliser les nouvelles API.

Notez que si vous utilisez la bibliothèque de support, la compilation avec le dernier SDK est une exigence pour utiliser les dernières versions de la bibliothèque de support. Par exemple, pour utiliser la bibliothèque de support 23.1.1, vous devez avoir une compileSdkVersion d’au moins 23 (ces premiers chiffres doivent correspondre !). En général, une nouvelle version de la bibliothèque de support est publiée en même temps qu’une nouvelle version de la plate-forme, fournissant des cales de compatibilité aux API nouvellement ajoutées ainsi que de nouvelles fonctionnalités.

minSdkVersion

Si compileSdkVersion définit les API les plus récentes disponibles pour vous, minSdkVersion est la limite inférieure pour votre application. La minSdkVersion est l’un des signaux que le Google Play Store utilise pour déterminer sur quels appareils d’un utilisateur une application peut être installée.

Elle joue également un rôle important pendant le développement : par défaut, lint s’exécute contre votre projet, vous avertissant lorsque vous utilisez des API supérieures à votre minSdkVersion, ce qui vous aide à éviter le problème d’exécution lié à la tentative d’appeler une API qui n’existe pas. La vérification de la version du système au moment de l’exécution est une technique courante lors de l’utilisation d’API uniquement sur des versions de plate-forme plus récentes.

N’oubliez pas que les bibliothèques que vous utilisez, telles que l’une des bibliothèques de support ou les services Google Play, peuvent avoir leur propre minSdkVersion – la minSdkVersion de votre application doit être au moins aussi élevée que la minSdkVersion de vos dépendances – si vous avez des bibliothèques qui nécessitent 4, 7 et 9, votre minSdkVersion doit être au moins 9. Dans de rares cas où vous voulez continuer à utiliser une bibliothèque avec une minSdkVersion plus élevée que votre application (et traiter tous les cas limites/assurer que la bibliothèque n’est utilisée que sur des versions de plateforme plus récentes), vous pouvez utiliser le marqueur tools:overrideLibrary, mais assurez-vous de tester minutieusement !

Lorsque vous décidez d’une minSdkVersion, vous devez tenir compte des statistiques des tableaux de bord, qui vous donnent un aperçu global de tous les appareils qui ont visité le Google Play Store au cours des 7 jours précédents – c’est votre public potentiel lorsque vous mettez une application sur Google Play. En fin de compte, c’est une décision commerciale de savoir si la prise en charge de 3 % de périphériques supplémentaires vaut le temps de développement et de test nécessaire pour assurer la meilleure expérience.

Bien sûr, si une nouvelle API est la clé de toute votre application, alors cela rend la discussion sur la minSdkVersion assez facile. Rappelez-vous simplement que même 0,7 % de 1,4 milliard d’appareils, c’est beaucoup d’appareils.

targetSdkVersion

Le plus intéressant des trois, cependant, est targetSdkVersion. targetSdkVersion est la principale façon dont Android fournit la compatibilité avant en n’appliquant pas les changements de comportement à moins que la targetSdkVersion ne soit mise à jour. Cela vous permet d’utiliser de nouvelles API (car vous avez mis à jour votre compileSdkVersion, n’est-ce pas ?) avant de travailler à travers les changements de comportement.

Une grande partie des changements de comportement que targetSdkVersion implique sont documentés directement dans le VERSION_CODES, mais tous les détails sanglants sont également répertoriés sur les faits saillants de la plate-forme de chaque version, joliment liés dans le tableau des niveaux d’API.

Par exemple, les changements d’Android 6.0 parlent de la façon dont le ciblage de l’API 23 fait passer votre application au modèle de permissions d’exécution et les changements de comportement d’Android 4.4 détaillent comment le ciblage de l’API 19 ou plus change la façon dont les alarmes définies avec set() et setRepeating() fonctionnent.

Avec certains des changements de comportement très visibles pour les utilisateurs (la dépréciation du bouton de menu, les permissions d’exécution, etc.), la mise à jour pour cibler le dernier SDK devrait être une priorité élevée pour chaque application. Cela ne signifie pas que vous devez utiliser chaque nouvelle fonctionnalité introduite ni que vous devez aveuglément mettre à jour votre targetSdkVersion sans faire de tests – s’il vous plaît, s’il vous plaît, testez avant de mettre à jour votre targetSdkVersion ! Vos utilisateurs vous remercieront.

Gradle et les versions du SDK

Donc, définir la bonne compileSdkVersion, minSdkVersion, et targetSdkVersion est important. Comme vous pouvez l’imaginer dans un monde avec Gradle et Android Studio, ces valeurs sont intégrées dans le système d’outils par l’inclusion dans le fichier build.gradle de votre module (également disponible par l’option Structure du projet dans Android Studio):

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

La compileSdkVersion, étant une chose de temps de compilation (qui aurait deviné !), est l’un des paramètres android aux côtés de votre version des outils de construction. Les deux autres sont légèrement différents en ce qu’ils sont déclarés au niveau de la variante de construction – le defaultConfig est la base pour toutes les variantes de construction et où vous mettriez des valeurs par défaut pour ceux-ci, mais vous pourriez imaginer un système plus compliqué où des versions spécifiques de votre app ont une minSdkVersion différente par exemple.

minSdkVersion et targetSdkVersion diffèrent également de compileSdkVersion en ce qu’ils sont inclus dans votre APK final – si vous regardiez le AndroidManifest.xml généré, vous verriez une balise telle que:

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

Vous constaterez que si vous mettez manuellement ceci dans votre manifeste, il sera ignoré lorsque vous construisez avec Gradle (bien que d’autres systèmes de construction pourraient certainement compter sur sa présence).

Mettre tout cela ensemble

Si vous l’avez fait à travers les notes en gras, vous remarquerez une relation entre les trois valeurs:

minSdkVersion <= targetSdkVersion <= compileSdkVersion

Cela a intuitivement du sens – si compileSdkVersion est votre « maximum » et minSdkVersion est votre « minimum », alors votre maximum doit être au moins aussi élevé que votre minimum et la cible doit être quelque part entre les deux.

Idéalement, la relation ressemblerait plus à ceci dans l’état stable :

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

Vous toucherez la plus grande audience avec une minSdkVersion basse et aurez l’apparence et l’action les meilleures en ciblant et en compilant avec le dernier SDK – une excellente façon de #BuildBetterApps.

Rejoignez la discussion sur le post Google+ et suivez la collection Android Development Patterns pour en savoir plus !

.