Version Android Min SDK vs. Version SDK cible

android: minSdkVersion

Un entier désignant le niveau minimum d’API requirejs pour l’exécution de l’application. Le système Android empêchera l’utilisateur d’installer l’application si le niveau d’API du système est inférieur à la valeur spécifiée dans cet atsortingbut. Vous devez toujours déclarer cet atsortingbut.

android: targetSdkVersion

Un entier désignant le niveau d’API ciblé par l’application.

Avec cet atsortingbut défini, l’application indique qu’elle peut s’exécuter sur les anciennes versions (jusqu’à minSdkVersion), mais a été explicitement testée pour fonctionner avec la version spécifiée ici. La spécification de cette version cible permet à la plate-forme de désactiver les parameters de compatibilité non requirejs pour la version cible (qui pourrait sinon être activée pour maintenir la compatibilité directe) ou d’activer des fonctionnalités plus récentes qui ne sont pas disponibles pour les anciennes applications. Cela ne signifie pas que vous pouvez programmer différentes fonctionnalités pour différentes versions de la plate-forme – il informe simplement la plate-forme que vous avez testée contre la version cible et la plate-forme ne doit effectuer aucun travail supplémentaire pour maintenir la compatibilité avec la version cible.

Pour plus d’informations, reportez-vous à cette URL:

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

Le commentaire posté par l’OP sur la question (indiquant essentiellement que le targetSDK n’affecte pas la compilation d’une application) est totalement faux! Désolé d’être franc.

En bref, voici le but de déclarer un targetSDK différent du minSDK: cela signifie que vous utilisez des fonctionnalités d’un SDK de niveau supérieur à votre minimum, mais vous avez assuré la rétrocompatibilité . En d’autres termes, imaginez que vous souhaitiez utiliser une fonctionnalité récemment introduite, mais cela n’est pas essentiel pour votre application. Vous devez ensuite définir le targetSDK sur la version où cette nouvelle fonctionnalité a été introduite et la réduire au minimum pour que tout le monde puisse toujours utiliser votre application.

Pour donner un exemple, disons que vous écrivez une application qui utilise largement la détection de gestes. Cependant, chaque commande pouvant être reconnue par un geste peut également être effectuée à l’aide d’un bouton ou du menu. Dans ce cas, les gestes sont un «extra cool» mais ne sont pas nécessaires. Par conséquent, vous devez définir le sdk cible sur 7 (“Eclair” lorsque la bibliothèque GestureDetection a été introduite) et minimumSDK sur le niveau 3 (“Cupcake”) pour que même les utilisateurs de vieux téléphones puissent utiliser votre application. Tout ce que vous avez à faire est de vous assurer que votre application a vérifié la version d’Android sur laquelle elle s’exécutait avant d’essayer d’utiliser la bibliothèque de gestes, pour éviter d’essayer de l’utiliser si elle n’existait pas. (Certes, il s’agit d’un exemple démodé car quasiment personne n’a encore un téléphone v1.5, mais à une époque le maintien de la compatibilité avec la v1.5 était vraiment important.)

Pour donner un autre exemple, vous pouvez l’utiliser si vous souhaitez utiliser une fonctionnalité de Gingerbread ou Honeycomb. Certaines personnes recevront bientôt les mises à jour, mais beaucoup d’autres, en particulier avec du matériel plus ancien, pourraient restr bloquées avec Eclair jusqu’à ce qu’elles achètent un nouvel appareil. Cela vous permettrait d’utiliser certaines des nouvelles fonctionnalités intéressantes, mais sans exclure une partie de votre marché potentiel.

Il y a un très bon article sur le blog du développeur Android sur la façon d’utiliser cette fonctionnalité, et en particulier sur la façon de concevoir le code “Vérifiez que la fonctionnalité existe avant de l’utiliser” que j’ai mentionné ci-dessus.

À l’OP: Je l’ai écrit principalement pour le bénéfice de quiconque arrive à trébucher sur cette question à l’avenir, car je réalise que votre question a été posée il y a longtemps.

Lorsque vous définissez targetSdkVersion = “xx”, vous certifiez que votre application fonctionne correctement (par exemple, elle a été testée avec succès et de manière approfondie) au niveau de l’API xx.

Une version d’Android exécutée au niveau de l’API au- dessus de xx appliquera automatiquement le code de compatibilité pour prendre en charge toutes les fonctionnalités disponibles avant ou au niveau d’API xx, mais qui sont désormais obsolètes au niveau supérieur de cette version d’Android.

