I. Introduction▲
Ce tutoriel a surtout pour objectif de vous permettre :
- de préparer votre livraison et d'organiser vos espaces de livraison ;
- de cibler les appareils sur lesquels votre application peut être installée.
Mais avant tout, effectuez deux actions nécessaires sur votre application.
Premièrement, rendez votre application non déboguable, en rajoutant la balise debuggable=« false », comme indiqué dans l'exemple suivant.
2.
3.
4.
5.
6.
<application
android:name= ".SmsListenerApplication"
android:icon= "@drawable/ic_launcher"
android:label= "@string/app_name"
android:theme= "@style/AppTheme"
android:debuggable= "false" >
Ensuite, modifiez vos degrés de log pour les passer en mode debug (Log.e, Log.w, Log.i deviennent Log.d) ou bien supprimez-les de votre code. Vous gagnerez en performance.
II. Prérequis▲
Vous avez déjà signé votre application avec votre clef de production. Si ce n'est pas le cas, ce tutoriel est pour vous : Déployer son application Android et obtenir sa clef MapView.
Ensuite vous avez créé un compte développeur sur GooglePlay en ayant fait bien attention de ne pas utiliser votre adresse mail personnelle ! Si ce n'est pas encore fait, c'est ici que ça se passe : https://play.google.com/apps/publish/Home .
Vous êtes donc maintenant à l'étape de la livraison de votre projet.
Attention à l'unicité des noms de vos packages roots. Toutes les applications doivent avoir un nom de package unique (et quand je dis toutes, c'est toutes celles qui existent dans le monde, pas que les vôtres).
III. Packager son application▲
Il est d'une importance primordiale de bien cibler les appareils qui pourront installer votre application. Pour cela il faut utiliser le fichier AndroidManifest.xml de votre application et ajouter les restrictions qui permettent de restreindre les appareils pouvant l'installer.
En effet, GooglePlay s'appuie sur votre fichier Manifest pour connaître les appareils éligibles à l'installation de votre application. C'est la notion de filtre. Quand un appareil se connecte sur GooglePlay, celui-ci est analysé par les serveurs Google et, en fonction de ses caractéristiques, GooglePlay filtrera les applications que l'appareil peut télécharger.
Typiquement, pour qu'une application ne soit jamais proposée aux appareils dont l'écran est de type XLarge, il suffit de rajouter les informations suivantes dans votre Manifest :
<supports-screens android:xlargeScreens"false"/>
De même, si vous voulez exclure les appareils ne possédant pas de flash, il vous suffit de rajouter le bloc suivant à votre manifest :
2.
3.
<uses-feature
android:name="android.hardware.camera.flash"
android:required="true" />
Enfin, si vous ne souhaitez pas voir votre application proposée au GoogleTv (car elle a toutes les chances d'être parfaitement horrible, vous ne l'avez pas désigné pour la GoogleTv), il suffit de rajouter la ligne :
2.
3.
<uses-feature
android:name="android.hardware.touchscreen"
android:required="true" />
Eh oui, il n'y a pas de TouchScreen sur les GoogleTv.
Toutefois, quand vous mettez en place ces filtres, soyez vigilant. Votre objectif est d'exclure les appareils sur lesquels vous êtes sûrs que votre application ne fonctionne pas ou n'est pas adaptée. Ce n'est certainement pas 90 % du parc qu'il faut exclure, soyez donc vigilant à ne mettre que le strict minimum.
Enfin, sachez que votre application est analysée par le store, elle est décompilée et le store détecte certaines lignes de code et en déduit certains filtres de manière automatique. Ainsi ajouter un listener de toucher d'écran (la méthode setOnTouchListener) dans votre code sera détecté et générera le filtre « nécessite que l'appareil soit équipé d'un TouchScreen ». Pour pallier ce genre de chose, vous pouvez expliquer dans votre Manifest que cette fonctionnalité n'est pas nécessaire au bon fonctionnement de votre application, en mettant :
2.
3.
4.
5.
6.
<uses-configuration
android:reqTouchScreen= "notouch"/>
ou
<uses-feature
android:name="android.hardware.touchscreen"
android:required="true" />
Tout un programme.
III-A. Spécification du fichier AndroidManifest.xml pour filtrer les appareils sur lesquels s'installer▲
III-A-1. Les écrans compatibles▲
Il y a deux balises permettant de spécifier les écrans supportés, la première est présentée dans ce paragraphe, la seconde le sera dans le paragraphe suivant. Ainsi la balise support-screen définit si votre application doit bénéficier du mode de compatibilité d'écran qui permet à Google de gérer l'affichage de votre application.
En effet, si votre application ne fonctionne pas quand elle est redimensionnée pour remplir différentes tailles d'écran, vous pouvez utiliser cette balise pour spécifier qu'elle doit être distribuée sur des « petits écrans » ou si votre GUI doit être zoomé pour remplir l'espace. Je vous suggère d'utiliser l'attribut compatible-screen décrit dans le paragraphe suivant pour filtrer les tailles d'écrans plutôt que cette balise-ci qui a plus pour vocation de mettre en place le mode compatibilité d'écran.
La balise support-screen :
2.
3.
4.
5.
6.
7.
8.
9.
<supports-screens android:resizeable =["true"| "false"]
android:smallScreens=["true" | "false"]
android:normalScreens=["true" | "false"]
android:largeScreens=["true" | "false"]
android:xlargeScreens=["true" | "false"]
android:anyDensity=["true" | "false"]
android:requiresSmallestWidthDp="integer"
android:compatibleWidth="integer"
android:largestWidth ="integer"/>
où les attributs sont :
- resizeable est Deprecated => il ne faut plus l'utiliser ;
- smallScreens, normalScreens, largeScreens et xLargeScreens permettent de définir si votre application est compatible avec ces tailles d'écrans. Si l'attribut est à false, l'application sera filtrée sur GooglePlay ;
- anyDensity => almost deprecated, il ne faut pas l'utiliser ;
- les attributs requiresSmallestWidthDp, compatibleWidthLimitDp et largestWidthLimitDp sont disponibles depuis la version 13.
Ces trois derniers attributs méritent une attention particulière.
Ainsi, requiresSmallestWidthDp permet de spécifier la plus petite taille de l'écran qui doit être disponible pour que votre application puisse s'afficher correctement (en dp). Cette taille est celle réellement disponible pour l'application, c'est-à-dire la taille réelle de l'écran moins l'ensemble des éléments qui pourraient prendre de l'espace (système.). Cette taille est indépendante de l'orientation, elle ne change pas quand l'orientation change, car elle est la plus petite taille (largeur / longueur) de l'écran de l'appareil. Cet attribut enclenche un filtrage sur GooglePlay.
Les deux autres attributs sont liés à l'enclenchement du mode de compatibilité d'écran.
La compatibleWidthLimitDp permet de spécifier la limite à partir de laquelle le mode de compatibilité d'écran (mise en place du zoom automatique de l'application) est proposé à l'utilisateur sans pour autant qu'il soit activé (une icône apparaît dans l'ActionBar, permettant d'activer ou de désactiver ce mode). Cette variable spécifie la plus grande petite taille d'écran compatible avec votre application, au-delà de cette taille, votre application proposera d'activer le mode de compatibilité (« les pixels prendront plus de place », la densité de l'écran sera logiciellement réduite de manière à ce que votre application remplisse l'écran). La valeur de cette variable doit être inférieure à 320 dp (density independant pixel) sinon rien ne se passe.
La largestWidthLimitDp permet de forcer l'enclenchement du mode de compatibilité au-delà de la valeur spécifiée. L'utilisateur n'a pas le choix, il ne pourra le désactiver. Doit être inférieur à 320 dp sinon rien ne se passe.
III-A-2. Les tailles et densités d'écrans compatibles▲
Cette balise permet de spécifier les tailles d'écrans et les densités d'écrans compatibles avec votre application. Vous pouvez ainsi spécifier pour chacune des 16 configurations possibles, celles qui sont supportées par votre application. En fait, dès qu'un couple est compatible avec votre application, il faut qu'il soit déclaré.
2.
3.
4.
5.
<compatible-screens>
<screen android:screenSize=["small" | "normal" | "large" | "xlarge"]
android:screenDensity=["ldpi" | "mdpi" | "hdpi" | "xhdpi"] />
...
</compatible-screens>
Les attributs de cette balise étant pour une fois limpides, nous ne nous éterniserons pas dessus, mais donnons un exemple exhaustif qui nous permettra par simple copier-coller de définir l'ensemble des écrans compatibles avec votre application :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
<compatible-screens>
<!-- all small size screens -->
<screen android:screenSize="small" android:screenDensity="ldpi" />
<screen android:screenSize="small" android:screenDensity="mdpi" />
<screen android:screenSize="small" android:screenDensity="hdpi" />
<screen android:screenSize="small" android:screenDensity="xhdpi" />
<!-- all normal size screens -->
<screen android:screenSize="normal" android:screenDensity="ldpi" />
<screen android:screenSize="normal" android:screenDensity="mdpi" />
<screen android:screenSize="normal" android:screenDensity="hdpi" />
<screen android:screenSize="normal" android:screenDensity="xhdpi" />
<!-- all large size screens -->
<screen android:screenSize="large" android:screenDensity="ldpi" />
<screen android:screenSize="large" android:screenDensity="mdpi" />
<screen android:screenSize="large" android:screenDensity="hdpi" />
<screen android:screenSize="large" android:screenDensity="xhdpi" />
<!-- all extra-large size screens -->
<screen android:screenSize="xlarge" android:screenDensity="ldpi" />
<screen android:screenSize="xlarge" android:screenDensity="mdpi" />
<screen android:screenSize="xlarge" android:screenDensity="hdpi" />
<screen android:screenSize="xlarge" android:screenDensity="xhdpi" />
</compatible-screens>
Ainsi, il vous suffit de copier-coller ce bloc dans votre Manifest et dès que l'une de ces configurations n'est pas compatible avec votre application, supprimez-la.
III-A-3. Texture OpenGL▲
Vous pouvez avoir besoin de définir le mode de compression de vos textures OpenGL.
C'est ici : <supports-gl-texture>
III-A-4. Configurations d'interaction avec l'appareil compatible▲
Cette balise indique quelles sont les caractéristiques matérielles ou logicielles nécessaires au bon fonctionnement de votre application. Ces caractéristiques sont les suivantes :
2.
3.
4.
5.
<uses-configuration android:reqFiveWayNav=["true" | "false"]
android:reqHardKeyboard=["true" | "false"]
android:reqKeyboardType=["undefined" | "nokeys" | "qwerty" | "twelvekey"]
android:reqNavigation=["undefined" | "nonav" | "dpad" | "trackball" | "wheel"]
android:reqTouchScreen=["undefined" | "notouch" | "stylus" | "finger"] />
Comme pour les balises des écrans compatibles (compatilble-screen), vous devez déclarer chacune des configurations qui sont compatibles avec votre application.
L'exemple suivant explique ce concept :
2.
3.
4.
5.
6.
7.
8.
<uses-configuration
android:reqFiveWayNav="true"
android:reqKeyboardType="qwerty"
android:reqTouchScreen="finger" />
<uses-configuration
android:reqFiveWayNav="true"
android:reqKeyboardType="twelvekey"
android:reqTouchScreen="finger" />
Les attributs commencent tous par « req » pour required.
L'attribut reqFiveWayNave spécifie que votre application a besoin du mode de navigation « five ways », qui n'est autre que la capacité à aller à droite, à gauche, en haut, en bas et à lancer une action sur l'élément courant (celui qui est sélectionné).
L'attribut reqHardKeyboard spécifie que votre application a besoin d'un clavier physique.
L'attribut reqKeyboardType spécifie le type de clavier requis par votre application. La valeur undefined permet de spécifier que l'application ne se soucie pas de la présence d'un clavier. La valeur noKeys spécifie qu'un clavier n'est pas nécessaire à votre application. La valeur qwerty implique que l'application a besoin d'un clavier standard (avec toutes les touches d'un clavier QWERTY ou AZERTY, c'est pareil). La valeur twelvekey, elle, spécifie que votre application a besoin d'un clavier de type téléphone (les anciens, ceux avec les touches 0 à 9,* et #).
L'attribut reqNavigation permet de spécifier le type de navigation requis par votre application. La valeur undefined permet de spécifier que votre application ne se soucie pas du type de navigation, la valeur nonav qu'elle n'en a pas besoin. La valeur dpad spécifie le besoin d'un dpad (le directional pad est utilisé par les GoogleTv, par exemple). La valeur trackball spécifie le besoin d'un trackball et wheel spécifie le besoin de la molette de la souris (sur une tablette ou un téléphone ?o?, ils sont fous chez Google).
Enfin le dernier attribut permet de spécifier le type de « touchscreen » requit par votre application, en d'autres termes la façon dont l'écran doit interagir avec l'utilisateur. Elle peut s'en fiche (undefined), ne pas en avoir besoin (notouch), être compatible avec le stylet (stylus) ou avec les doigts (finger).
On aura ainsi souvent tendance à soit ne pas mettre ce type de balise soit à cibler les téléphones et les tablettes.
Ainsi, si vous souhaitez spécifier que vous êtes compatibles uniquement avec les téléphones ou les tablettes, vous aurez tendance à mettre :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<uses-configuration
android:reqFiveWayNav="false"
android:reqHardKeyboard="false"
android:reqKeyboardType="qwerty"
android:reqNavigation="undefined"
android:reqTouchScreen= "stylus"/>
<uses-configuration
android:reqFiveWayNav="false"
android:reqHardKeyboard="false"
android:reqKeyboardType="qwerty"
android:reqNavigation="undefined"
android:reqTouchScreen= "finger"/>
III-A-5. Les pièces matérielles (UseFeature) compatibles ou nécessaires▲
Cette balise est extrêmement utile pour spécifier les caractéristiques matérielles/logicielles nécessaires au bon fonctionnement de votre application. Vous avez besoin du flash, du GPS, du Wi-Fi ou du Bluetooth, vous devez le déclarer avec cette balise. Cette balise possède en outre le bon goût de permettre de déclarer l'utilisation d'une pièce matérielle tout en spécifiant que si cet élément ne se trouve pas sur l'appareil, l'application fonctionnera quand même (vous avez mis en place un workaround pour résoudre l'absence dudit matériel).
2.
3.
<uses-feature android:name="string"
android:required=["true" | "false"]
android:glEsVersion="integer" />
Chaque caractéristique se déclare indépendamment :
2.
<uses-feature android:name="android.hardware.bluetooth" />
<uses-feature android:name="android.hardware.camera" />
Normalement pour chaque « feature » déclarée, vous avez fait une demande de permission pour son utilisation :
2.
3.
4.
<uses-permission android:name="android.permission.CAMERA" >
</uses-permission>
<uses-permission android:name="android.permission.BLUETOOTH" >
</uses-permission>
Enfin, pour chaque permission demandée pour l'utilisation d'une caractéristique qui n'est pas déclarée dans le bloc uses-features, GooglePlay supposera que cette caractéristique est nécessaire.
L'attribut name permet de déclarer le nom de la caractéristique et l'attribut required permet de spécifier si elle est nécessaire. En d'autres termes si votre application fonctionne (ou pas) lorsque l'appareil ne possède pas cette caractéristique. Par défaut required égale true. L'attribut glEsVersion s'utilise quand vous déclarez la caractéristique OpenGL ES et vous permet de spécifier la version de ce dernier.
Vous trouverez la liste des caractéristiques matérielles ici :
et celles des caractéristiques logicielles ici :
III-A-6. Versions du système compatibles et cibles▲
Enfin la dernière balise, de loin la plus importante de manière générale, est celle qui spécifie la version minimale, maximale et cible du système de l'appareil. En ces temps de fragmentation, cette balise peut vous permettre d'assurer le bon déploiement de votre application sur les versions de systèmes compatibles.
<uses-sdk android:minSdkVersion="integer"
android:targetSdkVersion="integer"
android:maxSdkVersion="integer" />L'attribut minSdkVersion (respectivement maxSdkVersion) vous permet de spécifier quelle est la version du système minimale (respectivement maximale) pour le bon fonctionnement de votre application.
Il y a une rumeur sur l'attribut maxSdkVersion : en effet, lors des updates du système (l'appareil se fait upgrader sa version), toutes les applications sont revalidées. Si la nouvelle version du système dépasse votre maxSdkVersion, votre application sera purement et simplement désinstallée de l'appareil. Cette rumeur est vraie pour les versions antérieures à Donut (1.6). (moins de 0.3 % des appareils).
L'attribut targetSdk permet de spécifier pour quelle version du système votre application fonctionne sans avoir besoin de mode de compatibilité. Par exemple, votre minSdk est Froyo (8), mais vous avez désigné votre application et l'avez testée pour ICS (14) et elle fonctionne nickel. Dans ce cas votre targetSdk est 14.
A contrario, si vous avez déclaré votre targetSdk pour GingerBread (10) quand elle tournera sur un ICS (14 ou 15), le mode de rétrocompatibilité sera enclenché et votre application tournera dans cet environnement. Cela lui interdira l'ensemble des nouveautés de cette version (thème, mode de compatibilité d'écrans).
Enfin, si cet attribut n'est pas spécifié, il est considéré comme égal à votre minSdkVersion.
III-B. Livrer plusieurs apk pour une même application.▲
Il faut savoir que vous pouvez livrer plusieurs apk pour une même application, chacune ayant des cibles (des restrictions définies dans son Manifest) différentes. Cela est permis pour les balises suivantes :
-
format de compression de vos textures OpenGL
- en utilisant l'élément <supports-gl-texture> ;
-
taille de l'écran (et, optionnellement densité de l'écran)
- en utilisant l'élément <supports-screens> ou <compatible-screens> ;
-
version du SDK
- en utilisant l'élément <uses-sdk> .
Et de mon point de vue, cela peut être la meilleure stratégie pour atteindre la satisfaction cliente tout en conservant un code propre avec plusieurs projets. Mais ce sera dans un autre tutoriel sur « Comment combattre la fragmentation ».
IV. Soigner sa livraison▲
IV-A. Configuration de votre espace de livraison▲
Pour cela je préconise dans votre projet Eclipse de faire un dossier delivery et dans ce dossier faire un sous-dossier par version livrée sur GooglePlay.
Pour chaque dossier de version (par exemple delivery\v1.0), il faut mettre :
- les captures d'écran ;
- l'icône en haute résolution ;
- les éléments graphiques : image promotionnelle, « featured » image et la vidéo ;
- le fichier texte décrivant votre application dans les différentes langues information-en, information-fr ;
- le fichier apk correspondant à votre livraison ;
- le fichier d'extension principal et le fichier d'extension correctif (si vous en avez).
Nous revenons sur ces différents éléments dans les paragraphes qui suivent.
IV-B. Préparation des éléments graphiques à fournir▲
Tout d'abord il vous faut votre application .apk. Attention le logo de votre application doit être en Png .
Les ressources graphiques suivantes sont nécessaires :
- deux copies d'écrans minimum et huit maximum, au format PNG ou JPEG, sans canal alpha, 24 bits, pas de bordure. Utilisez la vue DDMS et sa capture d'écran pour cela.
- une icône haute résolution de votre application : 512*512 en 32 bits PNG (avec alpha) d'une taille maximum de 1024 kB
Les ressources suivantes ne sont pas nécessaires, mais fortement préconisées en termes de marketing (bref c'est quasiment obligatoire) :
- une image promotionnelle de 180*120, 24 bits PNG ou JPEG sans alpha, pas de bordure.
- une « featured » image: 1024*500, 24 bits PNG ou JPEG avec une image utile de 924*400 le reste de l'image risquant d'être rogné.
- un lien vidéo YouTube vers une vidéo durant entre 30 s et 2 mn
À part la vidéo, considérez que vous devez livrer votre image promotionnelle et votre « featured » image.
IV-C. Préparation des éléments textuels à fournir▲
Le plus simple est encore de créer un fichier texte par langue (Word, OpenOffice ou texte cela n'a pas d'importance) que vous nommerez information-en.txt (ou doc) et information-fr.txt au minimum pour nous autres développeurs français.
Ce fichier doit contenir les paragraphes suivants :
- titre (30 caractères max) ;
- description (4000 caractères max) ;
- modifications récentes (500 caractères max) ;
- texte promotionnel (80 caractères max) ;
- type d'application (Application ou Jeu) et catégorie (vous pouvez trouver la liste des catégories ici : Category type ).
V. Livrer votre application▲
Si vous avez tout préparé, la livraison sera rapide, si vous n'avez pas encore tout préparé, he bien finissez de préparer les fichiers à remplir.
Allez à l'adresse suivante : https://play.google.com/apps/publish/Home. Et suivez le processus, vous avez déjà tous les éléments pour livrer votre application.
VI. Conclusion▲
J'espère que ce tutoriel vous a plu, vous êtes maintenant capable de livrer vos applications sur GooglePlay en ayant conscience des enjeux et des contraintes associés, félicitations.
À bientôt pour d'autres tutoriels sur le développement Android.
VII. Remerciements▲
Ce tutoriel a été publié avec l'aimable autorisation de Android2EE. Plus de détails sur Android2EE peuvent être trouvés sur sa page d'accueil de Developpez.com
J'adresse ici tous mes remerciements à Feanorin pour son implication, son aide et sa sympathie et à jacques_jean pour l'excellence de ses corrections orthographiques.
Je remercie le correcteur technique Feanorin pour la pertinence de ses remarques.
VIII. Référence▲
Les références générales à GooglePlay:
Android Market Featured-Image Guidelines
Les références permettant une excellente compréhension du fichier Manifest :