Version du SDK Min d'Android par rapport à la version du SDK cible

Question

Lorsqu'il s'agit de développer des applications pour Android, quelle est la différence entre la version Min et la version Target SDK ? Eclipse ne me laisse pas créer un nouveau projet si les versions Min et Target ne sont pas les mêmes !

Answer 1

Le commentaire posté par le PO en dessous de sa question (qui dit en gros que le targetSDK n'affecte pas la compilation d'une application) est entièrement faux ! Désolé d'être brutal.

En bref, voici l'utilité de déclarer un targetSDK différent du minSDK : Cela signifie que vous utilisez des fonctionnalités d'un SDK de plus haut niveau que votre minSDK, mais vous avez assurer la rétrocompatibilité . En d'autres termes, imaginez que vous souhaitiez utiliser une fonctionnalité qui n'a été introduite que récemment, mais qui n'est pas essentielle à votre application. Vous définirez alors le 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 continuer à utiliser votre application.

Pour donner un exemple, disons que vous écrivez une application qui fait un usage intensif de 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 "plus" mais ne sont pas nécessaires. Par conséquent, vous fixeriez le sdk cible à 7 ("Eclair", lorsque la bibliothèque GestureDetection a été introduite) et le sdk minimum au niveau 3 ("Cupcake") afin que même les personnes possédant de très vieux téléphones puissent utiliser votre application. Tout ce que vous auriez à faire est de vous assurer que votre application vérifie la version d'Android sur laquelle elle fonctionne avant d'essayer d'utiliser la bibliothèque gestuelle, pour éviter d'essayer de l'utiliser si elle n'existe pas. (Certes, il s'agit d'un exemple daté puisque presque personne n'a encore de téléphone v1.5, mais il fut un temps où maintenir la compatibilité avec la v1.5 était vraiment important).

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

Il y a un très bon article du Blog des développeurs Android sur la façon d'utiliser cette fonctionnalité, et en particulier, sur la façon de 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 toute personne qui tomberait sur cette question à l'avenir, car je réalise que votre question a été posée il y a longtemps.

Answer 2

Android:minSdkVersion

Un nombre entier désignant le niveau d'API minimum requis pour que l'application fonctionne. 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 nombre entier désignant le niveau d'API ciblé par l'application.

Avec cet attribut défini, l'application indique qu'elle est capable de fonctionner 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é qui ne sont pas requis pour la version cible (qui pourraient autrement être activés afin de maintenir la compatibilité avec l'avenir) 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 des fonctionnalités différentes pour des versions différentes de la plate-forme - cela informe simplement la plate-forme que vous avez testé la version cible et que la plate-forme ne doit pas effectuer de travail supplémentaire pour maintenir la compatibilité avec la version cible.

Pour plus d'informations, consultez cette URL :

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

Answer 3

Lorsque vous définissez targetSdkVersion="xx", vous certifiez que votre application fonctionne correctement (c'est-à-dire qu'elle a été testée de manière approfondie et avec succès) au niveau xx de l'API.

Une version d'Android fonctionnant au niveau de l'API au-dessus de xx appliquera automatiquement un code de compatibilité pour prendre en charge toutes les fonctionnalités dont vous dépendez et qui étaient disponibles au niveau xx de l'API ou avant, 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 à l'adresse o avant au niveau xx, le code de compatibilité sera pas être automatiquement appliquées par les versions du système d'exploitation à des niveaux d'API plus élevés (qui ne comprennent plus ces fonctionnalités) pour prendre en charge ces utilisations. Dans cette situation, votre propre code doit avoir des clauses de cas spéciaux qui testent le niveau d'API et, si le niveau d'OS détecté est un niveau supérieur qui ne possède plus la fonctionnalité d'API donnée, votre code doit utiliser des fonctionnalités alternatives qui sont disponible au niveau de l'API du système d'exploitation en cours d'exécution.

S'il ne le fait pas, il se peut que certaines fonctions d'interface n'apparaissent pas alors qu'elles devraient normalement déclencher 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 à leur fonctionnalité (comme dans l'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 de l'API initialement définies à des niveaux d'API plus élevés que votre minSdkVersion, et si vous avez pris des mesures pour vous assurer que votre code peut 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 d'API minimum requis pour utiliser une fonctionnalité, le compilateur émettra une erreur (et pas seulement un avertissement) si le code contient un appel à une méthode qui a été 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é rendue disponible pour la première fois. Pour supprimer cette erreur, la directive du compilateur

@TargetApi(nn)

indique au compilateur que le code compris dans la portée de cette directive (qui précède soit une méthode, soit une classe) a été écrit pour tester un niveau d'API d'au moins nn avant d'appeler toute méthode qui dépend de ce niveau d'API. Par exemple, le code suivant définit une méthode qui peut être appelée à partir du code d'une application dont la version minimale (minSdkVersion) est inférieure à 11 et la version cible (targetSdkVersion) égale ou supérieure à 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 también de déclarer une targetSdkVersion plus élevée si vous avez testé à ce niveau supérieur et que tout a fonctionné, même si vous étiez pas utiliser les fonctionnalités d'un niveau d'API supérieur à votre version minimale de SDK. Il s'agirait simplement d'éviter les frais généraux liés à l'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é de l'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 dont la targetSdkVersion est inférieure à 11, lorsque ces applications fonctionnent sous 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é, et donc le bouton à trois points apparaît pour prendre la place des anciennes versions matérielles et/ou à 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 de menu dédié sur le périphérique n'est plus supposé. Toutefois, si vous définissez la targetSdkVersion de votre application à 11 ou plus, on suppose 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 contourné d'une autre manière la nécessité d'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 surcharge onCreateOptionsMenu(menu) de votre activité pourrait ne jamais être invoquée, ce qui, à son tour, signifie qu'une partie importante de la fonctionnalité de votre application pourrait être privée de son interface utilisateur. À moins, bien sûr, que vous n'ayez 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 appareil doit avoir au moins ce niveau d'API pour pouvoir exécuter votre application. Cela a une incidence sur les appareils qui peuvent voir et télécharger votre application lorsqu'elle se trouve dans la boutique d'applications Google Play (et éventuellement dans d'autres boutiques d'applications). C'est une façon d'indiquer que votre application repose sur des fonctionnalités du système d'exploitation (API ou autres) qui ont été établies à ce niveau, et qu'elle ne dispose pas d'un moyen acceptable de faire face à l'absence de ces fonctionnalités.

Un exemple de l'utilisation de minSdkVersion pour assurer la présence d'une fonctionnalité qui est pas En ce qui concerne l'API, vous pouvez définir minSdkVersion à 8 afin de vous assurer que votre application ne s'exécutera que sur une version de l'interpréteur Dalvik compatible avec le JIT (puisque le JIT a été introduit dans l'interpréteur Android au niveau 8 de l'API). Étant donné que les performances d'un interprète compatible avec le JIT peuvent être jusqu'à cinq fois supérieures à celles d'un interprète dépourvu de cette fonctionnalité, si votre application fait un usage intensif du processeur, vous pouvez exiger un niveau d'API 8 ou supérieur afin de garantir des performances adéquates.

Answer 4

Un concept peut être mieux présenté avec des exemples, toujours . J'ai eu du mal à comprendre ces concepts jusqu'à ce que je creuse dans le code source du framework Android, et que je fasse quelques expériences, même après avoir lu tous les documents sur les sites des développeurs Android et les fils de discussion stackoverflow. Je vais partager deux exemples qui m'ont beaucoup aidé à comprendre pleinement ces concepts.

A DatePickerDialog sera différent en fonction du niveau que vous avez indiqué dans la variable targetSDKversion() du fichier AndroidManifest.xml. <uses-sdk android:targetSdkVersion="INTEGER_VALUE"/> ). Si vous définissez la valeur 10 ou moins, votre DatePickerDialog aura l'apparence suivante. En revanche, si vous définissez la valeur 11 ou plus, votre DatePickerDialog aura l'air d'être à droite, avec le même code .

Le code que j'ai utilisé pour créer cet échantillon est très simple. MainActivity.java regards :

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 regards :

<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 tout le code dont j'ai besoin pour tester ça.

Et ce changement de look est clair comme de l'eau de roche quand on voit les Code source du cadre Android . C'est comme ça :

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 cadre obtient la version actuelle du kit de développement cible et définit un thème différent. Ce type d'extrait de code ( getApplicationInfo().targetSdkVersion >= SOME_VERSION ) peuvent être trouvés ici et là dans le cadre d'Android.

Un autre exemple concerne WebView classe. Les méthodes publiques de la classe Webview doivent être appelées sur le fil d'exécution principal, et si ce n'est pas le cas, le système d'exécution lève un RuntimeException lorsque vous définissez la version 18 ou supérieure de targetSDK. Ce comportement peut être clairement livré avec son code source . C'est écrit comme ça.

sEnforceThreadChecking = context.getApplicationInfo().targetSdkVersion >=
            Build.VERSION_CODES.JELLY_BEAN_MR2;

if (sEnforceThreadChecking) {
    throw new RuntimeException(throwable);
}

Le document Android dit, " Comme Android évolue à chaque nouvelle version, certains comportements et même certaines apparences peuvent changer. ." Nous avons donc examiné le changement de comportement et d'apparence, et la manière dont ce changement s'opère.

En résumé, la doc Android dit que " Cet attribut (targetSdkVersion) informe le système que vous avez effectué des tests par rapport à la version cible et que le système ne doit pas activer de comportements de compatibilité pour maintenir la compatibilité de votre application avec la version cible. ". Le cas de WebView le montre clairement. Jusqu'à la sortie de JELLY_BEAN_MR2, il était possible d'appeler la méthode publique de la classe WebView sur un thread non principal. Il est absurde que le cadre 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 est OK sur certaines versions du SDK cible. Nous obtenons des avantages tels que l'amélioration de l'apparence en définissant une targetSDKversion plus élevée, mais cela implique une responsabilité.

EDIT : avertissement. Le constructeur de DatePickerDialog qui définit différents thèmes en fonction de la version actuelle du SDK cible (que j'ai montré ci-dessus) a en fait été modifié en engagement ultérieur . 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 de targetSDKversion.

Answer 5

Pour ceux qui veulent un résumé,

android:minSdkVersion

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

alors que,

android:targetSdkVersion

est le niveau d'API jusqu'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 bahviors de compatibilité pour maintenir la compatibilité en avant parce que vous avez testé jusqu'à cette API. En outre, cela vous permet d'utiliser un peu de mais pas toutes les fonctionnalités de cette version cible.

Freebie -

android:maxSdkVersion

si la version de l'API de votre appareil est supérieure, l'application ne s'installera pas. C'est l'API maximale jusqu'à laquelle vous autorisez votre application à s'installer.

Par exemple, pour MinSDK -4, maxSDK - 8, targetSDK - 8 Mon application fonctionnera avec la version minimale 1.6 mais j'ai également utilisé des fonctionnalités qui ne sont prises en charge qu'en 2.2 et qui seront visibles si elle est installée sur un appareil 2.2. De plus, pour maxSDK - 8, cette application ne s'installera pas sur les téléphones utilisant API > 8.

Référence plus petite

Référence expliquée