Alors que l’on attendait une version 5 d’Android, Google a surpris tout le monde en annonçant une version 4.4, qualifiée donc de « version mineure ». Mineure car elle apporte peu de changement « visible » pour le grand public et est donc plus difficile à « marketer ». Pourtant sous le capot, on constate un grand nombre d’évolutions importantes que je vais tenter de vous résumer dans cet article.
NFC : Host Card Emulation
Jusqu’à la version 4.3, le support NFC sur les téléphones Android est limité à une fonction de lecture de tags NFC. Ceci permet par exemple de déclencher des actions sur le téléphone en l’approchant d’un tag NFC.
Nous avons d’ailleurs réalisé plusieurs POC à ce sujet avec un grand groupe pharmaceutique français qui étudie actuellement la mise en place de tags NFC dans ses emballages.
Avec KitKat, il sera désormais possible d’émuler un tag NFC avec son téléphone. Cette nouvelle capacité va permettre de dématérialiser un grand nombre de cartes que nous possédons tous : carte de fidélité, carte de transport, et pourquoi pas à terme carte de paiement… Il suffira alors de rapprocher son téléphone NFC d’un lecteur, au lieu de fouiller dans son portefeuille.
Quand on voit le succès rencontré par Passbook qui permet de regrouper des cartes, des tickets, des bons de réduction avec une technologie de code barres ou qrcode, on peut imaginer ce que sera demain l’engouement du « sans-contact ».
Low-power Sensors
Android KitKat introduit un nouveau mode de gestion des capteurs du téléphone (accéléromètre, détecteur de positions, de pression, température etc..) : les événements peuvent désormais être traités par lots, on parle de « sensor batching ». En fonction des besoins, les applications peuvent être notifiées à un intervalle choisi avec un ensemble de données provenant des capteurs. Jusqu’à présent, chaque événement devait être traité par les applications d’une manière unitaire.
Cerise sur le gâteau, cette optimisation est faite au niveau hardware. Concrètement cela veut dire que les applications pourront continuer à « tracker » les événements des différents capteurs même lorsque le téléphone est éteint ou en veille, ce qui a pour effet de réduire drastiquement la consommation de batterie. (ex : une application de randonnée qui enregistre le trajet n’a plus besoin d’être active pendant la randonnée, il suffira de traiter à posteriori les données de position à la fin du parcours.)
Cette fonctionnalité, combinée à de nouvelles puces permettant de détecter les pas, vient se placer en concurrence directe des dispositifs embarqués (ex: les podomètres dans les chaussures.)
Évolution de la WebView
La WebView bénéficie enfin du même moteur que Chrome Android : Chromium ! Une bonne nouvelle qui devrait sans conteste améliorer les performances des applications dites « hybrides » qui embarquent une WebView pour gérer la partie vue.
Ce changement amène un meilleur support des standard HTML5, CSS3 et Javascript avec notamment le support attendu des websockets et des web workers.
Enfin, une nouveauté et non des moindres, est que l’on peut debugger une WebView directement dans Chrome sur le poste du développeur via les Chrome Developer Tools.
Un “vrai” plein écran : Immersive mode
Depuis KitKat les applications peuvent profiter du moindre pixel disponible avec un vrai mode plein écran. Il est désormais possible de cacher entièrement et de façon permanente la « status bar » et la « navigation bar ». Précédemment, cacher la navigation bar n’était possible que jusqu’à ce que l’utilisateur touche l’écran. (utilisé notamment dans les players video).
Dans ce nouveau mode, les applications peuvent capturer les événements de « touch » n’importe où sur l’écran, y compris sur les emplacements habituels des barres. Pour faire réapparaître les barres (qui sont en partie transparentes dans ce mode) par dessus le contenu, un nouveau geste a été introduit : un swipe de haut en bas en partant de l’extérieur du téléphone.
Préparer l’avenir
Les ingénieurs Google prépare l’avenir en proposant une preview de ce que pourrait être la nouvelle machine virtuelle qui sera amenée à remplacer Dalvik : ART (Android Runtime)
Alors qu’aujourd’hui le bytecode des applications est transformé en instructions natives à chacune de leurs exécutions (via un compilateur Just-In-Time), avec ART il est pré-compilé une bonne fois pour toute à l’installation (on parle de compilation Ahed-Of-Time).
Au prix d’un temps d’installation plus long, et d’un poids des applications de 10 à 20% plus lourd, il est donc possible d’améliorer les performances à l’exécution tout en économisant de la batterie.
Il est d’ors et déjà possible d’activer ART dans les “Options pour les développeurs” et les retours sont dans l’ensemble assez prometteurs.
Google travaillerait en secret sur ce projet depuis plus de 2 ans, certains avancent même que les poursuites d’Oracle à propos de brevets portant sur la machine virtuelle Dalvik pourraient avoir menées à l’émergence de ce projet.
Un seul mot d’ordre : performance
Un gros travail d’optimisation a eu lieu pour réduire l’utilisation de la mémoire et permettre à des devices peu puissants (512MB de RAM) de faire tourner KitKat. De nouvelles APIs sont désormais disponibles pour détecter ce genre de device (ActivityManager.isLowRamDevice).
Les composants majeurs ont été réécris, le système est plus agressif envers les applications qui consomment le plus, les services sont lancés en petit groupe et en série si le besoin s’en fait sentir.
On peut donc espérer de la part des constructeurs de téléphone, ou à défaut de la communauté, un déploiement de KitKat sur un plus large panel de device que les versions précédentes.
Pour le développeur, cela veut dire qu’il est de plus en plus primordial de s’orienter vers une approche « responsive » des applications, non seulement au niveau de l’affichage (tablette vs téléphone) mais surtout aussi au niveau de leurs fonctionnements et de leurs possibilités.
Ceci afin de tendre vers le but suprême : proposer des applications responsives, fluides et adaptées quelque soit le matériel sur lequel elle sont déployées.