Résumé Android Q AMA: modifications de la capture d'écran Android R, clarification du mode Bureau, mode sombre en fonction du temps, etc.

L'année dernière, l'équipe Android de Google a hébergé le subreddit Ask / Anything (AMA) sur Reddit / r / AndroidDev afin de répondre aux questions concernant la prévisualisation du développeur Android P. Cette année, l'équipe d'ingénieurs travaillant sur la version bêta d'Android Q a répondu aux questions sur Reddit. L’AMA a débuté le 1er août à 12 h 00 (heure du Pacifique) et a pris fin environ une heure et demie plus tard. 33 ingénieurs de Google ont participé à l'AMA et ont répondu à de nombreuses questions en peu de temps. Voici notre résumé de toutes les nouvelles informations que nous avons apprises.

Android Q AMA: Tout ce que nous avons appris de Google

Participants de l'équipe bêta Android Q

  • Adam Cohen: TLM sur Android Launcher / Interface utilisateur système
  • Adam Powell: TLM sur le toolkit / framework d’UI; vues, cycle de vie, fragments, bibliothèques de support
  • Alan Viverette : TLM, Jetpack / AndroidX
  • Allen Huang: PM pour l'interface utilisateur, le lanceur, les notifications, les intégrations de recherche et plus encore!
  • Andrew Sappirstein: TLM sur les paramètres Android
  • Brahim Elbouchikhi : directeur de projet pour la formation et l'appareil photo Android (API NN, kit ML, CameraX, plateforme de caméra)
  • Chad Brubaker : Ingénieur logiciel, Sécurité de la plateforme Android
  • Charmaine D'Silva: le PM pour la confidentialité
  • Chet Haase : Avocat principal pour Android, Relations avec les développeurs
  • Diana Wong: PM, Compatibilité des applications, Utilisation des API non-SDK, ART, NDK
  • Dianne Hackborn : responsable de l'équipe cadre Android (ressources, gestionnaire de fenêtres, gestionnaire d'activités, multi-utilisateurs, impression, accessibilité, etc.)
  • EK Chung: Directeur de l'UX
  • Ian Lake: Ingénieur logiciel, Jetpack (Fragments, Navigation, Composants d'architecture)
  • Iliyan Malchev: Ingénieur logiciel principal, Projet Mainline
  • Jacob Lehrbaum: Directeur des relations avec les développeurs pour Android
  • Jake Wharton : ingénieur logiciel, Jetpack
  • Jamal Eason : PM, Android Studio
  • Jeff Bailey : TLM, Projet Open Source Android (AOSP)
  • Jeff Sharkey : Ingénieur logiciel, Framework Android
  • Jeffrey van Gogh : Android Studio, Compilateurs
  • Jen Chai: PM, Lieu et contexte, Auth, Remplissage automatique, utilisation d'API non SDK, ART
  • Karen Ng: PM de groupe pour les outils de développement Android, Android Studio, Android Tookit et Jetpack
  • Paul Bankhead: directeur de la gestion des produits, Google Play
  • Rohan Shah: chef de produit, interface utilisateur du système Android
  • Romain Guy : Responsable de l'équipe Android Toolkit / Jetpack
  • Sagar Kamdar: Directeur de la gestion des produits, Android
  • Sat K: Directeur de l'ingénierie, connectivité Android
  • Selim Cinek : ingénieur logiciel, interface système Android
  • Stephanie Saad Cuthbertson : directrice principale de la gestion des produits, Android
  • Sumir Kataria: Ingénieur logiciel, Jetpack (WorkManager)
  • Travis McCoy: PM, plate-forme Android
  • Trystan Upstill: Ingénieur distingué, responsable de l'interface utilisateur et du système Android
  • Vinit Modi: PM, Appareil photo Android

Les OEM ne peuvent plus tuer les applications lorsque l'utilisateur les efface de manière récente

Si vous avez déjà utilisé un smartphone d'une marque chinoise, vous avez probablement déjà eu affaire à des fonctionnalités «d'optimisation de la batterie» qui gênent toutes vos applications préférées en arrière-plan. Non seulement ce comportement est gênant pour les utilisateurs qui s'attendent à ce que certaines applications continuent de s'exécuter en arrière-plan pour quelque raison que ce soit, mais il est également gênant pour les développeurs qui subissent de mauvaises critiques de la part d'utilisateurs qui ne comprennent pas que ce n'est pas la faute de l'application. Alors que Google ne résout pas encore complètement ce problème (ils ont écarté le problème en déclarant que ce comportement contrevenait probablement déjà aux exigences du document de définition de la compatibilité Android), mais la société prend actuellement des mesures contre le changement de comportement "d'économie de batterie" utilisé. par certains OEM.

«Pour nous aider dans cette situation, nous avons ajouté un test CTS sous Android Q afin de nous assurer qu'une application n'est pas détruite après avoir été balayée de Recents.»

Android R peut apporter plus de modifications aux captures d'écran que prévu

Google prévoit d’ajouter des captures d’écran de défilement dans Android R, mais dans le même temps, l’équipe Android «étudie de près la manière dont [ils] peuvent améliorer l’ensemble de l’expérience écran- [X] de R.». améliorations apportées au comportement de la capture d'écran (AND screencast) dans la prochaine version majeure d'Android.

Clarifier le nouveau mode de travail d'Android Q

La première version bêta publique d'Android Q a apporté une interface de mode bureau masquée à l'AOSP et à Pixel Launcher. Bien que Google ait brièvement abordé la fonctionnalité lors d'une session Google I / O, nous n'avons jamais entendu directement de Google comment cette nouvelle fonctionnalité s'intègre dans l'écosystème Android. Google clarifie maintenant:

«Dans Q AOSP, le« mode de bureau »est une option de développement destinée aux développeurs d'applications. Cela leur permet de tester leurs applications dans des environnements en mode multi-affichage et en mode fenêtrage libre. Auparavant, il n'existait aucun moyen pratique de tester le comportement des applications sur un affichage secondaire et avec des fenêtres redimensionnables librement sur Android. Cette fonctionnalité n’est pas produite à elle seule et n’est pas destinée aux utilisateurs réguliers pour le moment. Néanmoins, c’est la base de la plate-forme Android sur laquelle les constructeurs OEM doivent innover et créer de bons produits. ”

Ainsi, nous pouvons nous attendre à voir les OEM s’appuyer sur le mode de bureau natif d’Android Q. Par exemple, OnePlus 7 Pro prend en charge l'affichage via HDMI. Il est donc possible qu'OxygenOS 10 basé sur Android Q ait sa propre interface en mode Bureau à l'avenir. Nous espérons également que Google s'appuiera sur la fonctionnalité du prochain Pixel 4.

Mode obscur basé sur le temps

Android Q apporte enfin une fonctionnalité très demandée: le mode sombre à l’échelle du système. Actuellement, le mode sombre peut être activé manuellement dans Paramètres ou via une mosaïque Paramètres rapides, ou automatiquement lorsque l’économiseur de batterie est activé. Avant Android Q, il était possible d'activer le mode sombre en fonction de l'heure du jour, mais cette option était obsolète. Selon Chris Banes:

"Il existe plusieurs raisons pour lesquelles cela est obsolète (non supprimé) dans AppCompat v1.1.0: les applications doivent demander des autorisations de localisation pour être précises, et même avec un emplacement valide, les calculs de l'heure du lever / coucher du soleil peuvent être erronés."

Interrogé sur ces bugs, M. Banes a déclaré que «le calcul du lever et du coucher du soleil est notoirement difficile, en particulier pour les emplacements proches des pôles nord / sud». Un utilisateur affiche Night Light, disponible depuis Android 7.1 Nougat, qui peut être basculé automatiquement. sur les horaires Coucher / Lever. M. Banes a ensuite déclaré que, depuis que Night Light utilise CalendarAstronomer d'ICU4J, il utilise un «gros morceau de code sur lequel nous ne voudrions pas qu'AppCompat dépende». Cependant, l'équipe déclare que cette fonctionnalité est «quelque chose [qu'elle] va regarder dans. "

