Android 11 AMA: pas de captures d'écran avec défilement, lancements d'applications plus rapides, plus

Hier, Google a publié Android 11 Bêta 2, apportant le SDK finalisé, le NDK, les surfaces orientées application, les comportements de la plate-forme et les restrictions sur les interfaces non SDK pour les développeurs. Aujourd'hui, Google répond aux questions liées à Android 11 sur la communauté /r/AndroidDev de Reddit. après avoir répondu aux questions la semaine dernière. Voici un résumé de tout ce que nous avons appris de l'AMA (Ask Me Anything) de Google.

L'une des fonctionnalités les plus attendues d'Android 11 ne sera pas disponible lorsque le système d'exploitation sort de la version bêta le 8 septembre: Défilement des captures d'écran. Initialement lancement prévu dans Android 11, Google a maintenant confirmé que la fonctionnalité "n'a pas été retenue pour R". Android 11 Developer Preview 1 et toutes les versions ultérieures de DP et Beta ont un bouton d'espace réservé pour prendre une capture d'écran défilante qui peut être

fait surface manuellement avec une commande de développeur cachée, mais appuyer sur le bouton affiche simplement un message toast indiquant que la fonctionnalité n'est "pas implémentée".

Nous espérions que cette fonctionnalité serait disponible en version bêta ou même simplement en version stable, mais il semble que cela n'arrivera tout simplement pas.

Cette nouvelle va naturellement bouleverser certains utilisateurs. Après tout, de nombreux constructeurs OEM proposent cette fonctionnalité dans leur propre logiciel depuis des années. Pourquoi met-il autant de temps à Google pour l'ajouter aux téléphones Pixel? Comme l'explique Dan Sandler de l'équipe System UI de Google, le problème est que Google veut bien faire les choses. Certaines implémentations de captures d'écran à défilement émulent simplement un défilement, puis assemblent plusieurs captures d'écran au fur et à mesure que l'écran se déplace. Si vous avez déjà eu affaire à l'automatisation de l'interface utilisateur sur Android, vous saurez que cela ne fonctionne pas toujours car, comme le mentionne M. Sandler, les applications peut utiliser "un RecyclerView standard ou avoir implémenté son propre moteur de défilement accéléré par OpenGL". Puisque Google envisage de mettre en œuvre cette fonctionnalité non seulement pour les smartphones Pixel, mais pour l'ensemble de l'écosystème Android dans le cadre de l'AOSP, ils doivent s'assurer ça va marcher tous des applications et pas seulement « une ou deux applications triées sur le volet sur un appareil particulier ».

Parce que l'équipe a dû « concentrer [ses] ressources limitées », notamment en raison des défis posés À cause du COVID-19, l’équipe a décidé de mettre les captures d’écran défilantes en veilleuse pour une future version d’Android.

Nouvelle exigence CDD pour informer les utilisateurs des restrictions d'arrière-plan

Ce n’est un secret pour personne que de nombreux constructeurs Android, notamment chinois, imposent des restrictions agressives sur les applications exécutées en arrière-plan. Certains développeurs étaient tellement frustrés que leurs applications soient supprimées en arrière-plan qu'ils se sont regroupés pour créer un site Web appelé "Ne tuez pas mon application" pour classer les OEM en fonction de leur mauvaise gestion des processus d'application en arrière-plan. Ces mêmes développeurs a même récemment fait une référence afin que les utilisateurs puissent tester avec quelle agressivité leur appareil tue les applications en arrière-plan. La raison pour laquelle de nombreux OEM aiment supprimer les processus d'application en arrière-plan est compliquée, mais je pense qu'elle est mieux expliquée dans ce commentaire de Redditor /u/peut-être discutable. Le commentaire souligne la situation complexe du développement d'applications Android en Chine, ainsi que la manière dont les entreprises technologiques chinoises sont impliqués dans une complexité accrue des choses, et comment le manque de services Google contribue à la situation actuelle. désordre.

Quoi qu'il en soit, de nombreux développeurs d'applications sont naturellement frustrés par ces modifications apportées au comportement de la plate-forme Android, ce qui a conduit les développeurs à émettre un commentaire. demander à Google ce qu'ils font à ce sujet au sommet de l'AMA Reddit. Voici la réponse de Google :

Il y a quelques éléments à retenir de cette réponse. Premièrement, Google souhaite que les OEM soient plus transparents avec les utilisateurs sur les restrictions appliquées aux applications en arrière-plan. J'ai vérifié le document de définition de compatibilité (CDD) (inédit) avec Android 11 et j'ai trouvé l'ajout proposé suivant à la section 3.5 - Compatibilité comportementale des API :

Si les implémentations d'appareils implémentent un mécanisme propriétaire pour restreindre les applications et que ce mécanisme est plus restrictif que le compartiment de veille « rare » sur AOSP, elles :

[C-1-5] DOIT informer les utilisateurs si des restrictions d'application sont appliquées automatiquement à une application. (NOUVEAU) Ces informations NE DOIVENT pas être fournies plus de 24 heures avant l’application de ces restrictions.

