IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google publie la première bêta d'Android 13 « Tiramisu »
L'OS mobile dispose d'un nouveau système d'autorisation pour les fichiers multimédias

Le , par Stéphane le calme

28PARTAGES

16  0 
Google a publié mardi la première version bêta d'Android 13, la prochaine itération de son système d'exploitation mobile. Appelée en interne « Tiramisu », la version bêta fait suite à un aperçu du développeur qui a fait ses débuts en février. Android 13 propose une nouvelle autorisation dans l'environnement d'exécution pour envoyer des notifications à partir d'une application, un sélecteur de photos système pour partager des photos et des vidéos en toute sécurité avec des applications, des icônes d'application thématiques et une meilleure localisation, entre autres. La version bêta ajoute des autorisations plus spécifiques pour accéder aux fichiers multimédias. Auparavant, lors de la tentative de lecture de fichiers multimédias stockés localement, Android demandait l'autorisation READ_EXTERNAL_STORAGE. Cela donnait accès à tout. Les nouvelles autorisations sont plus précises : READ_MEDIA_IMAGES, READ_MEDIA_VIDEO et READ_MEDIA_AUDIO.

La prochaine version majeure de l’OS de Google était dans sa phase Developer Preview en attendant que Google lance la bêta. Ce mardi 26 avril 2022, Google a déployé Android 13 Bêta 1.

Dave Burke, VP of Engineering dans l'équipe Android, a expliqué que :

« Nous sommes déjà en avril et nous avons fait des progrès constants en affinant les fonctionnalités et la stabilité d'Android 13, construit autour de nos thèmes principaux de confidentialité et de sécurité, de productivité des développeurs, ainsi que de prise en charge des tablettes et des grands écrans. Aujourd'hui, nous entrons dans la phase suivante de notre cycle et publions la première version bêta d'Android 13.»

« Pour les développeurs, il y a beaucoup à explorer dans Android 13, des fonctionnalités de confidentialité telles que la nouvelle autorisation de notification et le sélecteur de photos, aux API qui vous aident à créer de superbes expériences, comme les icônes d'application thématiques, le placement rapide des tuiles de paramètres et la prise en charge de la langue par application, ainsi que des fonctionnalités telles que l'audio Bluetooth LE et MIDI 2.0 via USB. Dans la version bêta 1, nous avons ajouté de nouvelles autorisations pour un accès plus précis aux fichiers multimédias, des API de routage audio améliorées, et bien plus encore ».


Quoi de neuf dans la bêta 1 ?

Des autorisations plus précises pour l'accès aux fichiers multimédias

Auparavant, lorsqu'une application voulait lire des fichiers multimédias partagés dans le stockage local, elle devait demander l'autorisation READ_EXTERNAL_STORAGE, qui donnait accès à tous les types de fichiers multimédias. Pour apporter plus de transparence et de contrôle aux utilisateurs, Google a introduit un nouvel ensemble d'autorisations avec une portée plus granulaire pour accéder aux fichiers multimédias partagés.

Avec les nouvelles autorisations, les applications demandent désormais l'accès à un type de fichier spécifique dans le stockage partagé :
  • READ_MEDIA_IMAGES (pour les images et les photos) ;
  • READ_MEDIA_VIDEO (pour les vidéos) ;
  • READ_MEDIA_AUDIO (pour les fichiers audio).


La figure ci-dessus montre un exemple de boîte de dialogue orientée utilisateur qui s'affiche lorsque votre application demande l'une des autorisations indiquées dans la liste à puces précédente. Dans ce cas précis, l'application demande l'autorisation READ_MEDIA_AUDIO.

Lorsque les autorisations sont accordées par l'utilisateur, les applications auront un accès en lecture aux types de fichiers multimédias respectifs. Pour simplifier l'expérience des utilisateurs, si une application demande READ_MEDIA_IMAGE et READ_MEDIA_VIDEO en même temps, le système affiche une seule boîte de dialogue pour accorder les deux autorisations. Si votre application accède à des fichiers multimédias partagés, vous devrez migrer vers les nouvelles autorisations lorsque votre application ciblera Android 13.

Cette nouveauté ne devrait toutefois pas se limiter à Android 13. Tous les appareils sous Android 11 ou tournant sur une version plus récente pourront y prétendre dans les mois qui viennent.

Meilleur rapport d'erreur dans Keystore et KeyMint

Pour les applications qui génèrent des clefs, Keystore et KeyMint fournissent désormais des indicateurs d'erreur plus détaillés et précis. Google a ajouté une hiérarchie de classes d'exceptions sous java.security.ProviderException, avec des exceptions spécifiques à Android qui incluent les codes d'erreur Keystore/KeyMinte. Vous pouvez également modifier les méthodes de génération de clef, de signature et de chiffrement pour lever les nouvelles exceptions. Le rapport d'erreur amélioré devrait maintenant vous donner ce dont vous avez besoin pour réessayer la génération de clef.