Prise en charge obligatoire de l'API Camera2 / Camera HAL3 pour les dispositifs de lancement Android Q

Google a introduit l'API Camera2 pour mieux définir la manière dont les applications peuvent interagir avec les caméras individuelles connectées à votre smartphone. Tandis que Google encourage les fournisseurs de smartphones à "exposer toutes leurs caméras physiques aux développeurs", de nombreux fournisseurs décident de ne pas le faire, même si "l'API elle-même ne les empêche pas aujourd'hui". Cela signifie que de nombreuses applications tierces pour appareils photo ne peuvent pas utiliser les applications secondaire ou secondaire. modules de caméra tertiaire sur les smartphones modernes. Cependant, des progrès sont en cours, alors qu'Android Q a amélioré LOGICAL_MULTI_CAMERA, une API qui offre aux développeurs un meilleur accès à toutes les caméras d'un périphérique et permet aux OEM de contrôler la consommation d'énergie et de gérer plusieurs états de caméras.

En outre, Google indique qu'il a ajouté des exigences pour tous les appareils lancés avec Android Q afin de prendre en charge de manière native Camera2 API / Camera HAL3. Selon Vinit Modi:

«À partir d'Android P, les nouveaux appareils dotés de 1 Go de RAM ou plus sont nécessaires pour utiliser HALv3 / camera2 en mode natif. Android Q à partir de maintenant, tous les nouveaux appareils doivent prendre en charge nativement HALv3 / camera2. Malheureusement, les mises à niveau de HALv1 à HALv3 sont assez complexes en direct et peuvent avoir des conséquences inattendues. Nous avons donc dû limiter la portée à de nouveaux appareils. ”

