Dans ce billet nous détaillerons les façons de s’assurer que son application est disponible pour autant de gens que possible ou au moins de savoir qui n’y aura pas accès. En effet, la fragmentation est si forte dans l’écosystème Android, que l’on peut rapidement mettre de côté un nombre non négligeable d’utilisateurs potentiels. Google fournit des paramètres et des outils pour aider à prévenir les problèmes liés à la fragmentation logicielle et matérielle, dont une partie via l’Android Manifest que nous analyserons ici.

L’Android Manifest est un fichier de description contenant des informations nécessaires pour le système. Il comporte également des paramètres impactant la distribution de l’application. Voici par exemple le manifest de la démonstration d’un de nos projets Open Source, Shutterbug.

Avant de lire la suite, il faut garder en tête que le niveau d’API est un nombre identifiant la révision du framework d’API. En général, chaque nouvelle révision ajoute des fonctionnalités. Voici un tableau de correspondance entre la version de l’OS et le niveau d’API.

Niveau d’API minimum

<uses-sdk android:minSdkVersion="7" android:targetSdkVersion="15" />

Le paramètre minSdkVersion spécifie, malgré son nom, le niveau d’API minimum sur lequel l’application peut tourner (1 par défaut). Un niveau d’API spécifique peut être requis pour utiliser des fonctionnalités introduites dans des versions récentes d’Android.
Ainsi, en choisissant des fonctionnalités on choisit une version minimum d’Android. Inversement, s’il faut que l’application soit disponible sur un certain pourcentage d’appareils, cela limite le nombre de fonctionnalités.
Si la version minimum du SDK n’est pas spécifiée, l’application peut être disponible sur des appareils dont le niveau d’API est trop bas, ce qui créerait des crashes.

Lien entre niveau d’API et fonctionnalités

Résumé des fonctionnalités majeures, par niveau d’API

Chaque niveau d’API apporte son lot de nouvelles APIs. Voici un résumé des ajouts dans les plus importants niveaux d’API :

Niveau d’API	Version d’Android	Fonctionnalités
8	2.2 Froyo	Applications sur la mémoire externe, Notifications push
9	2.3 Gingerbread	Support de la lecture NFC
11	3.0 Honeycomb	Fragments, Barre d’action, HTTP Live Streaming version 2
12	3.1 Honeycomb	Widgets de l’écran d’accueil redimensionnables
16	4.1 Jelly Bean	Notifications extensibles
17	4.2 Jelly Bean	Widgets pour l’écran de verrouillage, Support de Miracast (affichage sans-fil)

Exemples

Pour une application capable de recevoir des notifications push, le niveau d’API 8 est requis. Seuls 1,5% des appareils ne verront pas votre application sur Google Play, ce qui est plutôt raisonnable.

Si vous souhaitez créer une application capable de lire des flux HLS, il faudra probablement utiliser des fonctionnalités du niveau d’API 13. De ce fait, environ 40% des appareils ne verront pas votre application sur Google Play.

Cela peut sembler être élevé, mais :

• Toutes les connexion à Google Play sont comptabilisées dans ce chiffre.
• Si les développements commencent maintenant, les appareils Android 4.0+ occuperont une part plus importante de la base installée
• Si le streaming video en direct est une fonctionnalité clé de votre application, vous avez difficilement le choix

Permissions et features

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Les permissions sont utilisées pour demander des droits d’accès à des composants (par ex appareil photo, bluetooth, internet, … ).

Les features (disponibles à partir du niveau d’API 4) indiquent les caractéristiques (matérielles ou logicielles) nécessaires ou optionnelles. Elles sont utilisées pour le filtrage sur Google Play.

Les permissions impliquent des features, ce qui fait qu’il n’est pas obligatoire de signaler ces dernières.

Pour le cas des features matérielles, Google recommande néanmoins de les déclarer explicitement plutôt que de se reposer sur Google Play pour les “découvrir”. Voici un tableau récapitulant les implications entre les permissions et les features. Par exemple, la permission ACCESS FINE LOCATION implique les features android.hardware.location.gps et android.hardware.location.

Pourquoi est-ce important de déclarer les features matérielles explicitement ?

Car votre application peut ne pas être disponible sur certains appareils à cause des permissions, alors que vous vouliez qu’elle le soit. Si une fonctionnalité de l’application ne représente pas le coeur de l’expérience, rendez la optionnelle.
Par exemple, la permission “appel téléphonique” empêchera les tablettes de voir votre application sur Google Play. Un exemple moins évident est l’appareil photo sur l’Asus Nexus 7 : cette tablette a un appareil photo sur son devant, mais pas à l’arrière. Aussi, la permission “appareil photo” rendra votre application indisponible sur Nexus 7.

Ecrans supportés

Indiquez les tailles d’écrans que votre application supporte. Par défaut, les paramètres pour les petits (small) écrans et les normaux (normal) sont à true. La définition des écrans small, normal, large et xlarge et assez vague, car c’est un paramètre défini par les constructeurs. Mais on peut considérer que small et normal sont des smartphones et que large et xlarge sont pour les tablettes. Voici un schéma de Google donnant une idée de la correspondance entre la taille et la taille généralisée.

Selon votre stratégie (qui devrait être définie en début de projet), vous pouvez développer :

• la même mise en page pour toutes les tailles d’écrans : simple et rapide, mais vous ne tirerez pas profit de l’espace disponible sur les grands écrans. Ci-dessous, une comparaison de l’écran Lecture en cours de l’application Spotify sur LG Nexus 4 et sur Asus Nexus 7. C’est exactement la même application. On remarque l’espace gâché sur tablette en paysage.
• une seule application gérant plusieurs mises en pages pour des tailles d’écrans différentes : le même coeur, mais des UI différentes. Cela veut aussi dire, que ce doit être une application Android 4.×.
• plusieurs applications : smartphones + tablettes, ou Android 2.x + Android 4.×. L’idée est de toucher un maximum d’utilisateurs potentiels et de proposer une UI et des fonctionnalités récentes aux utilisateurs d’Android 4.×. Le coût de développement est plus élevé et la maintenance est plus compliquée étant donné que cela fait deux codes différents.