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 !

La virtualisation Android 13 permet au Pixel 6 d'exécuter Windows 11 et des distributions Linux
Telles que Ubuntu ou Arch Linux Arm

Le , par Stéphane le calme

169PARTAGES

8  0 
Conformément à sa feuille de route, Google a annoncé le 10 février la disponibilité de la première version développeur d'Android 13. 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.

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. Android 13 apporte également de nouvelles fonctionnalités et de nouveaux outils pour la productivité des développeurs.

Il existe également un joyau caché avec une virtualisation complète possible sur du matériel tel que le smartphone Google Pixel 6. Cela signifie qu'il est désormais possible d'exécuter pratiquement n'importe quel système d'exploitation, y compris Windows 11, les distributions Linux telles qu'Ubuntu ou Arch Linux Arm sur le téléphone alimenté par Google Tensor, et ce, à une vitesse quasi native.

Le développeur Android et Web répondant au pseudonyme "kdrag0n" sur Twitter a testé plusieurs distributions Linux compilées pour Aarch64 sur Pixel 6 avec Ubuntu 21.10, Arch Linux Arm, Void Linux et Alpine Linux en utilisant "l'hyperviseur KVM sur Pixel 6 + Android 13 DP1". Il/elle explique en outre :

« Autant que je sache, nous pouvons à peu près obtenir EL2 complet sur les appareils de production maintenant. Le KVM protégé est facultatif et peut être activé sur une base par VM, mais pour les VM non protégées, il semble que la fonctionnalité KVM complète soit disponible ».

EL2 fait référence aux niveaux d'exception Arm, comme expliqué sur le site Web du développeur Arm. kdrag0n ne s'est pas arrêté là et a réussi à faire fonctionner Windows 11 sur le Pixel 6 également via la même virtualisation Android 13.


Super, le Windows Phone est de retour ! Plus sérieusement, nous devrons voir si tout fonctionne comme prévu, mais cela semble prometteur.

La virtualisation sur Android aujourd'hui est « le Far West de la fragmentation », selon Will Deacon de l'équipe Android Systems. Mais pourquoi Google a-t-il activé la virtualisation dans Android ? Il est peu probable qu'ils veuillent simplement laisser les utilisateurs installer Linux ou Windows sur le téléphone. Mishaal Rahman, Senior Technical Editor chez Esper a abordé ce problème il y a environ deux mois.

