Home.

Bienvenue sur le site personnel de Christophe Beyls.
Voici les derniers articles publiés, toutes sections confondues.

FOSDEM Companion pour Android

Android

Comme chaque année, je me suis rendu début février à la plus grande conférence internationale du logiciel libre: le FOSDEM. Nous avons la chance de pouvoir accueillir cet événement entièrement bénévole dans la ville de Bruxelles, au sein de l’ULB. Pour cette année 2014, j’ai voulu apporter ma pierre à l‘édifice en créant une nouvelle application Android dédiée: FOSDEM Companion.

Il existait déjà une application Android co-créée par 3 développeurs pour l‘édition 2010, qui a su rendre bien des services au fil des ans. En 2013, l’interface a même été améliorée par un autre développeur qui y a ajouté une Action Bar. Pour cette année 2014, j’ai d’abord envisagé de créer un fork (= une version dérivée) de l’application existante dont le code est public, puis j’ai finalement décidé de repartir de zéro sur de nouvelles bases au lieu du code d’il y a 4 ans, pour recréer une expérience similaire mais améliorée avec les dernières techniques de programmation sur Android. Et bien entendu, j’ai également publié le code source de cette nouvelle application sous une licence libre afin que tout le monde puisse en profiter. Celui-ci est disponible sur GitHub.

Mes deux objectifs principaux pour la réalisation de cette nouvelle application étaient l’amélioration des performances ainsi qu’une meilleure ergonomie et un aspect visuel épuré. Je voulais également rendre le code plus modulaire afin de pouvoir plus facilement l’adapter à l’avenir.

En dehors du remaniement de l’interface et de la navigation, j’ai également ajouté quelques fonctions par rapport à l’application précédente:




En plus d’une publication sur le Play Store de Google, j’ai mis à disposition l’application sur F-Droid, le store alternatif contenant uniquement des logiciels libres compilés à partir des sources officielles par le serveur de F-Droid. Ceci garantit à l’utilisateur que l’application qu’il installe sur son appareil correspond bien au code source publié.

FOSDEM Companion a connu un énorme succès durant le week-end du FOSDEM 2014 et a été installé sur environ 2000 appareils à partir du Play Store, sans compter les téléchargements à partir de F-Droid. Lorsque je me suis rendu sur place, je pouvais voir en permanence des gens autour de moi l’utiliser, ce qui m’a vraiment impressionné car je ne m’attendais pas à une telle popularité. Les organisateurs du FOSDEM ont eu la gentillesse de me donner la permission d’utiliser leur nom et leur logo, et m’ont offert un superbe t-shirt de l‘événement. En tous cas, je suis très content d’avoir pu améliorer l’expérience FOSDEM pour les nombreux visiteurs venus des 4 coins du globe et je reviendrai bien entendu l’année prochaine.

Phonebloks: restons réalistes!

Téléphonie

Voilà quelques semaines que les gens font tout un foin sur internet à propos de Phonebloks, un concept de smartphone modulaire créé par Dave Hakkens, un designer hollandais. Le buzz s’est encore accentué dernièrement lorsque Motorola a annoncé son partenariat avec Phonebloks pour le lancement de sa plate-forme expérimentale Ara.

Le concept de téléphone modulaire et extensible n’est pas nouveau: citons par exemple la firme Modu qui a créé en 2009-2010 deux mini téléphones capables d‘être intégrés dans différents boîtiers afin de modifier leurs capacités: un boîtier appareil photo, un boîtier audio hi-fi ou un boîtier avec clavier complet par exemple. Bien entendu les ambitions de Modu étaient plus modestes que celles du concept Phonebloks.

Seulement voilà, entre le concept naïf de la première vidéo de Phonebloks ci-dessus et la réalité physique qui nous entoure, il y a un monde de différences et de contraintes techniques que le grand public n’a pas forcément saisi. Analysons cela en détail de façon pragmatique pour mieux comprendre ce qu’on est vraiment en droit d’attendre d’un tel projet.

L’idée de départ de la vidéo est la suivante: un smartphone où chaque composant est séparé permettrait en théorie de remplacer uniquement le composant ancien ou défectueux, ce qui coûtera moins cher et limitera le gaspillage.

Sauf que dans la réalité, les smartphones d’aujourd’hui existent grâce à leur non modularité: ils sont hautement intégrés et c’est ce qui leur permet d‘être à la fois compacts, légers, peu gourmands en énergie et bon marché.

Toutes les fonctions de base d’un téléphone moderne se trouvent sur une unique puce appelée SoC (System on Chip): microprocesseur central, puce graphique, WiFi, GPS, Bluetooth. Certains SoCs intègrent même le modem GSM. Ceci réduit la complexité de fabrication et les coûts. Les autres composants sont ensuite branchés sur le SoC. Au final, le composant le plus volumineux à l’intérieur d’un smartphone récent demeure la batterie. Ci-dessous, l’intérieur d’un Samsung Galaxy S4 pour illustrer cela.

