Version SDK min Android vs. Version SDK Target

le commentaire posté par L'OP à la question (essentiellement en disant 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 plus élevé que votre minimum, mais vous avez assuré la compatibilité ascendante . En d'autres mots, imaginez que vous voulez utilisez une fonctionnalité qui n'a été introduite que récemment, mais qui n'est pas critique pour votre application. Vous définiriez alors targetSDK à la version où cette nouvelle fonctionnalité a été introduite et le minimum à quelque chose de plus bas 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 gestuelle. Cependant, toute commande qui peut être reconnue par un geste peut aussi être faite par un bouton ou à partir du menu. Dans ce cas, les gestes sont un "frais supplémentaires", mais ne sont pas obligatoires. 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") de sorte que même les personnes avec des téléphones vraiment vieux pourrait utiliser votre application. Tout ce que vous avez à faire est de s'assurer que votre application a vérifié la version D'Android il était en cours d'exécution avant d'essayer d'utiliser la bibliothèque de geste, pour éviter d'essayer de l'utiliser si elle n'existait pas. (Il est vrai que c'est daté exemple depuis à peine n'importe qui a encore un v1.5 téléphone, mais il fut un temps où il fallait maintenir la compatibilité avec v1.5 était vraiment important.)

pour donner un autre exemple, vous pouvez utiliser ceci si vous voulez utiliser une fonctionnalité de Gingerbread ou Honeycomb. Certaines personnes recevront les mises à jour bientôt, 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 cool, mais sans exclure une partie de votre possible marché.

Il ya un très bon article de la Android developer's blog sur la façon d'utiliser cette fonctionnalité, et en particulier, comment concevoir la" vérifier la fonctionnalité existe avant de l'utiliser " code que j'ai mentionné ci-dessus.

à L'OP: j'ai écrit ceci principalement pour le bénéfice de quiconque tombe sur 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, qu'elle a été testée avec succès) au niveau de L'API xx.

une version D'Android tournant au niveau API au-dessus de xx appliquera le code de compatibilité automatiquement pour prendre en charge toutes les fonctionnalités sur lesquelles vous pourriez Compter qui étaient disponibles au niveau API xx ou avant, mais qui sont maintenant obsolètes au niveau supérieur de cette version Android.

inversement, si vous utilisez des fonctionnalités qui sont devenues obsolètes à ou avant au niveau xx, le code de compatibilité sera et non appliqué automatiquement par les versions OS à des niveaux D'API plus élevés (qui ne comprennent plus ces fonctionnalités) pour supporter ces utilisations. Dans ce cas, votre propre code doit avoir des clauses spéciales qui testent le niveau de L'API et, si le niveau D'OS détecté est plus élevé, il n'a plus l'API donnée. fonctionnalité, votre code doit utiliser des fonctionnalités alternatives que sont disponibles au niveau de L'API de l'OS en cours d'exécution.

