juin
2009
Un article de adiGuba
La semaine dernière, Google annonçait en grande pompe l’Open Handset Alliance, regroupant une trentaine de compagnies avec l’objectif d’accélérer l’innovation dans le monde de la téléphonie mobile. Le tout basé sur Android, un système d’exploitation pour téléphone portable de nouvelle génération. Ce dernier comprendra un ensemble d’application de série (comme un client email, un gestionnaire de contacts, un calendrier, un navigateurs, etc.) mais surtout qui promettait la mise à disposition rapide d’un kit de développement pour les applications tierces, qui serait traité à l’identique des applications de base (c’est à dire que n’importe quelle application du système pourrait éventuellement être remplacé par une autre).
Un initiative bienvenu lorsque l’on sait que le fameux iPhone d’Apple ne permet toujours pas d’installer d’applications tierces sans recourir à des solutions plus ou moins légales et pratiques…
Déjà, dans la séléction hebdomadaire du 9 novembre, la rédaction java envisageait qu’une machine virtuelle Java pourraient être intégré en standard avec Android. Et en ce 12 novembre, alors que le premier SDK a vu le jour, force est de constater que ce n’est pas exactement le cas…
C’est nettement plus intéressant puisque Java se retrouve au coeur même du système d’Android ! Enfin presque…
Contrairement à ce que l’on aurait pu penser, ce n’est pas Java ME qui a été choisit, mais bel et bien Java SE. Ou plus précisément un étrange fork qui ne porte pas vraiment le nom de Java… mais qui en a bien toute la saveur.
Il n’y a pas donc pas véritablement de machine virtuelle Java, mais une machine virtuelle Dalvik au coeur même du système, qui est chargée d’exécuter toutes les applications du système (y compris les applications de base). Cette machine virtuelle n’exécute pas des fichiers *.class comme le ferait une JVM, mais des fichiers *.dex qui se trouve être en fait des classes Java transformées spécialement pour Dalvik via un outil de son SDK.
Ainsi les développeurs Java ne devraient pas être trop dépaysé puisqu’ils pourront continuer à utiliser leurs EDIs/compilateurs favoris : tout le développement est ainsi fait avec Java 5.0. D’ailleurs un plugin pour eclipse est déjà fourni par Google, et étant donné l’ouverture du système, des plugins pour les autres EDIs ne devraient pas tarder à suivre…
Comme toutes machines virtuelles, Dalvik est lié à un « runtime » qui contient toutes les librairies de base utile à la conception des applications. Et ce runtime comporte les principales librairies de Java 5.0. Plus exactement il s’agit d’un Java 5.0 épuré des packages suivants (le signe ‘*’ indique que tous les sous-packages sont également absent) :
- java.applet
- java.awt *
- java.beans *
- java.lang.management
- java.rmi *
- javax.accessibility
- javax.activity
- javax.imageio *
- javax.management *
- javax.naming *
- javax.print *
- javax.rmi *
- javax.security.auth.kerberos
- javax.security.auth.spi
- javax.security.sasl
- javax.sql.rowset *
- javax.swing *
- javax.xml * (sauf javax.xml.parsers)
- org.ietf.jgss
- org.omg * (CORBA/IOP)
- org.w3c.dom.bootstrap
- org.w3c.dom.events
- org.w3c.dom.ls
Mis à part l’absence des librairies graphiques standards de Java (AWT et Swing) et de ImageIO, la plupart des librairies manquantes sont d’un intérêt assez limité dans le cadre d’un système embarqué, et même très peu utilisé dans le cadre d’une application de bureau. Leurs absences ne devraient pas trop géner les développeurs Java…
En contrepartie on retrouve la quasi-totalité des librairies de base de Java, avec bien entendu java.lang mais aussi Java IO ou NIO pour les entrées/sorties, java(x).net pour le réseau, l’API de Collection au grand complet, JDBC, la réflection ou encore la nouvelle API de concurrence… Bref bien plus que ce que ne propose Java ME !
Mais ce n’est pas tout puisque le runtime d’Android se voit également enrichi par d’autres librairies sous les packages android.*, avec un « Application Framework » regroupant un scope assez large de fonctionnalité, allant de l’intégration de SQLite à un toolkit UI adapté pour les systèmes embarqués (que je trouve d’ailleurs plutôt agréable à l’oeil), en passant par des fonctions de téléphonie plus ou moins spécifique (appel téléphonique, SMS, GPS, caméra/appareil photo, etc.), la gestion des formats multimédia les plus courant, la reconnaissance vocale et bien d’autres éléments qui pourraient varier selon le matériel…
Et il ne faut pas oublier non plus l’ajout d’un certain nombre de librairie annexe au coureur même du runtime d’Android :
- javax.microedition.khronos.opengles, une implémentation de la JSR 239 qui propose un binding pour OpenGL ES. C’est d’ailleurs la seule API en provenance de Java ME.
- JUnit, la bibliothèque de test unitaire bien connu du monde Java.
- Jakarta Commons Codec, une série de codeurs/décodeurs commun tels que Base64, Hex, etc.
- Jakarta Commons HttpClient, permettant d’intérroger un site Web le plus simplement possible.
- org.bluez pour la gestion du Bluetooth.
- org.json afin de gérer le format de données JSON.
- Sans oublier deux librairies propre à Google, com.google.android.maps qui permet de manipuler et d’afficher les données de Google Map, et com.google.android.xmppService qui intègrera le protocole de communication XMPP, utilisé notemment à travers Jabber et Google Talk.
Bref tout le nécessaire pour développer des applications bien adaptées aux systèmes embarqués…
Mais Android c’est quoi en fait ?
Android correspond en fait au système d’exploitation complet qui sera utilisé sur les appareils mobiles compatibles, et il se décomposent en 4 couches principales comme le montre le schéma ci-dessous :
Android se base donc sur un kernel Linux en version 2.6, qui se chargera des services de base tel que la gestion des processus, de l’énergie, de la couche réseau ou encore des pilotes matériels. Il englobe également un ensemble de librairies natives couvrant un scope assez large allant de la librairie standard C aux librairies graphiques 2D/3D, en passant par le support multimédia des formats image/audio/vidéo les plus courant ou encore WebKit, le fameux moteur de rendu de page web (utilisé entre autre par le navigateur Safari ou l’iPhone).
Au même niveau, on retrouve la machine virtuelle Dalvik, qui se chargera donc d’exécuter toutes les applications du système, ainsi que les librairies de base du runtime.
On retrouve ensuite l’Application Framework (représenté dans l’API par les packages android.*) qui se chargera à la fois de proposer un cadre pour le développement d’application, mais également de fournir l’accès aux fonctionnalités avancées de l’appareil en se basant sur les librairies natives de la couche inférieur.
Enfin, la couche supérieur regroupera toutes les applications du téléphone, que ce soit les applications de base ou des applications tierces…
Qu’est-ce que cela apporte par rapport à Java ME ?
D’un premier abord, Android à vraiment l’air très prometteur, et semble offrir tout le nécessaire pour développer des applications aussi diversifié que possible.
En comparaison avec Java ME on remarquera surtout une API bien plus riche et surtout moins éparpillé : Java ME est basé sur un ensemble de JSR optionnelle plus ou moins présente d’un appareil à l’autre, ce qui ne facilite pas vraiment la tâche du développeur.
Ici on dispose d’une grosse API commune, qui permet de gérer la présence ou non des éléments trop dépendant du matériel (comme la présence ou non d’une caméra/appareil photo, du WiFi, d’un GPS ou d’une accélération 3D).
Par contre j’ai hâte de connaitre la position exacte de Sun vis à vis de cette plateforme, basé sur Java mais qui ne l’est pas vraiment… et surtout ce que cela implique quand à l’avenir de Java ME !
- Va-t-on rencontrer les mêmes problèmes qu’à l’époque de la JVM de Microsoft ?
- Sun va-t-il s’investir dans Android ?
- Et que va devenir JavaFX ?
Java 7 devrait apporter un système de module : n’y aurait-il pas une belle occasion à prendre pour modulariser les différentes composantes de Java et faire d’Android une vrai plateforme Java ?
Cela n’est pas sans poser un certain nombre de question, mais il semble clair que le monde de la téléphonie est en train de bouger !
Et il est intéressant de noter que contrairement à Apple et son iPhone qui reste encore assez fermé aux développeurs, Google a choisit une approche diamétralement opposée en publiant un SDK très tôt, et surtout en faisant de l’oeil aux développeurs via l’Android Developer Challenge, un concours de développement doté de 10 millions de dollars de lots…
Sans oublier une documentation qui semble relativement complète et bien garni en exemple.
Bref Google semble avoir mis tous les moyens de son coté, et il ne reste plus qu’à voir ce que cela va donner… mais personnellement je suis déjà conquis !
Et vous ?
17 Commentaires + Ajouter un commentaire
Tutoriels
Discussions
- L'apparition du mot-clé const est-il prévu dans une version à venir du JDK?
- Possibilité d'accéder au type générique en runtime
- Classes, méthodes private
- jre 1.5, tomcat 6.0 et multi processeurs
- [REFLEXION] Connaitre toutes les classes qui implémentent une interface
- Recuperation du nom des parametres
- Difference de performances Unix/Windows d'un programme?
- Définition exacte de @Override
- [ fuite ] memoire
Si je ne me trompe pas, le .NET Compact Framework n’est pas à 100% identique au .NET de bureau : il comporte aussi une partie des classe standard du .NET « de bureau » et y ajoute des classes plus spécifiques du monde mobile.
Ici c’est la même chose avec Android… Même langage (Java), même IDE pour développer et débugger (eclipse, même si d’autres EDI peuvent être utilisé via Ant). Il n’y a que l’API qui n’est pas 100% identique mais qui est adapté au monde du mobile…
Quand au « exotiques et incompatibles », si je suis ta logique il s’applique aussi à Windows CE : après tout une application pour Windows XP ou Vista ne fonctionne pas sous Windows CE…
Enfin concernant la confidentialité, je n’ai pas dit que ce n’était pas sérieux, mais je vois pas ce que cela vient faire ici, surtout qu’Android sera une plateforme open-source.
Et Microsoft fait également des collectes d’informations lorsque tu utilises les services live.com. Ce n’est pas un reproche de ma part, c’est à la base même du « business model » des services gratuits online : la pub ciblé !
a++
@adiguba:
Qu’il existe un concurrent à CE me semble une bonne chose, ça stimule toujours le marché la concurrence. Mais le prétexte de la concurrence ne doit pas faire crier au génie sans réfléchir vraiment à l’offre présentée non ?
Et justement, pour juger de la vaillance d’un concurrent il faut notamment des comparatifs. Sans comparaison pourquoi toi-même tu choisirais Android plus que Windows CE, pour quelles motivations techniques et objectives ? C’est ça le plus important et c’est ce que je soulignais dans mon commentaire précédent. Et si tu as des critères techniques et objectifs, c’est très sincèrement avec intérêt que je les lirais, pour m’informer.
Tu réfutes le qualificatif « exotiques et incompatibles entre eux », mais toi même tu le dis, ce n’est pas java, c’est « basé sur l’API java ». Donc ce n’est pas vraiment compatible et c’est un peu exotique (un truc original tout seul dans son coin qui réclame un apprentissage spécifique). Un des critères intéressants de Windows CE c’est qu’il accèpte la plateforme .NET, même langage, même IDE pour développer et debugger qu’une appli web ou windows. Si Android ne permet pas de le faire, j’y vois là un inconvénient majeur.
Et pour en revenir à la confidentialité, tu sembles renvoyer la question par une pirouette « MS n’est pas mieux placé… » ce qui est une accusation gratuite. L’espionnage de mes g-mails, l’espionnage de l’historique de mes recherches sous google, l’espionnage de mon agenda privé google, etc, très honnêtement MS ne s’est jamais permis un truc pareil sur une telle échelle sans que personne ne hurle au grand satan. C’est ça qui m’interpelle, c’est l’état de grâce de google, très à la mode, qui se permet des choses qui feraient un foin pas possible si MS faisait idem. Donc deux poids, deux mesures. Donc partialité dans le traitement, donc aveuglement dans le jugement ?
C’est une question très sérieuse hein, c’est pas trollesque. C’est une prise de conscience, voire un examen de conscience que doit faire chacun. Peu importe l’échange ici. Si chacun réfléchit à ma question sur ce point sans même répondre ici, c’est le plus important.
Merlin : c’est justement un système concurrent de Windows CE… si ce n’est qu’il est open-source et qu’il cible en priorité les téléphones portables (dans un premier temps tout du moins).
Ne connaissant pas Windows CE et ayant à peine explorer la doc d’Android je ne m’avancerait pas à les comparer… et étant donné qu’Android vient à peine d’être dévoilé je ne pense pas que de tel document existe déjà.
Quand aux « trucs exotiques et incompatibles entre eux », c’est quand même basé sur une grosse partie de l’API de base de Java, couplé à un framework standard pour les spécificités mobile…
Quand à la question de la confidentialité, c’est un peu hors-sujet mais je ne pense pas que Microsoft soit bien mieux placé sur ce plan là…
a++
J’ai du mal à voir l’intérêt… Tout cela existe déjà avec Windows CE, le tout servi par le framework .NET, ce qui permet de programmer le phone avec les mêmes libs, les mêmes langages et le même IDE que les applis de bureau et Web… Pourquoi se compliquer la vie avec des tas de trucs exotiques et incompatibles entre eux ? Juste pour suivre la mode ? Techniquement et point par point, y-a-t-il quelque part un comparatif objectif du zinzin de google avec Windows CE+Compact Framework?
Je suis vraiment perplexe devant ses soi-disant nouveautés super cool qui existent en mieux depuis longtemps..
Rappelons au passage que Google est le champion de l’espionnage de nos mails (gmail) par exemple, qu’ils trackent nos recherches sur google (pour mieux « aider »).. J’ai un peu peur de ce qu’ils vont faire sur nos téléphones !
Dire que si MS faisait le millième on ressortirait l’histoire de l’hégémonie et du grand satan…… ça me désole cet aveuglement.
Et hésitez pas à faire remonter des bugs, notamment sur code.google.com/android. On reste à l’écoute
Merci pour ce post très explicatif. Ca m’a motivé et j’ai décidé de regarder un peu tout ça du côté CONCRET de la force
1) installation du sdk : super facile et efficace. Tout est très bien expliqué. On récupère le zip que l’on décompresse dans un répertoire, on lance son Eclipse et on le met à jour avec le plugin pour Android par l’adresse qui est fourni sur la page d’installation… Il ne reste ensuite plus qu’à faire pointer la config du plugin vers le répertoire du sdk, un jeu d’enfant.
2) Le code : en gros, ça me fait penser à du XUL ou Flex… On a des « vues » côté XML qui définissent un layout, et on code dans les classes java les liaisons avec ces vues. Seul petit point noir : c’est un peu plus compliqué que dans Flex par exemple, et surtout il n’y a aucune barre d’outils avec tous les composants (textbox, button, listview… etc). Mais je suppose que ça viendra avec le temps.
A noter : les composants sont en fait des Widgets, que l’on peut dériver et redévelopper à souhait.
3) Lancement du projet : ok c’est un peu lourd, mais bon, une fois l’émulateur du téléphone et Android lancé, aucun souci. L’interface est rigoureusement la même que dans les vidéos que l’on a pu voir. De plus il ne sera pas utile de fermer et réouvrir l’émulateur à chaque modif du code. Il suffit de relancer l’appli avec l’émulateur allumé pour que ce dernier se réactualise.
En résumé : j’ai trouvé Android très motivant pour la suite. Les 2 exemples (notamment 3d open gl de Geek
) sont très convaincants et je n’ai eu aucun plantage ou bug. L’API est assez bien documenté, l’autocomplétion aide pas mal, mais on regrettera de ne pas l’avoir dans les « vues » xml… J’espère vraiment que cet OS libre réussira sa percée.
Avec Android, les téléphones portables vont devenir des Machines de Turing, c’est-à-dire de vrais ordinateurs.
arnobase : Je sais très bien qu’Apple a annoncé un SDK pour l’iPhone, mais il sortira près de 8 mois après la première commercialisation de l’iPhone…
Ici c’est presque l’inverse : les premiers « Android-Phone » ne devraient pas être disponible avant la mi-2008…
a++
en réaction à ça :
« Un initiative bienvenu lorsque l’on sait que le fameux iPhone d’Apple ne permet toujours pas d’installer d’applications tierces sans recourir à des solutions plus ou moins légales et pratiques… »
Apple a annoncé qu’il serait possible d’installer des appli tierce et va même fournir un SDK…
–> http://www.pcinpact.com/actu/news/39519-iphone-sdk-fevrier-2008-steve-jobs.htm
voili
Sinon effectivement, bien bonne idée le systeme mobile libre
Je trouve le principe de fonctionnement très proche de celui utilisé pour GWT.
Le développeur utilise Java pour coder et ensuite on compile le code dans l’environnement qui nous intéresse.
HTML+JS pour GWT, et fichier .dex pour android.
ça montre que Google investi sur le langage Java et sa communauté et le pousse là ou la JVM n’est pas forcément présente pour l’instant.
Merci de la réponse Uther.
Dans la même veine, savez vous s’il est possible d’intégrer les jolis widgets du toolkit ui d’Android en swt/swing/awt ?
Ils sont forts beaux et complèteraient à merveille d’autres librairies je trouve
Heuresement que Google n’a pas la touche design de Sun ou IBM… lol !
Merci, pour l’info.
Je trouve android très prometteur. J’ai parcouru la documentation. Sympa le plugin Eclipse. Cela va être l’occasion pour beaucoup de développeurs comme moi de se mettre au developpement d’application pour mobile.
Pour une fois on a tous les outils et les docs en main. Merci à Google
>Une petite question : avez vous une idée du pourquoi de la non inclusion de Swing/awt ?
performances peut-être, mais je pense surtout parceque awt/swing sont des lib plutôt orientées desktop avec système de fenetres ce qui n’est pas la norme sur mobile et android ne fera pas exeption à la regle.
Salut
Merci pour ce post
Une petite question : avez vous une idée du pourquoi de la non inclusion de Swing/awt ?
Est ce pour des raisons de perfs ou plus en rapport à priori avec l’idée qu’à Google de la qualité de cette librairie ?
Merci d’avance
++
Et au niveau des PDAs ?
Parce que là on parle des téléphones (et PDA-phones), mais les purs PDA qui tournent actuellement sous Windows Mobile, peut-on espérer en avoir avec Android ou c’est trop tôt pour le dire ?
En tout cas je suis enthousiaste à l’idée de pouvoir me procurer un téléphone « Android ». Je pourrais enfin trouver un mobile qui pourra faire ce que je veux et pas ce dont je n’ai pas besoin.
Et le logo est sympa
Tout d’abord merci pour ce poste qui vient de me faire économiser une heure de fouille et lecture sur divers sites.
Je pense que cela va être très intéressant si cela permet de simplifier la gestion des différentes configuration des téléphones portable qui est souvent un cauchemar en Java ME.
Stratégiquement Google joue très bien avec le SDK déjà sur le marché. Quand les premiers téléphones arriveront dans un peu plus de 6 mois, il y aura plein d’applications, contrairement à l’IPhone qui est sur le marché depuis plus de 6 mois, sans SDK…
De quoi entretenir un Buzz autour des communautés de Geeks et développeurs.
J’ai quelques doutes quand je voie la quantité de choses embarquées dans l’OS jusqu’à SQLite ! J’ai du mal à envisager que nos téléphones grand public actuels soient capables de faire fonctionner tout cela avec des performances acceptables… Je sais qu’en 6 mois la technique évolue, mais je doute qu’on le trouve dans les téléphones d’entrée de gammes dès le début. L’IPhone risquera de ne pas avoir à rougir de son prix.