(Remarque) L'arrêt forcé est considéré comme plus restrictif que « Rare » et DOIT respecter toutes les exigences de 3.5.1, y compris la nouvelle 3.5.1/C-1-5.

Fondamentalement, Google n'est pas grand-chose pour empêcher les OEM d'implémenter leurs propres fonctionnalités restrictives de suppression d'applications. Ils exigent uniquement que les OEM informent les utilisateurs si les restrictions de leurs applications sont automatiquement appliquées. Un OEM pourrait afficher une boîte de dialogue indiquant qu'il va empêcher les applications d'arrière-plan gourmandes en batterie de s'exécuter dans le en arrière-plan, et l'utilisateur peut consentir sans se rendre compte que les applications qu'il souhaite réellement exécuter en arrière-plan le sont également. affecté! Google impose aux développeurs la responsabilité de gérer les cas où leur application est supprimée de manière inattendue en arrière-plan. En effet, le commentaire de Reddit continue en soulignant le nouveau "raisons de sortie du processus d'application" API qui peut indiquer aux développeurs si leur application a été tuée par l'utilisateur, le système d'exploitation ou si elle a simplement planté.

D'un autre côté, Google s'attaque enfin à la pratique déloyale des OEM permettant à certaines applications privilégiées de contourner les restrictions de leurs applications en arrière-plan. Ce message Medium par le développeur Timothy Asimwe explique en détail que les applications telles que WhatsApp, Facebook et d'autres applications sont automatiquement exemptées des restrictions strictes en matière d'arrière-plan de certains logiciels OEM. Google affirme qu'ils "exigent que les fabricants d'appareils ne créent pas de listes d'autorisation pour les principales applications". Nous ne savons pas comment cela sera appliqué, mais il est bon de savoir que les constructeurs OEM seront enfin obligés de traiter les développeurs tiers sur un pied d'égalité, quelle que soit la taille de leurs applications. sont.

Enfin, Google mentionne également comment Android 11 a « ajouté des mesures supplémentaires pour empêcher les comportements abusifs liés aux applications qui se comportent mal », ce qui rend moins tentant pour les OEM de supprimer agressivement les processus en arrière-plan. L'entreprise n'a toutefois pas précisé ce qu'impliquaient ces « mesures supplémentaires ».

Sauvegardes améliorées d’appareil à appareil

Le mois dernier, nous avons repéré une modification dans la documentation d'Android 11 qui a fait allusion à la prise en charge de meilleures sauvegardes de données locales. Dans Android 11, le système ignorera l'attribut AllowBackup Manifest pour toute application ciblant le niveau d'API 30 lorsque l'utilisateur lance une migration « d'appareil à appareil » des fichiers d'application. Le googleur Eliot Stock affirme que cette fonctionnalité vise à permettre « aux fabricants de téléphones de créer beaucoup plus facilement des outils de migration d'appareil à appareil », tels que « l'excellent produit Smart Switch de Samsung » pour aider à "garantir que les applications sont transférées de manière plus fiable entre les appareils du point de vue de l'utilisateur". Malheureusement, cela ne s'applique pas aux sauvegardes basées sur le cloud, car Google souhaite « donner aux développeurs de logiciels le contrôle de ce qui se passe ». Cela se produit avec les données de leurs applications. » En tant que tel, Android 11 respectera toujours l'attribut AllowBackup pour toute sauvegarde et restauration basées sur le cloud, par exemple via Google Drive intégré au service Google Play. sauvegarde. Enfin, Google reconnaît que le plafond de sauvegarde de 25 Mo par application n'est peut-être pas suffisant pour certains développeurs, ils recherchent donc des moyens de résoudre ce problème. Les sauvegardes locales sur un PC ne sont cependant pas envisagées et Google réitère son intention de le faire. supprimer progressivement la sauvegarde adb dans une future version d'Android.

Les développeurs sont encouragés à mettre en œuvre des méthodes de migration de données fluides. Le nouvelle bibliothèque Block Store, qui fait partie de la bibliothèque Google Identity Services, est conçu pour faciliter la connexion aux applications restaurées. du cloud sur les nouveaux appareils, mais c'est aux développeurs de choisir s'ils souhaitent ou non implémenter cela bibliothèque.

Vitesses de démarrage des applications plus rapides grâce au processus de lecture anticipée des E/S (IORap)

Google expérimente toujours des moyens d'améliorer les performances d'Android. L’une des fonctionnalités peu connues ajoutées à Android 10 s’appelle USAP (Unspecialized App Process Pool). Cette fonctionnalité élimine le forking de Zygote pendant le processus de démarrage de l'application, ce qui permet d'économiser environ environ 5 ms de vitesse moyenne de démarrage de l'application sur un appareil Pixel 2. La fonctionnalité est actuellement désactivé par défaut dans AOSP, et Google explique que son utilisation de mémoire supplémentaire doit encore être testée. Ce qui est plus intéressant, cependant, est une nouvelle fonctionnalité à venir sur Android 11 appelée I/O Read Ahead Process (IORap). Selon Google, cette fonctionnalité entraînera « des démarrages à froid plus de 5 % plus rapides, les cas héros atteignant 20 % plus rapidement ». Cette fonctionnalité "pré-récupèrera les artefacts des applications (comme le code et les ressources) pendant le processus de démarrage" pour stimuler le lancement de l'application vitesses.

