Version du SDK Android Min vs.Version SDK cible

En ce qui concerne le développement d'applications pour Android, quelle est la différence entre la version Min et la version SDK cible? Eclipse ne me laisse pas créer un nouveau projet à moins que les versions Min et Target soient identiques!

android: minSdkVersion

Un entier désignant le niveau d'API minimum 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 API que l'application cible.

Avec cet attribut défini, l'application indique qu'elle est capable de 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 plateforme de désactiver les paramètres de compatibilité qui ne sont pas requis pour la version cible (qui pourraient sinon être activés afin de maintenir la compatibilité ascendante) ou d'activer des fonctionnalités plus récentes qui ne sont pas 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 informe simplement la plate-forme que vous avez testée par rapport à la version cible et la plate-forme ne doit pas effectuer de travail supplémentaire pour maintenir la compatibilité ascendante 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 (déclarant essentiellement que le targetSDK n'affecte pas la compilation d'une application) est tout à fait 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é une compatibilité descendante . En d'autres termes, imaginez que vous souhaitez utiliser une fonctionnalité qui n'a été introduite que récemment, mais qui n'est pas critique pour votre application. Vous devez ensuite définir le targetSDK à la version où cette nouvelle fonctionnalité a été introduite et le minimum à quelque chose de inférieur afin 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 des gestes. Cependant, chaque commande qui peut être reconnue par un geste peut également être effectuée par un bouton ou à partir du menu. Dans ce cas, les gestes sont un «extra cool» mais ne sont pas requis. Par conséquent, vous définiriez le sdk cible à 7 ("Eclair" lorsque la bibliothèque GestureDetection a été introduite), et le minimumSDK au niveau 3 ("Cupcake") afin que même les personnes ayant de très 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, c'est un exemple daté car presque personne n'a encore de téléphone v1.5, mais il fut un temps où la compatibilité avec la v1 était maintenue.

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 rester coincés avec Eclair jusqu'à ce qu'ils 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 du blog du développeur Android sur la façon d'utiliser cette fonctionnalité, et en particulier, comment concevoir le code "vérifier que la fonctionnalité existe avant de l'utiliser" que j'ai mentionné ci-dessus.

Au PO: J'ai écrit ceci principalement pour le bénéfice de quiconque se heurtera à cette question à l'avenir, car je me rends compte 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, a été minutieusement et correctement testée) au niveau de l'API xx.

Une version d'Android exécutée à un niveau d'API supérieur à xx appliquera automatiquement le code de compatibilité pour prendre en charge toutes les fonctionnalités sur lesquelles vous pourriez compter et qui étaient disponibles au niveau ou avant le niveau d'API xx, mais qui sont désormais obsolètes au niveau supérieur de cette version d'Android.