Il a noté que les hyperviseurs peuvent être présents ou non sur un appareil, et lorsqu'ils le sont, ils ne sont souvent même pas utilisés aux fins prévues, à savoir exécuter un système d'exploitation dans une machine virtuelle ! Au lieu de cela, ils sont utilisés pour des choses comme améliorer la sécurité du noyau (ou au moins, essayer de le faire) et exécuter divers codes (tels que du code tiers pour DRM, la cryptographie et d'autres binaires à source fermée) en dehors du système d'exploitation Android.

Pour comprendre pourquoi ce dernier est particulièrement problématique, considérons que dans le modèle d'exception Armv8/v9, l'hyperviseur s'exécute au niveau d'exception 2 (EL2). Dans la nomenclature Arm, plus le nombre est élevé, plus le niveau de privilège est élevé, ce qui signifie que le code exécuté à EL0 (par exemple, les applications de l'espace utilisateur) est le moins privilégié, le code exécuté à EL1 (par exemple, le système d'exploitation Android et le noyau Linux) est plus privilégié, etc. Ainsi, de nombreux blobs binaires tiers opaques s'exécutent avec des privilèges plus élevés même que le système d'exploitation et le noyau ! Ceci est préjudiciable à la sécurité, car cela augmente la surface d'attaque du code privilégié pouvant être exploité, car le code s'exécutant à un EL supérieur peut accéder à tous les registres des niveaux inférieurs.


Afin à la fois de priver ce code tiers et d'isoler ce code d'Android et d'autres programmes tiers, Google s'efforce d'apporter une solution d'hyperviseur commune au-dessus de laquelle une machine virtuelle s'exécutant au même niveau de privilège que le système d'exploitation et le noyau exécutera ce code. Il existe un mécanisme de virtualisation du noyau mature appelé KVM qui est déjà pris en charge par Linux, donc naturellement Google a choisi de le déployer en tant qu'hyperviseur commun. Et grâce aux efforts continus de Google pour réduire la fragmentation du noyau, KVM peut être activé sur un large éventail d'appareils Android équipés d'une version récente de la GKI.

Mishaal Rahman a souligné que Google étend en fait KVM avec des fonctionnalités de sécurité supplémentaires et l'appelle pKVM, ou "KVM protégé". pKVM est conçu pour permettre la confidentialité des données dans une machine virtuelle, même si le système d'exploitation est compromis. L'implémentation était alors disponible dans la ligne principale, branches android13-5.10 et android13-5.15 Android Common Kernel.

Pour gérer ces machines virtuelles, Google porte sur Android crosvm, le gestionnaire de machines virtuelles basé sur Rust (VMM) utilisé pour exécuter des applications Linux sur Chrome OS, et Mishaal Rahman notait qu'il serait livré aux appareils via un nouveau module Mainline appelé "Virtualisation" ( com.android.virt) : « Actuellement, aucun appareil Android sur le marché n'est livré avec le module de virtualisation - pas même le propre Pixel 6 de Google - mais cela devrait changer avec la prochaine version d'Android 13. En effet, Google teste actuellement ses nouveaux outils de virtualisation sur le Pixel 6 ; si vous construisez AOSP avec la cible aosp_oriole_pkvm, vous constaterez que com.android.virt sera automatiquement hérité. Je ne sais pas si Google activera pKVM sur la série Pixel 6 avec la mise à jour Android 13, mais il est prouvé que Google prévoit qu'Android 13 inclura la première version de l'hyperviseur pKVM et du framework de machine virtuelle ».

Si vous êtes intéressé par l'historique complet des efforts de Google pour apporter KVM aux appareils Android, regardez le discours de Will Deacon lors du forum KVM de l'année dernière :


La virtualisation est donc principalement apportée pour des besoins de sécurité et les binaires comme DRM.

Code source du module de virtualisation
guide expliquant comment démarrer avec les machines virtuelles protégées

Source : kdrag0n

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

Avatar de calvaire
Expert confirmé https://www.developpez.com
Le 15/02/2022 à 18:35
Citation Envoyé par OrthodoxWindows Voir le message

Cela est une pure aberration (pour ne pas dire une stupidité) technologique ; pourquoi virtualiser une distribution Linux alors qu’Android est construit sur un noyau Linux ?!? Utilisez GNUroot, Termux et un serveur X plutôt que de stupidement virtualiser au détriment des performances. Ou encore mieux, installez GNU/Linux parallèlement, ou à la place d'Android. Il existe des distributions spécifiques aux smartphones, comme PostMarketOS.
il y'a tres peu de perte de performance en virtualisation, du moins sur x86, sous vmware ou hyperv on a des perf quasi native.
Tu peux voir les bench de wsl2 (qui tourne sous hyperv), c'est pareil que du linux natif
ce qui manque dans la virtualisation c'est une bonne accelation graphique... mais ayant déja testé hangover c'est le même problème aussi (qui fait de l'émulation et donc perte du gpu)

et enfin windows arm émule mieux les app x86 que wine/hangover, il peut y avoir un intérêt a passé par windows

As ton l'acceleration graphique de supporté avec la virtualisation sous android 13 ?
2  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 14/02/2022 à 22:46
les hyperviseurs peuvent être présents ou non sur un appareil, et lorsqu'ils le sont, ils ne sont souvent même pas utilisés aux fins prévues, à savoir exécuter un système d'exploitation dans une machine virtuelle ! Au lieu de cela, ils sont utilisés pour [...] exécuter divers codes (tels que du code tiers pour DRM, la cryptographie et d'autres binaires à source fermée) en dehors du système d'exploitation Android. .

[...] Ainsi, de nombreux blobs binaires tiers opaques s'exécutent avec des privilèges plus élevés même que le système d'exploitation et le noyau ! Ceci est préjudiciable à la sécurité...


C'est assez fou en termes de conception de sécurité. Je me demande pourquoi on n'entend pas plus parler de rootkit : les gens qui savent sont déjà sous secret-défense ou bien ?
1  0 
Avatar de calvaire
Expert confirmé https://www.developpez.com
Le 17/02/2022 à 9:13
Citation Envoyé par OrthodoxWindows Voir le message
J'en suis donc arrivé à la conclusion qu'il n'est pas possible sous Linux d'utiliser des applications portables ultralégère et non conteneurisée, alors que cela fonctionne impeccablement sous Windows. Je ne suis pas un spécialiste de Linux (donc j'ai encore le temps d'apprendre à l'apprécier), mais je préfère largement la gestion des bibliothèques et la gestion des paramètres (base de registre) de Windows.
techniquement si, j'ai déjà fait des applications python et c portable sous linux.
mais dans la réalité, sous linux on fait des conteneurs car c'est plus pratique.

Citation Envoyé par OrthodoxWindows Voir le message

-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, et cela à une conséquence sur la consommation d'électricité (minimisé par le CPU ARM64, mais c'est quant même du gâchis).
je ne vois pas en quoi un programme codé en js ne serait pas une vrai application, qu'es ce qu'une vrai application ? du code compilé en assembleur ?
le java est executé dans une machine virtuel, les programmes java ne sont pas des vrai applications ?
python est interprété, les programmes python ne sont pas de vrai applications ?

MS a fait beaucoup d'applications web dans le passé (windows 98, xp...), les html application (fichiers .HTA)
1  0 
Avatar de calvaire
Expert confirmé https://www.developpez.com
Le 16/02/2022 à 9:42
Citation Envoyé par OrthodoxWindows Voir le message

Dans mon usage, j'utilise la virtualisation uniquement à des fins de test de système d'exploitation, et pour WSL (dans Linux, il n'y a pas besoin de virtualiser Windows grâce à Wine). Je n'utilise aucun système de sandbox, et je privilégie les programmes en code non managé. Et surtout je boycotte les systèmes possédant des applications écrites la plupart du temps en JavaScript et en plus sandboxées (c'est-à-dire Android et IOS).
Windows est tres en retard sur ce sujet, sous linux il y'a énormément d'applie tournant sous docker désormais.
en dev, je n'installe plus quasi de composants depuis des années, je télécharge un conteneur mariadb, elastic search, fluentd...

les nouveaux package linux snap et flatpak sont très populaire et tourne dans des conteneurs. 100% des desktops linux désormais utilise des applications conteneurisé.

moi je ne comprends pas l’intérêt d'installer des applications en dur dans l'os en dehors des pilotes. Tous devrait tourner dans des conteneurs.
Alors les contres c'est qu'on ne peut plus partager des librairies entre plusieurs applications, donc cela engendre une plus grosse consommation de mémoire. Mais les bénéfices sont très intéressants aussi, surtout à une époque ou la ram n'est plus vraiment un probleme, on est plus dans les années 90 ou lancer simplement la jvm freeze la machine
2  2 
Avatar de bdr443
Membre du Club https://www.developpez.com
Le 16/02/2022 à 16:29
Et surtout je boycotte les systèmes possédant des applications écrites la plupart du temps en JavaScript et en plus sandboxées (c'est-à-dire Android et IOS).
@OrthodoxWindows tu as piqué ma curiosité. Pourquoi tu boycott les systèmes utilisant des applis sand
0  0 
Avatar de OrthodoxWindows
Membre émérite https://www.developpez.com
Le 16/02/2022 à 18:57
Citation Envoyé par calvaire Voir le message
Windows est tres en retard sur ce sujet, sous linux il y'a énormément d'applie tournant sous docker désormais.
en dev, je n'installe plus quasi de composants depuis des années, je télécharge un conteneur mariadb, elastic search, fluentd...

les nouveaux package linux snap et flatpak sont très populaire et tourne dans des conteneurs. 100% des desktops linux désormais utilise des applications conteneurisé.
J'utilise Debian Linux, et il ne me semble pas y avoir beaucoup d'applications conteneurisées. Mais j'ai pour l'instant moins d'expérience sous Linux que sous Windows, je peux donc me tromper. Je suis cependant quasi-sur de n'avoir installé aucun package snap ou flatpak.

Citation Envoyé par calvaire Voir le message
moi je ne comprends pas l’intérêt d'installer des applications en dur dans l'os en dehors des pilotes. Tous devrait tourner dans des conteneurs.
Alors les contres c'est qu'on ne peut plus partager des librairies entre plusieurs applications, donc cela engendre une plus grosse consommation de mémoire. Mais les bénéfices sont très intéressants aussi, surtout à une époque ou la ram n'est plus vraiment un probleme, on est plus dans les années 90 ou lancer simplement la jvm freeze la machine
En fait, c'est un peu le contraire pour moi ; je ne comprends pas l'intérêt d'installer des applications dans des conteneurs. Concernant les avantages, je ne les perçois pas beaucoup ; je n'ai jamais de problèmes de sécurité, car je connais ce que j'installe, cela me suffit. Au niveau de compatibilité/portabilité accrue, le problème est peux être plus présents sous GNU/Linux que sous Windows. Sous Windows les librairies sont partagées entre les applications tant qu'il n'y a pas besoin d’effectuer de modification ; sinon, la charge revient au magasin de composant, ou les bibliothèques ne sont pas partagées. Ce fonctionnement a commencé avec Windows XP, et fonctionne très bien. Le seul problème est la taille très volumineuse du magasin de composant (winsxs). L'autre avantage de Windows est les applications portables, qui contiennent leur propre bibliothèque pour des tâches spécifiques, et utilise les bibliothèques du système pour les autres tâches. Sous Debian GNU/Linux, j'ai eu tout de suite eu beaucoup de difficulté lors de l'installation des applications (dès lors que l'application ne se situait pas dans APT-get) ; j'ai donc assez vite recherché une solution alternative. Je me suis effectivement rendu à l'évidence que le seul moyen d'utiliser des applications portables (et de me débarrasser des conflits incessants de bibliothèques, et autre problème lors de l'installation) sous Linux était d'utiliser des conteneurs. J'en suis donc arrivé à la conclusion qu'il n'est pas possible sous Linux d'utiliser des applications portables ultralégère et non conteneurisée, alors que cela fonctionne impeccablement sous Windows. Je ne suis pas un spécialiste de Linux (donc j'ai encore le temps d'apprendre à l'apprécier), mais je préfère largement la gestion des bibliothèques et la gestion des paramètres (base de registre) de Windows.
0  0 
Avatar de destroyedlolo
Membre actif https://www.developpez.com
Le 18/02/2022 à 11:33
Déjà Linux ne se résume pas à son kernel. D'autant plus qu'il est bien bidouillé pour Android et que les drivers sont externalisés sous Android.
Alors oui, on peut lancer un serveur X ou un terminal, mais ce n'est pas un Unix complet.

Pour la containérisation, je n'utilise quasiment que ca au taf car, avec Kubernetes, cela facilite grandement l'exploitation.
Maintenant, sur mes PC persos (sous Gentoo), le seul conteneur que j'utilisais était pour un logiciel de montage vidéo dont les dépendances étaient tellement pourries qu'elles foutaient la grouille dans les autres applications. Depuis, je suis passer a Shotcut qui non seulement est plus puissant mais n'a pas ces problèmes.

Par contre, pour les Dev, ca reste très utile pour basculer d'une version a une autre.
0  0 
Avatar de OrthodoxWindows
Membre émérite https://www.developpez.com
Le 16/02/2022 à 18:14
Citation Envoyé par bdr443 Voir le message
@OrthodoxWindows tu as piqué ma curiosité. Pourquoi tu boycott les systèmes utilisant des applis sand
Il s'agit d'une préférence personnelle, j’apprécie les programmes qui sont "direct" et n’empruntent pas des milliards de couche pour s'exécuter ; je n'apprécie pas la définition de l'application comme un objet "à part" dans un système. Une application/programme est d'abord un fichier exécutable (compilé ou interprété), et je considère les programmes comme n'importe quels autres fichiers. Cependant, ce n'est pas qu’à cause des applications sandboxées que je boycotte Android et IOS c'est à cause d'un ensemble d'éléments.

-L'interface utilisateur qui m'est rédhibitoire (juste un écran avec des icônes, pas de personnalisation, aucune intégration des applications les unes par rapport aux autres)
-L'architecture générale du système (infrastructure volumineuse injustifiée au-dessus du noyau Linux/Darwin, il n'existe pas d'exécutable Android...)
-L'offre des applications disponibles (principalement, des applications de loisir, pas de travail, et plus des deux tiers des applications Android/IOS sont soit gratuite contre revente de données personnelles, soit payantes, alors que des équivalents libres et gratuits existe sous Windows/GNU/Linux/Mac).
-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, et cela à une conséquence sur la consommation d'électricité (minimisé par le CPU ARM64, mais c'est quant même du gâchis).
-L’architecture des systèmes mobiles que je considère liberticides ; pour Android, le smartphone vendu non enraciner, alors qu'un PC est vendu enraciner ; pour IOS/IpadOS, c'est bien pire que cela, puisque tout est bridé (Apple se sert de la soi-disant protection des utilisateurs pour faire de la censure politique, un peu en occident et énormément en Chine).
0  1 
Avatar de OrthodoxWindows
Membre émérite 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
Expert confirmé 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