Google a également "apporté des améliorations aux profils utilisés pour optimiser le chemin de classe de démarrage et l'image système". ce qui améliorera les performances de l'application et réduira les coûts de mémoire et de stockage associés au système artefacts. Ces changements bénéficieront principalement aux appareils dotés de quantités de RAM plus élevées, bien que Google n'ait pas indiqué quelle est la limite pour laquelle nous verrons le plus d'avantages.

Modifications du stockage étendu d'Android 11 - Pourquoi l'accès aux/Téléchargements est-il restreint?

Applications qui ciblent Android 11 et utilisent l'intention ACTION_OPEN_DOCUMENT_TREE pour demander l'accès à des répertoires spécifiques sur le serveur externe. le stockage ne pourra plus demander aux utilisateurs l'accès au répertoire racine du stockage externe (/data/media/{user}), le téléchargement répertoire (/data/media{user}/Download), ou l'un des répertoires de données spécifiques à l'application sur le stockage externe (/Android/data ou /Android/obb). Pourquoi l'accès au répertoire de téléchargement est-il restreint? Selon Google Roxanna Aliabadi, c'est parce que le dossier de téléchargement "est le plus susceptible de contenir des informations privées". A titre d'exemple, les utilisateurs qui téléchargent leur taxe les déclarations ou les relevés bancaires ne devraient pas avoir à s'inquiéter de la possibilité que des applications abusent de leur accès continu en lecture au annuaire. Google indique que le sélecteur de documents aura "un texte mis à jour... pour indiquer qu'Android a restreint certains dossiers être sélectionné." Nous espérons que cela réduira la confusion sur les raisons pour lesquelles ils ne peuvent pas accorder aux applications l'accès à certains répertoires. plus.

Pour plus d’informations sur les prochaines modifications apportées aux politiques Scoped Storage and Play, référez-vous à cet article.

Sujets divers

• La position de Google sur le root/modding
  • Jeff Bailey de l'équipe AOSP de Google réitère la position de l'entreprise en faveur du choix. Google "continuera à garantir que le modding/rooting de la gamme d'appareils Pixel est possible", mais "soutenira également le choix des constructeurs OEM de ne pas autoriser leurs appareils". être rooté. » De plus, Google donne aux développeurs de logiciels le choix « de ne pas permettre à leurs logiciels de s'exécuter sur des appareils rootés », en référence aux récents changements dans détection de falsification logicielle de l'API d'attestation SafetyNet.
• Qu'est-il arrivé à « ouvrir et définir par défaut » ?
  • Android 10 créé c'est un peu ennuyeux de définir une application comme gestionnaire par défaut pour des liens spécifiques, qui, selon Google, ont été créés pour protéger les utilisateurs contre les « applications exploitantes ». Google a fait marche arrière sur ce changement après l'avoir repensé, en effectuant un "nombre de changements en coulisses" pour protéger l'utilisateur.
• Vous utilisez l'API Vulkan Graphics pour restituer l'interface utilisateur ?
  • Google envisage à terme d'utiliser l'API Vulkan Graphics pour restituer l'interface utilisateur, ce qui entraînera certaines améliorations de performances. C'est toujours en cours d'évaluation, mais la société n’avait aucun détail à partager.
• CallScreeningService manquant sur de nombreux appareils
  • Les applications Android peuvent implémenter le API CallScreeningService pour intercepter les nouveaux appels entrants et sortants, leur permettant d'identifier l'appelant et d'accepter ou de rejeter l'appel. Bien qu'il s'agisse d'une API officiellement documentée, il semble que de nombreux OEM ne l'implémentent pas correctement, selon le développeur /u/._zéromod_. Google confirme que cette API est validée par la Compatibility Test Suite (CTS), une suite de tests automatisés que tous les appareils doivent réussir pour être considérés comme compatibles avec Android. Pour une raison quelconque, cette API renvoie null lorsqu'elle est appelée sur des appareils de constructeurs OEM tels que Huawei, Vivo, Xiaomi ou Samsung. Il est donc probable que ces constructeurs OEM aient un bug dans leur logiciel.
• Aucun projet pour un framework de plugin audio
  • Un développeur a demandé à Google s'il prévoyait d'implémenter un framework de plugin audio comme Audio Units d'Apple, mais la réponse c'est qu'il est peu probable que cela se produise dans un avenir proche.

Vous pouvez lire toutes les réponses de l'équipe d'ingénierie Android ici. L'équipe parle un peu de Java, de Kotlin, du système de build Android, de l'API CameraX et d'autres sujets dans quelques commentaires. Il existe également plusieurs commentaires sur Wear OS, Android TV et Android Auto, mais Google réitère principalement leur travail existant sur ces plates-formes et demande aux développeurs de rester à l'écoute pour plus d'informations pendant la "Android au-delà des téléphones" semaine commençant le 10 août.