Inversement, si vous utilisez des fonctionnalités devenues obsolètes au niveau xx ou avant , le code de compatibilité ne sera pas automatiquement appliqué par les versions du système d'exploitation à des niveaux d'API plus élevés (qui n'incluent plus ces fonctionnalités) pour prendre en charge ces utilisations. Dans ce cas, votre code doit avoir des clauses particulières de cas test , le niveau de l' API et, si le niveau du système d'exploitation détecté est un plus qui n'a plus la fonction API donné, votre code doit utiliser des fonctions de remplacement qui sont disponibles au niveau du OS en cours d' exécution Niveau API.

S'il ne parvient pas à le faire, certaines fonctionnalités d'interface peuvent tout simplement ne pas apparaître qui déclencheraient normalement des événements dans votre code, et il se peut que vous manquiez une fonctionnalité d'interface critique dont l'utilisateur a besoin pour déclencher ces événements et accéder à leurs fonctionnalités (comme dans le exemple ci-dessous).

Comme indiqué dans d'autres réponses, vous pouvez définir targetSdkVersion plus haut que minSdkVersion si vous souhaitez utiliser certaines fonctionnalités d'API initialement définies à des niveaux d'API supérieurs à votre minSdkVersion, et avez pris des mesures pour vous assurer que votre code puisse détecter et gérer l'absence de ces fonctionnalités sur niveaux inférieurs à targetSdkVersion.

Afin d'avertir les développeurs de tester spécifiquement le niveau d'API minimum requis 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 d'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 le champ d'application de cette directive (qui précédera soit une méthode soit une classe) a été écrit pour tester un niveau d'API d'au moins nn avant d'appeler une méthode qui dépend d'avoir au moins ce niveau d'API . Par exemple, le code suivant définit une méthode qui peut être appelée à partir du code dans une application qui a une minSdkVersion inférieure à 11 et une targetSdkVersion de 11 ou supérieure:

@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 plus targetSdkVersion si vous aviez testé à ce niveau supérieur et tout a fonctionné, même si vous n'utilisez toutes les fonctionnalités d'un niveau API plus élevé que votre minSdkVersion. Ce serait juste pour éviter la surcharge d'accès au code de compatibilité destiné à s'adapter du niveau cible au niveau min, car vous auriez confirmé (par le biais de tests) qu'aucune telle adaptation n'était requise.

Un exemple de fonctionnalité d'interface utilisateur qui dépend de la version de 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 API 11 et supérieures. Si votre application a une version targetSdkVersion de 10 ou inférieure, il est supposé que l'interface de votre application dépend de l'existence d'un bouton de menu dédié, et donc le bouton à trois points semble remplacer le matériel dédié et / ou les versions à l'écran précédents. de ce bouton (par exemple, comme vu dans Gingerbread) lorsque le système d'exploitation a un niveau d'API plus élevé pour lequel un bouton de menu dédié sur l'appareil n'est plus supposé. Cependant, si vous définissez targetSdkVersion de votre application sur 11 ou plus, il est supposé que vous avez profité des fonctionnalités introduites à ce niveau qui remplacent le bouton de menu dédié (e. g., la barre d'action), ou que vous avez autrement contourné la nécessité d'avoir un bouton de menu système; par conséquent, le menu "bouton de compatibilité" à 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é pourrait ne jamais être invoquée, 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 n'ayez implémenté la barre d'actions ou un autre moyen alternatif pour l'utilisateur d'accéder à ces fonctionnalités. t trouver un bouton de menu, elle ne peut pas appuyer dessus, et cela, à son tour, signifie que la substitution onCreateOptionsMenu (menu) de votre activité pourrait ne jamais être invoquée, ce qui, à son tour, signifie qu'une partie importante des fonctionnalités de votre application pourrait être privé de son interface utilisateur. À moins, bien sûr, que vous n'ayez implémenté la barre d'actions ou un autre moyen alternatif pour l'utilisateur d'accéder à ces fonctionnalités. t trouver un bouton de menu, elle ne peut pas appuyer dessus, et cela, à son tour, signifie que la substitution onCreateOptionsMenu (menu) de votre activité pourrait ne jamais être invoquée, ce qui, à son tour, signifie qu'une partie importante des fonctionnalités de votre application pourrait être privé de son interface utilisateur. À moins, bien sûr, que vous n'ayez implémenté la barre d'actions ou un autre moyen alternatif pour l'utilisateur d'accéder à ces fonctionnalités.

minSdkVersion, en revanche, énonce une exigence que la version du système d'exploitation d'un appareil ait au moins ce niveau d'API pour exécuter votre application. Cela affecte les appareils qui peuvent voir et télécharger votre application lorsqu'elle est sur l'App Store de Google Play (et éventuellement d'autres magasins d'applications également). C'est une façon de déclarer que votre application s'appuie sur des fonctionnalités du système d'exploitation (API ou autres) qui ont été établies à ce niveau, et n'a pas de moyen acceptable pour faire face à l'absence de ces fonctionnalités.

Un exemple d'utilisation de minSdkVersion pour garantir la présence d'une fonctionnalité qui n'est pas liée à l'API serait de définir minSdkVersion sur 8 afin de garantir que votre application ne fonctionnera 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ète compatible JIT peuvent être jusqu'à cinq fois supérieures à celles qui ne disposent pas de cette fonctionnalité, si votre application fait un usage intensif du 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 livré avec des exemples, toujours . J'ai eu du mal à comprendre ce concept jusqu'à ce que je fouille dans le code source du framework Android et fasse quelques expériences, même après avoir lu tous les documents dans les sites de développement 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 selon le niveau que vous placez dans targetSDKversion ( <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>) du fichier AndroidManifest.xml . Si vous définissez la valeur 10 ou moins, votre DatePickerDialog ressemblera à gauche. D'un autre côté, si vous définissez la valeur 11 ou plus, un DatePickerDialog ressemblera à droite, avec le même code .

Le code que j'ai utilisé pour créer cet exemple est super simple. MainActivity.javaregards :

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.xmlregarde:

