Nous sommes très heureux de lui donner la parole sur FrAndroid :

Bien qu’Android ne soit actuellement disponible que sous la forme d’un SDK, où l’on peut le voir tourner sur l’émulateur fourni, quelques impatients se sont amusés à le porter sur du vrai matériel.
J’ai testé l’installation de l’OS de Google sur l’internet tablet de Nokia, le N810.

L’installation

Le site elinux décrit la marche à suivre pour l’installation sur des processeurs OMAP (ARM Texas Instrument), que l’on trouve dans le Nokia.
Pour lancer Android il faut trois éléments :

• Le noyau ou kernel linux
• Le système de fichier
• Les scripts de lancement

Le kernel est tout simplement construit à partir des sources officielles du noyau linux 2.6.21. Il faut tout de même le configurer à l’aide d’un patch Android fourni par la communauté et le cross-compiler avec un compilateur ARM.
La partie commence à être intéressante avec l’obtention du système de fichier. Il n’est en effet pas possible de l’obtenir directement à partir des fichiers présents dans le répertoire du SDK. L’astuce consiste donc à lancer l’émulateur en mode débogage, à installer un shell tiers afin de copier le système dans un espace extérieur (ici une image d’une SDcard).
Une fois ceci effectué, c’est presque gagné. Prenez une Mini SD Card, formatez la en ext2, copiez-y le système de fichier fraichement extrait, ajoutez y selon l’humeur quelques applications Android en .akp, et n’oubliez pas de rajouter les scripts de lancement (un dans la sdcard et un autre dans la racine du Nokia, via SSH).

Et l’on obtient…

Premières impressions

Un Nokia avec deux OS !

En effet la SDcard et les scripts permettent de passer de Maemo, l’OS de base (avec noyau Linux aussi), à Android.

Ce qui marche sous Android :

• Le touchscreen
• Le Wifi
• Le GPS
• Le lancement des applications tierces ou de base
• Le joystick et les boutons
• Une partie du clavier (querty, mais vous pouvez éditer le fichier querty.ty)

Ce qui ne marche pas :

• La gestion de la batterie
• Les touches Fn du clavier (donc pas de chiffres)

Ce qui marche moyennement :

• La réactivité. Installer le système de fichier sur une SDcard rend les réponses un peu lentes.

Quelques screenshots

L’interface de démarrage

Le navigateur

Le menu des applications

Une des démos de l’API, le cube OpenGL

MoonLander

Conclusion

A moins que vous ayez envie de vous amuser à installer Android sur votre hardware, ou que vous souhaitiez frimer devant vos amis, il est conseillé d’attendre une sortie plus officielle de l’OS, comme le HTC Dream. En attendant il reste encore de quoi s’amuser avec le SDK.

Fichier joint
Une archive avec le kernel compilé, le système de fichier, les scripts et le readme.

Nous sommes très heureux de lui donner la parole sur FrAndroid :

L’arrivée d’un nouvel OS sur le marché est toujours un événement, compte-tenu des investissements (argent ou temps) que ça représente pour l’éditeur ou la communauté et donc de l’intérêt qu’ils y voient. Le nombre d’OS sur mobile étant réduit, l’arrivée d’Android est donc un “vrai” événement.
Pour un non-technicien la promesse d’Android se situe dans l’ouverture, avec le potentiel d’avoir un grand nombre d’applications en partant du principe que la sécurité (anti-virus, etc) sera assurée.
Appliquée aux moyens de paiement, on peut noter deux axes de progression et d’attente : “fluidité” et “sécurité”.

Android devrait dans la mesure du possible s’attacher à gommer la complexité actuelle des solutions de mobile paiement, où les canaux sont multiples (wap, sms, ussd, etc) et les cinématiques à l’avenant (multiples mots de passe, etc). Une application idéale serait capable de s’adapter en fonction du contexte, par exemple :

• si je suis statique : l’appli propose du paiement sans contact,
• si je suis en mouvement : l’appli propose du paiement à distance, correspondant au canal utilisé (wap si je suis en train de browser, SMS si je suis en communication téléphonique, etc).

La possibilité d’avoir l’application en tâche de fond (c’est-à-dire ne pas avoir à lancer l’application avant de pouvoir s’en servir), d’avoir du multi-tache (ce qui est assez rare aujourd’hui sur les mobiles), et du multi-accès (le cas d’école d’accès au répertoire ou à l’interception des SMS/MMS) sont parmi les plus qu’Android peut apporter.

Android pourrait aussi au niveau des moyens de paiement apporter un renforcement de la sécurité et une meilleure gestion de cette même sécurité.
Avec son ambition sur la géolocalisation (qui existe déjà chez certains opérateurs mobiles), Android pourrait permettre de détecter la fraude en confrontant la géolocalisation issue du marchand (ou serveur marchand) et la géolocalisation issue du mobile du client. Ainsi, si je suis en train d’acheter par carte bancaire en Amérique du Sud alors que la géolocalisation de mon mobile indique un pays européen, on peut déclencher, à l’instar de ce que fait Paypal sur le tracking des adresses IP, une procédure anti-fraude. L’idée serait aussi que ces dispositifs anti-fraudes soient plus intelligents, grace à l’interactivité du mobile et de la capacité de l’OS et de l’application, afin d’éviter de polluer l’individu avec des alertes indaptées ou non paramétrables.
Toujours au niveau de la gestion de la sécurité, android pourra peut-être avancer là où les autres OS mobiles pêchent, à savoir la gestion simple des mots de passe (un mot de passe unifié ? la notion de trousseau ? une meilleure intégration de la biométrie ?) intégrée aux applications, et les aspects de gestion des certificats (et des liaisons https qui sont ensuite activées) qui aujourd’hui polluent les applications embarquées (les pop-up intempestifs pour demander une nieme fois si on est d’accord pour accéder à gmail en java finissent par décourager l’utilisateur … car en plus ça bloque l’application).

Si on devait résumer : l’iPhone a mis en lumière que l’internet mobile existe, Android devrait mettre en lumière que le mobile est un outil personnel intelligent, notamment pour les moyens de paiement.