s'il ne le fait pas, alors certaines fonctionnalités de l'interface peuvent tout simplement ne pas apparaître qui déclencherait normalement des événements dans votre code, et vous pouvez manquer une fonctionnalité de l'interface critique dont l'Utilisateur a besoin pour déclencher ces événements et accéder à leur fonctionnalité (comme dans l'exemple ci-dessous).

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

afin d'avertir les développeurs de tester spécifiquement le niveau minimum D'API requis pour utiliser une fonctionnalité, le compilateur émettra une erreur (pas seulement un avertissement) si le code contient faire appel à toute méthode qui a été définie à un niveau D'API posté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 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 API d'au moins nn avant d'appeler n'importe quelle méthode qui dépend de avoir au moins ce niveau D'API. Par exemple, le code suivant définit une méthode qui peut être appelée à partir d'un code dans une application qui a une version minsd de moins de 11 et une version targetsd de 11 ou plus:

@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 une version de targetsdk plus élevée si vous aviez testé à ce niveau plus élevé et que tout avait fonctionné, même si vous étiez et non en utilisant n'importe quelle fonctionnalité D'un niveau D'API plus élevé que votre minSdkVersion. Ce serait juste pour éviter les frais généraux d'accès au code de compatibilité destiné à s'Adapter du niveau cible au niveau min, puisque vous auriez confirmé (par des tests) qu'une telle adaptation n'était pas nécessaire.

un exemple de fonctionnalité D'interface utilisateur qui dépend de la targetSdkVersion déclarée serait le bouton de menu à trois points verticaux qui apparaît sur la barre d'état des applications ayant une targetSdkVersion inférieure à 11, lorsque ces applications tournent sous API 11 et plus. Si votre application a une version de targetsdk de 10 ou moins, il est supposé que l'interface de votre application dépend de l'existence d'un bouton menu dédié, et donc le bouton à trois points semble prendre la place du matériel dédié et/ou des versions précédentes à l'écran 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 menu dédié sur le périphérique n'est plus supposé. Cependant, si vous définissez targetSdkVersion de votre application à 11 ou plus, il est supposé que vous avez profité des fonctionnalités introduites à ce niveau qui remplacent le bouton menu dédié (par exemple, la barre D'Action), ou que vous avez autrement contourné la nécessité d'avoir un bouton menu système; par conséquent, le menu à trois points verticaux "bouton de compatibilité" disparaît. Dans ce cas, si l'utilisateur ne peut pas trouver un bouton menu, elle ne peut pas l'appuyer, et cela, à son tour, signifie que la commande onreateoptionsmenu(menu) de votre activité pourrait ne jamais être invoquée, ce qui, encore une fois à son tour, signifie qu'une partie importante de votre application fonctionnalité pourrait être privé de son interface utilisateur. À moins, bien sûr, que vous n'ayez mis en place la barre D'Action ou un autre moyen alternatif permettant à l'utilisateur d'accéder à ces fonctionnalités.

minSdkVersion, par contre, stipule que la version OS d'un périphérique doit avoir au moins ce niveau D'API pour exécuter votre application. Cela affecte les appareils qui sont en mesure de voir et de télécharger votre application lorsqu'elle est sur L'app store de Google Play (et peut-être d'autres magasins d'applications). C'est une façon d'affirmer que votre application repose sur des fonctionnalités OS (API ou autres) qui ont été établies à ce niveau, et ne dispose pas d'un moyen acceptable pour traiter l'absence de ces fonctionnalités.

