> "Google wants to turn Android into a proper desktop operating system"
Years ago (2020 I believe) I received a new laptop and Samsung S20-something for my new job. The laptop was DoA and I was unable to complete any of the internal training courses assigned to me (which required certs and such to access). I remembered DeX and on a whim, plugged the Samsung phone into my hub with Monitor, Keyboard, and mouse. Set Chrome to desktop mode and "worked" entirely on my phone until they replaced the laptop. It worked shockingly well, even back then.
I don't think those types of "desktop mode" features ever took off, myself included, but I really wonder why. If Apple let you run macOS from a tethered iPhone, it just might!
> If Apple let you run macOS from a tethered iPhone, it just might!
Maybe that's why? It seems that people just aren't currently capable of fathoming the concept of "one device for everything". If Apple did it though, people might realize it's a good idea. Then again, I think it's unlikely that they will, because they do want to sell you a Mac as well as an iPhone/iPad.
>I don't think those types of "desktop mode" features ever took off, myself included, but I really wonder why.
The Motorola Atrix had this "webtop" thing that was pushed before this sort of tech was ready and it was kinda, well, bad. Slow, glitchy, and hot. Battery life wasn't great either.
It had a really fierce ad campaign though, so I personally know a few people that bought one. I don't remember anyone enjoying it.
I got a Pixel Fold recently, and using it makes me sad that Windows Phone got cancelled. It was absolutely ahead of its time. I would love to roll an PS that can provide three interface experiences from the same device.
It has enforced isolation so a bunch of things termux kinda does do, won't work to do with file sharing. Not that termux (non rooted) is perfect: Termux can't even make symlinks into externally removable SD cards, if they are formatted for app use and not used for simple file transfer.
What it does termux doesn't do so well, is get to the screen. With termux you seem to wind up needing to vnc to an X server on yourself which is clunky.
You can use Termux:X11 now which is an X server you can target from your Termux shell. I've used it with Andronix distros and plain XFCE inside Termux and it works, ish. I occasionally experience crashes and it gets memory-killed on my phone.
I didn't know they were doing virtualized hardware sufficient to run a Wayland. That could be very very very simple/bad performance, who knows. But it's something!
I really thought this was going to be a terminal only release.
I wonder how much of this work was already existing vs how much was diy. Did they use existing virt-* work? Did they bring in ChromeOS's many many virtualized device sandbox daemons?
it would be really cool if I can hook a portable 15" LCD to my pixel 8, run a debian and use some bluetooth keyboard/mouse to do serious work without carrying a laptop. the LCD though has to be externally powered otherwise the phone battery will run dry quickly.
I tested three bigger displays, and settled on this 18" InnoView, nice brightness boost vs most I've tested. It can pass-through power the phone or laptop (up to 65W I think) if you give it usb-pd power. (No affiliation.)
I live in neovim anyways, so there wasn't any big adaption for me. Lenovo ThinkPad TrackPoint 2 keyboard ftw (Bluetooth).
Thanks for the info. I have a ViewSonic VA1655 15.6 Inch 1080p which can powered by the pixel 8 directly via one usb-c cable(though I'm sure the battery will run out fast). Looking for bluetooth(not 2.4G wireless that needs a receiver, my phone has no extra usb for that). will checkout the thinkpad keyboard.
> The Linux Terminal runs on top of a [...] virtual machine.
It should, uh, at least be noted that "Android is Linux" doesn't really matter if you're just going to use a Virtual Machine anyway. Android could be based on BeOS and you could still have a Linux virtual machine. You could have a Windows virtual machine, for that matter. I wonder if Microsoft would be interested...
I would be interested in what it would take to get a non-virtualized Linux terminal on Android. Android is just a Linux distro at the end of the day, right? Could you chroot into a Debian environment?
> It should, uh, at least be noted that "Android is Linux" doesn't really matter if you're just going to use a Virtual Machine anyway. Android could be based on BeOS and you could still have a Linux virtual machine.
For a worked example, this is also how WSL2 works.
> You could have a Windows virtual machine, for that matter. I wonder if Microsoft would be interested...
> I would be interested in what it would take to get a non-virtualized Linux terminal on Android. Android is just a Linux distro at the end of the day, right? Could you chroot into a Debian environment?
Yes, you can do a chroot if your Android device is rooted. You can also use Termux, which doesn't need root and essentially is its own Debian-like distro, and which further can has the proot-distro tool to automate installation of assorted Linux distros in what is basically a chroot without needing root (proot is an unprivileged tool that can do all kinds of interesting things, including what amounts to chroot and mount --bind).
The VM is probably for security. Oddly it might also actually improve performance, but that depends on the details (hardware-supported virtualization is fast, and using ptrace to fake a chroot has a perf hit; I don't know that it's faster, but it wouldn't surprise me).
The articles language is pretty confusing in the way that the author continues to say "the phone can run linux", even after saying that "of course, android is linux".
If the only shortcoming of android, compared to a more typical linux distribution, was that it didn't have a shell interface, that can be solved with the variety of shell programs available for the android environment.
However bigger issues remain unsolved by adding a shell. The configuration of the _actual_ linux kernel used in android being one of the most significant. For instance, typical linux has excellent support for all USB class devices, whereas android disables this functionality. USB-on-the-go only supports specific devices in most android distributions.
Rather than running a linux user space in an android chroot environment, as has been possible to do for years with many embedded linux flavors: archlinuxarm, debian, gentoo, ubuntu, all have documented means of installing a more full featured user space in a chroot over android.
The better/more desirable configuration is to run the more full featured linux kernel and user space directly on the phone h/w, and then run android in a chroot or virtual machine when access to an android only app is needed. Such as this phone:
This allows the android subsystem to be completely shut down when not in use, thus disabling the goggle surveillance and other undesirable features of android.
For any semi-technical phone user, this article is old news. The only thing new about it, is that the chroot is configured by goggle itself, which pretty much insures that the config will be primarily for the benefit of goggle, not the user.
It's always mind-boggling to me that software engineers find ways to screw things up, and then hype up effectively bringing back features that would have existed if they had done nothing at all.
Nonsense - Android's userland does not use GNU, at all; or Linux display servers; or the POSIX standard; or anything but the kernel. Apps on Android have no access, or ability, to directly call kernel functions. Android is deliberately designed so the kernel could, hypothetically, even be replaced one day without breaking anything.
Forcing apps into an abstraction layer from the kernel is good design, preventing kernel quirks from being permanent features. Not using GNU is another design choice which can be debated, but it's completely valid, there's no requirement (moral or otherwise) to use the GNU userland with the Linux kernel. Most embedded devices also eschew the GNU userland by instead using Busybox.
All of which are more expensive decisions than working from existing foundations and building on top of them, not throwing out the baby with the bathwater and demolishing the bathtub, then designing a walk-in shower, adopting a new baby, putting a portable bathtub in the walk-in shower, and refilling it.
Hey, but at least you can remove the tub whenever you want now.
Well, I think that it could be argued that GNU, and Xorg, and GTK, and all the rest, wasn’t the best foundation to build on in 2003. At a minimum, it would have required so much modification to run on mobile phones, that combined with the license (remembering that Android was originally a small company not part of Google), would not have led to a viable business model or platform. Even today, Xorg would be a terrible fit for a mobile device, and most embedded devices don’t use GNU.
The Nokia N900 was a production mobile phone that ran Linux (Debian-based) with a GNU userland, Xorg, and a GTK+ based graphical environment. It was very responsive, had a ton of features, and got great reviews (even outside the Linux enthusiast community). It failed in the market, but the reasons why it did had little to do with the choice in technology.
Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call.
In the Android-y part of Android, yes, they use ART, which is abstracted.
But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code?
It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example.
As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside).
Sure, and this VM solution is the exact path forward for “install stuff in a box” solutions as Android move towards trying to enforce w^x, which is probably why they chose a full Linux VM as their demo app. Emulators and games and apps with embedded JIT will be harder to deal with.
What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
I asked Claude, turns out I’m (probably, not celebrating) right:
Yes, Android's fopen() function is indeed an abstraction over the Linux fopen() system call. Android's implementation is part of the Bionic C library, which is Android's custom implementation of the standard C library (libc).
When you call fopen() in Android:
1. You're directly using Bionic's implementation of this standard C library function
2. Bionic ultimately relies on the underlying Linux kernel for actual file operations
3. The function provides the same basic functionality as the standard C library fopen() on other Linux systems
The Bionic library was specifically designed for Android to be more lightweight and optimized for mobile devices compared to the traditional glibc used in most Linux distributions. It maintains the same interface as standard C library functions like fopen() while providing platform-specific optimizations for Android's environment.
You might be able to turn off developer mode once it's enabled, maybe?
Anyway, apps have literally no reason to query the status of developer mode and should not be allowed to do so.
I don't think apps should be able to query the status of the OS' "integrity" either (which in practice just boils down to a "Google-approved" boolean anyway), but they do at least have somewhat legitimate reasons for wanting to do that -- Pokemon Go wants to make sure the GPS coordinates it receives aren't spoofed, for example.
But there is no reason they should be able to query the status of developer mode.
I can confirm. I have run into a number of money/banking/healthcare apps that refuse to run (or in some cases, run but not sign in) if the device is rooted or in developer mode.
Even simpler than that. I know Goldman Sachs will refuse to connect to their servers if you're using a proxy of any kind so that you can't easily inspect network traffic.
I don't think those types of "desktop mode" features ever took off, myself included, but I really wonder why. If Apple let you run macOS from a tethered iPhone, it just might!
> If Apple let you run macOS from a tethered iPhone, it just might!
Maybe that's why? It seems that people just aren't currently capable of fathoming the concept of "one device for everything". If Apple did it though, people might realize it's a good idea. Then again, I think it's unlikely that they will, because they do want to sell you a Mac as well as an iPhone/iPad.
>I don't think those types of "desktop mode" features ever took off, myself included, but I really wonder why.
The Motorola Atrix had this "webtop" thing that was pushed before this sort of tech was ready and it was kinda, well, bad. Slow, glitchy, and hot. Battery life wasn't great either.
It had a really fierce ad campaign though, so I personally know a few people that bought one. I don't remember anyone enjoying it.
> If Apple let you run macOS from a tethered iPhone, it just might[…]
…cannibalize iPad or Mac sales.
It’s almost insulting that modern iPhones support keyboard, mouse, and monitor via an USB-C hub, yet the experience remains artificially limited.
I got a Pixel Fold recently, and using it makes me sad that Windows Phone got cancelled. It was absolutely ahead of its time. I would love to roll an PS that can provide three interface experiences from the same device.
I wonder how many of these are just attempts for Google to try to slim down how much equipment they have to hand their own employees internally.
IIRC, they started handing their contractors Pixel Tabs and docks to work from?
The S20 Ultra is pretty powerful.
FWIW GrapheneOS is rolling it out as well: https://grapheneos.social/@GrapheneOS/114132940314692519
Looks like the GrapheneOS implementation will be less restricted and will let you run operating systems other than Debian, including Windows 11.
It has enforced isolation so a bunch of things termux kinda does do, won't work to do with file sharing. Not that termux (non rooted) is perfect: Termux can't even make symlinks into externally removable SD cards, if they are formatted for app use and not used for simple file transfer.
What it does termux doesn't do so well, is get to the screen. With termux you seem to wind up needing to vnc to an X server on yourself which is clunky.
You can use Termux:X11 now which is an X server you can target from your Termux shell. I've used it with Andronix distros and plain XFCE inside Termux and it works, ish. I occasionally experience crashes and it gets memory-killed on my phone.
The Nokia N900 has/had a Debian chroot app.
(Of course, some phones, like the Librem 5, runs a Debian derivative as their native OS.)
Maemo is/was based on Debian, with full compatibility with dpkg and apt.
I didn't know they were doing virtualized hardware sufficient to run a Wayland. That could be very very very simple/bad performance, who knows. But it's something!
I really thought this was going to be a terminal only release.
I wonder how much of this work was already existing vs how much was diy. Did they use existing virt-* work? Did they bring in ChromeOS's many many virtualized device sandbox daemons?
Linked from the article: https://www.androidauthority.com/android-16-linux-terminal-d...
it would be really cool if I can hook a portable 15" LCD to my pixel 8, run a debian and use some bluetooth keyboard/mouse to do serious work without carrying a laptop. the LCD though has to be externally powered otherwise the phone battery will run dry quickly.
I tested three bigger displays, and settled on this 18" InnoView, nice brightness boost vs most I've tested. It can pass-through power the phone or laptop (up to 65W I think) if you give it usb-pd power. (No affiliation.)
I live in neovim anyways, so there wasn't any big adaption for me. Lenovo ThinkPad TrackPoint 2 keyboard ftw (Bluetooth).
https://www.amazon.com/InnoView-Portable-2560x1600-FreeSync-...
Thanks for the info. I have a ViewSonic VA1655 15.6 Inch 1080p which can powered by the pixel 8 directly via one usb-c cable(though I'm sure the battery will run out fast). Looking for bluetooth(not 2.4G wireless that needs a receiver, my phone has no extra usb for that). will checkout the thinkpad keyboard.
Is this AOSP stuff, or is this only in the Google's proprietary parts?
https://developer.android.com/about/versions/15/release-note...
The feature is part of AOSP.
> Of course, Android is Linux.
> The Linux Terminal runs on top of a [...] virtual machine.
It should, uh, at least be noted that "Android is Linux" doesn't really matter if you're just going to use a Virtual Machine anyway. Android could be based on BeOS and you could still have a Linux virtual machine. You could have a Windows virtual machine, for that matter. I wonder if Microsoft would be interested...
I would be interested in what it would take to get a non-virtualized Linux terminal on Android. Android is just a Linux distro at the end of the day, right? Could you chroot into a Debian environment?
> It should, uh, at least be noted that "Android is Linux" doesn't really matter if you're just going to use a Virtual Machine anyway. Android could be based on BeOS and you could still have a Linux virtual machine.
For a worked example, this is also how WSL2 works.
> You could have a Windows virtual machine, for that matter. I wonder if Microsoft would be interested...
It would be interesting to get official buy-in, but https://news.ycombinator.com/item?id=43336934 links to GrapheneOS planning to make it work.
> I would be interested in what it would take to get a non-virtualized Linux terminal on Android. Android is just a Linux distro at the end of the day, right? Could you chroot into a Debian environment?
Yes, you can do a chroot if your Android device is rooted. You can also use Termux, which doesn't need root and essentially is its own Debian-like distro, and which further can has the proot-distro tool to automate installation of assorted Linux distros in what is basically a chroot without needing root (proot is an unprivileged tool that can do all kinds of interesting things, including what amounts to chroot and mount --bind).
https://wiki.debian.org/ChrootOnAndroid
Many other distros also support this...
https://github.com/selirra/anarch
https://hamelot.io/android/run-gentoo-on-android-via-chroot/
Oh. And there are even apps in the Play Store that do it.
What is even the point of Google doing this, with a VM no less?
The VM is probably for security. Oddly it might also actually improve performance, but that depends on the details (hardware-supported virtualization is fast, and using ptrace to fake a chroot has a perf hit; I don't know that it's faster, but it wouldn't surprise me).
The articles language is pretty confusing in the way that the author continues to say "the phone can run linux", even after saying that "of course, android is linux".
If the only shortcoming of android, compared to a more typical linux distribution, was that it didn't have a shell interface, that can be solved with the variety of shell programs available for the android environment.
However bigger issues remain unsolved by adding a shell. The configuration of the _actual_ linux kernel used in android being one of the most significant. For instance, typical linux has excellent support for all USB class devices, whereas android disables this functionality. USB-on-the-go only supports specific devices in most android distributions.
Rather than running a linux user space in an android chroot environment, as has been possible to do for years with many embedded linux flavors: archlinuxarm, debian, gentoo, ubuntu, all have documented means of installing a more full featured user space in a chroot over android.
The better/more desirable configuration is to run the more full featured linux kernel and user space directly on the phone h/w, and then run android in a chroot or virtual machine when access to an android only app is needed. Such as this phone:
https://furilabs.com/
This allows the android subsystem to be completely shut down when not in use, thus disabling the goggle surveillance and other undesirable features of android.
For any semi-technical phone user, this article is old news. The only thing new about it, is that the chroot is configured by goggle itself, which pretty much insures that the config will be primarily for the benefit of goggle, not the user.
It's always mind-boggling to me that software engineers find ways to screw things up, and then hype up effectively bringing back features that would have existed if they had done nothing at all.
I'm not familiar with the history here. What happened?
Nonsense - Android's userland does not use GNU, at all; or Linux display servers; or the POSIX standard; or anything but the kernel. Apps on Android have no access, or ability, to directly call kernel functions. Android is deliberately designed so the kernel could, hypothetically, even be replaced one day without breaking anything.
Forcing apps into an abstraction layer from the kernel is good design, preventing kernel quirks from being permanent features. Not using GNU is another design choice which can be debated, but it's completely valid, there's no requirement (moral or otherwise) to use the GNU userland with the Linux kernel. Most embedded devices also eschew the GNU userland by instead using Busybox.
All of which are more expensive decisions than working from existing foundations and building on top of them, not throwing out the baby with the bathwater and demolishing the bathtub, then designing a walk-in shower, adopting a new baby, putting a portable bathtub in the walk-in shower, and refilling it.
Hey, but at least you can remove the tub whenever you want now.
Well, I think that it could be argued that GNU, and Xorg, and GTK, and all the rest, wasn’t the best foundation to build on in 2003. At a minimum, it would have required so much modification to run on mobile phones, that combined with the license (remembering that Android was originally a small company not part of Google), would not have led to a viable business model or platform. Even today, Xorg would be a terrible fit for a mobile device, and most embedded devices don’t use GNU.
The Nokia N900 was a production mobile phone that ran Linux (Debian-based) with a GNU userland, Xorg, and a GTK+ based graphical environment. It was very responsive, had a ton of features, and got great reviews (even outside the Linux enthusiast community). It failed in the market, but the reasons why it did had little to do with the choice in technology.
> Apps on Android have no access, or ability, to directly call kernel functions.
That is nonsense.
Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call.
I could easily be completely wrong though.
In the Android-y part of Android, yes, they use ART, which is abstracted.
But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code?
It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example.
As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
> you're allowed access to full Linux-land
Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside).
https://github.com/termux/termux-app/issues/1072
https://github.com/termux/termux-app/issues/2155
Sure, and this VM solution is the exact path forward for “install stuff in a box” solutions as Android move towards trying to enforce w^x, which is probably why they chose a full Linux VM as their demo app. Emulators and games and apps with embedded JIT will be harder to deal with.
What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
I asked Claude, turns out I’m (probably, not celebrating) right:
Yes, Android's fopen() function is indeed an abstraction over the Linux fopen() system call. Android's implementation is part of the Bionic C library, which is Android's custom implementation of the standard C library (libc).
When you call fopen() in Android:
1. You're directly using Bionic's implementation of this standard C library function 2. Bionic ultimately relies on the underlying Linux kernel for actual file operations 3. The function provides the same basic functionality as the standard C library fopen() on other Linux systems
The Bionic library was specifically designed for Android to be more lightweight and optimized for mobile devices compared to the traditional glibc used in most Linux distributions. It maintains the same interface as standard C library functions like fopen() while providing platform-specific optimizations for Android's environment.
> Android's fopen() function is indeed an abstraction over the Linux fopen() system call
Yikes, `fopen` is not a system call...
I'm disappointed that this seems to need developer mode, given I have apps that refuse to work if I've got developer mode enabled.
You might be able to turn off developer mode once it's enabled, maybe?
Anyway, apps have literally no reason to query the status of developer mode and should not be allowed to do so.
I don't think apps should be able to query the status of the OS' "integrity" either (which in practice just boils down to a "Google-approved" boolean anyway), but they do at least have somewhat legitimate reasons for wanting to do that -- Pokemon Go wants to make sure the GPS coordinates it receives aren't spoofed, for example.
But there is no reason they should be able to query the status of developer mode.
Really? Banking?
I know apps looking for root but never for developer mode (didn't even know you could know its state).
I can confirm. I have run into a number of money/banking/healthcare apps that refuse to run (or in some cases, run but not sign in) if the device is rooted or in developer mode.
At least one banking app I know will crash if it detects something as normal as a remote desktop app like TeamViewer installed. Banks are insane!
Even simpler than that. I know Goldman Sachs will refuse to connect to their servers if you're using a proxy of any kind so that you can't easily inspect network traffic.