I/O : les développeurs dans le viseur de Google, qui multiplie les services
Vous êtes cernés
Le 18 mai 2017 à 14h42
16 min
Logiciel
Logiciel
Après une conférence d’ouverture particulièrement riche hier soir, nous avons décidé de faire le point sur les annonces touchant de plus près les développeurs. Nouveau Studio, Instant Apps, Firebase ou encore apprentissage profond étaient ainsi au programme.
On ne pourra pas dire que l’ouverture de la Google I/O manquait de contenu. L’entreprise a tiré dans toutes les directions, avec Android O et Go notamment, des améliorations sur Photos et de multiples services, en passant par l’arrivée de l’Assistant sur iOS et la TV.
Pour les développeurs, il y aura largement de quoi faire. La prochaine révision d’Android compte évidemment son lot de nouveautés, dont un mode spécifiquement taillé pour les appareils peu puissants, Android Go. Ajoutons tout ce qui touche à l'environnement Studio, à la suite d'outils Firebase, à l'intelligence artificielle ou encore aux Instant Apps, et on se retrouve avec une déferlante de nouveautés que les développeurs vont devoir absorber. Si tant est que ces apports les intéressent, car tous ne sont pas obligatoires, loin de là.
Android Studio 3.0 : d’importantes nouveautés et une première préversion
L’environnement de développement joue un rôle clé dans la création des applications pour Android. Ayant pris le relai d’Eclipse il y a plusieurs années, il est enrichi régulièrement, les derniers ajouts majeurs ayant été la modification en « live » de l’application après une retouche du code et des performances nettement améliorées pour l’émulateur.
La première préversion d’Android Studio 3.0 a donné hier soir les principales lignes d’amélioration. D’abord avec le support de Kotlin, un langage orienté objet, fonctionnel et à typage statique, que les développeurs peuvent utiliser pour compiler vers Java. Google indique que plusieurs éditeurs s’en servent déjà pour leurs applications, notamment Expedia, Flipboard, Pinterest et Square. Ils pourront soit créer un nouveau projet Kotlin, soit convertir un fichier Java existant.
Le support de Java 8 se renforce également avec la migration de la toolchain Jack vers celle basée sur javac. Si les développeurs passent les niveaux de Source et Cible à 1.8, ils pourront donc profiter de certaines fonctionnalités, notamment Instant Run.
La version 3.0 améliorera en outre l’un des derniers gros apports de l’environnement, à savoir le Layout Editor, qui doit simplifier la création des interfaces en calculant automatiquement bon nombre de placements. Le glisser/déposer des éléments est donc facilité, le panneau d’erreur a été remanié, et des objets supplémentaires sont pris en charge, en particulier les Barriers et les Groups.
Évolutions de la plateforme Android oblige, Android Studio 3.0 introduit un nouvel assistant pour concevoir des icones adaptives. Rappelons qu’Android O permet aux applications de présenter plusieurs icones, qui pourront varier selon le contexte, par exemple en fonction du Launcher. Les développeurs peuvent également, toujours en ciblant Android O, créer des ressources spécifiques pour les polices personnalisées, et les prévisualiser plus facilement.
Cette préversion ajoute en outre le support d’Android Things (objets connectés), d’IntelliJ 2017.1 et des Instant Apps, intègre le Play Store et le support d’OpenGL ES 3.0 dans l’émulateur, prend en charge les serveurs proxy, ajoute un nouvel outil pour générer des rapports de bugs, ou encore la capacité (très attendue par les développeurs) de pouvoir déboguer un APK externe, c’est-à-dire qui n’aurait pas été produit directement par Android Studio. Ajoutons l’Android Profiler, un outil spécifiquement dédié aux soucis de performances.
Android O : des nouveautés à prendre en compte… ou pas
Avec deux nouvelles versions du système mobile, il est clair que les développeurs vont avoir du pain sur la planche pour tirer parti des nouveautés ou pour s’adapter aux exigences spécifiques de chaque plateforme.
Android O comporte en fait deux volets de nouveautés, les premières étant purement fonctionnelles, les autres étant plutôt des conséquences d’améliorations mises en place. On retrouve donc les apports présentés hier soir, comme le mode Picture-In-Picture généralisé, l’arrivée des Notifications dots, l’intégration de l’API Autofill de Chrome dans Android, une sélection de texte plus intelligente (en utilisant l’apprentissage profond) ou encore la présence de TensorFlow Lite, sur lequel nous reviendrons.
Les développeurs vont devoir également prendre en compte certaines barrières mises en place par Android O sur les performances et la consommation de l’énergie. Outre tout ce qui touche aux optimisations internes sur l’exécution des applications et l’efficacité du ramasse-miettes, le système impose des limites au fonctionnement en arrière-plan. Les applications ne pourront plus abuser de la géolocalisation, du scanner Wi-Fi ou globalement de tout ce qui consommerait trop de ressources. L’idée générale est bien entendu d’augmenter l’autonomie des appareils mobiles.
Notez qu’Android O bénéficie depuis hier soir d’une Developer Preview 2, qui est en fait la première bêta du système mobile. Elle est compatible avec les Nexus 5X, 6P, et Player, ainsi que les Pixel, Pixel XL et Pixel C. Comme toujours, s’agissant d’une version non finale, on fera attention à ne l’installer que sur des appareils dont on n’a pas un besoin vital de fiabilité, puisque la bêta peut planter et entrainer des incompatibilités avec les applications.
Sur Android Go, les développeurs auront le choix
Enfin, Android Go est un cas à part. Il ne s’agit pas à proprement parler d’un nouveau système, mais d’une variante d’Android O à destination des appareils mobiles dont la puissance est limitée. L’objectif est de rationaliser l’expérience utilisateur, qui peut être profondément altérée avec la mouture classique, à cause du manque de performances. Android étant utilisé sur 2 milliards d’appareils, beaucoup tombent dans cette catégorie.
Android Go vise particulièrement les appareils munis de 1 Go de mémoire vive ou moins, et se veut donc plus léger. D’après Google, il peut être vu comme un mode spécifique d’Android O qui doit s’activer automatiquement selon la configuration. Toutes les applications Google fournies font également l’objet d’un travail en ce sens, notamment YouTube et Chrome. Par exemple, quand un mode basse consommation ou économie de données existe, il est systématiquement activé par défaut.
N’étant pas prévu avant 2018, les développeurs ont le temps de s’y faire. Cela étant, précisons tout de suite que les applications classiques pourront y fonctionner. Cependant, de la même manière que le Play Store signale celles prenant en charge Android Wear, celles ayant un mode « Go » seront mises en avant comme telles. Il n’y a donc pas de limitation sur le parc applicatif, mais on imagine que les utilisateurs risquent d’apprécier fortement les efforts qui pourront être faits par les éditeurs tiers.
Play Store : nouvelles métriques, gestion des clés et Protect
Côté développeurs, la boutique propose elle aussi une belle liste d’apports, dont certains étaient particulièrement attendus.
À commencer par un certain nombre de métriques, via l’ajout de nouveaux Android Vitals Dashboards dans la Play Console. Par exemple, un développeur pourra être informé si son application plante trop souvent, génère trop de réveils de l’appareil, si des animations se figent ou si le rendu global est trop lent. Ces panneaux indiquent combien d’utilisateurs sont affectés et fournissent des conseils sur la manière de remédier à ces problèmes.
L’un des plus gros changements introduits dans le Play Store est également optionnel : la gestion des clés de sécurité. Les développeurs ont besoin d’un certificat pour signer leurs applications et les présenter pour validation dans le Store. Mais puisque ces clés peuvent être perdues, Google propose désormais de gérer cette étape et de stocker les clés de son côté. SI tel est le cas, la firme pourra procéder à des optimisations supplémentaires dans le code, mais le développeur garde la main – pour l’instant en tout cas.
La boutique va devenir en outre plus proactive pour les utilisateurs sur la sécurité. Google, visiblement échaudé par les nombreux problèmes de sécurité autour de sa plateforme, n’avait ainsi pas hésité en mars dernier à reconnaitre que la moitié des appareils en circulation n’avait pas reçu la moindre mise à jour en ce sens sur l’année écoulée. Un constat dramatique, quand on sait à quel point la correction des failles est primordiale dans le domaine de la sécurité, comme l’a rappelé encore récemment le cas de WannaCrypt.
Après avoir communiqué plusieurs fois sur le travail fait en arrière-plan contre les applications malveillantes, Google introduit donc Play Protect. En dépit des apparences, il ne s’agit à proprement parler d’une nouveauté. Protect est davantage une mise en avant de fonctions existantes de sécurité, pour que l’utilisateur se rende mieux compte du travail effectué par Google. Par exemple, un message visible « Analyse de Play Protect » apparaît quand l’utilisateur veut installer une application.
La fonction est désormais intégrée directement dans l’application de la boutique et les utilisateurs n’ont donc rien à faire de particulier pour l’activer. Par ailleurs, Protect rassemble d’autres aspects de la sécurité, par exemple le repérage géolocalisé de son smartphone en cas de perte ou de vol. Une réunion bienvenue, puisque tous les utilisateurs ne sont pas nécessairement au courant que de telles capacités existent.
Les Instant Apps désormais disponibles pour tous les développeurs
Les Instant Apps ne sont en elles-mêmes pas neuves. Elles ont été introduites avec Nougat et se signalent par une forte modularité. De fait, quand une application ou une page web quelconque possède un lien vers un service quelconque, les éléments strictement nécessaires de l’application correspondante se chargent pour y effectuer l’action, plutôt que sur une page web mobile où l’expérience serait moins bonne. Point important, l’application ne s’installe pas.
Problème, les Instant Apps n’étaient accessibles que pour un nombre limité de partenaires. Ce n’est plus le cas désormais. N’importe quel développeur peut ainsi travailler son application pour la rendre compatible avec cette fonctionnalité. Ils auront par contre besoin d’Android Studio 3.0, disponible uniquement à travers une première préversion. Le SDK Instant Apps est également obligatoire.
Firebase : le plein de nouveautés
La plateforme applicative Firebase, que Google avait déjà nettement enrichi l’année dernière, revient une fois encore avec un certain nombre d’ajouts. On pouvait s’attendre ainsi à l’intégration de Fabric, racheté il y a quelques mois par Google à Twitter. Ce qui est désormais le cas.
Crashlytics, l’outil le plus important de Fabric, va ainsi non seulement débarquer dans Firebase, mais en devenir au passage le principal outil de signalement des bugs, même si l’éditeur ne dit pas exactement quand cette bascule se fera. Google récupère également Fabric Digits pour en faire Firebase Authentication, afin de fournir aux développeurs un service d’Authentication exploitable en l’état.
Évidemment, pas question de parler de Firebase sans aborder tout ce qui touche à la surveillance ou à l’analyse du comportement des applications. Firebase Analytics devient donc Google Analytics for Firebase, permettant aux rapports générés d’être disponibles dans les deux services (donc Firebase et Google Analytics). Firebase renforce aussi son intégration d’AdMob, le service de Google dédié aux publicités in-app et qui partage désormais ses données avec Analytics.
Firebase permet également aux développeurs de créer jusqu’à 50 paramètres personnalisés d’évènements pour surveiller des éléments précis de leurs applications, les informations étant alors fournies dans les rapports Analytics. Autre ajout important, l’intégration de DoubleClick Campaign Manager et DoubleClick Bid Manager. Google a clairement pour objectif de faire de Firebase le compagnon « idéal » du développeur en lui donnant accès à un nombre croissant d'informations.
D'autres annonces ont d'ailleurs été faites. Par exemple, la plupart des SDK vont devenir open source, un mouvement qu’on retrouve de plus en plus dans le monde du développement, chez de nombreux éditeurs. Les mêmes kits de développement prennent également mieux en charge le langage Swift d’Apple. En outre, Google ouvre pour la première fois un programme Alpha qui permettra aux développeurs intéressés de tester en avance les nouveautés prévues.
Précisons enfin que Google a profité de l’occasion pour donner à Firebase un site officiel remanié.
Android Things continue son avancée vers la version finale
Si les développeurs n’ont pas assez à faire avec l’ensemble des nouveautés annoncées sur Android, Android Studio ou encore Firebase, ils pourront toujours se tourner vers Android Things, dédié aux objets connectés et autres mini-ordinateurs.
La Developer Preview 4, disponible depuis hier soir, introduit donc plusieurs apports. D’abord, un renforcement du partenariat avec AIY Projects, qui permettait à Android Things de supporter Voice Kit, basé sur un Raspberry Pi. La nouvelle préversion apporte en plus tous les pilotes nécessaires à la prise en charge du SDK Google Assistant sur toutes les cartes certifiées pour la plateforme. Conséquence, ce matériel peut être utilisé pour utiliser l’Assistant à la voix, comme avec un smartphone.
Comme on peut s’y attendre, la Developer Preview 4 prend également en charge certains matériels en plus, comme la carte i.MX7D de NXP ou l’Inter-IC Sound Bus, supporté via l’API Peripheral I/O. Google en profite aussi pour montrer la voie avec sa Elison Candle, un prototype de production devant montrer une parfaite adéquation matériel/logiciel. Les plans sont disponibles sur CircuitHub et le code sur GitHub.
Mais puisqu'il n'était pas question d'aborder les nouveautés dédiées aux développeurs sans évoquer l'intelligence artificielle et l'apprentissage profond, Google avait d'autres annonces en réserve.
De nouveaux TPU à 180 TFLOPS, des TPU Pods de 11,5 PFLOPS
Il y a tout juste un an, Google présentait ses Tensor Processing Units, des circuits intégrés spécialisés (ASIC) dans l'apprentissage machine et taillés sur mesure pour le moteur d'apprentissage profond TensorFlow. Aujourd'hui, le géant du Net annonce que la seconde génération de puces arrive dans le Cloud maison, via Google Compute Engine.
Pour chaque TPU (Tensor Processing Units), le géant du Net annonce une puissance de calcul de 180 TFLOPS, sans plus de détail. Ils sont conçus pour fonctionner en cluster et peuvent servir de base pour construire des supercalculateurs baptisés TPU Pods. Composés de 64 TPU chacun, ils revendiquent une puissance de calcul de 11,5 PFLOPS.
Le fabricant annonce ainsi un gain de puissance très élevé par rapport à des GPU, mais se réserve bien de comparer son système aux TPU de première génération, dommage. « L'un de nos nouveaux modèles de traduction à grande échelle nécessitait une journée complète pour s'entraîner sur 32 des meilleurs GPU disponibles dans le commerce, maintenant il s'entraîne avec la même précision en une après-midi en utilisant seulement un huitième d'un pod TPU » affirme Google.
Vous pouvez demander à participer à la bêta ouverte en vous inscrivant par ici.
Un cluster de 1 000 TPU disponible gratuitement pour les chercheurs
Afin de s'assurer d'une certaine publicité auprès des chercheurs, la société de Mountain View présente son programme TensorFlow Research Cloud. Il s'agit de mettre gratuitement à disposition un cluster de 1 000 TPU. Le milieu universitaire n'est pas le seul visé, et tout le monde peut postuler à partir du moment où vous disposez d'un projet.
Les candidats seront sélectionnés par Google, qui leur donnera un accès (avec des limitations de temps) au cluster. Si vous avez plusieurs projets, il est possible d'effectuer plusieurs demandes. Tous les détails se trouvent par-là, tandis que le formulaire d'inscription est disponible ici.
TensorFlow débarque sur mobile
Comme annoncé durant la conférence, le moteur d'apprentissage automatique TensorFlow, qui est disponible depuis quelques semaines en version finale, se prépare à débarquer sur les smartphones. Cette mouture exploitera une nouvelle API spécialement conçue pour ces derniers, mais Google pense que des DSP (Digital Signal Processor, des puces spécialisées dans le traitement du signal) arriveront prochainement. Rappelons que le Snapdragon 835 de Qualcomm intègre déjà un DSP Hexagon 682 qui supporte justement TensorFlow.
Ce moteur devrait permettre d'améliorer les performances des terminaux mobiles dans plusieurs domaines. La reconnaissance de la parole et des images, ainsi que la réalité augmentée sont citées en exemple par Google.
Google se propose de gérer vos objets connectés, de A à Z
Impossible de passer à côté, il était également question de l'Internet des objets durant la conférence I/O avec l'annonce de Google Cloud IoT Core, qui s'intègre dans la Google Cloud Platform (alias GCP). Cette solution se veut complète : elle « vous permet de connecter de manière sécurisée l'ensemble de vos objets à GCP, de les gérer de manière centralisée et de créer des applications riches en vous intégrant à nos services d'analyse de données ».
Le géant du Net s'occupe de tout à votre place et vous permet de payer en fonction de l'utilisation de votre service, un point qui pourrait intéresser certaines entreprises qui peuvent ainsi maitriser leur évolution. Il faudra néanmoins accepter de centraliser l'ensemble de vos données chez Google.
Dans tous les cas, Cloud IoT Core est disponible sous la forme d'une bêta privée pour le moment. Les détails des partenaires de Google (pour les produits et les applications) est disponible par ici.
I/O : les développeurs dans le viseur de Google, qui multiplie les services
-
Android Studio 3.0 : d’importantes nouveautés et une première préversion
-
Android O : des nouveautés à prendre en compte… ou pas
-
Sur Android Go, les développeurs auront le choix
-
Play Store : nouvelles métriques, gestion des clés et Protect
-
Les Instant Apps désormais disponibles pour tous les développeurs
-
Firebase : le plein de nouveautés
-
Android Things continue son avancée vers la version finale
-
De nouveaux TPU à 180 TFLOPS, des TPU Pods de 11,5 PFLOPS
-
Un cluster de 1 000 TPU disponible gratuitement pour les chercheurs
-
TensorFlow débarque sur mobile
-
Google se propose de gérer vos objets connectés, de A à Z
Commentaires (9)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 18/05/2017 à 15h52
”…prend en charge les serveurs proxy…”
Y aura la prise en charge de l’option 252 du DHCP, on ne sera plus obligé de le rentrer à la main lors d’une connexion sur le Wi-Fi d’entreprise ?? LE REVE !
Le 18/05/2017 à 21h14
>Android Go vise particulièrement les appareils munis de 1 Go de mémoire vive ou moins, et se veut donc plus léger.
Ah oui quand même. J’ai un serveur qui fait une multitude de chose qui doit avoir près de 8 fois moins de mémoire … et qui se permet d’avoir plus de la moitié de sa mémoire de disponible _.
Pour moi peu puissant, je pensais à des vrais objets peu puissants : microcontroleurs 8 bits, 4ko de flash. La au moins il y aurait eu un challenge de fournir une couche de developpement unifiée.
J’aurais pu comprendre sur 1Mo de flash 64ko de flash, 32 bit @ 80Mhz. Pour faire de l’IoT (c’est une config typique d’un esp8266, et lorsqu’on voit ceux que certains arrivent à faire avec , c’est plutôt puissant :) )
Mais 1 Go et des processeur de l’ordre du ghz, comment on peut appeller ça “peu puissant” . C’est largement plus puissant que l’ordinateur des navettes spatiales.
J’ai l’impression de devenir un vieux con à voir les évolutions des logiciels “kikoolol” :(
Le 18/05/2017 à 23h39
Parce que ton smartphone fait 1Md de plus de truc que ton serveur " />
Et que l’optimisation coûte très cher… donc pas forcément très utile quand tu sais que tu as à dispo 1Go de RAM !
Le 19/05/2017 à 07h55
Rien qu’une interface graphique ça doit pomper pas mal " />
Même sur les téléphone-patateWiko et leurs écrans faibles résolution " />
Le 19/05/2017 à 08h03
C’est vrai qu’aujourd’hui bien des cartes qui autrefois auraient intégré un CPU 8b avec une misère de ROM (avant que la flash n’existe) et de RAM peuvent utiliser des configurations avec N fois plus de ressources CPU et mémoire qu’un serveur des années " /> (je ne vais pas dire mon âge quand même), pour pas plus cher, et peut-être même pour moins cher (en raison de la disponibilité des composants).
Le vrai point bloquant, c’est maintenant la question de la consommation électrique.
Et là, de nouveau on peut être amener à réfléchir avant d’ajouter de la mémoire, d’augmenter la largeur du bus, de jouer avec la fréquence, …
Le 19/05/2017 à 08h19
Faut arreter d’opposer les serveurs, les téléphones et les cartes electroniques d’IOT aussi " />
Android GO est un OS de smartphone … avec toutes les contraintes qui vont avec (x applications concurentes, obligation de garder certaines en RAM - musique / GPS …) plein de services consommateurs en tache de fond (entre téléphonie pur, Google, OEM et opérateur) et le fait que l’utilisateur a envie d’avoir un Pokemon GO qui tourne et passer de son app de chat aux jeux sans devoir relancer le jeu de zero … le tout en 720p … (quand c’est pas du 1080 ).
Tu n’as pas ces problématiques sur un serveur, et encore moins dans une ampoule connectée " />
Android things est déjà plus proche d’un OS pour IOT (et pour l’instant n’est pas compatible avec des cartes proto qui ont moins de 512Mo de Ram - à voir la version finale), mais pour le coup ils vendent des interactions plus “poussés” - comme le support de Google Assistant pour parler directement à l’IOT … avec 8Mo de RAM c’est un peu chaud à faire " />
Le 19/05/2017 à 08h30
Mais je n’oppose pas ces divers engins.
Je dis que la frontière est plutôt entre branché (sur secteur, sur batterie de voiture) et pas branché.
On peut trouver de l’IoT des deux côtés de la frontière.
Pour les pinailleurs:
J’ai dit que c’était la problématique de la consommation qui faisait la différence.
On comprends bien qu’entre tenir 2 ans sur une pile bouton et recevoir le 220V en permanence, il y a une différence. Mais il est possible aussi que dans certains cas la consommation possible soit limitée pour des considérations autres, le plus probable étant une place restreinte qui bloque toute dissipation thermique.
Le 19/05/2017 à 09h18
Je n’ai pas la même approche que toi.
Heureusement que tu n’es pas obligé de relancer la base de données à chaque transaction http sur un serveur et qu’ils savent gérer la concurrence et la prioritisation des taches. Il est bon ton de “réserver” de la ram sur certains services (sshd ^^‘) pour éviter qu’ils soient OOM Kill (en réalité surtout gérer le OOM kill directement).
* on ne parle pas des derniers services clouds qui créé une vm à chaque transaction, mais où la bd existe toujours à coté.
La résolution graphique d’un jeu, ou même d’une vidéo, est une fausse question sur un téléphone, car dépendant de circuits dédiés sur les téléphones (gpu, décodage vidéo hard).
Même sur les microcontrolleurs on utilise freertos ou d’autres os bas niveau qui assure un parallélisme avec des contraintes temps réels.
Perso, mes prises connectés ont 1Mo de rom (et je crois 256ko de ram). Elles gèrent le tcp /tls ,le wifi (par une puce dédiée), le mqtt , un serveur web , un client http et un client syslog et ntp.
Elles gèrent le statut de la prise, les mesures d’énergies, et les réponses https de façon concurrente (ie accéder et configurer la prise ne la rend pas indisponible à d’autres demandes, et elles continuent d’envoyer des informations en même temps, et de suivre le temps et …)
Je rejoint entièrement levhieu sur la question de la conso électrique. Certains capteurs iot sont censé être fonctionnel sur une pile AAA pendant 10 ans.
Le moindre smartphone avec 512Mo de ram ne sait pas tenir 2j sans consommer à minima 0.56 wh (batterie lipo 800 mah).
Le 19/05/2017 à 10h02
Pour les jeux 2D (fire emblem heroes par exemple), la résolution a du sens " /> … après dans un jeu il y a une tripoté de données qui doivent passer en RAM entre les textures, la musique, précharger des données en mode “non compressée” pour éviter les saccades, et garder un affichage le plus fluide possible, tout en ayant assez de ram pour gérer en tache de fond la lecture d’un fichier MP3 ou la navigation GPS si nécessaire.
Maintenant un smartphone est conçu pour des usages de smartphone avec tout ce que ça signifie (usages multiples, avec des apps mal codés, mal optimisés … ), à la différence de capteurs IOT qui ont un usage unique avec des puces spécialisés et les contraintes qui vont avec.
Aussi, je n’aurai aucun usage d’une puce IOT comme smartphone, comment veux tu qu’un smartphone tienne les contraintes d’ IOT " />