Compatibilité logicielle de Google Android

Android commence à prendre son envol. En seulement un an, le système d’exploitation mobile de Google est disponible sur une douzaine de smartphones ainsi que d’autres appareils tels que l’Internet Tablet du français Archos ou le Nook, l’eReader du plus gros libraire américain, Barnes & Noble. Et si ses parts de marché sont encore faibles, sa croissance est excellente. Il se vend plus de smartphones sous Android que de smartphones sous Windows Mobile

(Parenthèse sur Windows Mobile. Etant donné que Microsoft a annoncé Windows Phone 7 pour la fin de l’année, je ne serais pas surpris que les ventes de Windows Mobile 6.5 chutent, laissant Microsoft en chute libre sur le marché du mobile pendant plusieurs mois. Quelques éditeurs comme Skype ont en effet déjà annoncés qu’ils arrêtaient de supporter ce système d’exploitation pour se concentrer sur son successeur. Quant au public, qui voudrait d’un OS dont ont a annoncé la mort prochaine? Fin de la parenthèse)

Mais cette ascension rapide a son revers. Dans le cas d’Android, le risque est un manque de compatibilité logicielle. Car avec la diversification des appareils supportant Android, écrire une application qui fonctionne sur tous ces appareils relève de plus en plus du cauchemar.

Microsoft connait le problème: le nombre de configurations matérielles que Windows doit supporter entraîne de temps en temps des hics lorsqu’il s’agit de reconnaître tel ou tel pilote de périphérique. Android étant en logiciel libre, Google a encore moins de contrôle que Microsoft. Et les fabricants de matériel cherchant à se différentier de la concurrence, il est normal qu’ils tentent de personnaliser Android.

C’est là où Google a intérêt à faire preuve d’ingéniosité.

Le cœur du problème

La solution couramment utilisée pour remédier à ce problème est d’isoler les applications du matériel en utilisant une couche logicielle entre les deux. Windows utilise ainsi HAL (pour Hardware Abstraction Layer ou couche d’abstraction matérielle) pour tout appel au matériel. HAL a par la suite été complété par DirectX pour améliorer les performances graphiques (principalement pour les jeux vidéo). Un logiciel n’a donc qu’une vue « virtuelle » du matérielle. Dans le cas de DirectX, le logiciel ne sait pas si les calculs graphiques sont effectués par le système d’exploitation ou par la carte graphique, ni de la qualité du rendu – DirectX masque tout cela. De son côté, Sun a développé la plateforme Java pour permettre d’écrire des applications qui peuvent être déployées sur du matériel très varié. Macromedia, lui (depuis racheté par Adobe) a développé Flash, qui est utilisé sur de nombreux sites Web lorsqu’ils veulent des fonctionnalités évoluées tournant (pratiquement) quelle que soit le navigateur Web.

Une couche d’abstraction entre les applications et le matériel fonctionne dans la plupart des cas, même si elle n’est pas toujours 100% efficace. Java par exemple n’a pas complètement rempli ses promesses d’être 100% portable.  Dans le cas de Windows et de Flash cependant, la compatibilité logicielle reste excellente: les développeurs doivent rarement tester leur application sur une pléthore de systèmes différents.

Mais Android isole déjà (ou tente d’isoler) le matériel du logiciel. Mais ça n’est pas suffisant dans le cas de l’informatique mobile. Car autant Windows a toujours été aidé par un certain standard matériel (le PC), autant Android (et les smartphones en général) est confronté à un concept beaucoup plus flou.

Il n’existe en effet pas de tel standard matériel pour les smartphones – et encore moins pour les appareils qui supportent Android comme le Nook de Barnes & Noble ou l’Internet Tablet d’Archos. Suivant les modèles, un smartphone peut avoir – ou ne pas avoir – un GPS, un écran tactile, un accéléromètre (et il n’est pas certains qu’ils se comportent tous de la même manière). Une application qui utilise le GPS – même pour une fonctionnalité minimale – risque de se planter si le smartphone ne possède pas de GPS ou si ce dernier est désactivé par défaut. Sur le PC, le BIOS (Basic Input/Output System, la couche qui permet de gérer les périphériques comme le disque dur) est standardisé. Pas sur les smartphones.

Face à ce problème, Apple a adopté la solution de tout contrôler et de limiter les combinaisons matérielles. Cupertino contrôle le matériel utilisé par ses iPhones ainsi que les applications qui tournent dessus, et peut donc s’assurer que toutes les applications (officielles) pour iPhone fonctionnent correctement. Mais même dans ce cas, certains développeurs d’applications achètent un iPhone et un iPod Touch pour s’assurer que leur application fonctionne parfaitement sur les deux appareils. Google n’étant présent sur le marché des smartphones qu’au niveau du système d’exploitation (mis à part le Nexus One), une telle solution n’est de toute façon pas envisageable.

Google pourrait se baser sur Flash pour avoir une bonne compatibilité logicielle. Mais l’inconvénient est que c’est une technologie propriétaire, qui s’accorde donc peu avec un système d’exploitation libre. Et il n’est pas dit que Flash arrive à tirer le meilleur d’un smartphone. Sur ce point, Steve Jobs a raison: Flash peut ralentir les performances et est très souvent à la base des crashs du navigateur Web.

