Question Version Android Min SDK vs. Version SDK cible


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


420
2017-12-31 05:24


origine


Réponses:


android: minSdkVersion

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 d'API que l'application cible.

Avec cet ensemble d'attributs, l'application dit 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 plateforme de désactiver les paramètres de compatibilité qui ne sont pas requis pour la version cible (qui peut être activée pour assurer la compatibilité ascendante) 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: elle informe simplement la plateforme que vous avez testée par rapport à la version cible et la plateforme ne doit pas effectuer de travail supplémentaire pour assurer la compatibilité ascendante avec la version cible.

Pour plus d'informations, référez-vous à cette URL:

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


134
2017-12-31 05:46



Le commentaire posté par le PO sur la question (indiquant essentiellement que le targetSDK n'affecte pas la compilation d'une application) est entièrement faux! Désolé d'être franc.

En bref, voici le but de déclarer une cibleSDK différente de la minSDK: Cela signifie que vous utilisez des fonctionnalités d'un SDK de niveau supérieur à votre minimum, mais vous avez garantie de compatibilité ascendante. En d'autres termes, imaginez que vous souhaitiez utiliser une fonctionnalité qui n'a été introduite que récemment, 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 par un bouton ou à partir du menu. Dans ce cas, les gestes sont un «extra cool» mais ne sont pas nécessaires. Par conséquent, vous définissez la cible sdk à 7 ("Eclair" lorsque la bibliothèque GestureDetection a été introduite), et le minimumSDK au niveau 3 ("Cupcake") afin que même les personnes ayant des téléphones vraiment vieux 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 utiliser ceci si vous voulez 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 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 du Le blog du développeur Android sur la façon d'utiliser cette fonctionnalité, et en particulier, comment concevoir le code "vérifier la fonctionnalité existe avant de l'utiliser", 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.


856
2018-02-14 15:36



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 xx appliquera automatiquement le code de compatibilité pour prendre en charge toutes les fonctionnalités sur lesquelles vous pourriez compter et qui étaient disponibles avant ou au niveau de l'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 à ou avant au niveau xx, le code de compatibilité sera ne pas être 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 la fonctionnalité API, votre code doit utiliser des fonctionnalités différentes. sont disponible au niveau de l'API en cours d'exécution.

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 supérieurs à 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 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 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 portée 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();
    }
}

Tu pourrais aussi vouloir déclarer une version de targetSdkVersion plus élevée si vous avez testé à ce niveau supérieur et que tout a fonctionné, même si vous étiez ne pas en utilisant toutes les fonctionnalités d'un niveau d'API supérieur à votre minSdkVersion. Ce serait juste pour éviter la surcharge de l'accès 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 requise.

Un exemple de fonctionnalité d'interface utilisateur dépendant de la valeur cibleSdkVersion déclarée est le bouton de menu à trois points verticaux qui apparaît dans la barre d'état des applications ayant une valeur targetSdkVersion inférieure à 11, lorsque ces applications sont exécutées sous API 11 et versions ultérieures. Si votre application a une valeur targetSdkVersion inférieure ou égale à 10, il est supposé que l'interface de votre application dépend de l'existence d'un bouton de menu dédié. Ainsi, le bouton à trois points remplace les versions précédentes 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 supérieur pour lequel un bouton de menu dédié sur le périphérique n'est plus supposé. Cependant, si vous définissez la valeur targetSdkVersion de votre application sur 11 ou plus, il est supposé que vous avez profité des fonctionnalités introduites à ce niveau pour remplacer le bouton de menu dédié (par exemple, la barre des actions) ou que vous avez contourné 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 parvient pas à trouver un 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 invoqué, ce qui, à son tour, signifie 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 avoir au moins le même niveau 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 Google Play (et éventuellement dans d'autres boutiques d'applications). C'est une façon de dire 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 faire face à l'absence de ces fonctionnalités.

Un exemple d'utilisation de minSdkVersion pour garantir la présence d'une fonctionnalité ne pas API-related serait de définir minSdkVersion à 8 afin de s'assurer que votre application ne fonctionnera que sur une version JIT de l'interpréteur Dalvik (puisque JIT a été présenté à l'interpréteur Android au niveau de l'API 8). Étant donné que les performances d'un interpréteur JIT peuvent être cinq fois supérieures à celles d'un interpréteur, si votre application utilise beaucoup le processeur, vous pouvez avoir besoin du niveau d'API 8 ou supérieur pour garantir des performances adéquates.


