Après avoir développé et testé son application, on l’exporte et on obtient un fichier APK (Android package file). On peut ensuite le distribuer, par exemple sur Google Play grâce à la console développeur.
Quand on importe un nouvel APK et qu’on veut le mettre en production, on peut voir la listes des appareils, compatibles et incompatibles. Malheureusement, il est pour le moment impossible de savoir directement pourquoi certains appareils sont incompatibles. Cela peut être dû à des permissions trop restrictives, mais il faut jouer à la devinette pour en être sûr. De plus, si l’on modifie l’Android Manifest, on ne peut pas savoir comment cela affecte la compatibilité des appareils tant que l’on n’a pas mis l’APK en production.
Il est possible d’exclure des appareils à la main (càd que l’application n’apparaîtra pas sur Google Play pour ces appareils) à cause de problèmes connus (par ex problème de lecteur, codec manquant, … ). Cette liste d’exclusion est facile à gérer et si le problème est résolu plus tard, on peut toujours les retirer de cette liste.
Une autre fonctionnalité pour la publication et le support du multi-APK. Cela permet d’uploader plusieurs APKs pour une seule application. Vous pouvez y avoir recours si vous voulez utiliser des fonctionnalités introduites par Honeycomb (par ex HTTP Live Streaming), mais que la base installée de Gingerbread est tellement imposante (plus d’un tiers des appareils en Juillet 2013) que vous êtes forcés d’avoir une version pour ces utilisateurs. On peut obtenir le nombre d’appareils (in)compatibles pour chaque version, mais aussi pour ce multi-APK. Un appareil recevra l’APK dont la version du code est la plus élevée et qu’il est capable d’exécuter.
Google a introduit de nouvelles possibilités de publication : les versions alpha / bêta et le déploiement progressif (staged rollouts). Pour faire simple, la première permet de sélectionner des testeurs et leur fournir une version alpha / bêta via Google Play, mais ils ne pourront pas laisser de commentaire public. Il faut donc mettre en place un moyen de faire des retours pour les testeurs. La seconde permet de déployer son application petit à petit. Tant que le déploiement progressif n’est pas fini, il est impossible de mettre à jour son application en production. Plus d’informations ici.
Il y a peu de problèmes majeurs avec Google Play, mais dans certaines configurations cela peut s’avérer assez handicapant. Par exemple :
Google fournit une bonne console développeur, du moins pour la publication. C’est un élément très important, puisqu’on peut itérer très rapidement en cycles courts sur Google Play, contrairement à l’App Store. Malgré tous les efforts mis en place pour réduire les effets indésirables de la fragmentation, il reste difficile de promettre qu’une application pourra être disponible et bien fonctionner sur tous les appareils. Parfois, une mise à jour peut casser une application (il suffit de se rendre dans les commentaires de certaines applications et de regarder les mauvaises notes). C’est souvent le cas pour des appareils listées comme “autres”
Heureusement, Google se dirige dans la bonne direction pour réduire les soucis de fragmentation pour les développeurs :