Résumé Android Q AMA: ce que Google a dit à propos d'Android 10 sur Reddit

L'année dernière, l'équipe Android de Google a organisé une AMA (Ask Me Anything) sur le sous-reddit /r/AndroidDev de Reddit pour répondre aux questions sur le Aperçu du développeur Android P. Cette année, l'équipe d'ingénierie travaillant sur la version bêta d'Android Q a répondu aux questions sur Reddit. L'AMA a commencé le 1er août à 12h00 PST et s'est terminé environ une heure et demie plus tard. 33 ingénieurs de Google ont été impliqués dans l'AMA, répondant à une tonne de questions dans le peu de temps qu'a duré l'AMA. 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 d'Android Q

• Adam Cohen : TLM sur le lanceur Android/interface utilisateur système
• Adam Powell : TLM sur la boîte à outils/cadre d'interface utilisateur; vues, cycle de vie, fragments, bibliothèques de support
• Alain 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 : Paramètres TLM sur Android
• Brahim Elbouchikhi: Directeur PM pour Android Machine Learning et Camera (NN API, ML Kit, CameraX, Camera Platform)
• Tchad Brubaker: Ingénieur logiciel, sécurité de la plateforme Android
• Charmaine D'Silva : MP pour la confidentialité
• Chet Haase: Avocat en chef Android, relations avec les développeurs
• Diane Wong : PM, compatibilité des applications, utilisation de l'API non SDK, ART, NDK
• Dianne Hackborn: Manager de l'équipe framework Android (Ressources, Gestionnaire de fenêtres, Gestionnaire d'activités, Multi-utilisateurs, Impression, Accessibilité, etc.)
• E.K. Chung : Directeur de l'UX
• Lac Ian : Ingénieur logiciel, Jetpack (Fragments, Navigation, Composants d'architecture)
• Ilian Malchev : Ingénieur logiciel principal, projet principal
• Jacob Lehrbaum : Directeur des Relations Développeurs pour Android
• Jake Wharton: Ingénieur logiciel, Jetpack
• Jamal Raison: Premier ministre, 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, emplacement et contexte, authentification, remplissage automatique, utilisation de l'API non SDK, ART
• Karen Ng : Groupe PM 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
• Samedi K : Directeur de l'ingénierie, Connectivité Android
• Selim Cinek: Ingénieur logiciel, UI système Android
• Stéphanie Saad Cuthbertson: Directeur principal de la gestion des produits, Android
• Sumir Kataria : Ingénieur logiciel, Jetpack (WorkManager)
• Travis McCoy : PM, plateforme Android
• Trystan Upstill : Ingénieur émérite, responsable de l'interface utilisateur et de l'intelligence du système Android
• Modi Vinit : PM, appareil photo Android

En savoir plus

Les OEM ne peuvent plus supprimer les applications lorsque l'utilisateur les fait glisser récemment

Si vous avez déjà utilisé un smartphone d'une marque chinoise, vous avez probablement été confronté à des fonctionnalités ennuyeuses d'« optimisation de la batterie » qui tuez toutes vos applications préférées en arrière-plan. Non seulement ce comportement est ennuyeux pour les utilisateurs qui s'attendent à ce que certaines applications continuent de s'exécuter en arrière-plan pour une raison quelconque, mais mais c'est aussi ennuyeux pour les développeurs qui doivent subir de mauvaises critiques de la part des utilisateurs qui ne comprennent pas que ce n'est pas l'application faute. Alors que Google est toujours n’a pas entièrement abordé ce problème (ils ont écarté le problème en déclarant que ce comportement était probablement déjà en violation des exigences du document de définition de compatibilité Android), la société est Prendre part contre un changement de comportement « d’économie de batterie » employé par certains constructeurs OEM.

"Pour remédier à la situation, nous avons ajouté un test CTS dans Android Q pour garantir qu'une application n'est pas supprimée après avoir été glissée depuis Récents."

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

Google prévoit d'ajouter faire défiler les captures d'écran dans Android R, mais en même temps, le L'équipe Android est "en examinant de près comment [ils] peuvent améliorer l'expérience globale de l'écran-[X] pour R." Ainsi, nous pouvons Découvrez d'autres améliorations du comportement de la capture d'écran (ET du screencast) dans la prochaine version majeure d'Android.

Clarification du nouveau mode bureau d'Android Q

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

"Dans Q AOSP, le "mode bureau" est une option de développement destinée aux développeurs d'applications. Il leur permet de tester leurs applications dans des environnements multi-écrans et en mode fenêtrage de forme libre. Auparavant, il n'existait aucun moyen pratique de tester le comportement d'une application sur un écran secondaire et avec des fenêtres librement redimensionnables sur Android d'origine. Cette fonctionnalité n’est pas produite 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 permettant aux OEM d'innover et de fabriquer d'excellents produits. »

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

Mode sombre basé sur le temps

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

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

Interrogé sur ces bugs, M. Banes déclare que « le calcul des levers et couchers de soleil est notoirement difficile, en particulier pour les endroits proches de pôles nord/sud." Un utilisateur évoque cette veilleuse, disponible depuis Android 7.1 Nougat, qui peut être basculée automatiquement en fonction du coucher/lever du soleil. des horaires. M. Banes déclare ensuite que puisque Night Light utilise CalendarAstronomer de ICU4J, il utilise un "gros morceau de code dont nous ne voudrions pas qu'AppCompat dépende". Cependant, l'équipe fait État que cette fonctionnalité est "quelque chose [qu'ils] vont examiner".

Prise en charge obligatoire de l'API Camera2/Camera HAL3 pour les appareils 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. Alors que Google encourage les fournisseurs de smartphones « exposent toutes leurs caméras physiques aux développeurs », de nombreux fournisseurs choisissent de ne pas le faire même si « l'API elle-même n'est pas les empêcher aujourd'hui. " Cela signifie que de nombreuses applications de caméra tierces ne peuvent pas utiliser les modules de caméra secondaires ou tertiaires sur les appareils photo modernes. smartphones. Des progrès sont cependant réalisés, car Android Q s'est amélioré LOGICAL_MULTI_CAMERA, une API qui donne aux développeurs un meilleur accès à toutes les caméras d'un appareil et qui permet aux OEM de contrôler la consommation d'énergie et la gestion de plusieurs états de caméra.

De plus, Google affirme avoir ajouté des exigences pour que tous les appareils lancés avec Android Q prennent en charge nativement l'API Camera2/Camera HAL3. Selon Vinit Modi:

"À partir d'Android P, les nouveaux appareils livrés avec 1 Go de RAM ou plus doivent utiliser nativement HALv3/camera2. À partir d'Android Q, tous les nouveaux appareils doivent prendre en charge nativement HALv3/camera2. Malheureusement, les mises à niveau de HALv1 vers HALv3 sont assez complexes par voie hertzienne et peuvent avoir des conséquences inattendues, c'est pourquoi nous avons dû limiter la portée aux nouveaux appareils. »

Fait intéressant, la déclaration de Modi sur les appareils de lancement RAM Android P normaux contredit ce que Google nous a dit plus tôt et ce qui est publié sur la page Image Test Suite en ligne.

Thématisation d'application dynamique avec Jetpack Compose

Le cadre de thème OMS de Sony a été ajouté à l'AOSP il y a quelques versions, mais ce n'est que destiné aux OEM sur lequel s'appuyer. Nous le savons déjà Google est contre l'utilisation de superpositions de ressources d'exécution par les utilisateurs sur les applications thématiques, mais pour les développeurs, l'entreprise est en espérant que c'est Interface utilisateur de Jetpack Compose Ce cadre proposera « des approches intéressantes en matière de thématisation dynamique ».

Vulkan-backend pour Skia pour restituer l'interface utilisateur

L'année dernière, nous avons repéré une discussion parmi les ingénieurs de Google parlant de leur projet de faire en sorte que le framework Android utilise l'API graphique Vulkan pour le rendu de l'interface utilisateur. Bien qu'il soit désormais possible d'activer le backend à accélération matérielle Vulkan sans votre téléphone crash, nous n'avons pas entendu parler de plans concrets de la part de Google quant au moment où ils envisagent de déployer ces changements. Cette AMA ne répond pas à cette question, mais au moins nous avons la confirmation qu'elle est toujours en préparation. D'après Romain Guy:

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

Rendre la barre de gestes d'Android Q plus dynamique

Certains sur XDA pensent encore que Les nouveaux gestes d'Android sont en désordre, mais personnellement, je pense qu'ils vont bien. Si vous jouez un peu avec les nouveaux gestes d'Android Q, vous remarquerez que la barre de 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 l'aperçu des applications récentes. Allen Huang dit qu'ils "sont tout à fait d'accord sur le fait qu'il existe des opportunités" pour rendre "la ligne de navigation moins statique". Il dit en outre que "c'est quelque chose sur lequel nous travaillons - mais aussi sur un équilibre pour que ce ne soit pas distrayant apparaître/disparaître."

Améliorations du cadre d'accès au stockage

Les nombreux changements apportés à Android Q ont considérablement amélioré la sécurité et confidentialité de la plateforme. L'un de ces changements, appelé « Scoped Storage », limite l'accès des applications aux fichiers sur le stockage externe d'une manière logique; les applications musicales ne devraient pas avoir besoin de voir votre galerie, par exemple. Les applications de gestion de fichiers exécutées 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 dit l'équipe a répondu à certaines des plaintes de ces développeurs :

"Nous avons apporté quelques améliorations aux performances SAF dans les dernières versions bêta d'Android Q; pourriez-vous vérifier vos benchmarks par rapport à la dernière version bêta? Assurez-vous également que vous utilisez un ContentProviderClient lors de l'exécution d'opérations groupées.

Project Treble a amélioré l'adoption d'Android Pie par rapport à Android Oreo

Nous avons déjà vu comment le Projet Treble, une réarchitecture majeure de bas niveau du framework Android, a amélioré l'adoption des nouvelles versions du système d'exploitation Android. Google attribue à Treble le mérite du grand nombre de fournisseurs de smartphones rejoignant le Android P bêta l'année dernière et Android Q bêta cette année. Iliyan Malchev, responsable du projet Treble et Ligne principale ingénieur, dit que l'adoption d'Android Pie était "3 fois" celle d'Android Oreo fin 2018.

Dans le même commentaire, Dick Dougherty indique que des mesures plus utiles sont en préparation pour le tableau de distribution des versions d'Android. Le graphique était dernière mise à jour en mai, mais ses données sont plus utiles aux journalistes qu'aux développeurs d'applications.

L'enregistrement d'écran est toujours un WIP

Les premières versions bêta 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 l'équipe réfléchissait à "la façon dont nous pourrions améliorer les besoins en matière d'enregistrement d'écran aussi récemment qu'hier". D'autres marques de smartphones comme OnePlus, ASUS, Huawei et Samsung disposent d'enregistreurs d'écran robustes capables d'enregistrer l'audio interne, Google va donc rattraper son retard ici.

Thème sombre Toutes les choses !

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

Oui, les lanceurs tiers fonctionneront avec les gestes (éventuellement)

Les gestes d'Android sont en quelque sorte cassé lorsque vous utilisez un lanceur tiers. En effet, l'interface utilisateur des applications récentes est contenue dans l'application de lancement de stock et Google ne l'a pas encore fait. trouvé un moyen d'avoir les mêmes transitions transparentes que celles que nous voyons lors de l'utilisation de gestes avec le Pixel d'origine Lanceur. Adam Cohen affirme Google prévoit de résoudre ces problèmes "le plus rapidement possible après la sortie". Il dit en outre que l'incompatibilité "sera résolue dans la mise à jour post-Q et rétroportée pour les nouveaux appareils lancés avec Q."

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

Afin de soutenir Mises à jour dynamiques du système sous Android Q, certains appareils comme le Google Pixel 3 et le Pixel 3 XL utilisent des partitions logiques. Ces partitions peuvent être redimensionnées dynamiquement. Ce changement a il s'est avéré difficile de faire fonctionner l'accès root, et certains développeurs craignent que les ROM personnalisées soient ciblées. Iliyan Malchev nous assure que l'intention n'est pas de contraindre les ROM personnalisées. Comme il explique:

"Les partitions dynamiques ne sont pas destinées à limiter ce que vous pouvez faire avec des ROM personnalisées. Elles sont simplement un solution au problème des tailles de partition fixes et de l'absence de moyen sûr de répartir les périphériques sur OTA. Avant les partitions dynamiques, si un OEM faisait une erreur de dimensionnement, par ex. la partition système, puis ils serait limité par ce choix, rendant pratiquement impossible la mise à niveau d'un appareil après un certain temps. indiquer. Certains OEM répartissent généralement leurs appareils sur OTA, mais ceci a) n'est pas officiellement pris en charge dans Android, et b) la modification de la table de partition est considérée comme assez risquée. Les partitions dynamiques visent à atténuer le problème en introduisant un niveau d'indirection entre la table de partition physique et le système d'exploitation. Cela nous permet à son tour d’ajuster en toute sécurité la taille des partitions sur OTA. En ce qui concerne les ROM personnalisées, vous ne devriez pas être du tout limité plus qu’aujourd’hui par 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.

Ligne principale du projet - Module ART et durée du support

Mainline est une nouvelle initiative de Google qui vise à standardiser certaines bibliothèques et packages afin qu'ils puissent être mis à jour indépendamment des mises à jour de la plateforme. Certains se sont demandé pourquoi Android Runtime (ART) n'est pas encore un module Mainline, mais on m'a dit chez Google I/O que la complexité impliquée dans la modularisation d'ART les a empêchés de l'inclure parmi les packages APEX initiaux. Comme expliqué par Iliyan Malchev et Diana Wong :

"Faire des mises à jour du Runtime (en particulier les correctifs de performances, de GC et les bibliothèques principales) est définitivement quelque chose que nous explorons dans le contexte de la ligne principale. Nous pouvons constater de nombreux avantages à pouvoir rendre ces mises à jour cohérentes sur tous les appareils et sur plusieurs versions avec mainline. C’est également un énorme défi technique alors que nous réfléchissons à la meilleure façon de faire cela pour les développeurs, et probablement un effort sur plusieurs années. Ce n’est pas quelque chose que Mainline peut faire actuellement, mais c’est certainement quelque chose auquel nous réfléchissons. »

Si vous suivez l'AOSP Gerrit, vous verrez que Google a néanmoins été dur au travail créer un Runtime APEX. Actuellement, ils semblent être séparation de Bionic et ART/libcore en modules APEX séparés.

Concernant les avantages du projet Mainline, un utilisateur a posé des questions sur la durée des mises à jour de Mainline. En réponse, Ilian Malchev dit que "c'est une question de politique que nous sommes encore en train d'évaluer, mais nous souhaitons mettre à jour les modules Mainline sur un appareil le plus longtemps possible". Développeur reconnu XDA luca020400 a demandé si des modules Mainline prédéfinis seraient fournis afin que les développeurs de ROM personnalisés puissent fusionner les mises à jour, et en réponse, Jeff Bailey réitère que "les modules qui se séparent de l'AOSP auront des versions sources correspondant à chaque version de module". On peut déjà voir la progression de nouveaux modules APEX dans AOSP comme celui pour le API des réseaux de neurones.

CameraX rencontre ML Kit

Lors de l'I/O de cette année, Google a présenté le Bibliothèque CameraX Jetpack. Cette bibliothèque est conçue pour permettre aux développeurs de prendre plus facilement en charge l'API Camera2 d'Android tout en conservant la compatibilité jusqu'à Android Lollipop. Vinit Modi taquine que la société travaille à l'intégration de CameraX avec Trousse ML, le SDK Firebase d'apprentissage automatique de Google, afin que les développeurs puissent introduire des images dans ML Kit à des fins d'analyse.

Extensions du fournisseur CameraX et date de sortie

Le développeur d'une application d'appareil photo déplore le fait que les fonctionnalités avancées de l'appareil photo telles que Night Sight de Google Pixel ne soient pas accessibles aux applications d'appareil photo tierces. Ceci est censé pouvoir être résolu avec les extensions du fournisseur CameraX, auxquelles Jeff Sharkey de Google dit que "tous les appareils Pixel sont optimisés pour CameraX Core". Il taquine que "l'aspect Extensions sera pris en charge sur les appareils nouveaux et à venir". De plus, Google est "travailler avec plusieurs fabricants pour pouvoir proposer les capacités de leurs appareils aux développeurs et aux utilisateurs." Bien que cela ne soit pas directement confirmé, il est possible que nous voyions des fonctionnalités comme Vue nocturne sur le GooglePixel 4 devenir disponible pour les applications de caméra tierces qui utilisent la bibliothèque CameraX.

M. Sharkey déclare que Google vise une version bêta pour la fin de cette année.

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

Le Pixel 3 a été fustigé pour avoir de nombreux problèmes après le lancement, mais Google a fait beaucoup pour résoudre ces problèmes via de nombreux 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 déployé plusieurs efforts de refactorisation importants dans Q pour réduire l'utilisation de la RAM par les notifications et autres surfaces."

Aurons-nous enfin l’ADB sans fil ?

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

Google teste-t-il toujours sur les tablettes ?

Développeur reconnu XDA Luc1337 a demandé si Google testait toujours AOSP UX sur les tablettes. C'est une bonne question compte tenu du manque de bonnes tablettes Android et le bugs présents dans les versions actuelles. Allen Huang dit que Google "teste et apporte des correctifs chaque année" et que la société travaille en étroite collaboration avec des partenaires "pour garantir une bonne expérience sur 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 Googleurs (en particulier Dianne Hackborn) expliquent leur raisonnement derrière la suppression de la fonctionnalité X ou la non-implémentation de Y autorisation. Je vous recommande de lire l'AMA complète si vous souhaitez mieux comprendre la prise de décision de l'équipe Android.

Lisez l'AMA complète sur /r/AndroidDev