95
2018-06-24 10:59



Un concept peut être mieux livré 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 je fais quelques expériences, même après avoir lu tous les documents dans 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.

UNE DatePickerDialog sera différent en fonction du niveau que vous avez mis dans le fichier targetSDKversion du fichier AndroidManifest.xml (<uses-sdk android:targetSdkVersion="INTEGER_VALUE"/>). Si vous définissez la valeur 10 ou inférieure, votre DatePickerDialog ressemblera à gauche. D'un autre côté, si vous définissez la valeur 11 ou plus, un DatePickerDialog sera correct, avec le même code.

DatePickerDialog look with targetSDKversion 10 or lower  DatePickerDialog look with targetSDKversion 11 or higher

Le code que j'ai utilisé pour créer cet exemple est super 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 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 currentSDKversion 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 le cadre Android.

Un autre exemple concerne WebView classe. Les méthodes publiques de la classe Webview doivent être appelées sur le thread principal, sinon le système d’exécution lance un RuntimeException, lorsque vous définissez targetSDKversion 18 ou supérieur. Ce comportement peut être clairement dé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 doc Android dit, "Comme Android évolue avec chaque nouvelle version, certains comportements et même apparences peuvent changer"Donc, nous avons regardé le comportement et l'apparence change, et comment ce changement est accompli.

En résumé, le doc Android dit "Cet attribut (targetSdkVersion) informe le système que vous avez testé sur la version cible et le système ne doit pas activer les comportements de compatibilité pour maintenir la compatibilité ascendante de votre application avec la version cible.Cela est très clair avec le cas de WebView: JELLY_BEAN_MR2 a été libéré pour appeler la méthode publique de la classe WebView sur un thread non-principal.Il est absurde que l'environnement Android lève une exception RuntimeException sur les périphériques JELLY_BEAN_MR2. Donc, ce que nous avons à faire est de vérifier si tout est OK sur certaines targetSDKversions.Nous obtenons des avantages comme l'amélioration de l'apparence avec la définition de targetSDKversion plus élevée, mais cela vient avec la responsabilité.

MODIFIER : avertissement. Le constructeur DatePickerDialog qui définit différents thèmes basés sur currentSDKversion (que j'ai montré ci-dessus) a été modifié plus tard commettre. 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.


49
2017-07-21 14:49



Pour ceux qui veulent un résumé,

android:minSdkVersion

est la version minimale jusqu'à ce que votre application prend en charge. Si votre appareil dispose d'une version inférieure d'Android, l'application ne sera pas installée.

tandis que,

android:targetSdkVersion

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

Votre application continuera à fonctionner sur les versions d'Android supérieures à celles indiquées targetSdkVersion mais le comportement de compatibilité android va démarrer.

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 sur un minimum de 1.6 mais j'ai aussi utilisé des fonctionnalités qui ne sont supportées que dans 2.2 et qui seront visibles si elles sont installées 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


21
2018-06-12 09:56



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 requiert le niveau d'API 11 (le min courant 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 cela 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 ça va courir!

EDIT: Cela entraînera une erreur d'exécution au niveau de l'API inférieur à 11. À 11 ou plus, il fonctionnera 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 compiler mais vous l'exécutez à vos risques et périls.


9
2017-10-12 11:31



android:minSdkVersion et android:targetSdkVersion les deux sont une valeur entière 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 d'API minimum requis 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 de 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. Ceci est toujours vrai que "l'installation de support d'application sur toute version supérieure de l'API, nous avons déclaré comme version TargetSdk". Pour rendre la cible de l'application limitée, nous devons déclarer maxSdkVersion dans notre fichier manifeste ...


1
2017-07-28 08:04



Si vous créez des applications exiger autorisations dangereuses et définissez targetSDK à 23 ou plus vous devez être prudent. Si vous ne vérifiez pas les autorisations à 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.


0
2017-10-10 17:36