Android, Livrer son projet sur GooglePlay
Cet article est rédigé par Android2EE, Consulting, Expertise et Formation Android.
Pour plus d’information (tutoriels, ebooks, formations, architecture, consulting Android), une seule adresse :
Android2EE : http://www.android2ee.com.
L’objectif de cet article est de vous aider à préparer la livraison de vos projets Android sur GooglePlay. Je pars du principe que vous savez déjà signer et générer l’apk de votre application et que vous êtes inscrits sur GooglePlay.
Cet article 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.
Vous avez déjà signé votre application avec votre clef de production. Si ce n’est pas le cas, cet article 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).
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 :
<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 toute les chances d’être parfaitement horrible, vous ne l’avez pas désigné pour la GoogleTv), il suffit de rajouter la ligne :
<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 :
<uses-configuration
android:reqTouchScreen= "notouch"/>
ou
<uses-feature
android:name="android.hardware.touchscreen"
android:required="true"
/>
Tout un programme.
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 :
<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 (sytè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é (un 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.
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é.
<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 :
<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.
Vous pouvez avoir besoin de définir le mode de compression de vos textures OpenGL.
C’est ici : <supports-gl-texture>
Cette balise indique quels sont les caractéristiques matérielles ou logicielles nécessaires au bon fonctionnement de votre application. Ces caractéristiques sont les suivantes :
<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 :
<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 requit 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 requit 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 a 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 :
<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"/>
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 Wifi 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 du dit matériel).
<uses-feature android:name="string"
android:required=["true" | "false"]
android:glEsVersion="integer" />
Chaque caractéristique se déclare indépendamment :
<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 :
<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 :
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 designé 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 retrocompatibilité 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.
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 :
Ø en utilisant l’élément <supports-gl-texture> ;
Ø en utilisant l’élément <supports-screens> ou <compatible-screens> ;
Ø 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 article sur « Comment combattre la fragmentation ».
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.
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.
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 le liste des catégories ici : Category type).
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.
J’espère que cet article 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 articles sur le développement Android.
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 :