Android

Android

Faille Android du jour … Et hop, ton téléphone est wipé !

Faille Android du jour … Et hop, ton téléphone est wipé !

Mise à jour: Le sujet est tout chaud, il vient juste de tomber. Prenons les hypothèses avec des pincettes, et ne tirons pas de conclusions hâtives. Ce billet émane de premiers éléments qui seront peut-être/sûrement démentis/contredits dans les prochains jours.

La faille du jour ultra critique, au cas où vous seriez pour le moment passé à côté, concerne votre téléphone Android. Elle est plutôt du genre sévère et touche un grand nombre de combinés Android sans épargner les modèles phares et marques leader du marché.

Pour ma part, j’ai un Samsung Galaxy S et, ô surprise, il est vulnérable. Pourtant il fonctionne sur ICS, c’est à dire, la dernière version majeure du système Android.
La vulnérabilité concerne l’exécution automatique des codes spéciaux via le dialer de votre téléphone. Vous en avez peut-être déjà entendu parlé. Par exemple, si vous saisissez le code: *#06# sur votre téléphone, une popup avec son numéro IMEI apparaîtra.
En apparence, rien de très grave. Sachez cependant qu’il est possible de saisir d’autres codes provoquant d’autres actions sur votre téléphone dont un qui permet de wiper (Supprimer) toutes les données de votre cher téléphone Android.
Sachez également, qu’il est juste nécessaire d’ouvrir une page web contenant un lien téléphonique pour exécuter ce type de code. Le problème de sécurité réside dans le fait système Android permet l’exécution automatique de ces codes sans demander de confirmation, il est ainsi possible de créer des QRCode piégés ou bien encore de créer des liens piégés via de simples pages web.

Si vous avez des doutes quant à la criticité de cette faille, rendez-vous sur cette page avec votre téléphone: http://dylanreeve.com/phone.php et voyez comment il réagit. Si le numéro EMEI de votre téléphone apparaît dans une popup sans action de votre part, alors votre téléphone est vulnérable.
Mon Samsung Galaxy S ouvre fièrement une popup affichant son numéro IMEI. Ceci sous-entend qu’il est également capable d’exécuter le wipe du téléphone ou d’autres choses peut-être encore moins sympas dont personne n’a idée pour le moment.
En prenant le temps de la réflexion un instant, on se croirait revenu au temps de Windows 98, et de ses failles béantes découvertes tous les quatre matin ! On peut se demander comment de telles failles de sécurité peuvent encore passer entre les mains des équipes de sécurité chez Google sans être repérées, c’est tout bonnement incroyable!

Sachant que les mises à jours Android sont mises à dispositions, en général, uniquement pour les combinés les plus récents, nous sommes devant une faille avec potentiel destructeur énorme, et qui pourrait n’être jamais corrigée pour une vaste majorité de combinés. Je ne parle même pas du fait que l’utilisateur moyen n’a que peu de chance de savoir qu’il faille mettre à jour son téléphone lorsqu’il en a la possibilité.

Différentes solutions ou workaround existent. Si vous n’avez pas la chance d’avoir un téléphone protégé ou bien même d’avoir une mise à jour de sécurité applicable pour votre modèle de téléphone, vous pouvez dans un premier temps installer un second Dialer via le Google Play afin de vous prémunir de l’exécution automatique de ces code spéciaux. Vous vous verrez proposer à la place une popup de confirmation vous demandant de choisir l’application à utiliser. Vous aurez donc le choix d’annuler l’action.

Si votre système est assez moderne et dispose de Google Chromen vous pouvez attendre une nouvelle version de l’application fixant la faille de sécurité. Sachez cependant que bon nombre d’applications dont les readers fonctionnent avec un composant WebView basé sur le navigateur système. Ce composant n’est pour le moment pas une webview Google Chrome même pour les téléphones les plus récents (Hormis exception pour l’instant me semble-t-il). C’est donc la webview système qui prenda en chargement la page web. Une mise à jour de Chrome ne permettra donc pas de se prémunir des applications embarquant une webview et donc potentiellement affectées par le problème.Quant aux applications proposant la lecture de QRCode, il faudra attendre les mises à jour.