À l’inverse, si vous utilisez des fonctionnalités devenues obsolètes au niveau xx ou antérieures , le code de compatibilité ne sera pas automatiquement appliqué par les versions de système d’exploitation à des niveaux d’API supérieurs (qui n’incluent plus ces fonctionnalités) pour prendre en charge ces utilisations. Dans ce cas, votre propre code doit comporter des clauses de cas spéciaux qui testent le niveau de l’API et, si le niveau du système d’exploitation détecté est supérieur à celui de l’API, votre code doit utiliser d’autres fonctionnalités disponibles sur le système d’exploitation. Niveau API

Si cela ne réussit pas, certaines fonctionnalités d’interface peuvent ne pas apparaître, ce qui déclencherait normalement des événements dans votre code, et il se peut que vous manquiez une fonction d’interface critique dont l’utilisateur a besoin pour déclencher ces événements et accéder à leurs fonctionnalités (comme dans exemple ci-dessous).

Comme indiqué dans d’autres réponses, vous pouvez définir targetSdkVersion à une valeur supérieure à minSdkVersion si vous souhaitez utiliser certaines fonctionnalités d’API définies initialement à des niveaux d’API plus élevés que votre minSdkVersion, et vous assurer que votre code détecte et gère niveaux inférieurs à targetSdkVersion.

Afin d’avertir les développeurs de tester spécifiquement le niveau minimum d’API requirejs pour utiliser une fonctionnalité, le compilateur émettra une erreur (pas seulement un avertissement) si le code contient un appel à une méthode définie à un niveau d’API ultérieur à minSdkVersion, même si targetSdkVersion est supérieur ou égal au niveau de l’API auquel cette méthode a été mise à disposition pour la première fois. Pour supprimer cette erreur, la directive du compilateur

@TargetApi(nn) 

indique au compilateur que le code dans la scope de cette directive (qui précédera une méthode ou une classe) a été écrit pour tester un niveau API d’au moins nn avant d’appeler une méthode qui dépend au moins de ce niveau d’API . Par exemple, le code suivant définit une méthode pouvant être appelée à partir du code dans une application qui a une minSdkVersion inférieure à 11 et un targetSdkVersion de 11 ou supérieur:

 @TargetApi(11) public void refreshActionBarIfApi11OrHigher() { //If the API is 11 or higher, set up the actionBar and display it if(Build.VERSION.SDK_INT >= 11) { //ActionBar only exists at API level 11 or higher ActionBar actionBar = getActionBar(); //This should cause onPrepareOptionsMenu() to be called. // In versions of the API prior to 11, this only occurred when the user pressed // the dedicated menu button, but at level 11 and above, the action bar is // typically displayed continuously and so you will need to call this // each time the options on your menu change. invalidateOptionsMenu(); //Show the bar actionBar.show(); } } 

Vous pourriez également vouloir déclarer une targetSdkVersion plus élevée si vous aviez testé à ce niveau supérieur et que tout fonctionnait, même si vous n’utilisiez aucune fonctionnalité d’un niveau d’API supérieur à votre minSdkVersion. Ce serait juste pour éviter la surcharge de l’access au code de compatibilité destiné à s’adapter du niveau cible au niveau minimum, puisque vous auriez confirmé (via des tests) qu’aucune adaptation de ce type n’était requirejse.

Un exemple de fonctionnalité d’interface utilisateur qui dépend de targetSdkVersion déclaré serait le bouton de menu à trois points verticaux qui apparaît sur la barre d’état des applications ayant un targetSdkVersion inférieur à 11, lorsque ces applications sont exécutées sous API 11 et versions ultérieures. Si votre application a un targetSdkVersion de 10 ou moins, il est supposé que l’interface de votre application dépend de l’existence d’un bouton de menu dédié. Le bouton à trois points semble donc remplacer le matériel dédié antérieur et / ou les versions à l’écran de ce bouton (par exemple, comme vu dans Gingerbread) lorsque le système d’exploitation a un niveau d’API supérieur pour lequel un bouton de menu dédié sur le périphérique n’est plus supposé. Cependant, si vous définissez targetSdkVersion de votre application sur 11 ou plus, il est supposé que vous avez tiré parti des fonctionnalités introduites à ce niveau qui remplacent le bouton de menu dédié (par exemple, la barre d’action) ou que vous n’avez pas besoin de le faire. avoir un bouton de menu système; par conséquent, le menu à trois points-vert “bouton de compatibilité” disparaît. Dans ce cas, si l’utilisateur ne trouve pas de bouton de menu, il ne peut pas appuyer dessus, ce qui signifie que le remplacement de onCreateOptionsMenu (menu) de votre activité peut ne jamais être appelé, ce qui à son tour signifie que une partie importante des fonctionnalités de votre application pourrait être privée de son interface utilisateur. À moins, bien sûr, que vous ayez implémenté la barre d’action ou d’autres moyens alternatifs pour que l’utilisateur puisse accéder à ces fonctionnalités.

En revanche, minSdkVersion stipule que la version du système d’exploitation d’un périphérique doit au moins avoir ce niveau API pour exécuter votre application. Cela affecte les appareils capables de voir et de télécharger votre application sur le Google Play Store (et peut-être également sur d’autres magasins d’applications). C’est un moyen de déclarer que votre application s’appuie sur des fonctionnalités de système d’exploitation (API ou autres) établies à ce niveau et ne permet pas de gérer l’absence de ces fonctionnalités.

Un exemple d’utilisation de minSdkVersion pour garantir la présence d’une fonctionnalité non liée à une API serait de définir minSdkVersion sur 8 afin de garantir que votre application ne s’exécutera que sur une version compatible JIT de l’interpréteur Dalvik (depuis l’introduction de JIT). à l’interpréteur Android au niveau de l’API 8). Étant donné que les performances d’un interpréteur compatible JIT peuvent être cinq fois supérieures à celles d’un interpréteur manquant, si votre application utilise beaucoup le processeur, vous souhaiterez peut-être exiger le niveau 8 ou supérieur de l’API pour garantir des performances adéquates.