Fait intéressant, la déclaration de Modi concernant les dispositifs de lancement RAM Android P normaux va à l’encontre de ce que Google nous a dit précédemment et de ce qui est publié en ligne sur la page Image Test Suite.

Application dynamique avec Jetpack Compose

La structure de gestion de thèmes OMS de Sony a été ajoutée à AOSP il y a quelques temps, mais elle est uniquement destinée aux constructeurs OEM. Nous savons déjà que Google s'oppose à l'utilisation de superpositions de ressources d'exécution par les utilisateurs pour thématiser des applications, mais pour les développeurs, la société espère que son infrastructure d'interface utilisateur Jetpack Compose apportera «des approches intéressantes à la thématisation dynamique».

Vulkan-backend pour Skia pour rendre l'interface utilisateur

L'année dernière, les ingénieurs de Google ont discuté de leur intention de faire en sorte que le cadre Android utilise l'API graphique Vulkan pour le rendu de l'interface utilisateur. Bien qu'il soit maintenant possible d'activer le backend à accélération matérielle Vulkan sans que votre téléphone ne tombe en panne, Google n'a pas encore annoncé de plan concret sur la mise en œuvre de ces modifications. Cette AMA ne répond pas à cette question, mais au moins nous avons la confirmation que cela est toujours en cours. Selon Romain Guy:

«L’équipe a travaillé sur un backend Vulkan pour Skia, le moteur de rendu 2D utilisé par Android, mais il n’est pas activé par défaut pour le moment. L’interface utilisateur et Canvas passent toujours par OpenGL ES. ”

Rendre la barre de geste d'Android Q plus dynamique

