Google a publié mercredi dernier la première bêta publique d’Android Q. La liste initiale des améliorations comporte des éléments attendus, comme la gestion des écrans pliables, et d’autres espérés comme des retouches du panneau de partage et des permissions. Passage en revue.

Pour cette première bêta publique, seule la gamme Pixel est pour l’instant supportée. Y compris d’ailleurs le premier modèle, alors qu’il date de l’automne 2015 et ne devrait donc plus profiter de telles mises à jour. Il reste cependant à voir si la version finale sera bel et bien proposée pour ce « vieux » smartphone.

Comme l’année dernière à la même époque, l’installation passe par une inscription au programme de test puis le téléchargement d’une mise à jour OTA, comme n’importe quel lot mensuel de correctifs de sécurité.

Bien entendu, il est recommandé de n’installer la préversion que sur un appareil secondaire, surtout dans le cas d’une première révision où l’on s’attend à un code encore frais, donc capable de provoquer des cascades de problèmes. L’éditeur le rappelle d’ailleurs sur sa page : la bêta n’est proposée qu’à des fins de tests et se destine avant tout aux développeurs, Android Q promettant une vague d’adaptations nécessaires.

On espère cependant, à l’instar d’Android Pie, que la deuxième bêta prendra en charge un panel de smartphones issus d’autres constructeurs. Si oui, il y a peu de chances qu’il s’agisse des mêmes références, mais ceux bâtis sur Android One devraient une nouvelle fois être privilégiés.

• S’inscrire à la bêta publique

La gestion des écrans pliables

Il s’agit de l’une des nouveautés les plus évidentes du futur Android 10. Le Mobile World Congress a récemment montré comment tous les constructeurs ou presque travaillaient sur des smartphones à écrans pliables, alors même que les usages restent pour la plupart à inventer.

Google évoque ainsi des améliorations pour OnResume et OnPause, dans l’idée que les écrans dépliés fourniront une surface d’affichage s’approchant plus de la tablette que du téléphone. D’où la nécessité d’améliorer le fonctionnement des applications côte à côte. Même si la chose est possible depuis Android 7.0, les deux applications ne sont pas réellement actives en même temps.

Bien que les développeurs puissent « tricher » dans une certaine mesure, une application est forcément au premier plan, l’autre en arrière-plan. La seconde ne peut pas véritablement mettre à jour son contenu et son interface si l’autre est utilisée activement par l’utilisateur.

Les améliorations introduites par Android Q permettent le « multi-résume », c’est-à-dire la reprise simultanée de plusieurs applications en même temps. De même, une application saura plus précisément quand elle est utilisée activement.

Google n’en dit étrangement pas beaucoup plus, excepté que l’émulateur officiel est en cours de gros travaux pour aider à la conception d’interfaces tirant parti des écrans pliables. On peut cependant se replonger dans la présentation de Samsung de son futur Galaxy Fold, qui permettait d’observer plusieurs comportements attendus des applications, même s’ils dépendront avant tout des choix faits par les constructeurs.

La démonstration de Google Maps affichait par exemple l’application sur l’écran principal, avant de se transformer après déploiement de l’écran en « version tablette ». Les termes « screen continuity » ont d’ailleurs été utilisés pour expliquer la préservation de l’état de l’application en cours lors du « dépliage » du smartphone.

Remarqué par certains, on trouve même un mode bureau dans Android Q, laissant place à une interface qui rappelle plus facilement Chrome OS ou Windows. Dans ce mode, il est possible d’ajouter des icônes sur le bureau, les applications se lançant dans leur forme d’origine, comme les applications Android le font sur Chrome OS.

Des permissions plus strictes pour les applications

Depuis Android 7.0, Google retravaille version après version les permissions accordées aux applications. Le système fournissait auparavant un terrain de jeu idéal aux applications malveillantes, dont les actions étaient peu contrôlées.

L’éditeur s’est largement inspiré d’Apple et va continuer à le faire avec Android Q. C’est ainsi qu’en cas de demande d’autorisation d’accès à une fonction particulière – par exemple la géolocalisation – la fenêtre « Autoriser/Refuser » va s’accompagner d’une troisième option : autoriser uniquement quand l’application est active.

En clair, une application comme Waze n’aurait l’autorisation d’accéder à la position géographique que lorsqu’elle est au premier plan. Si, pour une raison ou une autre, l’utilisateur revient sur l’accueil ou bascule sur une autre application, Waze perdra son autorisation jusqu’à ce qu’elle soit rappelée. Cette nouvelle capacité sera généralisée à tous les capteurs.