Les entrailles du Samsung Galaxy S4

Le fait de scinder les différents composants du SoC pour en faire des blocs séparés rendrait les téléphones plus chers et plus volumineux, sans parler du fait que la distance accrue entre ces composants principaux (par exemple entre le CPU et le GPU) augmenterait la consommation énergétique tout en détériorant les performances. Pour transposer ces contraintes réelles dans le monde de Phonebloks, on devrait toujours avoir un “bloc” de base qui contiendrait un SoC, ce qui limiterait déjà beaucoup la modularité par rapport à ce qu’on voit dans la vidéo.

De plus, dans le but de pouvoir remplacer le SoC il faudrait créer un système de connecteur ou “socket” similaire à celui qui permet d’accueillir un CPU sur une carte mère de PC. Ceci contribuerait aussi à l’augmentation du volume et du prix par rapport à un téléphone non modulaire.

Pour le reste, les composants suivants devraient pouvoir être interchangeables sans trop d’efforts, mais toujours avec le même problème potentiel de volume gaspillé entraînant une augmentation de la taille de l’appareil:

Et c’est à peu près tout. Pour moi le fait de pouvoir remplacer l‘écran facilement serait vraiment l’atout principal d’un téléphone modulaire car c’est typiquement la pièce qui casse le plus souvent lors d’une chute et qui est pénible à remplacer.

En résumé, ce qu’il serait possible d’obtenir serait un téléphone modulaire mais pas trop, relativement volumineux et plus cher que la moyenne. Ce coût plus élevé doit être mis en perspective avec la durée de vie plus longue de l’appareil mais aussi avec le coût des modules de remplacement au fil du temps. L’offre a intérêt à être vraiment bien étudiée si elle veut tenter de séduire les consommateurs habitués à des modèles toujours plus puissants, toujours plus compacts, toujours moins chers.

Je n’ai fait qu’effleurer la surface des contraintes matérielles, mais de tels téléphones présenteraient aussi de gros problèmes logiciels à résoudre. En effet, pour que tout cela fonctionne, il faudrait que le système d’exploitation soit capable de reconnaître tous les modules. Pour cela il n’y a que 2 solutions:

Pour créer des téléphones conçus pour durer, il faudrait déjà que les constructeurs commencent par s’engager à fournir des mises à jour logicielles du système d’exploitation de leurs appareils mobiles pendant une durée minimale convenable, par exemple 3 ans comme les derniers iPhone d’Apple. Google vient de faire le contraire en annonçant qu’il ne garantissait la mise à jour logicielle des appareils Nexus que sur une période de 18 mois, ce qui est d’autant plus dommage qu’ils ont annoncé en même temps avoir réduit la consommation de mémoire de la dernière version de leur système d’exploitation Android afin qu’elle fonctionne de façon fluide sur des appareils aux spécifications techniques plus modestes.

En réalité, Google ne veut pas inciter les constructeurs à supporter le matériel plus ancien, il veut simplement inciter les constructeurs à utiliser systématiquement la dernière version d’Android sur tous leurs nouveaux appareils, y compris en entrée de gamme. Les constructeurs, eux, veulent constamment créer de nouvelles générations d’appareils et les vendre pour générer des revenus, et non supporter les anciens modèles. Ceci est en contradiction avec le concept d’un téléphone à longue durée de vie comme Phonebloks.

Pour que cela change il faut que nous, consommateurs, leur fassions comprendre que nous voulons acheter un appareil pas uniquement pour ce qu’il est au jour de l’achat, mais également pour une garantie de support et de mises à jour logicielles sur une longue durée, même si cela implique peut-être d’y investir un peu plus d’argent à l’achat. Certains constructeurs automobiles ont bâti leur réputation sur des garanties longue durée, pourquoi ne pas faire pareil dans le monde des smartphones avec des garanties longue durée de réparation et de mises à jour logicielles? Je pense que ce serait déjà un premier pas modeste mais efficace vers la réduction de l’obsolescence programmée et du gaspillage dans le monde des smartphones.

Ce qui est certain c’est que si une plate-forme de smartphones modulaires voit le jour, elle a intérêt à être supportée sur une très longue durée pour avoir une quelconque utilité, et cela seul le temps nous le dira.