Il est fort à parier que la solution la plus pérenne viendra de la mise à disposition via le Play Store d’applications de filtrage de demande d’exécution de ces codes spéciaux. La question étant de savoir s’il est nécessaire d’avoir un téléphone rooté pour installer une application de ce type.

Nos téléphones auraient-ils besoin finalement d’antivirus sachant que la plupart des failles de sécurités ne sont jamais corrigées du fait de l’obsolescence effrénée de nos combinés et donc de l’absence récurrente de mise à disposition de mises à jours de sécurité pour les modèles les plus anciens.
De même, combien de temps les constructeurs fermeront les yeux sur l’absence de mise à jour de sécurité régulières de nos combinés mobiles ?

Fait étonnant, les derniers Google Phone ne semblent pas touchés. Google aurait-il corrigé en toute discrétion cette faille et aurait-il fait passer une mise à jour silencieuse ? Il semble que cela soit effectivement le cas. Google, ses partenaires et différents opérateurs auraient été prévenus dès la fin du mois de juin, mais seul Google pour ses modèles récents et quelques opérateurs pour quelques modèles très précis auraient effectivement appliqué un patch de sécurité. Les autres combinés étant sujets aux aléas de la qualité des protections implémentés dans les surcouches constructeurs et opérateurs. En tout état de cause, les téléphone équipés de ROM stock ou custom (Rom Cyanogen et compagnie) semblent touchés par le problème.

En tout état de cause, il ne faut pas trop s’attendre à recevoir Over The Air une mise à jour pour un combiné Android qui a plus de 6 mois ou 1 an. Combien cela coûterait aux opérateurs de mettre à disposition des mises à jours de sécurité pour des centaines de modèles qui sont pour la plupart arrivés en fin de vie commerciale ? Nos chers opérateurs doivent-ils d’ailleurs prévoir de tels plans catastrophe ? Qui s’engage à sécuriser votre combiné ? J’aurais malheureusement tendance à dire personne à part vous-même: Soyez vigilant face aux alertes de sécurités concernant les systèmes mobiles:

  • Tenez votre système ainsi que vous applications à jour
  • Utilisez un navigateur updatable
  • Evitez l’usage du navigateur système
  • Utilisez à la place un navigateur updatable, tel que Google Chrome.

Les informations critiques relatives à votre vie privée et professionnelles sont toutes accessibles depuis votre combiné mobile ou même tout simplement stockées dans votre téléphone, il est donc impératif d’être vigilant quant à la sécurisation des données nomades. Preuve, s’il en faut, la mésaventure arrivée au mois d’août dernier à Mat Honan, journaliste du magazine Wired qui a vu sa vi digitale effacée en un claquement de doigt (ici et ).

Cette faille de sécurité met en lumière toute la problématique de la fragmentation du système Android, et c’est Apple qui doit se frotter les mains cette semaine après avoir subit les railleries la semaine dernière lors du lancement de sa nouvelle application Map.

Android, retour d’impressions

Android, retour d’impressions

Après quelques semaines d’utilisation, je commence à me faire une idée des capacités de la plateforme et de ses qualités ert défauts! Et il y a de quoi parler, à commencer par l’émulateur. Ce dernier m’a semblé de prime abord de très bonne facture, mais il s’impose vite la conclusion suivante: l’émulateur propose des performances catastrophiques! Le PC sur lequel je développe est un portable Athlon XP 3000+, ok il n’est pas tout neuf, mais cela reste honorable, étant donnée que l’ordinateur dispose de 1,5Go de RAM et d’un disque 5400 tpm, les performances restent donc correctes. Cependant, dès que l’émulateur est lancé, le pourcentage d’utilisation CPU monte à 95 % très facilement et le pc ne répond pas vraiment bien (C’est le moins qu’on puisse dire) . Ce qui me trouble le plus reste les performances des programmes exécutés sur l’émulateur. Je ne suis pas arrivé à des performances correctes sans faire des concessions importantes sur le design applicatif et encore avec difficulté.