De manière plus globale, Android Q empêchera les applications de lancer des activités en arrière-plan si elles ne sont pas le résultat d’une action directe de l’utilisateur. Désormais, elles n’auront plus droit qu’aux notifications pour signaler une information ou une demande d’interaction. Voilà qui devrait mettre un frein à certains comportements malveillants.

Toujours dans un esprit de rendre Android plus « sûr », les utilisateurs pourront limiter les autorisations d'accès des applications au stockage. Une application de retouche vidéo pourra n'être par exemple autorisée qu'à accéder aux fichiers vidéos et aux photos, sans pouvoir toucher au reste. Une granularité bienvenue.

Sachez qu'à l'inverse, les applications devant écrire des données sur un stockage externe (dont la carte SD) n'auront plus besoin d'autorisation spécifique pour le faire. L'application se verra automatiquement accorder un stockage privé dans lequel placer ses données. Si elle doit écrire ailleurs, pour une raison ou une autre, une demande d'autorisation sera envoyée à l'utillisateur. L'ensemble permet de fluidifier l'utilisation en ne réclamant une action que lorsque c'est strictement nécessaire.

Un menu de partage plus rapide

Ce n’est dans l’absolu par la plus révolutionnaire des améliorations, mais elle pourrait bien être dans la pratique l’une des préférées des utilisateurs.

Le menu de partage sera en effet rempli par des Sharing Shortcuts que les développeurs devront créer pour accompagner leurs applications. Ils viendront enrichir la liste à leur déclaration, en tâche de fond, permettant normalement son chargement instantané ou presque.

Une situation très différente d’aujourd’hui, la liste chargeant dynamiquement à chaque appel les applications qui peuvent en profiter. Étonnement, cette liste n’a jamais été statique et est recréée à chacun de ses appels, entrainant un affichage différent de ses éléments.

Ce délai dans la génération provoque de nombreux problèmes, dont le plus important est l’attente du chargement. Le comportement global perdait également en prévisibilité puisque des éléments pouvaient n’apparaître qu’après, décalant ceux déjà affichés à leur arrivée et pouvant donc entrainer des erreurs frustrantes de manipulation.

Des promesses sur les performances et la sécurité du Wi-Fi

Android Q bénéfice d’une pile Wi-Fi « remaniée » censée accroitre les performances et le respect de la vie privée. Elle doit, selon Google, mieux prendre en charge des scénarios courants tels que la gestion d’une flotte d’objets connectés ou la suggestion de connexions Internet, sans avoir besoin de la géolocalisation.

Le peer-to-peer devrait être particulièrement amélioré, dans la mesure où il intervient régulièrement dans les échanges avec ce type de produit. Google évoque notamment les phases de configuration, téléchargement et impression. Les applications vont pouvoir initier indirectement des requêtes de connexion en spécifiant les noms des réseaux via les WiFiNetworkSpecifiers. Android s’occupe lui-même de scanner les réseaux et renvoie ceux correspondants. Après le choix de l’utilisateur, le système s’occupe de la connexion automatiquement.

Les applications pourront également demander un mode particulier de fonctionnement du Wi-Fi pour augmenter les performances et réduire la latence. Elles devront utiliser la méthode WifiManager.WifiLock.createWifiLock(), Android travaillant alors de concert avec le firmware de l’appareil pour trouver le mode de consommation le plus faible pour accéder à la demande.

Côté sécurité, on note l’apparition du support de WPA3 et d’Enhanced Open pour les réseaux publics et privés. À moins d’initier des connexions P2P ou de récupérer les réseaux suggérés, les API permettant de scanner les réseaux Bluetooth, cellulaires et Wi-Fi seront mieux protégés (permissions FINE pour la géolocalisation au lieu des seules COARSE).

De nouvelles obligations pour les développeurs

Google continue de durcir la ligne, à la fois sur ce qu’il est possible de faire et la modernisation générale du code.

Android Pie a ainsi débuté une obligation de se servir d’API publiques pour certaines tâches, Google réclamant des développeurs l’arrêt des interfaces de programmation maison. Le mouvement sera renforcé pour Android Q, avec une liste de nouvelles interfaces restreintes. La décision sera cependant limitée aux seules applications visant Android Q pour éviter une panique générale. Google recommande quand même d’utiliser la méthode StrictMode pour que l’application avertisse automatiquement le développeur qu’une API n’appartenant pas au SDK Android est utilisée.

L’éditeur rappelle également que d’ici quelques mois, toute nouvelle application ou mise à jour devra obligatoirement être en 64 bits. Ce qui inclut les SDK et bibliothèques embarqués. À compter du 1^er août, le Play Store ne distribuera plus aucune application 32 bits à un appareil 64 bits. Si les applications ne sont pas prêtes d’ici là, elles n’apparaitront tout simplement plus dans la boutique. Les appareils 32 bits ne sont pas concernés.

