Version du SDK Android Min vs.Version SDK cible


442

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!


1
D'après ce que je lis, il semble que la version du SDK cible n'ait aucun impact sur la façon dont votre application est compilée. Il est juste là pour indiquer à l'appareil sur lequel l'application s'exécute qu'il n'a pas besoin d'activer de fonctionnalités de compatibilité spéciales pour que votre application fonctionne correctement. Est-ce correct? Il me semble que vous ne saurez pas quelle est votre version cible du SDK avant d'avoir compilé et fait beaucoup de tests. Pourquoi le compilateur ne peut-il pas simplement regarder votre code et déterminer avec quelles plates-formes votre application est compatible seule?
Michael Novello

5
Le commentateur ci-dessus a mal compris pourquoi on utilise la fonctionnalité targetSDK. Voir ma réponse ci-dessous pour plus de détails.
Steve Haley

157
La réponse acceptée n'est pas correcte. Veuillez lire la réponse de Steve H.
tylerl

3
@tylerl Mais ce n'est pas une erreur, mais plutôt une référence aux documentations Google Android. Je n'ai rien ajouté.
Vikas Patidar

3
La réponse de Carl est la plus détaillée et la plus précise à mon avis.
Ilya Kogan

Réponses:


136

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


Dans l'ensemble, vous allez définir les deux sur la même chose. Ce serait probablement une situation inhabituelle de les régler sur des valeurs différentes.
jjb

66
Concernant le commentaire de jjb: je ne suis pas d'accord. Il existe de nombreuses bonnes raisons pour lesquelles vous pouvez avoir un minSDK et un targetSDK différents. Voir ma réponse pour plus de détails.
Steve Haley

871

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.


2
Pourriez-vous s'il vous plaît fournir une explication précise de la façon dont la version targetSDK affecte la compilation de l'application? Parce que la version de compilation est à nouveau une autre configuration que vous devez configurer. Merci d'avance
hnviet

9
Je pense que Steve a confondu l'attribut xml manifeste android: targetSdkVersion (qui n'a pas vraiment son mot à dire) et entre la propriété cible qui réside dans le fichier project.properties qui représente contre quoi le code doit être compilé. Je le redis, le XML cible attrSdkVersion n'a pas vraiment de sens !!!
AlikElzin-kilaka

3
@kilaka La moitié de votre commentaire est valide, mais l'autre moitié est tout simplement fausse. Je supposais que quelqu'un utilise la même valeur dans le XML et le project.properties (également accessible via un clic droit-> propriétés dans Eclipse), vous avez donc raison de souligner qu'ils sont stockés dans des endroits différents. Cependant, l'Android Market se soucie très certainement de la valeur que vous attribuez à l'attribut xml targetSdkVersion. Par exemple, il l'utilise pour déterminer si vous devez avoir un ActionBar ou un menu de compatibilité pour Honeycomb et les applications ci-dessus.
Steve Haley

2
@Nate, je ne pourrais pas dire à quel point ce «code alambiqué» ralentit l'exécution, mais je pense que le fractionnement et l'utilisation de plusieurs fichiers APK sont pires en termes de complexité du code. Maintenant, vous devez vous rappeler de commenter les entrées / sorties ou de fusionner à travers plus de branches dans votre contrôle de source avant de pouvoir effectuer chaque exportation. Lors d'une conférence Android en octobre dernier, ils ont déclaré avoir présenté le système APK multiple comme une concession, mais étaient heureux que très peu de gens l'utilisent.
Steve Haley

2
Mais la gestion de plusieurs versions est la raison d'être des systèmes de contrôle de version. C'est ce que les développeurs connaissent (la plupart des logiciels, mobiles ou non, publient des versions légèrement différentes pour différentes plates-formes). Cette "fonctionnalité" Android ne réduit pas la complexité. C'est simplement le pousser dans l'application en cours d'exécution, et comme en témoigne ce fil, créant de la confusion. Bien sûr, Google va être heureux que peu de gens l'utilisent ... ce qui les aide à dire "voyez, nous avions raison de faire cette omission en premier lieu". De plus, certains ne l'utilisent pas car ils ne savent pas encore qu'il existe.
Nate

97

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.


Merci pour les instructions d'utilisation de la directive TargetApi.
samir105

@Carl Cela signifie-t-il que je peux toujours définir targetSdkVersion sur n'importe quelle version supérieure à ma minSdkVersion (en particulier pour obtenir ces améliorations de l'interface utilisateur) sans avoir besoin de tests (en soi ) tant que je restreins ma base de code pour utiliser uniquement les API disponibles dans ma minSdkVersion ?
Damilola Olowookere

Olowookere Emmanuel: Si je vous comprends bien, alors non, ça ne veut pas dire ça. Comme l'indique ma réponse, "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 supérieurs". Donc, si votre code utilise une fonctionnalité qui est devenue disponible au niveau de l'API, par exemple, 8 et que cette fonctionnalité est devenue obsolète au niveau 10, alors si vous augmentez votre targetSdkVersion à un niveau supérieur à 10, aucun code de compatibilité ne sera disponible pour ajuster vos utilisations de cette fonctionnalité au nouveau niveau de système d'exploitation.
Carl