Routage audio anticipé

Pour aider les applications multimédias à identifier comment leur audio va être routé, Google a ajouté de nouvelles API de routage audio dans la classe AudioManager. La nouvelle API getAudioDevicesForAttributes() vous permet de récupérer une liste d'appareils pouvant être utilisés pour lire l'audio spécifié, et Google a ajouté l'API getDirectProfilesForAttributes() pour vous aider à comprendre si votre flux audio peut être lu directement. Utilisez ces nouvelles API pour déterminer le meilleur format audio à utiliser pour votre piste audio.

Compatibilité des applications

Si vous n'avez pas encore testé la compatibilité de votre application avec Android 13, c'est le moment de le faire ! Avec Android 13 désormais en version bêta, Google ouvre l'accès aux utilisateurs précoces ainsi qu'aux développeurs. Cela signifie que dans les semaines à venir, vous pouvez vous attendre à ce que davantage d'utilisateurs essaient votre application sur Android 13 et signalent les problèmes qu'ils trouvent.

Pour tester la compatibilité, installez votre application publiée à partir de Google Play ou d'une autre source sur un appareil ou un émulateur exécutant Android 13 Beta et parcourez tous les flux de l'application. Passez en revue les changements de comportement pour cibler vos tests. Après avoir résolu les problèmes, publiez une mise à jour dès que possible.

Google indique « qu'avec la version bêta, nous nous rapprochons de la stabilité de la plateforme en juin 2022. À partir de là, les comportements système liés aux applications, les API SDK/NDK et les listes non SDK seront finalisés. À ce moment-là, vous devez terminer vos tests de compatibilité finaux et publier une version entièrement compatible de votre application, SDK ou bibliothèque ».

Quels sont les smartphones compatibles ?

Cette première bêta destinée au grand public n’est disponible que sur un nombre limité d’appareils. Comme pour la Developer Preview, il faut disposer d’un Pixel compatible et voici les différents modèles pris en charge : Pixel 4, Pixel 4 Xl, Pixel 4a, Pixel 4a (5G), Pixel 5, Pixel 5a, Pixel 6 et Pixel 6 Pro.

Si votre smartphone est compatible, la méthode la plus simple consiste à s’inscrire au programme Android Bêta. Vous pourrez alors activer votre appareil éligible et vous rendre dans les paramètres de l’appareil pour demander la mise en jour en OTA (Over-The-Air). Même si la méthode est simple, il est déconseillé d’installer Android 13 Beta 1 sur votre appareil principal. En effet, les risques de bogues sont nombreux et des problèmes d’instabilité peuvent survenir.

Mais si après avoir découvert l'ensemble des nouveautés de cette bêta vous voulez quand même tenter l’expérience, pensez à sauvegarder vos données au préalable.

Quels éléments ont été apportés par la Developper Preview

Android 13 dispose d'un nouveau sélecteur de photos intégré, remplaçant le gestionnaire de fichiers qui s'affichait pour sélectionner des photos. Le but ici n'est pas que le sélecteur de photos ressemble ou fonctionne différemment du gestionnaire de fichiers ; au lieu de cela, il vous permet d'envoyer une seule photo à une application sans accorder à cette application l'accès à l'autorisation de stockage.

Une application qui n'a pas accès au stockage peut appeler le sélecteur de documents du système (qui dispose d'un accès au stockage), et le sélecteur peut transférer l'accès au fichier unique que vous avez sélectionné. Il semble que le sélecteur de photos fournira la même chose pour les photos. Google indique que cette fonctionnalité nécessitera de nouvelles « API de sélection de photos », qu'une application devrait prendre en charge. Un système sans doute idéal pour des outils comme les applications de messagerie par lesquelles les utilisateurs veulent partager une image ou des applications qui n'ont besoin que d'une photo pour permettre à l'utilisateur d'étoffer son profil.