un exemple d'utilisation de minSdkVersion pour assurer la présence d'une fonctionnalité liée à L'API et non serait de définir minSdkVersion à 8 afin de s'assurer que votre application ne fonctionnera que sur une version JIT du Dalvik. interpréteur (depuis que JIT a été présenté à L'interpréteur Android au niveau API 8). Étant donné que les performances d'un interpréteur JIT peuvent être jusqu'à cinq fois supérieures à celles d'un interpréteur qui ne dispose pas de cette fonctionnalité, si votre application fait un usage intensif du processeur, vous pourriez avoir besoin d'API de niveau 8 ou plus afin d'assurer 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 creuse dans le code source de cadre Android, et faire quelques expériences, même après avoir lu tous les documents dans les sites de développeur Android et les threads stackoverflow connexes. Je vais partager deux exemples qui m'ont beaucoup aidé à bien comprendre ces concepts.

A DatePickerDialog sera différent selon le niveau que vous mettez dans AndroidManifest.targetSDKversion du fichier xml ( <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/> ). Si vous définissez la valeur 10 ou moins, votre DatePickerDialog ressemblera à left. D'autre part, si vous définissez la valeur de 11 ou plus, un DatePickerDialog ressemblera à droite, avec le même code .

le code que j'ai utilisé créer cet échantillon 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 looks:

<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 tout. C'est vraiment tous les codes dont j'ai besoin pour tester ça.

et ce changement de look est très clair lorsque vous voyez le code source du cadre Android . Il 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 reçoit la version actuelle de targetSDKversion et définit un thème différent. Ce genre d'extrait de code( getApplicationInfo().targetSdkVersion >= SOME_VERSION ) peut être trouvé ici et là dans Android framework.

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 lance un RuntimeException , lorsque vous définissez targetSDKversion 18 ou plus. 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 , déclare, " Comme Android évolue à chaque nouvelle version, certains comportements et même les apparences peuvent changer ."Nous avons donc observé un changement de comportement et d'apparence, et comment ce changement est accompli.

en résumé, L'Android doc dit " cet attribut(targetSdkVersion) informe le système que vous avez testé par rapport à la version cible et le système ne devrait pas permettre des comportements de compatibilité pour maintenir la compatibilité de votre application avec la version cible. ". C'est très clair avec WebView case. Il était OK jusqu'à ce que JELLY_BEAN_MR2 libéré pour appeler la méthode publique de classe de WebView sur le fil Non-principal. C'est absurde si Android framework lance une RuntimeException sur les appareils JELLY_BEAN_MR2. Il ne devrait tout simplement pas permettre les comportements nouvellement introduits pour son intérêt, qui causent résultat fatal. Donc, ce que nous devons faire est de vérifier si tout va bien sur certaines targetSDKversions. Nous obtenons des avantages comme l'amélioration de l'apparence avec la mise en place de targetSDKversion supérieur, mais il vient avec la responsabilité.

EDIT : avertissement. Le constructeur DatePickerDialog qui a défini différents thèmes basés sur la version actuelle de targetSDKversion(que j'ai montré ci-dessus)) en fait a été modifié dans plus tard commit . Néanmoins j'ai utilisé cet exemple, parce que la logique n'a pas été changée, et ce code snippet montre clairement le concept de targetSDKversion.

Pour ceux qui veulent un résumé,

android:minSdkVersion

est la version minimale jusqu'à ce que votre application supporte. Si votre appareil possède une version plus basse d'android , app ne s'installera pas.

tandis que,

android:targetSdkVersion

est le niveau D'API auquel votre application est conçue pour fonctionner. Cela signifie que le système de votre téléphone n'a pas besoin d'utiliser des comportements de compatibilité pour maintenir la compatibilité forward parce que vous avez testé till avec cette API.

votre application fonctionnera toujours sur les versions Android supérieures à celles données targetSdkVersion , mais le comportement de compatibilité android sera activé.

Freebie -

android:maxSdkVersion

si la version API de votre périphérique est plus élevée, app ne s'installera pas. IE. c'est l'API max jusqu'à laquelle vous autorisez l'installation de votre application.

ie. pour MinSDK -4, maxSDK - 8, targetSDK-8 Mon application fonctionnera sur 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 périphérique 2.2. De plus, pour maxSDK - 8, cette application ne s'installera pas sur les téléphones utilisant API > 8.

au moment d'écrire cette réponse, la documentation Android ne faisait pas un bon travail pour l'expliquer. Maintenant, il est très bien expliqué. Vérifier ici

si vous avez 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 l'erreur de compilation:

Le champ

exige le niveau D'API 11 (min actuel est 10): Android.graphique.BitmapFactory $ Options#inBitmap

depuis la version 17 D'Android Development Tools (ADT) Il ya une nouvelle et très utile annotation @TargetApi qui peut corriger ce très facilement. Ajouter il 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**
            //...
      }
    }

Pas d'erreurs de compilation maintenant et cela fonctionnera !

EDIT: il en résultera une erreur d'exécution au niveau de L'API inférieure à 11. Sur 11 ou plus, il fonctionne sans problème. Vous devez donc être sûr d'appeler cette méthode sur un chemin d'exécution gardé par la vérification de version. TargetApi permet de compiler, mais vous l'exécutez sur votre propre risque.

android:minSdkVersion et android:targetSdkVersion tous deux 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: C'est le niveau minimum 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 application not support apparaîtra.

android:targetSdkVersion: cible sdk la version est de définir la Cible de l'API au niveau de l'application. si cet attribut n'est pas déclaré dans manifest, la version minSdk sera votre version TargetSdk. Est-ce toujours vrai que "support de l'application d'installation sur tous les plus de la version de l'API, nous avons déclaré que TargetSdk Version". Pour rendre app limited target, nous devons déclarer maxSdkVersion dans notre fichier manifest...

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

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