Un concept peut être mieux fourni avec des exemples, toujours . J’ai eu du mal à comprendre ces concepts jusqu’à ce que je découvre le code source du framework Android et que je fasse des expériences, même après avoir lu tous les documents sur les sites de développeurs Android et les threads de stackoverflow associés. Je vais partager deux exemples qui m’ont beaucoup aidé à bien comprendre ces concepts.

Un DatePickerDialog sera différent en fonction du niveau que vous avez placé dans targetSDKversion du fichier AndroidManifest.xml ( ). Si vous définissez la valeur 10 ou inférieure, votre DatePickerDialog ressemblera à gauche. Par contre, si vous définissez la valeur 11 ou plus, un DatePickerDialog sera correct, avec le même code .

Le code que j’ai utilisé pour créer cet exemple est très simple. MainActivity.java air:

 public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); } public void onClickButton(View v) { DatePickerDialog d = new DatePickerDialog(this, null, 2014, 5, 4); d.show(); } } 

Et activity_main.xml ressemble à:

C’est tout. C’est vraiment chaque code dont j’ai besoin pour le tester.

Et ce changement de look est clair lorsque vous voyez le code source du framework Android . Ça va comme:

 public DatePickerDialog(Context context, OnDateSetListener callBack, int year, int monthOfYear, int dayOfMonth, boolean yearOptional) { this(context, context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB ? com.android.internal.R.style.Theme_Holo_Light_Dialog_Alert : com.android.internal.R.style.Theme_Dialog_Alert, callBack, year, monthOfYear, dayOfMonth, yearOptional); } 

Comme vous pouvez le voir, le framework obtient targetSDKversion en cours et définit un thème différent. Ce genre d’extrait de code ( getApplicationInfo().targetSdkVersion >= SOME_VERSION ) peut être trouvé ici ou là dans le framework Android.

Un autre exemple concerne la classe WebView . Les méthodes publiques de la classe Webview doivent être appelées sur le thread principal. Dans le cas contraire, le système d’exécution génère une RuntimeException lorsque vous définissez targetSDKversion 18 ou une version ultérieure. Ce comportement peut être clairement fourni avec son code source . C’est juste écrit comme ça.

 sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.JELLY_BEAN_MR2; if (sEnforceThreadChecking) { throw new RuntimeException(throwable); } 

Le document Android indique: “A mesure qu’Android évolue avec chaque nouvelle version, certains comportements et même certaines apparences peuvent changer “. Nous avons donc examiné les changements de comportement et d’apparence, et comment ce changement est accompli.

En résumé, le document Android indique: « Cet atsortingbut (targetSdkVersion) informe le système que vous avez testé par rapport à la version cible et le système ne doit activer aucun comportement de compatibilité pour maintenir la compatibilité de votre application avec la version cible . C’est très clair avec le cas WebView. C’était OK jusqu’à ce que JELLY_BEAN_MR2 soit publié pour appeler la méthode publique de la classe WebView sur le thread non principal. Cela n’a aucun sens si le framework Android lève une exception RuntimeException sur les périphériques JELLY_BEAN_MR2. Cela ne devrait pas permettre des comportements nouvellement introduits pour son intérêt, qui entraînent des résultats fatals. Donc, ce que nous avons à faire est de vérifier si tout est correct sur certaines versions de targetSDKversions. Nous obtenons des avantages comme l’amélioration de l’apparence en définissant une version cible plus élevée de SDK, mais cela implique des responsabilités.