Mise à jour (04/03/2014): Je me dois d‘éditer cet article pour y apporter une note plus positive suite à de nouvelles informations. Le responsable du projet Ara de Motorola, qui appartient désormais à Google, a fait une démonstration de leur prototype de téléphone modulaire à la conférence “Launch” et je dois reconnaître que le résultat était plutôt convaincant. Grâce à un système d’endosquelette compact à connecteurs électro-aimantés, le surplus de volume du téléphone est limité à environ 20%, ce qui reste très raisonnable. Les prix pour les modules de base s’annoncent également démocratiques ce qui est une autre bonne nouvelle. Les modules présentés étaient les suivants: l‘écran, le SoC, la radio (antenne et module GSM/WiFi), la batterie, l’appareil photo (arrière ou avant), les haut-parleurs. La modularité reste limitée comme je m’y attendais mais offre néanmoins des possibilités intéressantes. Les modules suivront un standard ouvert et pourront être créés par tous, ce qui pourrait permettre à cette technologie de vraiment décoller grâce à la valeur ajoutée de modules spécialisés créés par des sociétés indépendantes et compatibles avec un grand nombre d’appareils. Je publierai un nouvel article fin avril après la publication du SDK pour modules afin de vous en dire plus.

La double nature d'Android

Android

Suite à la parution d’un article très populaire sur le site Ars Technica, intitulé Google’s iron grip on Android: Controlling open source by any means necessary, j’ai souhaité réagir pour apporter une version un peu plus nuancée du bilan qui y est fait. Si les éléments détaillés dans l’article sont globalement exacts, j’ai trouvé qu’il tirait des conclusions un peu hâtives et souvent trop pessimistes sur les intentions de Google ou qu’il manquait d’informations sur certains points.

L’article conclut dans les grandes lignes que Google tue à petit feu le projet AOSP (le code source public d’Android) et reprend le contrôle de sa plate-forme en la rendant partiellement propriétaire, faisant au passage un pied-de-nez aux constructeurs. Certains ont même osé commenter sur Twitter: “Ne soyez pas naïfs, Android ne restera pas ouvert” !

Pour nuancer ces propos il est nécessaire d’expliquer comment les différents composants d’Android interagissent entre eux et de faire un petit bilan de la plate-forme à l’heure actuelle.

Une formule gagnante depuis le début

Android est un système qui possède une double nature depuis la première version publique parue en 2008, et les choses n’ont quasiment pas changé depuis.

Il convient en effet de distinguer le système Android de base et les services de Google. La base du système est intégralement “open source” (et fait partie d’AOSP) tandis que les services de Google ne le sont pas. Le système est également conçu depuis le départ pour être très modulaire et les services de Google sont des “modules” de plus haut niveau qui viennent compléter le reste mais ne sont pas indispensables au fonctionnement du système, même s’ils sont souvent d’une grande utilité et ont contribué au succès de la plate-forme.

L’article tend à mettre en opposition AOSP et Android avec les services Google comme s’il s’agissait de deux variantes incompatibles d’Android alors que tous les appareils Android ont la même base open source (AOSP), la différence étant que certains disposent des services de Google et d’autres pas (comme le Kindle d’Amazon ou BlackBerry 10).

Les modules propriétaires de Google pour Android correspondent quasiment toujours à des services fournis par leurs infrastructures. À l’exception de PhotoSphere et de la fonction “swype” du clavier Google qui utilisent des technologies propriétaires brevetées, les fonctionnalités qui ne sont pas liées directement aux serveurs de Google sont toujours open source.

Les services Google propriétaires

Les principaux services et applications fournis par Google pour Android sont les suivants:

Il existe bien entendu d’autres applications Google qui contribuent au succès d’Android telles que Google Traduction, Goggles ou leur jeu de réalité augmentée Ingress.

Tous les services cités ci-dessus peuvent ne pas être installés ou être remplacés par des alternatives. Il existe des marchés d’applications alternatifs, des services de cartographie alternatifs, des sites de vidéo alternatifs, des services de synchronisation de contacts alternatifs, etc. Ceux de Google sont évidemment de très bonne qualité et gratuits, raison pour laquelle tout le monde les utilise, mais s’il fallait un jour s’en passer complètement pour une raison ou une autre, l’architecture du système Android s’y prêterait parfaitement: on ne peut donc pas déclarer que le système a été verrouillé par Google pour ne fonctionner qu’avec ses services.

Un bon exemple d’une plate-forme Android complète et fonctionnelle n’utilisant pas les services Google sont les ROMs Cyanogenmod disponibles “prêtes à l’emploi” pour de nombreux téléphones Android et construites entièrement à partir de code source non propriétaire (à l’exception des pilotes matériels). Les logiciels propriétaires Google sont ensuite installables séparément via une simple opération, mais ce n’est pas obligatoire.

Des logiciels AOSP abandonnés

L’article explique également de façon un peu alarmiste que dès qu’un logiciel dans AOSP fait double emploi avec un nouveau logiciel propriétaire de Google, le développement du logiciel AOSP est abandonné. Les composants en question sont les suivants:

