J'ai fait quelque tests avec adb en wifi,
scrcpy ( ca marche aussi avec Vyzor) et un Pixel 6 (sccpy c'est juste pour eviter la galere du clavier sur un smartphone).
Ce n'est pas contrairement a crostini un container LXD dans une VM hote mais bien une VM directe.
En regardant les process qui tourne coté Android (avec adb shell) on voit crosvm
https://github.com/google/crosvm mais sans LXD en plus. C'est plus proche d'AVF donc (Android Virtualization Framework).
On peut faire du ssh dans la vm depuis l'exterieur. J'ai utilisé Tailscale qui inclut un ssh intégré et est bien plus simple a configurer:
dans la VM du téléphone: on fait
curl -fsSL https://tailscale.com/install.sh | sh
comme indiqué ici:
https://tailscale.com/kb/1031/install-linuxmais a la fin au lieu de faire
sudo tailscale up
on fait
sudo tailscale up -ssh
ca permet ensuite de faire ssh droid@ip_ou_nom depuis n'importe quel machine/vm qui a aussi Tailscale (par défaut le nom de la vm est localhost donc tailscale utilisera localhost-0, ca peut se changer).
L'avantage de Tailscale est qu'on garde la connexion ssh tout le temps ou qu'on soit vu que ca suit les changements réseaux en dessous (passage wifi / 5G, etc).
L'application Terminal du téléphone a du mal parfois et plante ou se reconnecte alors que la VM tourne très bien en tache de fond (visible via ssh). Y'a un souci coté Android a ce niveau donc (vu dans le journalctl c'est le forwarder_guest_launcher qui se plante a priori) pas coté VM.
J'ai pu testé nspeed directement dans la vm du Pixel 6:
wget https://dl.nspeed.app/nspeed-client/preview/nspeed_linux_arm64/nspeed
chmod +x nspeed
puis
droid@localhost:~$ ./nspeed from https://dl.nspeed.app/aw
reading commands from https://dl.nspeed.app/aw
running jobs of 'download mono' (0)...
running jobs of 'upload mono' (1)...
running jobs of 'download multi' (2)...
running jobs of 'upload multi' (3)...
batch download mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#0| 1.1 Gbps| 0 bps| 8.00| 1.1 GB| 0 B|get http://appliwave.testdebit.info/10G/10G.iso (IPv4 - 7.53 ms - HTTP/1.1 - )
batch upload mono:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#1| 0 bps| 522.1 Mbps| 8.00| 0 B| 522.2 MB|post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv4 - 1040.671 ms - - )
batch download multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#2| 1.3 Gbps| 0 bps| 8.01| 1.3 GB| 0 B|4 x get http://appliwave.testdebit.info/10G/10G.iso (IPv4 - 14.863 ms - HTTP/1.1 - )
batch upload multi:
Id| Read speed| Write speed| Time| Bytes read| Bytes written|command
#3| 0 bps| 587.9 Mbps| 8.00| 0 B| 588.2 MB|4 x post http://appliwave.testdebit.info/ul/ 10.7 GB (IPv4 - 1029.220 ms - - )
=> bon débit niveau réseau de la vm donc (le téléphone arrive a 1,5Gbps/800Mbps, la VM 1.3G/600Mbps)/
on peut meme en mettant le client Tailscale Android faire un lien vpn entre Android et la VM
exemple le moniteur de nspeed qui tourne dans la vm et qui est affiché par le navigateur du téléphone:
On peut aussi utiliser l'ouverture de port mais ca ne marche qu'en IPv4 (il faut bind que IPv4: 0.0.0.0:port, si on bind "dual" *:port) ca n'ouvre pas) et il faut accepter la demande via la notification coté Android.
Ca permet ensuite d'acceder via localhost:port coté Android (testé avec nspeed api)
OS mobile (Android, iOS,...)