<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 limpide 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 la version actuelle de targetSDK et définit un thème différent. Ce type d'extrait de code ( getApplicationInfo().targetSdkVersion >= SOME_VERSION) peut être trouvé 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 et, si ce n'est pas le cas, le système d'exécution renvoie un 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 dit: " À mesure qu'Android évolue avec chaque nouvelle version, certains comportements et même les apparences peuvent changer ." Nous avons donc examiné le changement de comportement et d'apparence, et comment ce changement est accompli.

En résumé, le document Android dit " Cet attribut (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é ascendante de votre application avec la version cible. ". C'est vraiment clair avec le cas WebView. C'était OK jusqu'à ce que JELLY_BEAN_MR2 soit libéré 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 RuntimeException sur les appareils JELLY_BEAN_MR2. Il ne devrait tout simplement pas activer les comportements nouvellement introduits pour son intérêt, ce qui entraîne un résultat fatal. Donc, ce que nous devons faire est de vérifier si tout va bien sur certaines ciblesSDKversions. Nous obtenons des avantages tels que l'amélioration de l'apparence en définissant une version plus élevée de targetSDK,

EDIT: avis de non-responsabilité. Le constructeur DatePickerDialog qui définit différents thèmes en fonction de la version actuelle de targetSDK (que j'ai montré ci-dessus) a en fait été modifié lors de la validation ultérieure . Néanmoins, j'ai utilisé cet exemple, car la logique n'a pas été modifiée, et ces extraits de code montrent clairement le concept targetSDKversion.

Pour ceux qui veulent un résumé,

android:minSdkVersion

est la version minimale jusqu'à ce que votre application le prenne en charge. Si votre appareil a une version inférieure d'Android, l'application ne s'installera pas.

tandis que,

android:targetSdkVersion

est le niveau d'API jusqu'à ce que votre application soit conçue pour fonctionner. Cela signifie que le système de votre téléphone n'a pas besoin d'utiliser de comportements de compatibilité pour maintenir la compatibilité ascendante, car vous avez testé jusqu'à cette API.

Votre application fonctionnera toujours sur les versions d'Android supérieures à ce qui est indiqué, targetSdkVersionmais le comportement de compatibilité avec Android démarrera .

Freebie -

android:maxSdkVersion

si la version de l'API de votre appareil est supérieure, l'application ne s'installe pas. C'est à dire. il s'agit de 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 qui ne sont prises en charge qu'en 2.2 qui seront visibles si elle est installée sur un appareil 2.2. De plus, 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-le 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 l'API niveau 11 (la valeur minimale actuelle est de 10): android.graphics.BitmapFactory $ Options # inBitmap

Depuis la version 17 des outils de développement Android (ADT), une annotation nouvelle et très utile @TargetApipeut résoudre ce problème très facilement. Ajoutez-le avant la méthode qui entoure 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 s'exécutera!

EDIT: Cela entraînera une erreur d'exécution au niveau de l'API inférieur à 11. Sur 11 ou supérieur, 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 la vérification de version. TargetApi vous permet simplement de le compiler mais vous l'exécutez à vos propres risques.

android:minSdkVersionet les android:targetSdkVersiondeux sont des valeurs entières 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 d'API minimum requis pour exécuter une application Android. Si nous installons la même application sur une version d'API inférieure, l'erreur de l'analyseur apparaîtra et le problème d'application non prise en charge apparaîtra.

android:targetSdkVersion:La version SDK cible consiste à définir le niveau d'API cible de l'application. si cet attribut n'est pas déclaré dans le manifeste, la version minSdk sera votre version TargetSdk. Cela est toujours vrai que «l'installation de support d'application sur toutes les versions supérieures de l'API que nous avons déclarée comme version TargetSdk». Pour faire une cible limitée aux applications, nous devons déclarer maxSdkVersion dans notre fichier manifeste ...

Si vous créez des applications qui nécessitent des autorisations dangereuses et définissez targetSDK sur 23 ou plus, vous devez être prudent. Si vous ne vérifiez pas les autorisations sur le runtime, vous obtiendrez une SecurityException et si vous utilisez du code dans un bloc try, par exemple, ouvrez la caméra, il peut être difficile de détecter une erreur si vous ne vérifiez pas logcat.

Target sdk est la version que vous souhaitez cibler, et min sdk est la version minimale.