L’article sous-entend que si la version AOSP de ces logiciels est abandonnée, les logiciels propriétaires de Google deviendront la référence et donc Google aura un contrôle accru sur la plate-forme. Ceci est faux pour deux raisons:

1) Depuis tout temps, ces logiciels ont déjà été remplacés par les constructeurs sur leurs téléphones: Samsung, Sony ou HTC fournissent déjà leur propre lecteur audio, leur propre calendrier, leur propre lanceur ou leur propre application SMS, qui sont souvent fort différents de la version AOSP. La plupart des utilisateurs continuent à utiliser ces logiciels de base du constructeur et le fait que Google fournisse de nouvelles alternatives ne changera rien ni pour eux ni pour les constructeurs qui ont quand même déjà développé leurs propres solutions pour tenter de se distinguer.

2) Il existe un nombre incalculable d’applications alternatives gratuites de qualité à tous ces composants, parmi lesquelles certaines sont open source. Toutes ou presque sont plus évoluées que les applications AOSP qu’elles remplacent. Voici quelques exemples marquants:

En plus de cela, Google continue à faire évoluer certaines applications AOSP parallèlement aux siennes, donc on ne peut pas dire que toutes les applications de cette liste aient été réellement abandonnées.

Services Google Play

Les services Google Play sont apparus en mai 2013 en tant qu’extension Google qui s’installe et se met à jour automatiquement sur tous les appareils disposant du Play Store à partir d’Android 2.2. Ils permettent aux développeurs d’utiliser la dernière version des services Google dans leurs applications, à savoir principalement les cartes Google Maps. Jusqu’ici rien d’anormal: si les développeurs souhaitent utiliser un autre fournisseur de cartes, rien ne les empêche d’utiliser un SDK concurrent aux services Google Play.

Mais Google est allé encore plus loin en intégrant une nouvelle couche de géolocalisation et geofencing dans les services Google Play. En réalité, il s’agit d’une surcouche sur les APIs de géolocalisation de base d’Android, qui permet d’optimiser l’usage de la batterie et augmenter la rapidité de la géolocalisation ainsi que fournir un meilleur service de geofencing, à condition que les applications tierces passent par ce service propriétaire.

Il faut reconnaître que sur ce point le choix des développeurs est cornélien: s’ils veulent offrir la meilleure expérience de géolocalisation à leurs utilisateurs, ils n’ont pas vraiment d’autre alternative que d’utiliser les services Google Play, qui en plus sont gracieusement auto-installés sur les téléphones même les plus anciens grâce au système de déploiement de Google. Google pourrait mettre à disposition le code source de cette nouvelle couche de géolocalisation, mais elle ne pourrait pas être auto installée et mise à jour via le Play Store, ce qui reste son atout principal.

Même sans les services Google Play, une application ne pourrait pas faire grand chose sans les services de base de géolocalisation via antennes WiFi et GSM, services qui ne sont pas non plus open source car ils utilisent les bases de données de Google. Sur ce point, la fondation Mozilla a annoncé récemment qu’elle travaillait sur un système de géolocalisation similaire, basé sur des données publiques. On peut imaginer la sortie d’un SDK pour Android à l’avenir permettant d’exploiter ce nouveau service.

Les services Google Play offrent également la possibilité aux développeurs de jeux de sauvegarder la progression des joueurs afin de la synchroniser entre leurs différents appareils, en utilisant gratuitement les infrastructures de Google. Cette fonction ne pourrait évidemment pas non plus être open source, mais rien n’empêche les développeurs d’utiliser leur propre solution de synchronisation à la place.

Toujours plus d’open source

Google pousse sa plate-forme et ses services au maximum sur Android, c’est certain. Cela signifie-t-il pour autant qu’Android se ferme? Je ne pense pas. Parallèlement à ses solutions propriétaires, Google a également publié cette année une grande quantité de code open source. En voici quelques exemples:

Dans l’ensemble, la communauté Open Source autour d’Android se porte plutôt bien, c’est même l’une des communautés de développeurs les plus actives que je connaisse. Rappelons qu’aujourd’hui, grâce à ce projet et à sa nature ouverte, il est possible de faire fonctionner des applications sur une énorme quantité d’appareils de types, tailles et marques variées ou encore d’installer la dernière version d’un système d’exploitation sur des appareils abandonnés par leurs constructeurs, des choses qu’on n’aurait pas pu imaginer il y a à peine 6 ans. Et visiblement ce n’est pas prêt de changer!

Sortez vos poubelles avec Google Calendar

Android

Petite astuce du quotidien en vidéo: comment utiliser Google Calendar comme pense-bête pour les gestes du quotidien.