MinSdk et TargetSdk, à qui incombe la vérification de la compatibilité?

Bonjour tous le monde,
Petite question qui me taraude depuis quelques temps.
Donc, on sait tous que dans le manifest on définit deux balises (trois ok) le minSDK et le targetSDK.
Ok, je mets minSDK="8" et targetSDK="11" donc je compile mon code avec Android3.
La question est du coup: comment je m'assure que je suis bien compatible avec le SDK niveau 8 ?o?
Y'a deux cas, soit la compilation est magique et assure la compatibilité, soit c'est au développeur qu'incombe la vérification (en d'autres termes on tombe le target à 8 et on regarde ce que donne le compilation, au minimum, ensuite on teste sur un émulateur).
A mon avis, c'est à nous qu'incombe la vérification, mais j'en suis pas sûr.
Et vous, votre avis, c'est quoi ?

Je crois que c'est le target mais je ne suis pas sur (à verifier)

:calim2: relis la question :lol:
Là j'ai pas bien compris ta réponse :calim2:

Ah oui, je m'etais presque arrêté au titre x)
Sinon, c'est à toi de vérifier que tout marche correctement :P

Hello,

Hum, en fait la réponse ce sont les deux mon capitaine !

Ex :
Tu crées un menu (dans les ressources) avec les attributs pour tirer profit de l'action bar
et bien en fonction de la cible sur laquelle ça s’exécute ça sera pas la même chose.

Donc déjà y'a une adaptation du code généré par le compilateur qui s'adaptera au runtime.

Par contre si dans le code tu veux à ton tour adapter ton menu (crée précédemment), ben là
va bien falloir le prendre en charge (genre le getActionBar marchera pas sur les pateformes <
Honeycomb).

C'est là où c'est lourd pour gérer plusieurs cibles à la fois car si tu utilise différentes évolutions
du SDK ça fait beaucoup de hook dans le code.

En définissant le SDK minimum et target, de toute façon l'IDE empêche d'utiliser les fonctionnalités qui ne seraient pas compatible ? Je me trompe ?

Donc au pire, ce qu'on risque c'est de ne pas avoir le même résultat visuel, mais en aucun cas un plantage ? Si ?

Sinon alors on a tout intérêt à tout développer avec le SDK minimum et simplement "à la fin" on change le target pour autoriser plus de devices à installer l'application.

Citation:

---

Donc déjà y'a une adaptation du code généré par le compilateur qui s'adaptera au runtime.

---

Euh non, tu passes dans des branches spécifiques de ton appli, pas de magie compilateur, pas d'adaptation.
Mais c'est pas ma question :calim2:, je ne demande pas comment s'adapter à la fragmentation.
Largo13 a compris la question :ccool:, mais ça nous avance pas... car c'est justement la question. Au moins il l'a bien reformulé.

NotaBene: le SDK android pour compiler ne se définit pas dans le manifest mais dans le fichier project.properties (comme ça au cas où il y est des doutes).

Pour ma part, j'ai 2 "expérience" à partager :

1) Au tout début quand j'ai expérimenté Android, je déployais mes bouts de codes sur mon HTC Desire (2.2). Mon application de test était déclarée pour Min SDK 2.2 et MAX 4.1. Tout (enfin le peu de code) fonctionnait bien.

Ensuite j'ai reçu un tablette Asus sous ICS (4.0), première fois que je déploie mon code dessus : plantage intégral.

En fait l'astuce était que dans mon code (tout pourri) de test, je faisais une requête I/O dans le thread principal. Ce qui n'est plus autorisé depuis Honeycomb (3.x).

Conclusion : Mon compilateur ne me dit rien , me laisse compiler un code qui plante sous ICS ...


2) En parcourant les "Sample Project" fournis avec le SDK, j'ai vu pas mal de morceaux de code où on testait précisément la version de l'OS pour adapter le code.

Conclusion : J'ai bien peur que la réalité soit bien plus complexe que ce qu'on voudrait qu'elle soit :-(

Je pourrais également rajouté que maintenant Lint fait des vérification sur les API disponibles sur les cibles SDK demandées.
Si je reprend ton exemple initiale, il peut notamment te prévenir qu'utiliser le composant "Switch" n'est pas présent dans ta cible minimum (malgrès qu'elle le soit dans la cible idéale).

:ccool:
Ben, c'est cool, merci MrDuChnok et Largo13, je crois que vous m'avez donné les réponses :o)
C'était aussi mon sentiment, je savais pas que Lint nous faisait un topo, en même temps j'aurais du m'en douter.
Merci les gars, à bientôt.

Citation:

---

Envoyé par Largo13

En fait l'astuce était que dans mon code (tout pourri) de test, je faisais une requête I/O dans le thread principal. Ce qui n'est plus autorisé depuis Honeycomb (3.x).

Conclusion : Mon compilateur ne me dit rien , me laisse compiler un code qui plante sous ICS ...

---

Juste un rectificatif.... ce n'a jamais été autorisé même dans la version 1.x d'Android. Le chapitre sur le main thread qui ne doit pas faire de traitement long existait déjà...
Comme certains ne s'empêchaient pas de le faire quand même, la 2.x a introduit les ANR rapides (Application Not Responding) sur les devices de test...
Et comme certains n'avaient toujours pas compris (parce que quand tout va bien en local, une requête http prend 0.1s), tout accès au réseau est devenu protégé par les NOMTE...
Bref, un peu comme sur windows, ou l'accès à program files s'est vu restreindre aux admin parce que les gens continuaient d'y coller les fichier dynamiques.... (ou qu'un Admin n'est plus vraiment admin parceque tout le monde jouait avec un compte admin).


Bien sur, il est possible de passer outre ces trucs là à coup de StrictMode... mais bon... ^^

Et oui Lint est parfait pour dire ce qui ne colle pas avec le minSDK (même si le targetSDK est >)
Et on peut lui dire "ok, je gère le cas à la main" avec @TargetApi