(Continuant): Alors que si vous laissez votre targetSdkVersion au niveau 8, alors, si vous ne pourrez pas utiliser les fonctionnalités introduites à des niveaux supérieurs, un code de compatibilité sera appliqué pour permettre à vos utilisations des fonctionnalités de niveau 8 de fonctionner lorsqu'elles sont exécutées sur niveaux d'OS plus élevés.
Carl

(Continuant): Pensez-y de cette façon: supposons que vous ayez écrit du code lorsque le niveau Android le plus élevé disponible était 8, et que vous avez défini votre targetSdkVersion sur 8 (car c'était le niveau le plus élevé à l'époque). Maintenant, certaines nouvelles versions d'Android sortent et certaines des fonctionnalités de niveau 8 que vous avez utilisées deviennent indisponibles. Les utilisateurs qui ont toujours votre ancien APK ne devraient pas rencontrer d'erreurs, n'est-ce pas? Ainsi, pour garantir qu'ils ne le sont pas, un code de compatibilité est automatiquement appliqué pour ajuster vos anciens appels d'API afin de faire quelque chose de raisonnable lorsqu'ils sont invoqués pendant qu'un utilisateur exécute une version plus récente du système d'exploitation.
Carl

50

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 .

Look DatePickerDialog avec targetSDKversion 10 ou inférieure Look DatePickerDialog avec targetSDKversion 11 ou supérieur

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.


2
"Nous obtenons des avantages tels que l'amélioration de l'apparence en définissant une version de targetSDK plus élevée, mais cela implique des responsabilités." S'ils avaient mentionné cette ligne dans les documents, je ne la chercherais pas.
pulp_fiction

@ 김준호 J'ai deux questions: 1.) Dans l'exemple de datepicker ci-dessus, si vous avez défini targetSdkVersion à 10 ou moins et exécutez l'application sur un appareil exécutant la dernière version d'Android (par exemple API 22), le datepicker s'affichera toujours comme l'ancien. sur la photo de gauche? 2.) Est-ce que cela signifie que je peux toujours définir targetSdkVersion sur n'importe quelle version supérieure à ma minSdkVersion (par exemple pour obtenir ces améliorations d'interface utilisateur comme ce sélecteur de date croustillant à partir d'API supérieures) sans avoir besoin de tests (en soi) ) tant que je restreins ma base de code utiliser uniquement les API disponibles dans ma version minSdk?
Damilola Olowookere

@Olowookere 1) Oui. Courez juste pour ça. 2) Vous pouvez définir targetSDKVersion n'importe quelle version que vous aimez si elle est supérieure à minSDKVersion. Mais vous devez toujours tester si cela fonctionne bien sur la version ciblée. Peu importe que vous vous en teniez à l'api minSDKVersion ou non. Pensez à l'exemple de DatePicker.
김준호

Pensez à un cas où vous définissez la version min 14 et la version sdk cible à 16, et vous n'avez utilisé des API que pour 14 ou moins. Supposons que vous ayez utilisé TextView qui est introduit au niveau 1 de l'API. Que se passerait-il?
김준호

@ 김준호 Merci. Mais pour votre deuxième réponse, je suis confus. Si mon code utilise uniquement l'API dans minSdkVersion et que je cible un SDK supérieur, pourquoi dois-je tester? En pensant à l'exemple de DatePicker, la valeur targetSdkVersion élevée n'a amélioré que l'apparence du widget DatePicker et rien ne se brise car je n'ai pas utilisé de code dans l'API supérieur à minSdkVersion. Je veux seulement targetSdkVersion plus élevé parce que je veux le nouveau look et la sensation des widgets, pas que je veux utiliser de nouvelles fonctionnalités introduites à une API plus élevée
Damilola Olowookere

21

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


"est la version maximale d'où votre application a hérité des fonctionnalités." : c'est faux. Il s'agit de la version minimale à partir de laquelle votre application a hérité des fonctionnalités, c'est-à-dire la première version qui inclut les fonctionnalités requises utilisées par votre application.
RichieHH

L'anglais est une langue délicate. Lisez mon exemple donné dans la réponse. Je suppose que j'ai du sens là-bas. :)
Darpan

Je ne suis pas pédant et l'anglais est la langue de support dans ce groupe. Tricky ou ne pas dire que c'est la "version maximale où l'application a pris en charge les fonctionnalités" n'est pas seulement faux: c'est totalement faux à 180 degrés. Il s'agit de la version PREMIÈRE ou minimale qui prend en charge toutes les fonctionnalités prévues de votre application sans utiliser les modes / bibliothèques de compatibilité de secours.
RichieHH

9

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.


1
Je suis confus à ce sujet. Que se passe-t-il si vous exécutez votre application plus tard dans un système avec sdk 10?
Fran Marzoa

Il exécutera l'instruction options.inBitmap et l'application devrait fonctionner correctement.
NinjaCoder

1

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


0

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.


0

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.