Je comprend l’angoument autour de la plateforme, mais également pourquoi on voit si peu de programmes disponibles (Je ne pense pas que ce soit lié au concour Android de Google uniquement). La source du problème n’est pas tant dans la plateforme que dans les performances de l’émulateur qui ont de quoi dégouter du développement sur Android et pousser à explorer les progrès fait sur J2ME et les JVM MIDP de Sony et Nokia qui semblent d’ailleurs très intéressant.

Même si les constructeurs proposent des machines performantes, il va falloir que Google fasse un effort sur son émulateur pour proposer des performances acceptables sur son émulateur. Dans le cas contraire, il se pourrait que certains développeurs soient rebutés. Pour l’instant j’en fait parti.

Autre bémol et de taille: c’est l’obscurantisme des API de la plateforme et le peu d’explications qu’on peut trouver. On est bien trop amené à essayer de deviner comment utiliser les API.  Les API étant complètement nouvelles, elles obligent le développeur à un apprentissage nouveau. De plus les API sont complexes et accrobatiques à utiliser. Souvent élégantes dans le concept, il faut tout de même avoir de bonnes notions de développement pour les exploiter correctement.

j’appuye cette petit analyse sur un retour d’expérience réel , j’ai essayé d’exploiter des API REST simples et cela me pose trop de difficultés pour en rendre le développement sympathique: j’ai plus tendance à m’arracher les cheveux entre la complexité des API et les performances de l’émulateur.

Gageons que la plateforme est encore jeune, et des best practices Android simples et efficaces  apparaitrons, mais pour le moment ce n’est pas la panacé. Et un travail urgent est à faire sur les performances de l’émulateur. Pour am part, le constat est simple: j’arrêtele développement Android ou bien j’achète un nouveau PC…

Un dernier mot: Je suis en 1280 et l’émulateur prend une grande partie de mon écran! C’est quand même assez embêtant. Google est capable de penser des API complexe, mais pas à un détail aussi simple.

A noter: les JVM de Sony et de Nokia embarquent aujourd’hui tout un ensemble d’extensions intéressantes, sur lesquelles je reviendrais un autre fois, mais qui permettent de développer facilement aujourd’hui des applications intéressantes sans vraiment de difficultés particulières. Les problématiques d’antant n’existent plus vraiment sur MIDP aujourd’hui.

Depuis quelques jours, j’ai un W910 de Sony, et il faut dire que je suis impressionné par les progrès effectués et la diversité des API MIDP proposées (Sensor API, Content handler API, MMAPI, Bluetooth API, …). De plus, les JVM sony, par exemple, en sont à leur 8ème génération, ce qui en fait un choix de plateforme proposant de nombreux avantages (performances, stabilité, support d’API étendues, …) et un choix pour le moment bien plus sûr qu’Android.

Ma conclusion, est donc la suivante: comme de nombreuses personnes, je suis rentré dans le jeu des Buzz (IPhone /Android), mais rien ne vaut les valeurs sûres telles que MIDP ou le DotNet CF ou bien la plateforme de dev Symbian ou Palm. Attendons donc quelques mois que la plateforme Android murisse et que les premiers modèles sortent avant de trop en dire sur Android. N’oublions pas, entre autre, pour le moment qu’Android repose sur une plateforme Linux qui n’est compatible ni Symbian, ni Windows Mobile, ni Palm. Le marché est de ce fait extrêmement restreint. De la même manière que l’Iphone, le marché Android risque de rester une niche un certain temps. L’arrivée de l’IPhone et d’Android ne font que segmenter le marché et rendre la tâche plus difficile pour les sociétés travaillant dans le domaine de la mobilité. Il existe au bas mot 6 plateformes importantes: Midp, Windows Mobile, Symbian, Palm, l’IPhone et Android!

N’hésitez pas à faire part de vos impressions!

