Articles taggés Android

Rappel généraux sur Android

Google a annoncé Android en 2007. Le marché visé est principalement le téléphone mobile mais il peut facilement s’étendre à n’importe quel dispositif mobile. Android a été réalisé autours des choix suivants :

• ouvrir les possibilités des terminaux (open source, modérer les applications à posteriori, pas d’IDE obligatoire, personnalisation, applications internes ou tierces logées à la même enseigne)
• rendre accessible toutes les fonctionnalités
• réduire les couts de R&D et de réalisation d’applications (s’appuyer sur des standards java/XML)
• promouvoir une expérience utilisateur plus riche et sans besoin de notice
• réunir les acteurs majeurs dans l’ Open Handset Alliance, travailler avec les constructeurs et les opérateurs.

On remarque déjà de forte différence dans la philosophie avec ces concurrents notamment Apple.
Android a déjà sorti plusieurs SDK apportant diverses fonctionnalités (le dernier étant le 2.1).

Le marché d’Android

Google a décidé (à l’origine) de ne pas créer un téléphone unique mais de travailler en collaboration avec les constructeurs de téléphone. De nombreux constructeurs ont lancé leur téléphone sous Android et à différent niveau du SDK. Le marché s’est donc très vite fragmenté avec différentes spécifications matérielles et un respect plus ou moins suivi des consignes de Google (SDK bloqué par exemple). Cette segmentation est à la fois la force et un des plus gros défauts pour Google qui a donc décidé de sortir le Nexus One pour donner leur vision d’un téléphone sous Android. La fragmentation est surtout un problème pour les développeurs qui doivent gérer plusieurs SDK et matériels (la taille de l’écran ? la présence d’un clavier ? GPS ?).

Google a aussi lancé son « Android Market ». Les applications y sont triées par zones géographiques ou types. Le prix des applications va de 0.99 à 200 euros (limitation de Google) avec bien sur les applications gratuites. Les revenus des achats sont répartis à 70% pour le développeur et 30% pour Google. L’inscription coute 25$ par an (contre 100$ pour Apple). La publicité est bien sur en projet de par le coeur de métier de Google.
Quelques chiffres : 6 000 applications en juin, 22 000 en janvier 2010, 39% payante, 16% jeux, une augmentation forte du nombre d’applications.

Le développement d’une application Android représente quand même des difficultés :

• un framework difficile pour faire du travail pointu
• il faut penser java en environnement hostile
• uns système de paiement imposé : Checkout (contre Itunes sur Apple).
• Annulation des achats sous 48h : bien pour l’utilisateur mais problématique pour le développeur.
• Interaction actuellement trop faible entre le développeur et le potentiel client (descriptif avec uniquement 320 caractères et un screenshot, market uniquement visible par le téléphone).

De plus le succès d’Android est bien sur conditionné par la qualité du terminal. Cependant les pronostiques envers Android sont plutôt bons par exemple Gartner le place devant Apple en 2012 avec une petite avance.
Le développement des applications va se partager entre les applications disponibles par l’intermédiaire du navigateur web et les applications natives.

L’architecture d’Android

Comme le montre le schéma ci-dessus, la plateforme Android est basée sur 5 couches :

• un noyau linux. 2.6 qui fournit les drivers nécessaires
• un ensemble d’API C/C++ fournissant des fonctionnalités de plus haut niveau (SQLite, OpenGL ES 2.0…)
• un framework java exploitable par toutes les applications s’exécutant sur la machine virtuelle Dalvik
• un ensemble d’application déjà fourni couvrant les besoins standards.

Le noyau Linux offre la possibilité de créer des applications natives en C. Un des coeurs d’Android est bien sur la machine virtuelle Dalvik. Celle-ci ne correspond pas à une JVM standard. Elle a été réécrite pour correspondre aux besoins et limitations d’un téléphone mobile : un processeur lent, peu de mémoire, pas de swap, une batterie.

Si l’API et le langage sont quasi équivalents à Java 5 SE, le bytecode généré est spécifique (le code Dalvik interprété est contenu par un fichier .dex). De plus il y a de nombreuses différences plus ou moins contraignantes :

• il n’y pas de compilation à la volée
• les tables de constantes sont simplifiées
• il est impossible de faire la programmation orientée aspect
• le garbage collector est encore peu évolué.

Tout ceci nécessite des optimisations manuelles et spécifiques (voir chapitre bonnes pratiques). L’ensemble du code et des ressources est contenue dans un fichier nommé apk qui représente l’application.

Chaque application vit dans son propre monde. Par défaut une application est lancé dans un processus Linux contenant sa propre machine virtuelle ce qui permet de garantir une forte étanchéité entre les applications. Par défaut, chaque application à son propre utilisateur avec ces propres permissions. En conséquence, les fichiers d’une application ne sont visibles que par elle même mais il existe bien sur des moyens de les exporter. Il reste quand même possible de faire correspondre ces éléments pour différentes applications.
Le code Java peut faire appel à l’API bas niveau par JNI.

Google propose un outillage dédié au développement : Android Development Toolkit disponible sur Windows (x86), Mac et Linux. Cet outil s’intègre directement à Eclipse avec le débugage, les logs et un éditeur d’interface graphique.