Standard Debian-with-root Arm package repo in pKVM hardware-nested VM with OpenGL (v)GPU remoting! So many years of upstream work across Linux, Android and ChromeOS to make this possible. Now we need phone/tablet OEMs to support Android Virtualization Framework (AVF) and OpenTitan-derived enclaves, so this feature can move beyond Pixel hardware.
> GFX virtualization aims at providing support for hardware accelerated 3D graphics in virtual machines. Unlike GPU-passthrough, with GFX virtualization the host and all VM guests can access the host GPU simultaneously. Vulkan and OpenGL are supported by virglrenderer using various approaches.. vDRM is a much thinner layer.. able to achieve native GPU performance, where VirGL and Venus may struggle to overcome expensive host/guest synchronizations..at the beginning of 2025, vDRM is partially supported by crosvm.
Hopefully Google's phone-tablet-laptop-desktop convergence of Android, ChromeOS and developer-targeted Debian Linux will motivate Apple to restore iPadOS 16.2 (2022!) virtualization support, https://github.com/utmapp/UTM/discussions/5748.
I can't help be annoy by the fact that a terminal inside a VM/container is referred to as "Linux" in this way, both by Android and Windows.
It sounds to me like trying to redefine exactly what Linux is: just an app that you run on top of your proprietary OS. For a lot of people who'll be exposed to it for the first time, that's all it'll be. The mere idea of a standalone free and open source OS will be even more alien that to the previous generation.
What is the general consensus on the usability of the Terminal app?
On two different Pixel phones (6a & 8a) I had a terrible experience:
- Very slow
- Crash all the time
- The app need to be reinitialised almost every day
But I have heard some people have no complain.
Also, since I couldn't really keep it alive long enough: what as the prospects in terms of battery usage? will it be realistic to have it running all time in the background?
+ Doesn't have the same compatibility issues Termux has, so I can install things like bun.js and npm packages with native bindings (e.g. database connectors)
- Can't edit text selection, which makes it difficult to copy text
- Can't paste text
- Frequently restarts and loses all progress while switching apps
I can't say much about the battery because I just haven't used it enough to tell the difference. Honestly, with all these major flaws, I usually end up just using Termux.
I hope they fix these glaring flaws soon, IMO they're a lot more urgent to get devs to actually use this than GUI support.
Nitpick: also, a more distinctive name would be nice. Right now, it's basically impossible to search for solutions to Android Terminal issues
Sometimes it crashes just running regular apt-get upgrade if it has too many packages to update, or takes too long. Switching away from the app can also mean it crashes.
Nice idea, nowhere near ready for anything but playing.
> just running regular apt-get upgrade if it has too many packages to update, or takes too long
That's really interesting! How's it handle nala[0]? I ask because it parallelizes apt. So if it crashes fast then might be a good hint that it is overloaded but if it is more successful could be a timeout?
Also... I mean nala is also a much better experience than apt...
I keep advocating that all these are kind of band aids, the right approach is to do the CLI as many non-UNIX OSes have done it, not by keeping VT100 hardware alive virtually.
In Android's case, a Java or Kotlin written Terminal app, exposing CLI capabilities, taking advantage of Android's APIs.
Even assuming the Terminal app works great, it is still only usable for playing, unless I am able to plug a keyboard, mouse and external monitor to a phone, and I have used both DEX and Windows Continuum in the past.
They are also working on a more full-fledged desktop mode in Android 16 QPR 1. Obviously, you can also plug a keyboard, phone, and external monitor. Pixel 8 and 9 support DP-Alt.
I am not sure why VT100 emulation is relevant in this context. Removing it will break a lot of existing Unix/Linux terminal applications and the point of this emulator is to bring the wealth of existing applications (as well as X11/Wayland applications) to Android.
Which naturally requires being a Pixel phone, and not something that works across the ecosystem.
Exactly because we should stop dragging UNIX all over place, and embrace new computing models, the world already has enough UNIX clones always redoing the same stuff over and over again, as if Lion's book had been published last week.
This was the issue I had doing anything interesting on Android in the past. It just randomly kills things so you can't do much more serious stuff than web browsing/social media on it.
I suppose normal GNU/Linux might have this issue as well if you run an OS with lots of background services that randomly consume large amounts of RAM or if your desktop environment does. I don't so outside of kind of insane environments like raspberry pi zeros or weird situations on servers I don't typically run into this. (and no. It's not 2010, phones are normal PCs not a weird embedded environment.)
Android app scheduling is different than what not-Android Linux does. oomkiller might kill stuff in high memory pressure situations, but Android does a bunch of dynamic loading and unloading all the time.
No, it's just Android working the way it was designed. Long running server or VM-esque apps are incompatible with Android's ideal process management and scheduling.
Apps are meant to be started and destroyed dynamically when the user does something else, their phone is idle for a long time, battery life is low, etc. If something is in the background it's fair game to kill.
Same thing. Google owns both Android and the Linux Terminal app. Some combination of Google's OS and Google's app causes the app to crash or be crashed in the background. That's something that Google needs to fix regardless of where the bug lies.
Not if it's not crashing at all and is just a fundamental difference between Android's memory management and what the Debian guest is expecting (which is no RAM management at all)
OOM is only triggered when you actually run out of virtual memory. With modern phones that shouldn't normally happen unless you're doing something silly like compiling a web browser.
From my experience it was quite usable on Pixel 8a, but I did experience problems.
For context, I use it mostly for web development. It runs a desktop environment with VNC, so I'm able to connect and run software like a browser. I don't develop on the device, but instead connect to a remote machine. Although the browser takes a few seconds to start, I didn't have any issues doing frontend development or doing web searches and reading docs, but I tend to be careful regarding the number of open tabs.
The Terminal app does crash from time to time. It can crash after 15 minutes, but I've also had it running for about 2 hours without issues. I'm not bothered by this as I just reconnect and continue where I left.
The reinstall is not needed every day. When I run the app, sometimes it says there was an unrecoverable error and suggests to reinstall. I ignore this, because it's a timing issue; the app was slow to start. Usually, if I run it again after closing the activity, it starts normally. The same VM has been running for me without a need to reinstall for a few months.
The battery usage is not too bad. I use an external display and make the phone screen black during this time. The battery gets depleted at a rate between 5% and 20% per hour, but this is only for active usage. I haven't been running it all the time in the background.
Pixel 7a: slow to start, and you must wait for it to finish shutting down (or crashing) before you try to launch it again. Lord help you if Debian pushes a systemd update, since updating systemd is a reliable crash.
Pixel 8a has 8gb ram. It's not a low end number for Android phones.
Probably more the fact that the memory and battery management logic assumes all user apps which are not in focus can be killed aggressively, which makes the system unsuitable for any background task by design.
Yeah I have machines with 8Gb and I am popping VMs like there is no tomorrow without problem.
Now I am not very knowledge about memory management on Android but I just noticed the 8Gb of the Pixel 8a are almost all used just after reboot. So this is very different than a Linux desktop...
Android is not GNU/Linux, yes it may use the Linux kernel, however it has a complete different userland, complete different driver model microkernel inspired with Android IPC, and the kernel itself is heavly customised, more so the OEMs ones.
Expecting Android to be just another Linux distro is exactly the root cause of many Termux developers frustations.
Yes, all of the background google services that don't come with desktop Linux chew up a big chunk. You could look into disabling all non-critical services on the phone, there's probably lots of low-hanging fruit.
> Pixel 8a has 8gb ram. It's not a low end number for Android phones.
I mean... linux runs fine of a Gen 1 raspberry pi... I have several machines around me that are running linux with 4GB or less. Hell, my 3D printer only has 128MB and my car has under a gig and run Linux fine. A low end phone *should* be just fine...
Welp, this is how Apple made their comeback 20+ years ago. Developers.
If they’re not quick in getting some more bang in the phone, which is more expensive than a computer, I might even switch. At that point, what’s the point of all the other Apple hardware.
I'm very interested as an e-ink enjoyer, as the most capable tablets run Android, mainly the Boox ones.
Sure there's the PineNote that runs ordinary Debian but I hear it's not quite there yet usability-wise, and it doesn't have colour yet.
You aren't going to get good performance for apps that are sending their graphics via Sixels or Kitty Graphics, unless they are specifically designed for it.
This is obviously very cool and how I've always wanted my phone to work. But what does chocolate factory gain out of this? I appreciate it, but I don't have the savvy to figure out how this advertising supported business profits from it.
Nested virt with AVF can balance the competing goals of security, usability, freedom, individuals, and corporate supply chains. It can reduce the size and attack surface of the most-privileged code which runs in a system.
Nested virt has been available on x86 for a decade (KVM, Bromium vSentry / HP SureClick, Microsoft Defender App Guard), on Apple Silicon since M2, MacOS since M3 and iPadOS since M4 (Secure eXclave VM). On mobile, it can sidestep some business model conflicts which torpedoed Nokia, RIM, Maemo, Meego, Tizen, etc.
1) security. Container breakouts are much more common than VM breakouts
2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server
For starters, the microkernel like driver model, where classical Linux drivers are considered legacy, since Android 8 all modern drivers run on their own processes (Java or C++) and talk with the kernel via Android IPC, known as Binderized HAL.
Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp.
Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon.
TIL that binderfs is a mainline kernel feature now,
Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!
Containers are native executables (with cgroup rules sprinkled on top). If Android does not let you call exec in the traditional way then you have a problem.
Also you're moving the goalpost with this comment a bit. My original comment says "may benefit from" being run under a "vanilla" kernel, as opposed to saying it would be completely non-functional under Android's kernel.
Presumably because container breakouts are fairly common and "external Linux software downloaded by the user" is at least as presumptively malicious as an app from the store. Modern consumer systems need to be safe vs. the user being tricked to run terrible things. A docker or whatever isn't quite up to the standards[1] required on its own.
[1] Though I'm very much not one of the pedants who refuse to see any security value at all in container isolation. Containers isolate software access (e.g. limiting access to libraries with vulnerabilities) and network communication (writing firewall rules for a container is a lot easier than it is for an app) really well, for example. Use them! But not for this.
This is great. We build a graphical MUD client (Mudlet) that's available for Linux/macOS/Windows, but Android support has (so far) eluded us. Would be amazing if this ran a native Linux binary.
Also, GNUs it's the only working usenet client for Android too. Which is ironic, because k9mail/Thunderbird and friends both support NNTP in the biggy build in the desktop...
And NNTP support on Android for MUA developers should be a piece of cake...
It sounds like that's not actually publicly available yet? Once/if released, yes that would help, although you'll probably still want a binary translation layer since most games don't have ARM binaries. Unless of course Valve includes one like Proton, in which case you still want it but get it for free.
What about Valve actually getting the studios that target Android NDK[0], to care about SteamOS exists, instead of having Valve translate their Windows deployments via Proton?
[0] - Meaning the OpenGL ES, Vulkan, OpenSL, OpenMAX, C and C++ that also exist in GNU/Linux.
What about it? Steam Deck didn't do any of that stuff, and half of YouTube is saying it's a better value than the Switch 2. Same goes for the Game Porting Toolkit derived from Proton's code, it's just about the only reason the Mac supports real games right now, not just Monument Valley and Laura Croft.
We've already seen the whole "corporate sponsor courts game publisher" thing with Eidos and Capcom at Apple. Let's just say that Apple's commitment to native experiences didn't put them in contention with Sony or Nintendo in the way Valve did.
Consumers really should pay more attention to those YouTube influencers, buying the wrong stuff. /s
Apple is doing just fine across iOS, iPadOS and TV OS, which apparently people like to ignore when discussing numbers and monetary figures in gaming profits.
Hmm... let's think. Why would iOS, iPadOS and TVOS all be ignored when discussing margins on gaming profits? Any guesses?
Oh! The Mac! Whenever you let publishers compete with software storefronts of their own, Apple is chronically incapable of making money for some reason. You know, like how League of Legends and Steam and World of Warcraft and all support the Mac but conspicuously don't show up on the macOS app store or get ported to the mobile platforms that could clearly support them. Or how Photoshop and Pro Tools and Premiere all support the Mac, but just refuse to put their professional software on the App Store or iPad! What's up with that?
The fact that those storefronts are entirely captive audiences might be it. When you add macOS to the lineup, it becomes the punchline to a tortuously protracted joke.
I wonder if we'll reach a point soon where the monitor can be replaced by AR glasses?
Beginning to dream of a Corne keyboard + AR glasses + phone setup. There's a chance we're beginning
to approach fully pocketable computing with no ergonomic compromises!
We're pretty much there. I ditched my monitors for the XReal One Pro. In Ultra Wide Mode (3840x1080 32:9) I can be productive for 1 or 2 hour sessions. Only bummer is some blurry spots in the lens, which I can see when looking through the glasses disconnected as well as when looking at rendered text. Support wasn't very helpful asking for proof with a photo or video recording even though it's near impossible to get a camera in front of the glasses and take a reasonable clear photo.
Kali net hunter can show a Linux environment over usb display port on some phones. There's also Samsung Dex but that's just android apps. They were working on a Linux version of it but killed it off within a year. It only ever worked on the S9.
I know, I specifically bought an S10e few years ago just for that (it worked on the s10 series too), but they had a special version of Ubuntu and all the repos were down so kinda useless.
The Kali thing is also just a chroot image (if rooted) that you have to VNC into, and cannot do docker and stuff.
...meanwhile, as always with any major/meaningful/useful Android updates, here on Earth in the world of non-Google hardware, we wait, patiently, for we have learned that one needs patience.
Hardware accelerated graphics in such an environment is certainly impressive... Looks like they did it via GPU virtualization, even. Isn't that one of those features used by manufacturers to segment the market?
Google is certainly demonstrating some good habits here. They did good work in opening up their laptop hardware. Their pixels are the most friendly devices for alternative operating systems. They added standard API access to GNSS raw data. Now it looks like they're doing GPU virtualization. They just keep breaking down barriers.
Looks like it's virglrenderer. This isn't like SR-IOV.
It's opengl/vulkan call interception (virgl/venus) and/or virtgpu drm native context which operates at the graphics driver level for both guest and host.
Separately, wayland memory sharing channels between guest and host need to be established. This is also done through the virtgpu pipeline.
Currently this appears to both work on Android and macOS[1]. AMDGPU also has virtgpu drm native context merged into Mesa but I believe it's still 'experimental'.
(SELinux has run in enforcing mode on Android devices since Android 4.4, which was released in 2013. But Android in ChromeOS only runs SELinux in the guest VM FWIU)
Is this another one we can blame on Ursula v.d. Leyen et al. or it's enough for today? Sorry, I was late to the previous 900+ comment thread, because I was busy having my mandatory 2h evening walk after having 2 hour late lunch break.
Standard Debian-with-root Arm package repo in pKVM hardware-nested VM with OpenGL (v)GPU remoting! So many years of upstream work across Linux, Android and ChromeOS to make this possible. Now we need phone/tablet OEMs to support Android Virtualization Framework (AVF) and OpenTitan-derived enclaves, so this feature can move beyond Pixel hardware.
https://www.collabora.com/news-and-blog/blog/2025/01/15/the-...
> GFX virtualization aims at providing support for hardware accelerated 3D graphics in virtual machines. Unlike GPU-passthrough, with GFX virtualization the host and all VM guests can access the host GPU simultaneously. Vulkan and OpenGL are supported by virglrenderer using various approaches.. vDRM is a much thinner layer.. able to achieve native GPU performance, where VirGL and Venus may struggle to overcome expensive host/guest synchronizations..at the beginning of 2025, vDRM is partially supported by crosvm.
Hopefully Google's phone-tablet-laptop-desktop convergence of Android, ChromeOS and developer-targeted Debian Linux will motivate Apple to restore iPadOS 16.2 (2022!) virtualization support, https://github.com/utmapp/UTM/discussions/5748.
Samsung supports this on the new Flip 7 as well. Ironically, not on Fold 7 though.
(The Flip is Exynos while the Fold is Qualcomm.)
May be Qualcomm charges extra for using virtualization features on their chips?
Not sure, as far as folks say it's because it doesn't support all the features Android Virt expects on current phone SoCs.
I can't help be annoy by the fact that a terminal inside a VM/container is referred to as "Linux" in this way, both by Android and Windows.
It sounds to me like trying to redefine exactly what Linux is: just an app that you run on top of your proprietary OS. For a lot of people who'll be exposed to it for the first time, that's all it'll be. The mere idea of a standalone free and open source OS will be even more alien that to the previous generation.
What is the general consensus on the usability of the Terminal app?
On two different Pixel phones (6a & 8a) I had a terrible experience:
- Very slow
- Crash all the time
- The app need to be reinitialised almost every day
But I have heard some people have no complain.
Also, since I couldn't really keep it alive long enough: what as the prospects in terms of battery usage? will it be realistic to have it running all time in the background?
My experience with a Pixel 6:
+ Doesn't have the same compatibility issues Termux has, so I can install things like bun.js and npm packages with native bindings (e.g. database connectors)
- Can't edit text selection, which makes it difficult to copy text
- Can't paste text
- Frequently restarts and loses all progress while switching apps
I can't say much about the battery because I just haven't used it enough to tell the difference. Honestly, with all these major flaws, I usually end up just using Termux.
I hope they fix these glaring flaws soon, IMO they're a lot more urgent to get devs to actually use this than GUI support.
Nitpick: also, a more distinctive name would be nice. Right now, it's basically impossible to search for solutions to Android Terminal issues
Sometimes it crashes just running regular apt-get upgrade if it has too many packages to update, or takes too long. Switching away from the app can also mean it crashes.
Nice idea, nowhere near ready for anything but playing.
Also... I mean nala is also a much better experience than apt...
[0] https://gitlab.com/volian/nala
I keep advocating that all these are kind of band aids, the right approach is to do the CLI as many non-UNIX OSes have done it, not by keeping VT100 hardware alive virtually.
In Android's case, a Java or Kotlin written Terminal app, exposing CLI capabilities, taking advantage of Android's APIs.
Even assuming the Terminal app works great, it is still only usable for playing, unless I am able to plug a keyboard, mouse and external monitor to a phone, and I have used both DEX and Windows Continuum in the past.
They are also working on a more full-fledged desktop mode in Android 16 QPR 1. Obviously, you can also plug a keyboard, phone, and external monitor. Pixel 8 and 9 support DP-Alt.
I am not sure why VT100 emulation is relevant in this context. Removing it will break a lot of existing Unix/Linux terminal applications and the point of this emulator is to bring the wealth of existing applications (as well as X11/Wayland applications) to Android.
Which naturally requires being a Pixel phone, and not something that works across the ecosystem.
Exactly because we should stop dragging UNIX all over place, and embrace new computing models, the world already has enough UNIX clones always redoing the same stuff over and over again, as if Lion's book had been published last week.
This was the issue I had doing anything interesting on Android in the past. It just randomly kills things so you can't do much more serious stuff than web browsing/social media on it.
I suppose normal GNU/Linux might have this issue as well if you run an OS with lots of background services that randomly consume large amounts of RAM or if your desktop environment does. I don't so outside of kind of insane environments like raspberry pi zeros or weird situations on servers I don't typically run into this. (and no. It's not 2010, phones are normal PCs not a weird embedded environment.)
Android app scheduling is different than what not-Android Linux does. oomkiller might kill stuff in high memory pressure situations, but Android does a bunch of dynamic loading and unloading all the time.
See also https://developer.android.com/guide/components/processes-and...
> phones are normal PCs not a weird embedded environment
It's the opposite.
Nope. My last laptop has lower specs than modern phones.
That doesn't mean they are "normal PCs".
Define what is a "normal PC" to you, then. Is it just specs?
> Switching away from the app can also mean it crashes.
That sounds more like it's being killed for RAM reasons rather than "crashing"
No, it's just Android working the way it was designed. Long running server or VM-esque apps are incompatible with Android's ideal process management and scheduling.
Apps are meant to be started and destroyed dynamically when the user does something else, their phone is idle for a long time, battery life is low, etc. If something is in the background it's fair game to kill.
It could simply pause or throttle apps instead of killing. Also I am sure Google Play Services are not killed randomly.
Same thing. Google owns both Android and the Linux Terminal app. Some combination of Google's OS and Google's app causes the app to crash or be crashed in the background. That's something that Google needs to fix regardless of where the bug lies.
Is this with battery optimizations disabled?
Not if it's not crashing at all and is just a fundamental difference between Android's memory management and what the Debian guest is expecting (which is no RAM management at all)
>which is no RAM management at all
I'm sure the Android one is much more aggressive, but Linux's OOM killer isn't too different is it?
OOM is only triggered when you actually run out of virtual memory. With modern phones that shouldn't normally happen unless you're doing something silly like compiling a web browser.
oomkiller is triggered when requested pages can't be allocated
From my experience it was quite usable on Pixel 8a, but I did experience problems.
For context, I use it mostly for web development. It runs a desktop environment with VNC, so I'm able to connect and run software like a browser. I don't develop on the device, but instead connect to a remote machine. Although the browser takes a few seconds to start, I didn't have any issues doing frontend development or doing web searches and reading docs, but I tend to be careful regarding the number of open tabs.
The Terminal app does crash from time to time. It can crash after 15 minutes, but I've also had it running for about 2 hours without issues. I'm not bothered by this as I just reconnect and continue where I left.
The reinstall is not needed every day. When I run the app, sometimes it says there was an unrecoverable error and suggests to reinstall. I ignore this, because it's a timing issue; the app was slow to start. Usually, if I run it again after closing the activity, it starts normally. The same VM has been running for me without a need to reinstall for a few months.
The battery usage is not too bad. I use an external display and make the phone screen black during this time. The battery gets depleted at a rate between 5% and 20% per hour, but this is only for active usage. I haven't been running it all the time in the background.
Pixel 7a: slow to start, and you must wait for it to finish shutting down (or crashing) before you try to launch it again. Lord help you if Debian pushes a systemd update, since updating systemd is a reliable crash.
I had pretty good speed on pixel 6 but the reinitializeling randomly made it useless.
The Pixels whose names end in "a" are the budget models with less RAM etc. You will probably have a better experience on more capable hardware.
You're running VMs on low-RAM phones, what did you expect?
> You're running VMs on low-RAM phones, what did you expect?
You used to be able to run Unix fine on computers with 64MB of ram. A modern phone has more than enough memory.
It was, but Android is not UNIX System V, Xenix, Slackware 2.0,....
Pixel 8a has 8gb ram. It's not a low end number for Android phones.
Probably more the fact that the memory and battery management logic assumes all user apps which are not in focus can be killed aggressively, which makes the system unsuitable for any background task by design.
Yeah I have machines with 8Gb and I am popping VMs like there is no tomorrow without problem.
Now I am not very knowledge about memory management on Android but I just noticed the 8Gb of the Pixel 8a are almost all used just after reboot. So this is very different than a Linux desktop...
Android is not GNU/Linux, yes it may use the Linux kernel, however it has a complete different userland, complete different driver model microkernel inspired with Android IPC, and the kernel itself is heavly customised, more so the OEMs ones.
Expecting Android to be just another Linux distro is exactly the root cause of many Termux developers frustations.
Yes, all of the background google services that don't come with desktop Linux chew up a big chunk. You could look into disabling all non-critical services on the phone, there's probably lots of low-hanging fruit.
Welp, this is how Apple made their comeback 20+ years ago. Developers.
If they’re not quick in getting some more bang in the phone, which is more expensive than a computer, I might even switch. At that point, what’s the point of all the other Apple hardware.
It will certainly help those looking to learn technical skills in the 3rd world. Many have Android phones but can't afford a computer.
I'm very interested as an e-ink enjoyer, as the most capable tablets run Android, mainly the Boox ones. Sure there's the PineNote that runs ordinary Debian but I hear it's not quite there yet usability-wise, and it doesn't have colour yet.
The absolute killer feature for this is the ability to finally play Minecraft Java Edition on phones.
Amethyst (formerly Pojav) has made this work for years: https://github.com/AngelAuraMC/Amethyst-Android
There's another app out there i've seen people use to run Fallout 4 an Samsung phones.
And with decent performance.
It's emulating windows and an x86 cpu though. Could probably run minecraft java too
https://www.reddit.com/r/Android/comments/1divvyo/samsung_ga...
Java doesn't need X86 emulators, but a proper interpreter for Android.
Instead of running in the terminal, this "just" seems to launch a full Wayland session from the terminal.
Anybody know if the actual terminal supports pixel graphics via Sixels, or better Kitty Graphics Protocol?
It looks like the terminal is not a terminal but showing the content of virtual frame buffer, just like what you see when you run QEMU.
You aren't going to get good performance for apps that are sending their graphics via Sixels or Kitty Graphics, unless they are specifically designed for it.
Anyway that's not really what this is about.
So we'd still need to run X11 apps via a separate server app then?
I would assume that once you have Wayland you can just use XWayland?
This is obviously very cool and how I've always wanted my phone to work. But what does chocolate factory gain out of this? I appreciate it, but I don't have the savvy to figure out how this advertising supported business profits from it.
Nested virt with AVF can balance the competing goals of security, usability, freedom, individuals, and corporate supply chains. It can reduce the size and attack surface of the most-privileged code which runs in a system.
Nested virt has been available on x86 for a decade (KVM, Bromium vSentry / HP SureClick, Microsoft Defender App Guard), on Apple Silicon since M2, MacOS since M3 and iPadOS since M4 (Secure eXclave VM). On mobile, it can sidestep some business model conflicts which torpedoed Nokia, RIM, Maemo, Meego, Tizen, etc.
"Virtual Machine as a core Android Primitive" (2023), 160 comments, https://news.ycombinator.com/item?id=38538100
>> On mobile, it can sidestep some business model conflicts which torpedoed Nokia, RIM, Maemo, Meego, Tizen, etc.
Do you have a good link to learn more about that?
Why does this run in a virtual machine (per the article) and not a container?
Two reasons I can think of:
1) security. Container breakouts are much more common than VM breakouts
2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server
What changes do you think makes the Android kernel heavily modified?
For starters, the microkernel like driver model, where classical Linux drivers are considered legacy, since Android 8 all modern drivers run on their own processes (Java or C++) and talk with the kernel via Android IPC, known as Binderized HAL.
https://source.android.com/docs/core/architecture/hal/archiv...
https://source.android.com/docs/core/architecture/hal
Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp.
Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon.
https://source.android.com/docs/core/runtime/zygote
Android is quite stright in memory consumption, an application that is seen as misbehaving gets killed without remorses.
For all details, you can go from here https://source.android.com/docs/core/architecture/kernel
Modern distros supports binder too. In the reverse, you can run Waydroid, which is an Android userland under a Wayland distro.
On native executables and such, file and objdump once I installed clang under termux to compile a simple binary tells me otherwise.
I bet you didn't install Termux from the PlayStore.
What matters is how an Android device as bought on a random shop as consumer behaves, not how one can hack around Android and AOSP.
Install it from F-Droid. If you are advanced enough to run Terminal bound software, using PlayStore is not the developers' fault.
Thus my point is made, should have placed the bet.
It is the developers fault for Termux's architecture not being aligned with Android's app model.
TIL that binderfs is a mainline kernel feature now,
Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!
This reply doesn't address why a container would be unable to work due to "heavy modification."
Containers are native executables (with cgroup rules sprinkled on top). If Android does not let you call exec in the traditional way then you have a problem.
Also you're moving the goalpost with this comment a bit. My original comment says "may benefit from" being run under a "vanilla" kernel, as opposed to saying it would be completely non-functional under Android's kernel.
Try to run a mainline kernel on a phone and let us know how it goes!
It's not the Android part that would get in the way. Assuming the kernel supported the hardware, Android would work.
Development independence of guest VM from host kernel, security policy, attestation, etc.
If you have to depend on the host kernel, you will likely be stuck on some old kernel fork at some point in your device's life.
You can run whatever kernel you want in a VM, though.
Presumably because container breakouts are fairly common and "external Linux software downloaded by the user" is at least as presumptively malicious as an app from the store. Modern consumer systems need to be safe vs. the user being tricked to run terrible things. A docker or whatever isn't quite up to the standards[1] required on its own.
[1] Though I'm very much not one of the pedants who refuse to see any security value at all in container isolation. Containers isolate software access (e.g. limiting access to libraries with vulnerabilities) and network communication (writing firewall rules for a container is a lot easier than it is for an app) really well, for example. Use them! But not for this.
This is great. We build a graphical MUD client (Mudlet) that's available for Linux/macOS/Windows, but Android support has (so far) eluded us. Would be amazing if this ran a native Linux binary.
Of course, UI adjustments would be the next step!
I just run Android Emacs and mu.el for that =).
Also, GNUs it's the only working usenet client for Android too. Which is ironic, because k9mail/Thunderbird and friends both support NNTP in the biggy build in the desktop...
And NNTP support on Android for MUA developers should be a piece of cake...
Is there any way to install this on non-Pixel phones yet?
AVF is supposedly available on a number of non-Samsung, non-Pixel phones.
https://www.androidauthority.com/android-15-virtual-machine-...
So...can we run SteamOS then on android?
AFAIK SteamOS doesn't run on ARM, but I can't see any reason why you couldn't install just Steam itself with the appropriate binary translation
https://www.notebookcheck.net/Valve-adds-experimental-Arm-su... ?
It sounds like that's not actually publicly available yet? Once/if released, yes that would help, although you'll probably still want a binary translation layer since most games don't have ARM binaries. Unless of course Valve includes one like Proton, in which case you still want it but get it for free.
Steam can be installed on Winlator https://github.com/brunodev85/winlator/releases
What about Valve actually getting the studios that target Android NDK[0], to care about SteamOS exists, instead of having Valve translate their Windows deployments via Proton?
[0] - Meaning the OpenGL ES, Vulkan, OpenSL, OpenMAX, C and C++ that also exist in GNU/Linux.
What about it? Steam Deck didn't do any of that stuff, and half of YouTube is saying it's a better value than the Switch 2. Same goes for the Game Porting Toolkit derived from Proton's code, it's just about the only reason the Mac supports real games right now, not just Monument Valley and Laura Croft.
We've already seen the whole "corporate sponsor courts game publisher" thing with Eidos and Capcom at Apple. Let's just say that Apple's commitment to native experiences didn't put them in contention with Sony or Nintendo in the way Valve did.
Where are the sales to match that supposed half of YouTube, one would expect it to outsold Switch 2, yet....
"Nintendo Shares Have Breakout Year as Switch 2 Sales Smash Records"
https://www.asktraders.com/analysis/nintendo-shares-have-bre...
Consumers really should pay more attention to those YouTube influencers, buying the wrong stuff. /s
Apple is doing just fine across iOS, iPadOS and TV OS, which apparently people like to ignore when discussing numbers and monetary figures in gaming profits.
Hmm... let's think. Why would iOS, iPadOS and TVOS all be ignored when discussing margins on gaming profits? Any guesses?
Oh! The Mac! Whenever you let publishers compete with software storefronts of their own, Apple is chronically incapable of making money for some reason. You know, like how League of Legends and Steam and World of Warcraft and all support the Mac but conspicuously don't show up on the macOS app store or get ported to the mobile platforms that could clearly support them. Or how Photoshop and Pro Tools and Premiere all support the Mac, but just refuse to put their professional software on the App Store or iPad! What's up with that?
The fact that those storefronts are entirely captive audiences might be it. When you add macOS to the lineup, it becomes the punchline to a tortuously protracted joke.
Ignored by HN folks like yourself, that is, industry knows what they should care about.
"- Mobile games generated $81 billion revenue in 2023 across both platforms
- iOS was responsible for $47.7 billion of that revenue, Google Play generated $33.3 billion
- Mobile was responsible for 49% of total game revenues, close to PC and console totals combined"
https://www.businessofapps.com/data/mobile-games-revenue/
Laugh at will, we don't want sad people.
We'll see how well, or not, it works with the TalkBack screen reader.
So what phone that I can get right now that runs linux with external monitor and 12+GB of RAM?
I wonder if we'll reach a point soon where the monitor can be replaced by AR glasses?
Beginning to dream of a Corne keyboard + AR glasses + phone setup. There's a chance we're beginning to approach fully pocketable computing with no ergonomic compromises!
We're pretty much there. I ditched my monitors for the XReal One Pro. In Ultra Wide Mode (3840x1080 32:9) I can be productive for 1 or 2 hour sessions. Only bummer is some blurry spots in the lens, which I can see when looking through the glasses disconnected as well as when looking at rendered text. Support wasn't very helpful asking for proof with a photo or video recording even though it's near impossible to get a camera in front of the glasses and take a reasonable clear photo.
Kali net hunter can show a Linux environment over usb display port on some phones. There's also Samsung Dex but that's just android apps. They were working on a Linux version of it but killed it off within a year. It only ever worked on the S9.
I know, I specifically bought an S10e few years ago just for that (it worked on the s10 series too), but they had a special version of Ubuntu and all the repos were down so kinda useless.
The Kali thing is also just a chroot image (if rooted) that you have to VNC into, and cannot do docker and stuff.
Ohh I thought Linux on DeX was only for the S9. But it was only for a very short period (during Android 9's availability :( )
I think they killed it way too quickly. But anyway, meh..
The S10e was the last small Samsung too :'(
This is my dream coding machine with a 10" tri-fold screen and Bluetooth keyboard when on the go and connected to a monitor / real keyboard when home.
Pixel 8/9 have USB-c external display.
Pixel 8/9 Pro have at least 12GB of RAM, with some models (256GB unlocked Obsidian?) having more.
...meanwhile, as always with any major/meaningful/useful Android updates, here on Earth in the world of non-Google hardware, we wait, patiently, for we have learned that one needs patience.
Hardware accelerated graphics in such an environment is certainly impressive... Looks like they did it via GPU virtualization, even. Isn't that one of those features used by manufacturers to segment the market?
Google is certainly demonstrating some good habits here. They did good work in opening up their laptop hardware. Their pixels are the most friendly devices for alternative operating systems. They added standard API access to GNSS raw data. Now it looks like they're doing GPU virtualization. They just keep breaking down barriers.
Looks like it's virglrenderer. This isn't like SR-IOV.
It's opengl/vulkan call interception (virgl/venus) and/or virtgpu drm native context which operates at the graphics driver level for both guest and host.
Separately, wayland memory sharing channels between guest and host need to be established. This is also done through the virtgpu pipeline.
Currently this appears to both work on Android and macOS[1]. AMDGPU also has virtgpu drm native context merged into Mesa but I believe it's still 'experimental'.
[1] <https://github.com/AsahiLinux/muvm> , <https://github.com/containers/libkrun>
Does `ls -Z` work in Android Terminal?
(SELinux has run in enforcing mode on Android devices since Android 4.4, which was released in 2013. But Android in ChromeOS only runs SELinux in the guest VM FWIU)
It's a virtual machine, so its SELinux support should be separate from what the host is doing
SELinux on a host should restrict KVM (and X/Wayland, and the sound server,).
SELinux in a guest [VM or container] should restrict processes in the guest from interfering with other processes and resources in the guest.
IMHO, Nested UIDs like uid1.subuid1.subuid2 would be better for rootless containers than root-writeable /etc/subuids.
Since I had to look it up:
-Z, --context: print any security context of each file
So, is this the year of desktop on Linux on mobile? /s
[flagged]
Wrong thread.
Apologies.-
PS. May I, however, invoke rule 34? :)
Go nuts.
Particularly, "nuts".-
Is this another one we can blame on Ursula v.d. Leyen et al. or it's enough for today? Sorry, I was late to the previous 900+ comment thread, because I was busy having my mandatory 2h evening walk after having 2 hour late lunch break.