Android Version minimale du SDK par rapport à la version cible du SDK
En ce qui concerne le développement d'applications pour Android, quelle est la différence entre les versions SDK Min et Target? Eclipse ne me laissera pas créer un nouveau projet si les versions Min et Target ne sont pas identiques!
Android: minSdkVersion
Un entier désignant le niveau API minimal requis 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 attribut. Vous devez toujours déclarer cet attribut.
Android: targetSdkVersion
Un entier désignant le niveau de l'API ciblé par l'application.
Avec cet ensemble d'attributs, l'application indique qu'elle peut s'exécuter sur des versions plus anciennes (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 paramètres de compatibilité non requis pour la version cible (qui pourraient sinon être activés afin de maintenir la compatibilité en aval) ou d'activer des fonctionnalités plus récentes non disponibles pour les applications plus anciennes. Cela ne signifie pas que vous pouvez programmer différentes fonctionnalités pour différentes versions de la plate-forme; cela indique simplement à la plate-forme que vous avez testée par rapport à la version cible et que la plate-forme ne doit effectuer aucun travail supplémentaire pour maintenir la compatibilité en aval 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 à la question (affirmant en gros que targetSDK n'affecte pas la compilation d'une application) est totalement faux! Désolé d'être franc.
En bref, voici l’objet 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 que vous avez compatibilité ascendante assurée . En d'autres termes, imaginez que vous souhaitiez utiliser une fonctionnalité récemment introduite, mais que cela ne soit pas critique pour votre application. Vous définissez ensuite targetSDK sur la version où cette nouvelle fonctionnalité a été introduite et le minimum sur quelque chose de plus bas afin que tout le monde puisse utiliser votre application.
Pour donner un exemple, supposons que vous écriviez une application qui utilise beaucoup la détection des gestes. Cependant, chaque commande reconnaissable par un geste peut également être exécutée à l'aide d'un bouton ou à partir du menu. Dans ce cas, les gestes sont un "extra cool" mais ne sont pas obligatoires. Par conséquent, vous devez définir le sdk cible sur 7 ("Eclair" lorsque la bibliothèque GestureDetection a été introduite) et sur le minimumSDK sur le niveau 3 ("Cupcake") afin que même les personnes disposant de très vieux téléphones puissent utiliser votre application. Tout ce que vous avez à faire est de vous assurer que votre application vérifie la version de Android sur laquelle elle s'exécute avant d'essayer d'utiliser la bibliothèque de gestes afin d'éviter de l'utiliser si elle n'existait pas. (Certes, il s'agit d'un exemple daté car pratiquement personne ne dispose encore d'un téléphone v1.5, mais il fut un temps où le maintien de la compatibilité avec la version 1.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 obtiendront bientôt les mises à jour, mais de nombreuses autres, en particulier avec du matériel ancien, risquent de rester 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, sans toutefois exclure une partie de votre marché potentiel.
Il existe un très bon article du blog du développeur Android sur l'utilisation de cette fonctionnalité, et en particulier sur la manière de concevoir le code "la fonctionnalité de vérification de l'existence de cette fonctionnalité avant de l'utiliser" que j'ai mentionnée ci-dessus.
Au OP: J'ai écrit ceci principalement pour le bénéfice de tous ceux qui tombent par hasard 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, qu'elle a été testée de manière approfondie et avec succès) au niveau de l'API xx.
Une version de Android exécutée au niveau de l'API ci-dessus xx appliquera automatiquement le code de compatibilité pour prendre en charge les fonctionnalités disponibles au niveau de l'API xx ou antérieur, mais qui sont maintenant obsolètes au niveau supérieur de cette version Android.
Inversement, si vous utilisez des fonctionnalités devenues obsolètes at ou antérieur au niveau xx, le code de compatibilité sera non automatiquement appliqué par les versions de système d'exploitation à niveaux d'API plus élevés (qui n'incluent plus ces fonctionnalités) pour prendre en charge ces utilisations. Dans ce cas, votre propre code doit comporter des clauses de casse spéciales testant le niveau de l'API. Si le niveau du système d'exploitation détecté est supérieur à celui qui n'existe plus, votre code doit utiliser des fonctionnalités alternatives qui are disponible au niveau de l'API du système d'exploitation.
Si cela échoue, alors certaines fonctionnalités d'interface risquent de ne pas apparaître, ce qui déclencherait normalement des événements dans votre code. Il se peut que vous manquiez d'une fonctionnalité d'interface essentielle dont l'utilisateur a besoin pour déclencher ces événements et accéder à leurs fonctionnalités (comme dans le cas contraire). exemple ci-dessous).
Comme indiqué dans d'autres réponses, vous pouvez définir targetSdkVersion sur une valeur supérieure à minSdkVersion si vous souhaitez utiliser certaines fonctionnalités de l'API initialement définies à des niveaux d'API plus élevés que votre minSdkVersion et si vous avez pris des mesures pour que votre code puisse détecter et gérer l'absence de ces fonctionnalités à niveaux inférieurs à targetSdkVersion.
Afin de demander aux développeurs de tester spécifiquement le niveau d'API minimum requis pour utiliser une fonctionnalité, le compilateur émettra une erreur (pas simplement 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é rendue disponible pour la première fois. Pour supprimer cette erreur, la directive du compilateur
@TargetApi(nn)
indique au compilateur que le code contenu dans le champ d'application de cette directive (qui précède une méthode ou une classe) a été écrit pour tester un niveau d'API d'au moins nn avant d'appeler une méthode dépendant du moins de ce niveau d'API . Par exemple, le code suivant définit une méthode pouvant être appelée depuis du code dans une application ayant une minSdkVersion inférieure à 11 et une cibleSdkVersion supérieure ou égale à 11:
@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 aussi vouloir déclarer un targetSdkVersion supérieur si vous aviez testé à ce niveau supérieur et que tout fonctionnait, même si vous utilisiez non toute fonctionnalité d'un niveau d'API supérieur à votre minSdkVersion. Cela éviterait simplement d'avoir à accéder à un code de compatibilité destiné à s'adapter du niveau cible au niveau minimal, car vous auriez confirmé (par des tests) qu'aucune adaptation de ce type n'était nécessaire.
Un exemple de fonction d'interface utilisateur qui dépend de la targetSdkVersion déclarée serait le bouton de menu à trois points verticaux qui apparaît dans la barre d'état des applications ayant une targetSdkVersion inférieure à 11, lorsque ces applications s'exécutent sous l'API 11 et plus. Si votre application a une 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 se substituer à la version matérielle et/ou à l'écran précédente. de ce bouton (par exemple, comme on le voit dans Gingerbread) lorsque le système d'exploitation a un niveau API supérieur pour lequel un bouton de menu dédié sur le périphérique n'est plus utilisé. Toutefois, si vous définissez targetSdkVersion de votre application sur 11 ou une version supérieure, 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 avez autrement contourné la nécessité de: avoir un bouton de menu système; par conséquent, le "bouton de compatibilité" du menu à trois points verticaux 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 la substitution onCreateOptionsMenu (menu) de votre activité peut ne jamais être invoquée, ce qui, encore une fois, signifie que une partie importante des fonctionnalités de votre application pourrait être privée de son interface utilisateur. Sauf si, bien sûr, vous avez implémenté la barre d’action ou un autre moyen alternatif permettant à l’utilisateur d’accéder à ces fonctionnalités.
minSdkVersion, en revanche, stipule que la version du système d'exploitation d'un périphérique doit au moins avoir le même niveau d'API pour pouvoir exécuter votre application. Cela concerne les appareils capables de voir et de télécharger votre application lorsqu'elle se trouve sur la boutique d'applications Google Play (et éventuellement d'autres magasins d'applications). C'est une façon de dire que votre application s'appuie sur les fonctionnalités du système d'exploitation (API ou autres) qui ont été établies à ce niveau et ne dispose pas d'un moyen acceptable 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 à l'API consisterait à définir minSdkVersion sur 8 afin de vous assurer que votre application ne s'exécutera que sur une version du Interprète Dalvik (depuis que JIT a été introduit dans l'interprète Android au niveau 8 de l'API). Étant donné que les performances d'un interpréteur compatible JIT peuvent être jusqu'à cinq fois supérieures à celles d'un opérateur dépourvu de cette fonctionnalité, si votre application utilise beaucoup le processeur, vous souhaiterez peut-être exiger une API de niveau 8 ou supérieur afin de garantir des performances adéquates.
Un concept peut être mieux fourni avec des exemples, toujours . J'ai eu du mal à comprendre ce concept avant de plonger dans Android code source du framework et de faire des expériences, même après avoir lu tous les documents situés dans Android sites de développement et fils de discussion 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 défini dans le fichier targetSDKversion du fichier AndroidManifest.xml (<uses-sdk Android:targetSdkVersion="INTEGER_VALUE"/>). Si vous définissez une valeur inférieure ou égale à 10, votre DatePickerDialog ressemblera à gauche. Par contre, si vous définissez la valeur 11 ou une valeur supérieure, un DatePickerDialog ressemblera à droite avec le même code .
Le code que j'ai utilisé pour créer cet exemple est très simple. MainActivity.Java regarde:
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 regarde:
<RelativeLayout xmlns:Android="http://schemas.Android.com/apk/res/Android"
xmlns:tools="http://schemas.Android.com/tools"
Android:layout_width="match_parent"
Android:layout_height="match_parent" >
<Button
Android:layout_width="wrap_content"
Android:layout_height="wrap_content"
Android:onClick="onClickButton"
Android:text="Button" />
</RelativeLayout>
C'est ça. C'est vraiment tous les codes dont j'ai besoin pour tester cela.
Et ce changement de look est parfaitement clair lorsque vous voyez le code source du framework Android . Cela 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 constater, la structure récupère la version actuelle de targetSDKversion et définit un thème différent. Ce type d’extrait de code (getApplicationInfo().targetSdkVersion >= SOME_VERSION) est disponible ici et là dans le cadre Android.
Un autre exemple concerne la classe WebView . Les méthodes publiques de la classe Webview doivent être appelées sur le thread principal. Sinon, le système d'exécution renvoie un RuntimeException lorsque vous définissez targetSDKversion 18 ou une version supérieure. Ce comportement peut être clairement livré 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 Android doc dit, " À mesure que 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, ainsi que la manière dont ce changement est accompli.
En résumé, Android doc indique ". Cet attribut (targetSdkVersion) informe le système que vous avez testé la version cible et que le système doit n'activez aucun comportement de compatibilité pour maintenir la compatibilité en aval de votre application avec la version cible. ". Ceci est vraiment clair avec le cas WebView. C'était correct 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 cadre Android lève une exception RuntimeException sur les périphériques JELLY_BEAN_MR2. Cela ne devrait tout simplement pas permettre les comportements nouvellement introduits pour son intérêt, ce qui entraînerait un résultat fatal. Donc, ce que nous devons faire est de vérifier si tout va bien sur certaines versions targetSDK. Nous obtenons des avantages, tels que l’amélioration de l’apparence, avec la définition d’une cibleSDKversion plus élevée, mais cela implique des responsabilités.
EDIT: disclaimer. Le constructeur DatePickerDialog qui définit différents thèmes en fonction de la version actuelle de targetSDKversion (que j'ai présentée ci-dessus) a été modifié dans commit ultérieur . Néanmoins, j'ai utilisé cet exemple, car la logique n'a pas été modifiée et que l'extrait de code montre clairement le concept targetSDKversion.
Pour ceux qui veulent un résumé,
Android:minSdkVersion
est la version minimale jusqu'à ce que votre application prenne en charge. Si votre appareil dispose de la version inférieure de Android, l'application ne sera pas installée.
tandis que,
Android:targetSdkVersion
est le niveau de l'API auquel votre application est conçue pour fonctionner. Cela signifie que le système de votre téléphone n'a pas besoin de recourir à des comportements de compatibilité pour maintenir la compatibilité ascendante, car vous avez effectué des tests jusqu'à cette API.
Votre application fonctionnera toujours sur Android versions supérieures à celles données targetSdkVersion mais Android seront compatibles.
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 maximale jusqu’à laquelle vous autorisez l’installation de votre application.
c'est à dire. pour MinSDK -4, maxSDK - 8, targetSDK - 8 Mon application fonctionnera au minimum 1.6, mais j’ai également utilisé des fonctionnalités prises 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 une API> 8.
Au moment de la rédaction de cette réponse, Android la documentation ne l'expliquait pas très bien. Maintenant, c'est très bien expliqué. Vérifiez ici
Si vous obtenez des erreurs de compilation, par exemple:
<uses-sdk
Android:minSdkVersion="10"
Android:targetSdkVersion="15" />
.
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 nécessite le niveau 11 de l’API (la valeur minimale est 10 à présent): Android.graphics.BitmapFactory $ Options # inBitmap
Depuis la version 17 de Android Outils de développement (ADT), une nouvelle annotation très utile, @TargetApi, permet de résoudre ce problème très facilement. Ajoutez-le avant la méthode qui inclut 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 ça va courir!
EDIT: Cela entraînera une erreur d’exécution au niveau de l’API inférieur à 11. Sur 11 ou plus, il s’exécutera sans problème. Vous devez donc être sûr d'appeler cette méthode sur un chemin d'exécution protégé par le contrôle de version. TargetApi vous permet simplement de le compiler mais vous l'exécutez à vos risques et périls.
Le sdk cible est la version que vous souhaitez cibler, et sdk min est la version minimale.
_Android:minSdkVersion_ et _Android:targetSdkVersion_ sont des valeurs entières que nous devons déclarer dans le fichier manifeste Android, mais dont les propriétés sont différentes.
Android:minSdkVersion: Il s'agit du niveau minimal requis de l'API 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'analyseur apparaîtra et le problème de l'application non prise en charge apparaîtra.
Android:targetSdkVersion: La version du sdk cible consiste à définir le niveau de l'API cible de l'application. si cet attribut n'est pas déclaré dans le manifeste, la version de minSdk sera votre version de TargetSdk. Cela est toujours vrai que "l'application prend en charge l'installation sur toutes les versions supérieures de l'API déclarées comme version TargetSdk". Pour que la cible de l'application soit limitée, nous devons déclarer maxSdkVersion dans notre fichier manifeste ...
Si vous créez des applications qui nécessitent autorisations dangereuses et définissez targetSDK sur 23 ou plus , vous devez être prudent. Si vous ne vérifiez pas les autorisations au moment de l'exécution, vous obtiendrez une exception SecurityException. 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.