Certains pensent encore que les nouveaux gestes d'Android sont un gâchis, mais personnellement, je pense qu'ils vont bien. Cependant, si vous jouez un peu avec les nouveaux gestes dans Android Q, vous remarquerez que la barre des gestes ne bouge pas avec votre doigt. Il reste également sur les écrans où il n'est pas nécessaire, comme l'écran d'accueil ou la vue d'ensemble des applications récentes. Allen Huang dit qu'ils "sont tout à fait d'accord qu'il existe des opportunités" pour rendre la "ligne de navigation moins statique". Il ajoute que "c'est un travail sur lequel nous travaillons - mais nous équilibrons aussi pour ne pas faire apparaître / disparaître de manière distrayante."

Améliorations apportées à la Storage Access Framework

Les nombreuses modifications apportées à Android Q ont considérablement amélioré la sécurité et la confidentialité de la plate-forme. L'un de ces changements, appelé «Scoped Storage» (Stockage limité), limite l'accès des applications aux fichiers du stockage externe de manière logique. Les applications de musique ne devraient pas avoir besoin de voir votre galerie, par exemple. Les applications de gestionnaire de fichiers fonctionnant sous Android Q doivent utiliser une API appelée Storage Access Framework pour continuer à fonctionner normalement, mais certains développeurs considèrent cette API comme inférieure à ce qui était auparavant disponible. Jeff Sharkey de Google indique que l'équipe a résolu certaines des plaintes de ces développeurs:

«Nous avons apporté quelques améliorations aux performances de SAF dans les dernières versions d'Android Q Beta; Pourriez-vous vérifier vos points de repère par rapport à la dernière version bêta? Assurez-vous également que vous utilisez un ContentProviderClient lors de l'exécution d'opérations en bloc. ”

Le projet Treble a amélioré l'adoption de la tarte Android par rapport à Android Oreo

Nous avons déjà vu comment Project Treble, une réarchitecture majeure à bas niveau du framework Android, a amélioré l’adoption de nouvelles versions du système d’exploitation Android. Google attribue des crédits à Treble derrière le grand nombre de fournisseurs de smartphones rejoignant Android Peta l'an dernier et Android Q bêta cette année. Iliyan Malchev, ingénieur principal de Project Treble et Mainline, a déclaré que l'adoption d'Android Pie était «trois fois» supérieure à celle d'Android Oreo à la fin de 2018.

Dans le même commentaire, Dick Dougherty affirme que d’autres indicateurs utiles sont prévus pour le tableau de distribution de la version Android. Le graphique a été mis à jour pour la dernière fois en mai, mais ses données sont plus utiles pour les journalistes que pour les développeurs d'applications.

L'enregistrement d'écran est toujours un WIP

Les premières applications d'Android Q ont ajouté un indicateur de fonctionnalité pour un enregistreur d'écran de base, mais la plate-forme elle-même a considérablement amélioré l'utilité de l'enregistrement d'écran en permettant aux applications de capturer l'audio d'autres applications. Stephanie Saad Cuthbertson a déclaré que son équipe était en train de réfléchir à «comment améliorer encore les besoins en enregistrement sur écran». D'autres marques de smartphones comme OnePlus, ASUS, Huawei et Samsung ont des enregistreurs d'écran robustes capables d'enregistrer l'audio interne. être en train de jouer rattraper ici.

Dark Thème Toutes les choses!