Plus tard dans l’année, les nouvelles applications et mises à jour devront en outre viser le niveau 28 du SDK Android, correspondant à Android Pie. En suivant les règles établies, Android Q avertira donc l’utilisateur en cas d’application visant le niveau 23 (Marshmallow) ou plus ancien.

Dans tous les cas, Google encourage les développeurs à tester leurs applications aussi rapidement que possible à cause de la multitude de changements importants présents dans cette première bêta, d’autant que d’autres suivront. Sont particulièrement pointées les restrictions sur le fonctionnement en arrière-plan et les nouvelles permissions.

Ceux n’ayant pas de Pixel sous la main pourront attendre que la liste s’étoffe avec la bêta 2 ou récupérer Android Studio pour passer par l’émulateur, lui aussi mis à jour.

• Télécharger Android Studio

Interface : mode sombre, police et personnalisation

Plusieurs évolutions d’interface attendent les utilisateurs dans Android Q. Le changement le plus attendu est un mode sombre à l’échelle du système. Comme nous l’avions vu dans notre dossier consacré à Android Pie, certaines zones pouvaient déjà basculer dans ce mode, mais leur nombre était limité. En outre, il a fallu attendre que Google mette à jour ses propres applications pour qu’elles puissent en tirer parti.

Dans la première bêta d’Android Q, le thème sombre est présent mais n’est pas simple à activer en tant que tel. Le moyen le plus rapide d’y accéder est de basculer le smartphone en mode économie d’énergie. La plupart des fonds blancs deviennent alors noirs, notamment dans les paramètres du système.

La méthode, bien qu’efficace, n’est pas forcément pratique pour le moment. Le mode économie d’énergie ne fait bien sûr pas que changer les fonds des fenêtres, puisqu’il coupe notamment tous les fonctionnements en arrière-plan. À moins de besoins spécifiques dans ce domaine, il faudra attendre une prochaine bêta du système.

Le changement de police par défaut est en revanche visible partout. Product Sans, que l’on voyait déjà progresser dans nombre de produits et était présente dans Android 9, remplaçant désormais toutes les autres dans le système.

Certaines options de personnalisation de l’interface sont également apparues dans les réglages développeur, disponibles tout en bas des paramètres. On peut y changer notamment la couleur d’accentuation (même si on n’en trouve que quatre pour l’instant) et la police par défaut (donc en remplacement de Product Sans), en plus de la forme des icônes (carrées ou rondes) que l’on pouvait déjà modifier.

Rien à voir bien sûr avec ce que laissent faire certains environnements créés par les constructeurs, mais puisque l’on parle d’un Android « pur » – donc disponible sur les Pixel ou les smartphones Android One – ces nouveautés restent bienvenues.

De petites améliorations pratiques çà et là

Bien qu’un nouvel Android soit toujours l’occasion pour les développeurs de plonger leur nez dans une longue liste de nouveautés, il existe des améliorations purement pensées pour les utilisateurs.

Par exemple, si une application a besoin d’une autorisation particulière qui ne peut pas être demandée via une fenêtre, elle pourra – avec accord de l’utilisateur – l’envoyer directement dans la partie concernée des paramètres d’Android. Une capacité qu’iOS propose depuis un moment et qui permet d’éviter de perdre son temps à chercher le réglage idoine.

Dans le même esprit, tirer le panneau de paramètres rapides affichera désormais une estimation du temps restant d’autonomie. Cette information ne devra évidemment pas être prise au pied de la lettre puisqu’elle dépendra de l’utilisation en cours du smartphone. Si vous lancez un jeu ou de multiples applications dans les heures qui suivent, l’estimation risque de changer radicalement.

Le menu apparaissant en cas d’appui long sur le bouton Alimentation gagne de son côté un nouveau venu : les services d’urgence. En outre, le mot de passe d’un réseau Wi-Fi peut être partagé sous forme d’un QR code. En l’affichant sur votre écran, une personnage pourra le scanner et obtenir automatiquement l’accès au dit réseau. Pratique quand on n’a pas le mot de passe sous la main ou qu’on ne souhaite pas le dicter.

Signalons en outre plusieurs « feature flags » à tester dans les options développeurs, dont plusieurs concernant directement les utilisateurs. Par exemple, une fonction intégrée d'enregistrement de l'écran. Une action possible de longue date sur Android, mais uniquement via des applications tierces. La fonction est cependant assez instable pour le moment.

On y trouve également le Media Switcher qui, une fois activé, ajoute un bouton en forme de note de musique sur la notification d'un média en cours de lecture. Une fois pressé, il permet de choisir la sortie audio, par exemple entre un haut-parleur et un casque.

Multiples évolutions dans les API et autres améliorations pour les développeurs