Nouvelle version du plugin maven-android-plugin

Nouvelle version du plugin maven-android-plugin

Pour rappel: le plugin maven ‘maven-android-plugin‘ propose ue intégration des outils Android avec Maven.

Après une courte utilisation du plugin en mode multi-modules, j’ai repéré un petit problème d’utilisation lorsque les commandes maven sont lancées depuis un projet parent. Ce problème hélas rendait très gênant l’utilisation en mode multi-module de maven. L’auteur a heuresement apporté les corrections nécessaire et le plugin est donc maintenant utilisable en mode multi-modules. Je conseille donc à tout le monde de l’essayer. Il a beau être dans la sandbox des plugins maven j’espère bien qu’il sera supporté à terme pour sortir de la sandbox et fournir un support complet Maven pour Android.

A noter: L’auteur du plugin indique uniquement le chemin du projet en utilisant un lien vers ViewVC, mais pour l’installer il faut bien le checkouter depuis un client subversion, puis l’installer en tapant la commande Maven: ‘mvn install‘. Cette URL est hélas visible nul part…

L’url svn du plugin est la suivante:

http://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-android

Android et Eclipse: Choisir le bon plugin Maven

Android et Eclipse: Choisir le bon plugin Maven

Android est de prime abord un framework qui propose tout le nécessaire pour avoir une intégration avec les outils de développement traditionnels. Google propose, en effet, une intégration avec Eclipse via un plugin plutôt bien fait, et une intégration avec Ant.

Mais qu’en est-il de l’intégration d’Android avec Maven ? Un billet de ce blog en fait déjà mention (‘Android + Maven, C’est déjà possible‘) : Shane Isbell a développé tout l’outillage maven nécessaire à cela.

Cependant l’intégration ‘Android + Maven’ avec Eclipse ne se rélève pas aisée pour autant et pour cause: le packaging maven est spécifique (Génération de fichiers Dex), des builders spécifiques existent pour eclipse, etc.

Pour avoir essayé plusieurs plugins d’intégration de Maven avec Eclipse et Android, j’ai peux conclure que tous ne sont pas adaptés!

Et en particulier Q4E qui présente de nombreuses lacunes. Je vous conseille donc d’essayer soit le plugin maven : maven-eclipse-plugin, qui propose une génération des fichiers nécessaires à Eclipse ou bien m2eclipse qui dans l’ensemble semble bien fonctionner si ce n’est la nécessité de supprimer la référence vers le JRE par défaut d’Eclipse inclus dans le classpath généré. Maven-eclipse-plugin posera plus de difficultés étant donné qu’il ne propose pas la génération de classpath avec un packaging spécial (android:dex) ce qui est au final très embêtant puisqu’il faut le confectionner soit même alors que c’est un des buts premier du plugin … De plus il est nécessaire d’ajouter les builder complémentaires à la main dans la configuration du plugin.

Première contributions et démos intéressantes pour Android

Première contributions et démos intéressantes pour Android

Une première application complète et fonctionnelle est sortie ce soir, il s’agit d’une application exploitant le système de micro-bloging ultra connu. Cerise sur le gâteau le code source de l’application est disponible sur le site de l’auteur!


twitter.jpg

Ce qui m’étonne le plus dans l’affaire, c’est qu’en regardant le code source de plus près, on s’aperçoit que le gentil développeur manie parfaitement le framework et ses concept malgré la quasi-existence d’exemple et de bonne pratique sur le web. Qui plus est il utilise même des fonctions qui ne sont pas documenté!Pas mal non?

Je fais référence à l’object RequestQueue qui traite les requêtes HTTP à haut niveau! Cette classe se trouve dans le package android.net.http.

On note bien l’absence totale de documentation sur ce package, de plus une petite recherche sur Google montre bien une absence totale de documentation de cette classe sur le Web!

En faisant un tour sur le blog de l’auteur pour récupérer les sources et lire le code, je m’aperçois qu’il à posté d’autres exemples pour le moins étonnant également, vu le peu d’info sur le net!