Au cas où vous l'auriez manqué, Google ajoute le mode sombre à la plupart de ses applications. Stephanie Saad Cuthbertson a déclaré s'attendre à ce que toutes les «applications majeures» prennent en charge un thème sombre «par la version officielle [d'Android Q]». Même Google Chrome, qui impose actuellement un rechargement de page lorsque le thème sombre à l'échelle du système est activé, sera mis à jour. ne plus actualiser lorsque le thème est changé.

Oui, les tiers lanceurs travailleront avec des gestes (éventuellement)

Les gestes d'Android sont un peu cassés lorsque vous utilisez un lanceur tiers. En effet, l'interface utilisateur des applications récentes est contenue dans l'application de lancement des actions, et Google n'a pas encore trouvé le moyen d'avoir les mêmes transitions transparentes que lorsque vous utilisez des gestes avec Pixel Launcher. Adam Cohen affirme que Google envisage de traiter ces problèmes «le plus rapidement possible après la publication». Il ajoute que l'incompatibilité «sera corrigée dans la mise à jour post-Q et restituée en arrière-plan pour les nouveaux appareils lancés avec Q.».

Les partitions dynamiques / logiques ne sont pas là pour tuer les ROM personnalisées

Afin de prendre en charge les mises à jour système dynamiques dans Android Q, certains appareils, tels que Google Pixel 3 et Pixel 3 XL, utilisent des partitions logiques. Ces partitions peuvent être redimensionnées dynamiquement. Ce changement s'est avéré difficile à faire fonctionner pour que l'accès root fonctionne, et certains développeurs craignent que les ROM personnalisées ne soient ciblées. Iliyan Malchev nous assure que l’intention n’est pas de contraindre les ROM personnalisées. Comme il l'explique:

«Les partitions dynamiques ne sont pas conçues pour limiter ce que vous pouvez faire avec des ROM personnalisées. Ils constituent simplement une solution au problème de la taille fixe des partitions et de l’absence de moyen sûr de repartitionner les périphériques sur l’OTA. Avant les partitions dynamiques, si un constructeur faisait une erreur en dimensionnant, par exemple, la partition système, il serait contraint par ce choix, ce qui rendrait pratiquement impossible la mise à niveau d'un périphérique après un certain point. Certains constructeurs ont l'habitude de repartitionner leurs périphériques sur OTA, mais il s'agit a) de ne pas être officiellement pris en charge sous Android et b) de modifier la table de partition est considéré comme assez risqué. Les partitions dynamiques ont pour but de résoudre le problème en introduisant un niveau d'indirection entre la table de partition physique et le système d'exploitation. Cela nous permet d’ajuster en toute sécurité la taille des partitions sur l’OTA. En ce qui concerne les ROM personnalisées, vous ne devriez pas du tout être plus contraint qu'aujourd'hui avec ce que vous pouvez faire. La prise en charge des ROM personnalisées est et continue d’être quelque chose que chaque OEM décide d’activer. ”

Projet Mainline - Module ART et longueur de support

Mainline est une nouvelle initiative de Google qui vise à normaliser certaines bibliothèques et packages afin qu'ils puissent être mis à jour indépendamment des mises à jour de plate-forme. Certains se sont demandé pourquoi Android Runtime (ART) n’était pas encore un module Mainline, mais on m'a dit à Google I / O que la complexité liée à la modularisation de l’ART les empêchait de l’inclure dans l’un des packages APEX initiaux. Comme l'ont expliqué à la fois Iliyan Malchev et Diana Wong:

«Effectuer des mises à jour du Runtime (en particulier les correctifs relatifs aux performances et au GC, ainsi que les bibliothèques principales) est certainement une chose que nous explorons dans le contexte de mainline. Nous pouvons constater de nombreux avantages à pouvoir rendre ces mises à jour cohérentes sur tous les appareils et dans plusieurs versions avec mainline. C'est également un énorme défi technique car nous réfléchissons à la meilleure façon de procéder pour les développeurs, et probablement à un effort pluriannuel. Ce que Mainline ne peut pas faire actuellement, c’est certainement une chose à laquelle nous pensons. »

Si vous suivez le projet AOSP Gerrit, vous verrez que Google a néanmoins travaillé dur pour créer un APEX d'exécution. Actuellement, ils semblent diviser Bionic et ART / libcore en modules APEX distincts.

En ce qui concerne les avantages du projet Mainline, un utilisateur a demandé quelle était la durée des mises à jour de Mainline. Iliyan Malchev a répondu: «C’est une question de politique que nous sommes en train d’évaluer, mais nous souhaitons mettre à jour les modules Mainline sur un périphérique aussi longtemps que possible. Les développeurs de ROM peuvent fusionner les mises à jour et, en réponse, Jeff Bailey répète que «les modules qui se séparent d’APOS auront des versions source correspondant à chaque version de module». Nous pouvons déjà voir la progression des nouveaux modules APEX dans AOSP, par exemple une pour la version précédente. API de réseaux de neurones.

CameraX rencontre le kit ML

Aux I / O cette année, Google a présenté la bibliothèque CameraX Jetpack. Cette bibliothèque est conçue pour aider les développeurs à prendre en charge l’API Camera2 d’Android tout en maintenant la compatibilité jusqu’à Android Lollipop. Vinit Modi indique que la société travaille actuellement à l'intégration de CameraX à ML Kit, le SDK Firebase de Google destiné à l'apprentissage automatique, afin que les développeurs puissent insérer des cadres d'images dans ML Kit à des fins d'analyse.

Extensions du fournisseur CameraX et date de publication

Le développeur d'une application appareil photo déplore le fait que des fonctionnalités d'appareil photo avancées telles que Night Sight de Google Pixel ne soient pas accessibles aux applications tierces. Ceci est supposé pouvoir être résolu avec les extensions du fournisseur CameraX, auxquelles Jeff Sharkey de Google indique que «tous les appareils Pixel sont optimisés pour CameraX Core». Il déclare que «l'aspect Extensions sera pris en charge sur les nouveaux appareils et les appareils à venir». Google collabore avec plusieurs fabricants pour pouvoir mettre à la disposition de leurs développeurs et de leurs utilisateurs les fonctionnalités de leurs appareils. »Bien que cela ne soit pas confirmé directement, il est possible que des fonctionnalités telles que Night Sight sur Google Pixel 4 soient disponibles pour les applications de caméras tierces. qui utilisent la bibliothèque CameraX.

M. Sharkey a déclaré que Google visait une version bêta d'ici la fin de l'année.

Améliorations de la gestion de la mémoire dans Android Q

Le Pixel 3 a été critiqué pour ses nombreux problèmes post-lancement, mais Google a beaucoup fait pour résoudre ces problèmes via de nombreuses mises à jour post-lancement. La gestion de la mémoire est l'un des aspects les plus faibles du Pixel 3, mais les choses devraient être un peu meilleures dans la version Android Q. Selon Selim Cinek:

«Dans SystemUI, par exemple, nous avons mené plusieurs efforts importants de refactorisation dans Q afin de réduire l’utilisation de la mémoire RAM par les notifications et d’autres surfaces.»

Aurons-nous enfin la BAD sans fil?

Si vous souhaitez déboguer votre téléphone sans fil, vous devez rooter votre appareil. Jamal Eason de l'équipe Android Studio a déclaré qu'ils envisageaient actuellement la faisabilité de cette fonctionnalité.

Google teste-t-il toujours sur des tablettes?

Un développeur reconnu, Luk1337, a demandé si Google testait toujours AOSP UX sur des tablettes. C'est une bonne question compte tenu de la pénurie de bonnes tablettes Android et des bugs présents dans les versions actuelles. Allen Huang a déclaré que Google "testait et corrigeait chaque année" et que la société travaillait en étroite collaboration avec ses partenaires "afin de garantir une bonne expérience de la tablette Android".


Il y a beaucoup plus de messages dans le fil de discussion complet sur Reddit. Ce que j'ai couvert ici résume toutes les nouvelles informations que nous avons apprises, mais plusieurs Googlers (en particulier Dianne Hackborn) expliquent leur raisonnement derrière la suppression de la fonctionnalité X ou la non-application de l'autorisation Y. Je vous recommande de lire l'AMA au complet si vous voulez comprendre un peu mieux la prise de décision de l'équipe Android.

Lire l'intégralité de l'AMA sur / r / AndroidDev