Android réussit quelque chose d’assez spécial : me rendre curieux d’un téléphone qui n’existe pas encore en magasin. Le SDK et l’émulateur permettent déjà de regarder sous l’écran plutôt que d’attendre seulement le matériel.

La pile annoncée place Linux au bas pour les pilotes, la mémoire, les processus et le réseau. Au-dessus se trouvent des bibliothèques natives, la machine virtuelle Dalvik et le framework Java utilisé par les applications. Chaque application reçoit son processus et son identité Linux, ce qui donne une première frontière entre ses fichiers et ceux des autres.

application -> Activity / Service / ContentProvider
            -> framework Android -> Dalvik + bibliothèques
            -> noyau Linux -> écran, radio, stockage, batterie

Une Activity représente un écran ou une interaction. Un Service peut poursuivre un travail sans interface visible. Un ContentProvider expose des données selon un contrat. Les Intent transportent une intention entre composantes : ouvrir une adresse, choisir un contact ou lancer une autre activité. L’application peut demander une capacité sans connaître exactement l’écran qui la réalisera.

Le système peut reprendre la mémoire

Sur un téléphone, quitter un écran ne signifie pas que son processus restera vivant. Le système doit récupérer de la mémoire pour un appel, une autre application ou un appareil plus petit. Une activité possède donc un cycle de vie; elle doit conserver l’état nécessaire et savoir reconstruire l’interface.

création -> visible -> active -> pause -> arrêt -> destruction possible

Pour un formulaire, je garderais l’identifiant et les champs non envoyés dans un état persistant avant l’arrêt. Mettre uniquement l’objet courant dans une variable globale fonctionne dans l’émulateur jusqu’au moment où le processus est tué. Le redémarrage doit aussi éviter de soumettre deux fois la même opération après une réponse réseau perdue.

Le manifeste déclare les composantes et les permissions demandées. Une application qui veut accéder au réseau ou aux contacts doit l’annoncer. Cette transparence aide, mais une longue liste risque de devenir un écran que tout le monde accepte sans lire. Le développeur devrait demander le minimum et le système devrait faire respecter la permission à chaque frontière, pas seulement à l’installation.

L’ouverture crée le risque de fragmentation. Un écran tactile ou un clavier, plusieurs résolutions, des processeurs différents et des modifications du fabricant peuvent changer le comportement. Je séparerais les ressources par taille d’écran, éviterais les dimensions fixes et testerais la rotation, la mémoire faible, l’absence de réseau et une batterie presque vide.

L’émulateur ne simule pas tout. Il ne montre ni la qualité réelle de la radio, ni le coût énergétique d’un GPS gardé ouvert, ni un pilote imparfait. Je préparerais une matrice minimale : petit et grand écran, tactile et clavier, réseau rapide et coupé, processus tué pendant une tâche. La même application doit conserver ses données ou expliquer clairement ce qui a été perdu.

Je ne choisirais aucun gagnant en avril 2008. Android propose une architecture de composantes et de permissions très intéressante. Sa vraie réussite se mesurera lorsque le premier téléphone recevra une mise à jour et que la même application fonctionnera sur le deuxième sans dépendre d’un hasard de l’émulateur.