EDIT: avertissement. Le constructeur DatePickerDialog qui a défini différents thèmes en fonction de la cible targetSDKversion actuelle (que j’ai montrée ci-dessus) a en fait été modifié lors d’une validation ultérieure . Néanmoins, j’ai utilisé cet exemple, car la logique n’a pas été modifiée, et cet extrait de code montre clairement le concept targetSDKversion.

Pour ceux qui veulent un résumé,

 android:minSdkVersion 

est la version minimale prise en charge par votre application. Si votre appareil a une version inférieure de Android, l’application ne sera pas installée.

tandis que,

 android:targetSdkVersion 

est le niveau d’API jusqu’à l’application de votre application. Moyens, le système de votre téléphone n’a pas besoin d’utiliser des comportements de compatibilité pour maintenir la compatibilité avec le temps, car vous avez testé jusqu’à cette API.

Votre application fonctionnera toujours sur les versions d’Android supérieures à celles indiquées dans targetSdkVersion mais le comportement de compatibilité avec Android se déclenchera.

Freebie –

android:maxSdkVersion

Si la version de l’API de votre appareil est supérieure, l’application ne sera pas installée. C’est à dire. c’est l’API max jusqu’à laquelle vous autorisez l’installation de votre application.

c’est à dire. pour MinSDK -4, maxSDK-8, targetSDK – 8 Mon application fonctionnera au minimum sur 1.6, mais j’ai également utilisé des fonctionnalités sockets en charge uniquement dans la version 2.2 qui seront visibles si elle est installée sur un périphérique 2.2. En outre, pour maxSDK-8, cette application ne sera pas installée sur les téléphones utilisant l’API> 8.

Au moment d’écrire cette réponse, la documentation Android ne faisait pas un excellent travail pour l’expliquer. Maintenant, c’est très bien expliqué. Vérifiez ici

Si vous obtenez des erreurs de compilation, par exemple:

.

 private void methodThatRequiresAPI11() { BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Config.ARGB_8888; // API Level 1 options.inSampleSize = 8; // API Level 1 options.inBitmap = bitmap; // **API Level 11** //... } 

Vous obtenez une erreur de compilation:

Le champ requirejs le niveau 11 de l’API (le min actuel est 10): android.graphics.BitmapFactory $ Options # inBitmap

Depuis la version 17 d’Android Development Tools (ADT), il existe une nouvelle annotation très utile, @TargetApi qui peut résoudre ce problème très facilement. Ajoutez-le avant la méthode qui contient la déclaration problématique:

 @TargetApi private void methodThatRequiresAPI11() { BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Config.ARGB_8888; // API Level 1 options.inSampleSize = 8; // API Level 1 // This will avoid exception NoSuchFieldError (or NoSuchMethodError) at runtime. if (Integer.valueOf(android.os.Build.VERSION.SDK) >= android.os.Build.VERSION_CODES.HONEYCOMB) { options.inBitmap = bitmap; // **API Level 11** //... } } 

Aucune erreur de compilation maintenant et elle fonctionnera!

EDIT: Cela entraînera une erreur d’exécution au niveau de l’API inférieure à 11. Le 11 ou plus, il s’exécutera sans problème. Vous devez donc vous assurer d’appeler cette méthode sur un chemin d’exécution protégé par un contrôle de version. TargetApi vous permet simplement de le comstackr mais vous l’exécutez à vos risques et périls.

android:minSdkVersion et android:targetSdkVersion sont tous deux une valeur android:targetSdkVersion que nous devons déclarer dans le fichier manifeste Android, mais les deux ont des propriétés différentes.

android:minSdkVersion: il s’agit du niveau minimum requirejs pour exécuter une application Android. Si nous installons la même application sur la version inférieure de l’API, l’erreur de l’parsingur apparaîtra et le problème de l’application non prise en charge apparaîtra.

android:targetSdkVersion: version cible de SDK consiste à définir le niveau de l’API cible de l’application. Si cet atsortingbut n’est pas déclaré dans le manifeste, la version de minSdk sera votre version de TargetSdk. C’est toujours vrai que “l’installation de support d’application sur toutes les versions supérieures de l’API que nous avons déclarées comme version TargetSdk”. Pour rendre la cible de l’application limitée, nous devons déclarer maxSdkVersion dans notre fichier manifeste …

Sdk cible est la version que vous souhaitez cibler et min sdk est le minimum.

Si vous créez des applications qui nécessitent des permissions dangereuses et définissez targetSDK sur 23 ou plus, vous devez faire attention. Si vous ne vérifiez pas les permissions à l’exécution, vous obtiendrez une exception SecurityException et si vous utilisez du code dans un bloc try, par exemple une caméra ouverte, il peut être difficile de détecter une erreur si vous ne vérifiez pas logcat.