En cherchant un peu d’infos sur l’auteur on se rend compte assez rapidement que ce n’est pas n’importe qui puisque c’est le co-fondateur (Davanum Srinivas) de la société WSO2. Toute personne qui s’y connaît un tant soi peu en stack web service Java, aura compris qu’il s’agit de la société qui s’occupe des développements d’Axis (entre autre). D’un coup on comprend mieux! (Désolé, j’utilise la stack XFire ou plutôt CXF maintenant).

Châpeau bas pour ces contributions!

Android sans Java … Ok, mais à quoi bon?

Android sans Java … Ok, mais à quoi bon?

Le lien d’une news qui me fait tiquer:

Et vous, qu’en pensez-vous? Trouvez-vous cela bien intéressant ?

Pour ma part, je ne comprends pas vraiment l’intérêt de la chose… Développer un programme C ou installer un package pour un système Linux: ok, je comprends bien (Et cela reviendra au constructeur du téléphone de le permettre ou non), mais tenter de se passer d’un framework sur un système qui est spécialement fourni comme support de base de ce framework, franchement je ne comprends pas vraiment bien la chose.

Un support d’accès natif est toutefois prévu, mais dans l’optique d’étendre les possibilités d’une application Android par exemple, via des appels système, et non  pour installer des outils tiers, à moins que cela apporte un avantage direct. Mais là encore, c’est au constructeur de définir le périmètre des fonctionnalités qu’il souhaite mettre à disposition dans son matériel.

De plus, Google a déjà incorporé un outil similaire à BusyBox dans son émulateur et sa plateforme en général qui est ToolBox! Il serait intéressant de connaitre la vision de Google à ce sujet: Linux est-il uniquement un support pour Android, ou bien est-ce un système destiné à être extensible par n’importe qui!

Un premier essai avec Android ( UI + XML + HTTP )

Un premier essai avec Android ( UI + XML + HTTP )

Je me suis essayé à développer une application test pour mieux cerner les capacités de la plateforme.

Il se révèle plutôt simple de développer avec Android, mais le manque d’exemple fait cruellement défaut. Cependant, on peut rapidement se débrouiller et trouver des solutions…

Je me suis donc amusé à charger un document XML d’un site internet bien connu des parisiens, et je l’ai affiché sous forme d’une liste. En voici le résultat:

Velib_android.jpg

Ressources Android sur le Web. Ca s’organise …

Ressources Android sur le Web. Ca s’organise …

Afin de compléter un peu la liste des ressources que j’ai pu trouver sur Internet à propos d’Android, je vous propose de nouvelles :

Le point commun de ces différents sites est la langue, ils sont tous 3 anglophones. Les sites anglophones ont tendance à fleurir souvent bien plus vite, cependant PointGPhone (http://www.pointgphone.com) est un site francophone qui semble plutôt bien fait, je vous conseille donc d’aller y faire un tour si l’anglais vous donne mal à la tête ! Le site présenté sous forme de blog fait une assez bonne synthèse des infos à propos d’Android. Il semble déjà avoir un lectorat régulier. Cerise sur le gâteau, il a design agréable et moderne.

PointGPhone.jpg

La blogosphère, Internet et Android

La blogosphère, Internet et Android

Je suis parti à la recherche des site intéressants (Blog et autre) sur Android. Pour l’instant la pêche n’a pas donné grand chose à part un site qui peut se révéler intéressant s’il est suivi, puisqu’il se nomme : http://www.androidfrance.com .

J’imagine qu’il se veut sérieux s’il se nomme ainsi, on verra avec le temps!

Edit: Je suis tombé sur un autre site sur Android mais Anglophone cette fois: http://androidwiki.com/, qui se veut être comme son nom l’indique un Wiki sur Android. Je trouve que ça fait un peu double emploi pour le moment avec le site officiel, mais pourquoi pas!

Edit 2: Encore un site intéressant sur lequel je viens de tomber: http://www.android-freeware.org , le site répertorie les différentes applications existant pour Android.