Android 13 introduit l'autorisation d'exécution NEARBY_WIFI_DEVICES (qui fait partie du groupe d'autorisations NEARBY_DEVICES) pour les applications qui gèrent les connexions d'un appareil aux points d'accès à proximité via Wi-Fi. La nouvelle autorisation sera requise pour les applications qui appellent de nombreuses API Wi-Fi couramment utilisées et permet aux applications de découvrir et de se connecter aux appareils à proximité via Wi-Fi sans avoir besoin d'une autorisation de localisation. Auparavant, les exigences d'autorisation de localisation étaient un défi pour les applications qui devaient se connecter à des appareils Wi-Fi à proximité, mais n'avaient pas réellement besoin de l'emplacement de l'appareil. Les applications ciblant Android 13 pourront désormais demander l'autorisation NEARBY_WIFI_DEVICES avec le drapeau "neverForLocation", ce qui devrait aider à promouvoir une conception d'application respectueuse de la vie privée tout en réduisant les frictions pour les développeurs.


Dans Android 13, Google étend la couleur dynamique Material You au-delà des applications Google à toutes les icônes d'application, permettant aux utilisateurs d'opter pour des icônes qui héritent de la teinte de leur fond d'écran et d'autres préférences de thème. Tout ce que votre application doit fournir est une icône d'application monochrome (par exemple, votre notification pouvant être dessinée) et une modification de l'icône adaptative XML.

L'éditeur encourage tous les développeurs à fournir des icônes compatibles pour aider à offrir une expérience cohérente aux utilisateurs qui se sont inscrits. Les icônes d'application thématiques sont initialement prises en charge sur les appareils Pixel et Google travaille avec ses partenaires fabricants d'appareils pour les proposer à plus d'appareils.

Certaines applications permettent aux utilisateurs de choisir une langue différente de la langue du système, pour répondre aux besoins des utilisateurs multilingues. Ces applications peuvent désormais appeler une nouvelle API de plateforme pour définir ou obtenir la langue préférée de l'utilisateur, ce qui permet de réduire le code passe-partout et d'améliorer la compatibilité lors de la définition de la langue d'exécution de l'application. Pour une compatibilité plus large, Google va ajouter une API similaire dans une prochaine bibliothèque Jetpack.

Source : Android

Et vous ?

Que pensez-vous de ces améliorations ? Quelle(s) est/sont celle(s) qui vous intéresse(nt) le plus ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de OrthodoxWindows
Membre expérimenté https://www.developpez.com
Le 30/04/2022 à 0:34
Que pensez-vous de ces améliorations ? Quelle(s) est/sont celle(s) qui vous intéresse le plus ?
Concernant l'amélioration de la gestion des autorisations d’accès aux fichiers, ce n'est pas trop tôt. Windows est capable de ça depuis la première version . D’ailleurs Android n'est pas vraiment sécurisé : https://forum.malekal.com/viewtopic....2916e125899ea9 .
Concernant Material You, ce n'est pas fondamentalement une nouveauté. Par exemple, j'utilise Windows avec le thème classique (le thème de Windows pendant les années 1990), et le comportement du thème classique est très proche de Material You et des autres interfaces du même genre. Par exemple, quand je change une couleur, tous les programmes s'adaptent à ce changement. Autre chose : sous le thème classique, les boutons sont dessinés par GDI et par des caractères de polices, donc de manière vectorielle....exactement comme les interfaces web les plus "moderne" ! Les designers web n'ont rien inventé.

Dans l'ensemble aucune de ces amélioration ne m'intéresse, car je n'utilise pas Android pour ces raisons (je l'ai déjà évoqué plus haut) :

1. L'interface utilisateur qui m'est rédhibitoire (juste un écran avec des icônes, peu de personnalisation, aucune intégration des applications les unes par rapport aux autres).
2. L'architecture générale du système (infrastructure volumineuse injustifiée au-dessus du noyau Linux, il n'existe pas d'exécutable Android...).
3. L'offre des applications disponibles (principalement, des applications de loisir, pas de travail, et plus des deux tiers des applications Android/IOS sont soi gratuite contre revente de données personnelles, soit payantes, alors que des équivalents libres et gratuits existe sous Windows/GNU/Linux/Mac).
4. Le fonctionnement des applications ; la plupart des applications sont écrite en JavaScript ou un autre langage de développement web. Ce ne sont pas des vrais programmes mais des applications web, et cela à une conséquence sur la consommation d'électricité (minimisé par le CPU ARM64, mais c'est quant même du gâchis).
5. L’architecture des systèmes mobiles que je considère liberticides ; pour Android, le smartphone est vendu non enraciner, alors qu'un PC est vendu enraciner.
6. La difficulté de stopper la géolocalisation de Google

Si utiliser un Android tiers (genre E/OS, LineageOS) est une solution pour le 5. et le 6., pour les autre, ça ne change quasiment rien.
2  3 
Avatar de calvaire
Membre expert https://www.developpez.com
Le 12/09/2022 à 14:19
il faudrait m'expliquer ou part la ram (et le cpu).
Que ce soit de windows 95 à windows 11 ou d'android 4 à android 13, il n'y a pas eu grand chose en plus pour l'utilisateur justifiant une hausse de la consommation des ressources.

La plupart des utilisateurs utilise leurs téléphones pour regarder une vidéo sur youtube/réseaux sociaux, consulter des mails, envoyer des sms, gps et prendre une photo.
Bref des usages bureautique qu'un os light et bien optimisé suffirait.

le problème quand on lance android et windows 10/11 ce sont les tonnes de bloatware qui tourne en arrière plan qui bouffe des ressources et de la batterie inutilement. Les services de google play en 1er, essayer une rom custom sans c'est le jour et la nuit niveau perf et autonomie.
Meme remarque sous windows 11, sans les merde MS d'arriere plan c'est 2 fois moins énergivore et encore je suis gentil.
0  1