Google propose une nouvelle série d’apports pour son ART (Android RunTime). En plus de la PGO (Profile Guided Optimization), qui identifie et précompile les parties les plus exécutées d’un code, Google Play fournit des profils ART « basés sur le cloud ».

Anonymisés, ils permettent à ART de précompiler certaines parties de l’application avant son lancement initial. Les gains mesurés par Google vont de 10 à 20 %. Il ne s’agit pas à proprement parler d’une nouveauté puisque ces profils peuvent déjà être utilisés par des applications sur Android Pie. Leur fonctionnement est simplement généralisé avec Android Q.

Cette volonté d’accélérer le lancement des applications se retrouve dans d’autres améliorations. Le processus Zygote (initialisation d’instances virtuelles, préchargement de classes, fork des processus d’applications, etc.) a par exemple été optimisé en lançant l’application plus tôt et en déplaçant son processus principal dans un conteneur.

On note également un stockage d’informations supplémentaire en tête d’image (dont les classes), qui sera chargée plus rapidement via du multiprocessus. Android Q ajoute aussi un ramasse-miettes générationnel à ART, décrit comme plus efficace pour collecter les objets récemment générés, donc moins gourmand en ressources.

Côté sécurité, on note deux améliorations importantes. D’abord sur TLS, dont la version 1.3 est désormais supportée et activée par défaut. En plus des bénéfices attendus en termes de sécurité, les performances sont améliorées, avec par exemple des connexions établies jusqu’à 40 % plus rapidement. Ceux qui souhaitent en savoir plus sur ce protocole, validé en août 2018, pourront lire l’article très complet de Stéphane Bortzmeyer sur le sujet.

Le framework BiometricPrompt est également enrichi pour prendre des méthodes d’authentification passives, dont la reconnaissance faciale. Rien n’empêchait évidemment jusque là les constructeurs d’intégrer ce type de technologie, mais BiometricPrompt les gère nativement à l’échelle du système, simplifiant le travail des développeurs.

Même philosophie pour le « floutage » de fond des photos avec les caméras pouvant jouer avec la profondeur de champ. Avec Android Q, les applications pourront demander un cliché Dynamic Depth, composé d’un fichier JPEG, de métadonnées XMP et d’une carte de profondeur, le tout rassemblé dans un fichier unique. Les développeurs pourront l’exploiter directement pour appliquer un flou ou un effet bokeh sur les photos, à condition que l’optique en soit capable. Google dit être en relation avec les constructeurs pour préparer le terrain.

Plusieurs autres nouveautés font leur apparition, dont le support du codec AV1, la prise en charge du codec Opus (spécialisé dans la voix et le streaming musical), la gestion du HDR10+ ainsi qu’une API native MIDI, pour communiquer avec les appareils dédiés à travers le NDK (Native Development Kit). On note également l’apparition d’une API MediaCodecInfo qui risque de plaire : interrogée, elle renvoie à l’application les capacités de rendu vidéo de l’appareil utilisé, pour adapter d’autant plus facilement le flux à envoyer.

Ça bouge également dans le domaine graphique. Google dit ainsi travailler sur un nouveau pilote OpenGL, standard et capable d’être mis à jour. Le support expérimental d’ANGLE y est présent, une couche d’abstraction reposant sur Vulkan. Idéalement, toutes les applications – y compris les jeux – utilisant OpenGL ES pourront profiter d’une implémentation native dans Android, donc indépendante de tout choix constructeur.

Google évoque OpenGL ES 2.0 supporté dans Android Q, avec la version 3.0 plus tard, mais sans détails supplémentaires pour l’instant. Un autre travail est en cours avec les constructeurs pour que tout appareil 64 bits livré avec le prochain Android supporte obligatoirement Vulkan 1.1. Sur les produits 32 bits, ce support ne sera que « recommandé ».

Difficile également de parler d’un nouveau produit Google sans que la question de l’IA ne soit évoquée. L’API Neural Networks (NNAPI) passe ainsi en version 1.2, apportant une soixantaine de nouvelles opérations, parmi lesquelles ARGMAX, ARGMIN et LSTM quantifiée, ainsi qu’une série d’optimisations de performances. Les modèles pris en charge seront donc plus nombreux, dont ceux pour la détection d’objets et la segmentation d’image.

Rappelons qu'il ne s'agit que de la première bêta publique. D'autres nouveautés arriveront avec les prochaines, et celles déjà en place pourraient fortement évoluer d'ici la version finale. Google a d'ailleurs fourni un calendrier d'arrivée, la bêta 2 étant manifestement prévu pour début avril, une troisième début mai, une quatrième début juin et encore deux autres durant l'été. La version finale, elle, est attendue pour le troisième trimestre.