S’il n’y a pas de recette miracle, Google pourrait améliorer l’état des choses en segmentant les types d’application pour smartphone.

Les applications haut de gamme: pas de recette miracle

Il existe beaucoup d’application que j’appellerais « haut de gamme ». Des applications qui utilisent grandement les capacités du matériel: que ce soient les jeux ou autres applications poussées. Ici, pas de miracle. Les jeux auront besoin de tirer partie de toutes les possibilités du matériel s’ils veulent rivaliser avec leurs concurrents sur iPhone.

Pour éviter un casse-tête pour les développeurs, Google devra standardiser encore plus certaines couches matérielles des appareils qui veulent utiliser Android (comme un BIOS).

Entre temps, il est possible que certain constructeurs payent des développeurs pour supporter leurs appareils. Des constructeurs tels que HTC ou Motorola qui ont grandement investit sur Android pourraient envisager de courtiser des développeurs pour s’assurer que, si ces derniers ne testent leurs logiciels que sur une marque de smartphone, ce soit la leur.

Les applications plus simples

Mais il existe beaucoup d’autres applications qui sont beaucoup plus simples et qui ne sont ni plus ni moins un remake d’un site Web. L’application Facebook est un exemple, mais il en existe plein d’autre. Sur le site Web d’Apple, certaines des applications iPhone présentées sont des recettes de cuisine et des applications d’actualités. Elles n’apportent ni plus ni moins la même information que l’on trouve sur le Web, mis au format iPhone. Et beaucoup de ces applications sont gratuites.

Pourquoi donc ces applications existent-elles? Pourquoi leurs développeurs ont-ils accepté de subir le tristement célèbre processus de sélection des applications iPhone alors qu’il s’agit souvent de réinventer ce qui existe déjà sur le Web?

La raison est une histoire de packaging. Si on peut certes aller sur Facebook depuis son iPhone, une application Facebook sera optimisée pour le smartphone. Les données affichées sont formattées pour l’écran de ce dernier. On a une icône Facebook depuis l’écran principal, au côté des autres applications. Et l’application peut être intégrée avec les autres fonctionnalités de l’iPhone (carnet d’adresse, téléphone, GPS, etc.)

Mais c’est là où Google a une carte à jouer: permettre de packager une application Web en une application Android. Remplacer les contrôles HTML par des contrôles ayant un look & feel Android. De même que certains sites Web ont un sous-domaine en mobile (http://mobile.monsiteweb.com) optimisé pour les smartphones, on pourrait imaginer que qu’ils développent un http://android.monsiteweb.com optimisé pour Android. Google possède déjà certaines technologies clé telles que Google Gears qui permet à un site Web de sauvegarder localement des données. Et de la même manière que l’URL « mailto: » indique au navigateur Web qu’il s’agit d’une adresse email, on peut imaginer un format tel que « phone: » ou « contact: » pour appeler d’autres fonctionnalités du smartphone.

Bien évidemment, cette solution ne marcherait pas pour tous les types d’applications. De plus, cela nécessiterait une connexion Internet constante (cependant beaucoup des applications d’information telles que Facebook ont de toute façon besoin d’une connexion Internet constante). Mais il serait bon de simplifier le développement d’applications mobiles lorsque cela est possible. Car force est de constater que l’on a assisté à un retour en arrière à ce sujet. Autant le développement d’applications Web a simplifié le processus, autant le développement d’applications pour smartphone reprend le même modèle que les applications traditionnelles pour PC ou Mac. Utilisation d’un SDK propriétaire et souvent complexe (alors qu’on peut créer un site Web dynamique avec quasiment n’importe quel langage). Dans le cas de l’iPhone, le SDK ne fonctionne que sur le Mac, et on doit passer par un processus de certification fort contraignant.

Permettre de packager une application Web en une application Android permettrait à n’importe quel designer de site Web de facilement adapter leur site pour Android. Sous le capot ce n’est que du HTML et un peu de Javascript. Mais pour l’utilisateur cela se comporte comme une application.

Le Web a eu le succès que l’on connait grâce à la simplicité du HTML. N’importe qui pouvait développer son site Web facilement, avec un budget très limité et sans demander d’accord à personne. Google aurait beaucoup à gagner en simplifiant l’écriture d’applications pour Android et de faire qu’il soit aussi facile de créer une application Android qu’un site Web sur Internet ou un intranet. Cela pourrait lui apporter énormément d’applications gratuites. Cela lui donnerait l’avantage sur le BlackBerry, qui nécessite de coûteuses licences serveur pour déployer des applications BlackBerry au sein d’une entreprise. Et cela lui permettrait même peut-être de prendre l’ascendant sur Apple en termes de logithèque, car je ne suis pas certain que ce dernier suivrait Google dans cette direction.

Explore posts in the same categories: Google, Ordinateurs de poche

2 commentaires sur “Compatibilité logicielle de Google Android”


  1. […] impliquer plusieurs applications. Je reste de même persuadé qu’il y aurait un intérêt à packager des sites Web en applications. Explore posts in the same categories: Non […]


  2. […] Framework) au profit d’une API basée sur HTML 5 et JavaScript. Si je trouve que c’est une excellente idée, le problème est que cette dernière propose moins de fonctionnalités que ce que proposait […]


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s


%d blogueurs aiment cette page :