Waydroid – Run Android containers on Ubuntu(waydro.id)
waydro.id
Waydroid – Run Android containers on Ubuntu
https://waydro.id/
212 comments
One thing to add to The bad/The ugly:
- requires Wayland - does not seem to work with X11
This makes it a no-go for many a potential user.
- requires Wayland - does not seem to work with X11
This makes it a no-go for many a potential user.
Thanks. That explains the "Way" prefix for the project name, I suppose.
One of the major advantages of Waydroid that I've found is that it's lighter than Anbox. I know some here have compute to spare, but it makes a big difference on my Pinephone :)
It's still early days for Waydroid, but it's also decidedly a step forwards.
It's still early days for Waydroid, but it's also decidedly a step forwards.
Can you add a bit more on what works and what doesn't work on waydroid compared with regular android and regular lineageos on pine phone.
Wait - you can run waydroid, and thus presumably Android apps, on Pinephone? This is huge! How well does it work?
Quite well: https://www.youtube.com/watch?v=bG0uAQqeqW4
Here is on a OnePlus 6T running postmarketOS, for comparison: https://www.youtube.com/watch?v=I9qaD5YIPkc
Here is on a OnePlus 6T running postmarketOS, for comparison: https://www.youtube.com/watch?v=I9qaD5YIPkc
I've asked about anbox (not having heard of waydroid before now) on Pinephone threads before, consensus seemed to be even without bugs it's too slow on Pinephone hardware. (And indeed I've found it too buggy to be useful on my desktop anyway.)
So certainly lighter sounds good, and hopefully the future's bright - could be very useful in bridging the gap driving more Linux phone adoption. Some things just can't and won't be available (without way more adoption), like bank apps say, so being able to run the Android version smoothly would be a huge win.
So certainly lighter sounds good, and hopefully the future's bright - could be very useful in bridging the gap driving more Linux phone adoption. Some things just can't and won't be available (without way more adoption), like bank apps say, so being able to run the Android version smoothly would be a huge win.
The PinePhone runs mainline Linux on a regular Arm64 SOC. Why shouldn’t it work? ;)
Because you're running an emulator on a damnd phone!! A PHONE! Wild!
Phones have more processing power than laptops from just a few years ago. People aren't exaggerating when they call them pocket supercomputers.
The PinePhone processor and GPU are pathetic. It's not the phone people mean when they say phones are comparable in power to laptops.
Up thread some person is running and emulator/container with some not-lightweight software in it! On the Pine! Maybe "pathetic" is not the right word. It's more powerful than my first laptop (I think the comparison there is phones-now to laptops-back-then)
> Performance is quite comparable to Anbox on the same device.
I had a PinePhone. The performance of Anbox on it was slow, and apps were rendered at a low resolution and scaled up using bilinear scaling. And I had to configure zram/zswap (which was a good idea regardless of using Anbox or not), because otherwise the 1 gigabyte of RAM wasn't enough to fit Linux and Anbox, and Anbox would terminate from merely poking around in the settings app and trying to login to MicroG or something.
I hope that the scaling (and performance?) is fixed in Anbox, and that Waydroid performs faster than Anbox and uses less RAM. But I no longer have a functioning PinePhone to test further on.
I watched https://www.youtube.com/watch?v=bG0uAQqeqW4. Scrolling through the recent apps list has both a high latency and low frame rate (and PinePhone-native UIs like GTK Phosh and Plasma Mobile are not really better). And the gameplay had 150 or more milliseconds of latency between touch input and the screen responding, which is awful.
> It's more powerful than my first laptop
This speaks to how unoptimized and GPU-dependent today's software is (Xfce on a dual-core ULV Intel-based laptop from 2016 is more responsive than KDE Plasma on that laptop or a Zen 3 desktop PC, admittedly with a crappy GPU), and perhaps how today's screens are higher-resolution than old laptops.
> I think the comparison there is phones-now to laptops-back-then
The comparison is with "laptops from just a few years ago". My old laptop runs circles around my PinePhone, though I won't say it's better than good phones of today.
I had a PinePhone. The performance of Anbox on it was slow, and apps were rendered at a low resolution and scaled up using bilinear scaling. And I had to configure zram/zswap (which was a good idea regardless of using Anbox or not), because otherwise the 1 gigabyte of RAM wasn't enough to fit Linux and Anbox, and Anbox would terminate from merely poking around in the settings app and trying to login to MicroG or something.
I hope that the scaling (and performance?) is fixed in Anbox, and that Waydroid performs faster than Anbox and uses less RAM. But I no longer have a functioning PinePhone to test further on.
I watched https://www.youtube.com/watch?v=bG0uAQqeqW4. Scrolling through the recent apps list has both a high latency and low frame rate (and PinePhone-native UIs like GTK Phosh and Plasma Mobile are not really better). And the gameplay had 150 or more milliseconds of latency between touch input and the screen responding, which is awful.
> It's more powerful than my first laptop
This speaks to how unoptimized and GPU-dependent today's software is (Xfce on a dual-core ULV Intel-based laptop from 2016 is more responsive than KDE Plasma on that laptop or a Zen 3 desktop PC, admittedly with a crappy GPU), and perhaps how today's screens are higher-resolution than old laptops.
> I think the comparison there is phones-now to laptops-back-then
The comparison is with "laptops from just a few years ago". My old laptop runs circles around my PinePhone, though I won't say it's better than good phones of today.
Most phones don't have iPhone class CPUs.
The series 7 Apple Watch has a higher resolution display than the original iPhone.
The SoC is pretty slow. speaking as a PinePhone owner.
If you think that Pinephone is slow, try a less cluttered OS (https://sxmo.org), or consider Librem 5 instead.
...or wait for the fxtec to ship. If I'm going to have a command line on my phone, I want a keyboard.
> If I'm going to have a command line on my phone, I want a keyboard.
https://pineguild.com/pinephone-keyboard-first-impression-is...
Also, you can connect via ssh and use your computer's keyboard to manage the phone. Or buy a Bluetooth keyboard.
https://pineguild.com/pinephone-keyboard-first-impression-is...
Also, you can connect via ssh and use your computer's keyboard to manage the phone. Or buy a Bluetooth keyboard.
The fxtec looks neat in theory, but one thing I love on my PinePhone is its ability to just boot any OS on any SD-card you insert.
Do you know if the fxtec will offer the same? For a tinkerable Linux phone where you genuinely go distro-hopping, that's truly a game-changer.
Do you know if the fxtec will offer the same? For a tinkerable Linux phone where you genuinely go distro-hopping, that's truly a game-changer.
You mean any OS that has been painstakingly ported and compiled for the Pinephone? I don't think that leaves you with a plethora of options...
I mean as opposed to having to use weird key-combos, special reset-modes, and arcane tools to flash/erase internal storage and re-install my phone every time I want to try something new.
With the PinePhone I can boot from external media (like SD-cards), and that's quite a big deal.
Yeah, it's not ACPI and UEFI and generic images running HW-discovery and magically "just working", but it's still way better than the options you have pretty most everywhere else in phone-space.
With the PinePhone I can boot from external media (like SD-cards), and that's quite a big deal.
Yeah, it's not ACPI and UEFI and generic images running HW-discovery and magically "just working", but it's still way better than the options you have pretty most everywhere else in phone-space.
I don't - all I know is that the bootloader is unlocked and it has a few recommended options. Agree with you that it's neat in theory, but am waiting for the first reviews before I plunk down cash.
Looks a lot like the planet Astro Slide but with a worse keyboard?
Sure. I have one too. I know.
But that’s no reason for it not to work, it will just work more slowly ;)
But that’s no reason for it not to work, it will just work more slowly ;)
Has anyone had success getting any of these containers to work with a camera?
Recently, my bank discontinued their website based deposit system for checks in favor of their app. I'm reluctant to keep an app with full access to my account on my phone, so a container system like Waydroid or Anbox would be great if I could just emulate the app when I need it. Has anyone else run into this issue and, if so, how have you dealt with it?
Recently, my bank discontinued their website based deposit system for checks in favor of their app. I'm reluctant to keep an app with full access to my account on my phone, so a container system like Waydroid or Anbox would be great if I could just emulate the app when I need it. Has anyone else run into this issue and, if so, how have you dealt with it?
I got by in similar circumstances with Android x86. Which is simply an android VM. The catch is that it's not ARM, which some apps lamented - but the app I needed worked just fine.
FWIW/out of curiosity, I just tried poking the emulator that comes with Android Studio, and found an option (under "advanced settings") to route the emulated front or back camera to "Webcam0". This is out of the box on Debian.
While definitely a heavyweight approach (yay, installing all of Android Studio - but you also install an update tool), I can confirm it works. (And you can fish out and save the qemu invocation from `ps axfww`, then launch it directly without needing to start anything else, although I think the idiomatic approach is using the `emulator` command.)
While definitely a heavyweight approach (yay, installing all of Android Studio - but you also install an update tool), I can confirm it works. (And you can fish out and save the qemu invocation from `ps axfww`, then launch it directly without needing to start anything else, although I think the idiomatic approach is using the `emulator` command.)
The emulator is part of the android SDK so you don't need to install the full IDE if all you need is the emulator. You can just install the Android SDK standalone and use that to install additional images and start/stop devices.
Android is actually pretty secure. If you trust Linux kernel (which I think you do since you trust lxc), then you can trust Android.
I have been trying to get my banking software to work with both Anbox and Waydroid for the last couple of days.
So far I've had no success with either.
I've gotten other apps to run just fine but not any related to banking.
These apps are extremely picky about the environment you run them in.
At least the ones I'm working with require Google Play Services, which is proprietary and have to be ripped from an Android image (if you don't want to take a chance on some shady download).
Even with Play services, my app still will not start.
I'm thinking it could be related to how Anbox and Waydroid shares the kernel with the host OS, and therefor it may not look like valid Android to the apps.
Perhaps banking apps refuse to run on devices which don't pass SafetyNet (which generally expects a TPM to be present, which I find appalling)?
Possibly very stupid question ahead: Can't the TPM be emulated?
I think TPMs are designed such that Google only trusts TPMs with private keys inaccessible to users (and bank account stealers, and Netflix downloaders), and which follow the instructions of your bank or Netflix (not the instructions of the user).
Do you have a taobao link for Google trusted TPM chips in reel?
The problem is (I think) you can't get a TPM to tell Google you're running on an unmodified phone (barring hardware mods or TPM exploits) if you have discrepancies from the unmodified phone visible in the CPU's RAM or flash.
Most banking apps will require Google Play Services in order to work right. Currently, Waydroid does not offer that.
[deleted]
Install Android in a VMWare box. Works like a charm. No fuss, no hassle. And you can customize your network isolation as you want.
perhaps the containerized environment looks like a rooted phone?
Due to vague security requirements most banking apps refuse to run if the phone has been rooted.
Due to vague security requirements most banking apps refuse to run if the phone has been rooted.
What about using last year's phone for banking etc?
Erfan is finishing up on camera fixes soon. Updates should be pushed this weekend sometime.
I have tried Waydroid in Manjaro Linux, and to my surprise, it runs smoothly. I even able to install Aurora Store and install Telegram from there, which also run perfectly. RAM usage was minimal, maybe because of it is running on a container.
The only thing I haven't figured out is keyboard input from my physical keyboard directly to the android.
> I even able to install Aurora Store and install Telegram from there, which also run perfectly
Why Telegram specifically, when it already offers both a web client and a FOSS Linux client?
Why Telegram specifically, when it already offers both a web client and a FOSS Linux client?
Mainly because I want to see if :
- I can install something from Aurora Store
- The app can run
- The app can connect to the internet without changing any config
- The app can operate normally
It is just a coincidence that the first apps I installed was Telegram.
AFAIK, Waydroid doesn't add ARM virtualization, and because I installed it on a X86_64 computer, I doubt something installed from a store (which mainly aimed for ARM device) can even run properly.
In fact, if you have qemu-user-static installed and binfmt configured properly, it will likely just work.
I intended to write the same in reponse to some other comment. But then I got unsure. It would only work if Android has no native ABIs to the system at all. On a Gnu/Linux system you would need a libc in the emulated architecture at least. Applications won't typically bring their own. I have never not looked at Android development, so no idea whether such ABI exist or whether all APIs are Java.
Quite a lot of stuff from the Play Store has an x86 version, because then they get users on Chromebooks.
wut? most chromebooks are arm
nope! These days a heck of a lot are a lower-power Intel chip or an AMD chip. They're just very slightly weird PCs.
Makes sense, thanks.
I do not know why they do not give credits, nor mention that they use LXC behind the scenes [1].
[1] https://github.com/waydroid/waydroid/blob/bullseye/tools/hel...
[1] https://github.com/waydroid/waydroid/blob/bullseye/tools/hel...
Why do they need to? Sure it'll be nice, but depending on your market, maybe that's an unnecessary implementation detail.
They do mention
"Waydroid uses Linux namespaces (user, pid, uts, net, mount, ipc) to run a full…" [see main page]
when in fact they simply use LXD, which uses all these features. Besides, it is a project dependency, which is not mentioned anywhere.
Edit: clarity.
"Waydroid uses Linux namespaces (user, pid, uts, net, mount, ipc) to run a full…" [see main page]
when in fact they simply use LXD, which uses all these features. Besides, it is a project dependency, which is not mentioned anywhere.
Edit: clarity.
[deleted]
I am, of course, not naive enough to think that there's a good chance of it happening -- but I nevertheless strongly feel this way about every large tech company that isn't Microsoft not mentioning that they use Linux.
[deleted]
We figured mentioning it in the docs under dependencies was enough (https://docs.waydro.id/usage/install-on-desktops). We will add it to the website instructions as well then to make things more clear.
Thanks for clarifying, I haven’t seen it previously.
Have you considered adding support for other container systems like systemd-nspawn or Kata Containers?
We are working with a few community members to support as many systems as possible RN. On down the road, there might be aossibility of supporting different container methods, but for now, we are focusing our efforts on using LXC
Title should be changed to Linux - thought this was Ubuntu-only at first (like if it were only in Ubuntu repos)
Yeah. This title should be reverted to the title on the page.
A container-based approach to boot a full Android system on a regular GNU/Linux system like Ubuntu.
This could be simplified to:
WayDroid: Containerized Android for GNU/Linux
But as it is now, the title has been changed to be confusing.
A container-based approach to boot a full Android system on a regular GNU/Linux system like Ubuntu.
This could be simplified to:
WayDroid: Containerized Android for GNU/Linux
But as it is now, the title has been changed to be confusing.
I wish I could setup waydroid on Raspberry Pi so that I can finally use hotstar/primevideo and netflix on my dumb tv.
I had bought firestick in past that is now stuck on boot loop for over a year. I have decided not buy these sticks or smart TV where I have little to no control over Software.
I had bought firestick in past that is now stuck on boot loop for over a year. I have decided not buy these sticks or smart TV where I have little to no control over Software.
One of the biggest problems with anbox and ARC was that they would need to do tons of work on each new android version. If somebody is willing to keep updating this for new versions of android at least every other android release then it’s reasonable to say this will work long term, otherwise people will use of a year then abandon it.. so Google is now switching to using arcvm where they use a VM instead of trying to do a bunch of work to make android apps run in chromeOS running in a container that requires the right kernel and special compatibility libs / services running to pretend to be android.
Doubts:
- Is it better/faster/more compatible than anbox?
- Runs on ARM?
- Does it allows me to watch DRM streaming services on my linux box?
- Can I install google play on it?
- Is it better/faster/more compatible than anbox?
- Runs on ARM?
- Does it allows me to watch DRM streaming services on my linux box?
- Can I install google play on it?
I feel like you're expecting a lot from a a container running LineageOS with some integrations into the window manager.
It's a container so the arch matches the host kernel.
In general on LineageOS it's possible to install gapps.
You won't be able to watch DRM streaming services that require Widevine higher than L3 support.
It's a container so the arch matches the host kernel.
In general on LineageOS it's possible to install gapps.
You won't be able to watch DRM streaming services that require Widevine higher than L3 support.
> - Does it allows me to watch DRM streaming services on my linux box?
It doesn't include a HSM, so if it does allow you to watch DRM content, it'll only be Widevine level 3 content, which most services restrict to 420p or sometimes 720p streaming.
https://support.google.com/widevine/answer/6072714?hl=en
It doesn't include a HSM, so if it does allow you to watch DRM content, it'll only be Widevine level 3 content, which most services restrict to 420p or sometimes 720p streaming.
https://support.google.com/widevine/answer/6072714?hl=en
Waydroid has Android use your actual Linux kernel, so on an x86-64 host you’ll run x86-64 Android, and on an ARM host, ARM Android. This means that there will be some apps that won’t run on your Intel/AMD computer. I have no idea at all how common it is for Android apps to be tied to ARM, but I imagine that ARM64 will have helped with architecture-neutrality.
> This means that there will be some apps that won’t run on your Intel/AMD computer.
Should be able to still run them if you use binfmt_misc. Of course it will be slower but it's possible.
Should be able to still run them if you use binfmt_misc. Of course it will be slower but it's possible.
> binfmt_misc
https://en.wikipedia.org/wiki/Binfmt_misc
> binfmt_misc can also be combined with QEMU to execute programs for other processor architectures as if they were native binaries.[9]
QEMU supported [ARM guest] machines: https://wiki.qemu.org/Documentation/Platforms/ARM#Supported_...
Edit: from "Running and Building ARM Docker Containers on x86" (which also describes how to get CUDA working) https://www.stereolabs.com/docs/docker/building-arm-containe... :
> multiarch/qemu-user-static is to enable an execution of different multi-architecture containers by QEMU [1] and binfmt_misc [2]. Here are examples with Docker [3].
https://en.wikipedia.org/wiki/Binfmt_misc
> binfmt_misc can also be combined with QEMU to execute programs for other processor architectures as if they were native binaries.[9]
QEMU supported [ARM guest] machines: https://wiki.qemu.org/Documentation/Platforms/ARM#Supported_...
Edit: from "Running and Building ARM Docker Containers on x86" (which also describes how to get CUDA working) https://www.stereolabs.com/docs/docker/building-arm-containe... :
sudo apt-get install qemu binfmt-support qemu-user-static # Install the qemu packages
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes # Execute the registering scripts
docker run --rm -t arm64v8/ubuntu uname -m # Test the emulation environment
> multiarch/qemu-user-static is to enable an execution of different multi-architecture containers by QEMU [1] and binfmt_misc [2]. Here are examples with Docker [3].
Why the heck isn't there just an official Android container and/or a LineageOS container?
It's not a certified device, so.
There are a number of ways to build "multi-arch docker images" e.g. for both x86 and ARM: OCI, docker build, podman build, buildx, buildah.
Containers are testable.
Here's this re: whether the official OpenWRT container should run /sbin/init in order to run procd, ubusd,: https://github.com/docker-library/official-images/pull/7975#...
AFAIU, from a termux issue thread re: repackaging everything individually, latest Android requires binaries to be installed from APKs to get the SELinux context label necessary to run?
It's not a certified device, so.
There are a number of ways to build "multi-arch docker images" e.g. for both x86 and ARM: OCI, docker build, podman build, buildx, buildah.
Containers are testable.
Here's this re: whether the official OpenWRT container should run /sbin/init in order to run procd, ubusd,: https://github.com/docker-library/official-images/pull/7975#...
AFAIU, from a termux issue thread re: repackaging everything individually, latest Android requires binaries to be installed from APKs to get the SELinux context label necessary to run?
If the app doesn't use any native libraries, it should be able to run on any architecture. Otherwise, I don't think you'll find many developers shipping x86/x86_64 binaries nowadays considering there are no real devices that use it.
I think Intel has (or had?) a tool/library for translating ARM to x86 called Houdini. Can't seem to find it though, and it might require a license anyways.
I think Intel has (or had?) a tool/library for translating ARM to x86 called Houdini. Can't seem to find it though, and it might require a license anyways.
Aren't x86 chromebooks real devices?
If you mean x86_64 then yes certainly. They are about as common as ARM64 Chromebooks these days.
Can Chrome books run Android apps?
Yes they can. It's been an advertised feature for a few years.
TIL! In that case, x86 builds are probably more common than I assumed.
> but I imagine that ARM64 will have helped with architecture-neutrality.
What would have helped a lot more here is the default emulator in Android Studio is currently, and has been for a while now, x86. Since of course x86 to x86 virtualization is a lot faster than ARM to x86 virtualization.
ARM64 didn't do much to help with architecture-neutrality just like X86_64 didn't.
What would have helped a lot more here is the default emulator in Android Studio is currently, and has been for a while now, x86. Since of course x86 to x86 virtualization is a lot faster than ARM to x86 virtualization.
ARM64 didn't do much to help with architecture-neutrality just like X86_64 didn't.
> Is it better/faster/more compatible than anbox?
From the Anbox website:
> "We're reusing what Android implemented within the QEMU-based emulator for OpenGL ES accelerated rendering."
I'm not certain but I believe WayDroid more directly attempts to provide Android drawing subsystems on top of Wayland. This should be better/faster. Cross fingers.
Compatibility wise, I'm unsure. Anbox may be a more faithful Android platform perhaps. Waydroid feels like it's a closer integration to me, with less virtualized-machinery, which is a much wider support target since it's running directly atop a wide variety of hosts. But I for one am very glad we have a closer integrated option, one where Android apps are running more within the Linux desktop context.
There's probably a bunch wrong with my understandings here. Hoping some even better informed people can correct/supplement.
From the Anbox website:
> "We're reusing what Android implemented within the QEMU-based emulator for OpenGL ES accelerated rendering."
I'm not certain but I believe WayDroid more directly attempts to provide Android drawing subsystems on top of Wayland. This should be better/faster. Cross fingers.
Compatibility wise, I'm unsure. Anbox may be a more faithful Android platform perhaps. Waydroid feels like it's a closer integration to me, with less virtualized-machinery, which is a much wider support target since it's running directly atop a wide variety of hosts. But I for one am very glad we have a closer integrated option, one where Android apps are running more within the Linux desktop context.
There's probably a bunch wrong with my understandings here. Hoping some even better informed people can correct/supplement.
What streaming service doesn't work on FF ESR on Linux?
Netflix and prime and Pluto do, at least. That's all I use, so I am curious. I don't stream anything else, no Roku or Android-tv or whatever.
Netflix and prime and Pluto do, at least. That's all I use, so I am curious. I don't stream anything else, no Roku or Android-tv or whatever.
4k Netflix doesn't work on Linux, and also downloading for offline viewing, but I think those only work on Windows with HDCP enabled.
None on ARM. Google never offered widevine to Firefox on ARM64.
Exactly, AFAIK you can't watch netflix on your ARM SBC.
You can, all you need to do is to extract the widevine binary from a ChromeOS arm build and put them on your Pi/ARM board.
Admittedly, it's a bit cumbersome to do this, but it works very well. I've been watching Netflix on my Raspberry Pi 4 for over a year using it.
Also, according to this guy [0] you now seem to be able to just install libwidevine in Raspberry OS. I haven't tested this yet though.
[0]: https://lemariva.com/blog/2021/04/raspberry-pi-amazon-prime-...
Admittedly, it's a bit cumbersome to do this, but it works very well. I've been watching Netflix on my Raspberry Pi 4 for over a year using it.
Also, according to this guy [0] you now seem to be able to just install libwidevine in Raspberry OS. I haven't tested this yet though.
[0]: https://lemariva.com/blog/2021/04/raspberry-pi-amazon-prime-...
Right, as long as you are using Chrome (maybe chromium in a 32 bit chroot or container if you do not have an RPI), you can use widevine. But I'm not a big fan of the RPI devices, or chrome.
I'm glad to recently switch to Linux as my primary OS with things like these available. Windows 11's android app integration now doesn't sound as appealing.
Can anyone post a list of terminal commands to install Waydroid in Ubuntu 21? I'm a total Linux noob who just migrated from Windows.
I got as far as:
Sudo apt install python3 && curl && lxc
I don't know how to word the install for wayland session manager.
And copy pasting the.... "export DISTRO="bullseye" && \ curl https://repo.waydro.id/waydroid.gpg > /usr/share/keyrings/waydroid.gpg && \ echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && \ sudo apt update"
...told me permission denied to modify some files, even if I did it as "sudo".
I think once I get past that point I'll be able to type in the rest of the commands to start running it.
I think it would be lots of fun to run Android apps on a FOSS Android module. I was running LineageOS in VMWare within Windows, and it was ok.
Thanks!
I don't know how to word the install for wayland session manager.
And copy pasting the.... "export DISTRO="bullseye" && \ curl https://repo.waydro.id/waydroid.gpg > /usr/share/keyrings/waydroid.gpg && \ echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && \ sudo apt update"
...told me permission denied to modify some files, even if I did it as "sudo".
I think once I get past that point I'll be able to type in the rest of the commands to start running it.
I think it would be lots of fun to run Android apps on a FOSS Android module. I was running LineageOS in VMWare within Windows, and it was ok.
Thanks!
I tested it on bullseye, so I had to change nothing. I think, the thing you have to change is replacing
export DISTRO="bullseye"
export DISTRO="focal"I tried it on Ubuntu 20.04 LTS which is also focal, but I'm getting this error on "apt update":
Get:4 https://repo.waydro.id focal InRelease [1,343 B]
Err:4 https://repo.waydro.id focal InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 959FE34E90E51522
Reading package lists... Done
W: GPG error: https://repo.waydro.id focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 959FE34E90E51522
E: The repository 'https://repo.waydro.id focal InRelease' is not signed.
Unfortunately I'm still getting:
"bash: /etc/apt/sources.list.d/waydroid.list: Permission denied"
"bash: /etc/apt/sources.list.d/waydroid.list: Permission denied"
Try "sudo" before the command that failed.
I think it will become: "export DISTRO="bullseye" && sudo curl https://repo.waydro.id/waydroid.gpg > /usr/share/keyrings/waydroid.gpg && sudo echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && sudo apt update"
I think it will become: "export DISTRO="bullseye" && sudo curl https://repo.waydro.id/waydroid.gpg > /usr/share/keyrings/waydroid.gpg && sudo echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && sudo apt update"
That command won't work because the lrrmjddkkn problem stems from the redirection to a file. Running curl as root doesn't elevate the shell and therefore won't give you write access to /usr/share.
I don't understand why developers don't just use the output flag of curl instead of using file redirections like this. sudo curl -o [...] would've prevented all of that, instead of relying on someone being logged in as root (which is a terrible security practice I thought we as Linux users have been over already). I have to replace I/O redirections with sudo tee way too often, and it's impossible for any Linux beginner to understand what's going on here.
I don't understand why developers don't just use the output flag of curl instead of using file redirections like this. sudo curl -o [...] would've prevented all of that, instead of relying on someone being logged in as root (which is a terrible security practice I thought we as Linux users have been over already). I have to replace I/O redirections with sudo tee way too often, and it's impossible for any Linux beginner to understand what's going on here.
This is what my terminal shows:
sudo curl https://repo.waydro.id/waydroig.gpg > /usr/share/keyrings/waydroid.gpg && echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && \ > echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && \ > sudo apt update bash: /usr/share/keyrings/waydroid.gpg: Permission denied
sudo curl https://repo.waydro.id/waydroig.gpg > /usr/share/keyrings/waydroid.gpg && echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && \ > echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list && \ > sudo apt update bash: /usr/share/keyrings/waydroid.gpg: Permission denied
You are not pasting the command I typed. Look with attention.
sorry, I'm just not getting it. After typing:
export DISTRO="bullseye"
I do the sudo curl....waydroing.gpg
and it gives me the permission denied thing.
I also tried with "focal" and yielded the same result.
Maybe I'll leave the project for now until I get a better grasp of the terminal.
Maybe I'll leave the project for now until I get a better grasp of the terminal.
When invoking `sudo`, you're escalating privileges on the command followed but that doesn't apply to the redirection of output (`>`). So it's saying permission denied to write to the files. You'll need to do something like `curl | sudo tee /path/to/file`. Same with `echo`.
Try one command at a time:
export DISTRO="focal"
sudo curl https://repo.waydro.id/waydroid.gpg > /usr/share/keyrings/waydroid.gpg
sudo echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list
sudo apt update
export DISTRO="focal"
sudo curl https://repo.waydro.id/waydroid.gpg > /usr/share/keyrings/waydroid.gpg
sudo echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" > /etc/apt/sources.list.d/waydroid.list
sudo apt update
Try this command (sudo is needed only for writing files):
DISTRO="focal"
sudo curl https://repo.waydro.id/waydroid.gpg -o /usr/share/keyrings/waydroid.gpg
echo "deb [signed-by=/usr/share/keyrings/waydroid.gpg] https://repo.waydro.id/ $DISTRO main" | sudo tee /etc/apt/sources.list.d/waydroid.list
sudo apt update
sudo apt install waydroidthis worked for me, thank you very much potyl!
Oh it almost worked! I got as far as the apt install waydroid this time.
However, it gave me this error:
The following packages have unmet dependencies: python3-gbinder : Depends: python3 (< 3.9) but 3.9.4-1 is to be installed
How do I downgrade python?
However, it gave me this error:
The following packages have unmet dependencies: python3-gbinder : Depends: python3 (< 3.9) but 3.9.4-1 is to be installed
How do I downgrade python?
instead of export DISTRO=....
use: export DISTRO=`grep DISTRIB_CODENAME /etc/lsb-release |awk -F= '{print $2}'`
Name strongly implies it requires Wayland? (which, eww)
But the front page doesn't make this too clear, can anyone confirm?
But the front page doesn't make this too clear, can anyone confirm?
Yes it requires Wayland.
FWIW you can just run a Wayland compositor in a window on X. Not sure if there's a way to get it working without the root window to make it seamless, but it's still an option.
EDIT: Actually I tried it and this doesn't want to work in an instance of weston running on top of X; not sure where the failure is.
EDIT: Actually I tried it and this doesn't want to work in an instance of weston running on top of X; not sure where the failure is.
Color me surprised :)
Obviously its no one's job to fix Wayland for me or anything like that, but I've literally never gotten Wayland to work on anything beyond a live distro. Now, of course, I haven't tried very hard because I have no use for it. But yeah.
Obviously its no one's job to fix Wayland for me or anything like that, but I've literally never gotten Wayland to work on anything beyond a live distro. Now, of course, I haven't tried very hard because I have no use for it. But yeah.
Eww? Do you honestly believe the future of the Linux desktop is anything but Wayland?
Well, yes, I do. I expect X11 to be around for quite a while, possibly even longer than Wayland. Now if Wayland itself gains some of the features which keep me at X11 - network transparency (through nx/x2go) and compatibility with the kitchen sink being the most important - this might change but until such a time I will use X11, as will many others.
Ha, are you me? get out of my head. My thoughts exactly.
Funny way to ask the question, which lets me know that it's at least still a question :)
What I believe doesn't matter of course, and I get that it's probably happening whether I like it or not; but this is the worst rollout of anything I've ever seen in the Linux world, and to me just violates the heck out of at least one of "the whole points" of using Linux.
Don't break backward compatibility! (and for me, e.g don't break my x2go)
What I believe doesn't matter of course, and I get that it's probably happening whether I like it or not; but this is the worst rollout of anything I've ever seen in the Linux world, and to me just violates the heck out of at least one of "the whole points" of using Linux.
Don't break backward compatibility! (and for me, e.g don't break my x2go)
Idea: take the open source Beagle Bone Black, which has open source schematics, put into (probably chunkier) phone form factor, add 4g phone modem.
Use containers to segregate any apps, e.g. web browser, maps, Signal/Telegram all in a separate container from each other.
Would this allow for less privacy-invasion from Google etc.?
Use containers to segregate any apps, e.g. web browser, maps, Signal/Telegram all in a separate container from each other.
Would this allow for less privacy-invasion from Google etc.?
BBB requires non-free drivers for the GPU, which are a huge PITA even if you don't mind them being non-free. You would end up with more-or-less a Nokia N9 clone.
It's better to use something like i.MX 8M Quad - you may want to take a look at the Librem 5; or if you want something lower-end than that then there's also the PinePhone which is based on A64.
It's better to use something like i.MX 8M Quad - you may want to take a look at the Librem 5; or if you want something lower-end than that then there's also the PinePhone which is based on A64.
i.MX still needs binary blobs. I think the only ARM SBC today that can run blob-free today is Radxa's Rock pi 4.
Why only that particular rk3399 board? My rock64 runs blob free, as I would imagine most rk3328 boards do. The rk3399 type c port does require a blob, but I guess that is optional and boards without the USB3 type c port do not need it. Other than that the only blob I need for my PBP is for the broadcom WiFi modem. Are there any ac WiFi modems that work without blobs? I have only seen the ath9k chipsets which top out at 802.11n
With that said, I worry an rk3399 would run hot in a phone. Hopefully the thermals on the rk3588 are better. But rockchip is dedicating die space to a poorly supported "neural processing unit" now, so we will have to see.
With that said, I worry an rk3399 would run hot in a phone. Hopefully the thermals on the rk3588 are better. But rockchip is dedicating die space to a poorly supported "neural processing unit" now, so we will have to see.
The USB-c port on the rock pi 4 is for power only, no eDP or any blob required for HDMI. The model A has no wifi, so no blob required for that too.
> i.MX still needs binary blobs
Which ones? Librem 5 runs an FSF-endorsed OS and is recommended by the FSF: https://www.fsf.org/givingguide/v11/.
Which ones? Librem 5 runs an FSF-endorsed OS and is recommended by the FSF: https://www.fsf.org/givingguide/v11/.
AFAIK fsf recommending a distro doesn't says much about the hardware it runs on. With regard to the blobs still required, see https://news.ycombinator.com/item?id=28189184
FSF recommends hardware which runs purely blob-free OSes. Such hardware can still have proprietary components, which can be considered "hardware, not software", i.e., have no access to RAM, CPU or network and do not require updates.
Purism solved the problem with the RAM here: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd....
Purism solved the problem with the RAM here: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd....
This was posted a long time ago. The phone has been available for a more than a year now and it still is not ryf-certified. I don't think it will ever be.
Have a look at my first link. FSF did not certify the phone, because they did not receive the units yet. Purism is struggling with delivery due to the supply chain problem. Nevertheless, FSF recommends Librem 5 every year, and they never recommend anything requiring binary blobs. I have no doubt it will be certified (later rather than sooner).
I couldn't find "FSF did not certify the phone, because they did not receive the units yet" in the links you posted.
Purism has been tight-lipped about getting ryf certification. These maneuvers around memory and hdmi look more like cheating to me. According to the links I posted, i.MX8 cannot be deblobbed. I stand by what I say: I don't think the librem-5 will ever get ryf-certified.
Purism has been tight-lipped about getting ryf certification. These maneuvers around memory and hdmi look more like cheating to me. According to the links I posted, i.MX8 cannot be deblobbed. I stand by what I say: I don't think the librem-5 will ever get ryf-certified.
> I couldn't find "FSF did not certify the phone, because they did not receive the units yet" in the links you posted.
Just below the picture of the phone, first sentence: While we're still waiting to get our hands on one, this device looks promising: https://www.fsf.org/givingguide/v11.
> These maneuvers around memory and hdmi look more like cheating to me.
Why does it matter to you that a secondary CPU which has no access to anything runs proprietary blobs to train the RAM? Do you also care about proprietary firmware of SSDs (and avoid them)?
Just below the picture of the phone, first sentence: While we're still waiting to get our hands on one, this device looks promising: https://www.fsf.org/givingguide/v11.
> These maneuvers around memory and hdmi look more like cheating to me.
Why does it matter to you that a secondary CPU which has no access to anything runs proprietary blobs to train the RAM? Do you also care about proprietary firmware of SSDs (and avoid them)?
> > I couldn't find "FSF did not certify the phone, because they did not receive the units yet" in the links you posted.
> Just below the picture of the phone, first sentence: While we're still waiting to get our hands on one, this device looks promising: https://www.fsf.org/givingguide/v11.
I'd still argue that it is a bit different from "FSF did not certify the phone, because they did not receive the units yet".
> > These maneuvers around memory and hdmi look more like cheating to me.
> Why does it matter to you that a secondary CPU which has no access to anything runs proprietary blobs to train the RAM? Do you also care about proprietary firmware of SSDs (and avoid them)?
To makes things clear: I'm not opposed to the "secondary processor exception". In this case specifically, the firmware was artificially stored on a ROM chip, and copied from there to "a secondary processor" by the main processor to unlock a feature (train the RAM) to allow the main processor to work properly. This is a bit too much for me. Also, I'm not sure the HDMI initialization runs on a secondary processor.
Also, librem-5 getting ryf-certified would make me very very happy. I really would love to see this happen.
> Just below the picture of the phone, first sentence: While we're still waiting to get our hands on one, this device looks promising: https://www.fsf.org/givingguide/v11.
I'd still argue that it is a bit different from "FSF did not certify the phone, because they did not receive the units yet".
> > These maneuvers around memory and hdmi look more like cheating to me.
> Why does it matter to you that a secondary CPU which has no access to anything runs proprietary blobs to train the RAM? Do you also care about proprietary firmware of SSDs (and avoid them)?
To makes things clear: I'm not opposed to the "secondary processor exception". In this case specifically, the firmware was artificially stored on a ROM chip, and copied from there to "a secondary processor" by the main processor to unlock a feature (train the RAM) to allow the main processor to work properly. This is a bit too much for me. Also, I'm not sure the HDMI initialization runs on a secondary processor.
Also, librem-5 getting ryf-certified would make me very very happy. I really would love to see this happen.
The "secondary processor exception" is abhorrent, it creates a perverse incentive for vendors who seek RYF to lock down firmware instead of leaving it open to reverse engineering and reimplementation by the community.
A better approach would be to require public documentation of which components are proprietary (for all processor ISAs, processors, other hardware, all firmware and all software) and what roles they play.
A better approach would be to require public documentation of which components are proprietary (for all processor ISAs, processors, other hardware, all firmware and all software) and what roles they play.
Every i.MX blob combined is an order of magnitude less problematic in practice than PowerVR blob on OMAP.
If Google privacy invasion is what you fear, then there are simpler solutions. Simply installing lineageOS on a supported android device yields a functioning, de-googlified phone. Install only open source apps (from F-Droid, for example) and you're all set.
Android itself containerizes/isolates apps, with better & better security features in modern versions. LineageOS also adds their own layer of security (ex-PrivacyGuard) on top.
Granted, not all phones are created equal, meaning some of them will have restrictive bootloaders/need more proprietary drivers. It's possible some of them have spyware built in their bootloader/recovery/hardware, although I haven't heard of it. And of course there's 0 fully open-source android hardware phones.
Which, speaking of... this would be excellent on pinephone, which runs linux. Would allow running android apps on it, which is very very useful of course. I might finally bite the bullet and buy it...
Android itself containerizes/isolates apps, with better & better security features in modern versions. LineageOS also adds their own layer of security (ex-PrivacyGuard) on top.
Granted, not all phones are created equal, meaning some of them will have restrictive bootloaders/need more proprietary drivers. It's possible some of them have spyware built in their bootloader/recovery/hardware, although I haven't heard of it. And of course there's 0 fully open-source android hardware phones.
Which, speaking of... this would be excellent on pinephone, which runs linux. Would allow running android apps on it, which is very very useful of course. I might finally bite the bullet and buy it...
You could just use a PinePhone, you'd probably get similar performance in a much more convenient form factor.
See the video comparing a pinephone to a librem-5 running supertuxkart: https://source.puri.sm/Librem5/community-wiki/-/wikis/Benchm...
They are not on par in terms of performance.
They are not on par in terms of performance.
Your idea has been (in principle) implemented here: https://puri.sm/products/librem-5.
What's different between this and anbox (other than support, focus, etc)?
How good is the 3d support, ie: Does it support a modern version of OpenGL ES? Can it process that via host hardware support (a la angle or similar)? Can it do that headlessly without an window server running on the host? Can the video output of the app be easily captured by nvenc or intel/amd equivalent?
Is arm translation supported natively or does it require plugins for the abi translation?
Are google's libraries (play services, play store, webview) or alternatives easy to install/supported?
Can the app data and system volume be mounted externally?
Can the system details (cpuid/flags, device name/mfg/model, android OS specifics) be provided/spoofed?
Can sensor inputs (gps location, tilt, multi-touch gestures, battery level, network status, camera/s) be easily simulated or passed from host sensor to the guest app? Can bluetooth be passed through from the host?
Would love for somebody to crush this space and not pivot immediately into commercial offering.
How good is the 3d support, ie: Does it support a modern version of OpenGL ES? Can it process that via host hardware support (a la angle or similar)? Can it do that headlessly without an window server running on the host? Can the video output of the app be easily captured by nvenc or intel/amd equivalent?
Is arm translation supported natively or does it require plugins for the abi translation?
Are google's libraries (play services, play store, webview) or alternatives easy to install/supported?
Can the app data and system volume be mounted externally?
Can the system details (cpuid/flags, device name/mfg/model, android OS specifics) be provided/spoofed?
Can sensor inputs (gps location, tilt, multi-touch gestures, battery level, network status, camera/s) be easily simulated or passed from host sensor to the guest app? Can bluetooth be passed through from the host?
Would love for somebody to crush this space and not pivot immediately into commercial offering.
I'm sorry if this is rude, but this comment reads really strangely. You seem to acknowledge that you really want something, whilst also accept you cannot do it for a lack of time|skill and then seem annoyed that the people who do ask for some kind of payment for their work?
I can understand how he ended up with that kind of accusatory tone. Existing solutions either come with severe compatibility issues(official Emulator, QEMU, etc.), or vaporwares with great demos(Project Astoria) or are really sketchy borderline malwares(rest of it - my presumptions) that does wonders.
Not just borderline. Most of the ones that can feasibly run a game for example are basically real malware.
I can run most games on the Android Studio emulator without much of an issue, though it takes a higher mid-tier system to do it.
Which games? I don't mean like Fruit Ninja or Candy Crush, but the games that people actively bot or abuse will have a ton of ridiculous bullshit (checking anti-root, safetynet, borderline malware or malware-esque SDKs that exfiltrate huge amounts of data)
You're right, probably nothing that would be the target of bots like that, so I don't know how well those would work.
I play a few games my kids got me addicted to, Williams Pinball, and miscellaneous niche games. They run fine. But I haven't tried some of the popular MMOs or games where farming is basically the point.
I play a few games my kids got me addicted to, Williams Pinball, and miscellaneous niche games. They run fine. But I haven't tried some of the popular MMOs or games where farming is basically the point.
Do you mind elaborating on this? Is it just because the use case turns into something like app install fraud?
It's everything from a mix of cryptominers being deployed quietly (since of course anyone installing these will have a low end or better GPU), app install fraud, review fraud, Play token theft, spyware-tier telemetry. Even on the ones that don't install anything bad at all, they tend to auto-install the lowest common denominator apps via advertisements or paid placement that then have their own absurdist SDKs or whatever for data collection and mining.
Pretty much any of the closed source emulators that can feasibly run games (i.e., be horribly abused en masse for botting games) are festering piles of crap.
Another super common thing in those low tier trash apps is using your computer as a proxy ala Hola. Pay-per-install for using you to run stolen card traffic.
Pretty much any of the closed source emulators that can feasibly run games (i.e., be horribly abused en masse for botting games) are festering piles of crap.
Another super common thing in those low tier trash apps is using your computer as a proxy ala Hola. Pay-per-install for using you to run stolen card traffic.
THis guy wants to run containers of Android games, such as the various Pay to Win Machine Zone games (they are just one example).
I played one of these once (some Final Fantasy thing) and the amount of manipulative social engineering, dopamine triggering sidegames, and manipulation by devs or employed super-players to "mix things up" to try to provoke people to fork over money was appalling.
Thankfully I used almost no money, I paid up for one or two things to see if they would be worth it (they weren't) before I could fully recognize the money extraction treadmill they were trying to get you one.
The games are a fascinating example of hyperinflation too.
I played one of these once (some Final Fantasy thing) and the amount of manipulative social engineering, dopamine triggering sidegames, and manipulation by devs or employed super-players to "mix things up" to try to provoke people to fork over money was appalling.
Thankfully I used almost no money, I paid up for one or two things to see if they would be worth it (they weren't) before I could fully recognize the money extraction treadmill they were trying to get you one.
The games are a fascinating example of hyperinflation too.
> The games are a fascinating example of hyperinflation too.
Can you elaborate on what's fascinating?
Can you elaborate on what's fascinating?
Aside from the social engineering aspect of constantly undermining the value of "currency" such as "gold" or resources like "food", etc.
The game devs have complete control over the value of things be it buildings, soldiers, items, etc. The ability to constantly release new tiers/soldiers/etc that instantly devalue previous invested time and work all in service to wring more real-world money from addicts...
Of course once too many new shiny things are released, suddenly the climb/intro for new players is too high.
So suddenly, new players are given far more of the original "currency" of gold and resource to skip past the beginning steps so they can come within shouting distance to where investing money would keep them alive.
Well, it's kind of like a perverse fiat currency and a central government with the power to impose regulations and print currency at will.
The fact that the "central government" started printing money / resources once several more tiers of buildings/soldiers/defenses were introduced devalued all that previous investment and work to startling degrees.
To me it was reminiscent of fiat currency and hyperinflation due to printing money.
The game devs have complete control over the value of things be it buildings, soldiers, items, etc. The ability to constantly release new tiers/soldiers/etc that instantly devalue previous invested time and work all in service to wring more real-world money from addicts...
Of course once too many new shiny things are released, suddenly the climb/intro for new players is too high.
So suddenly, new players are given far more of the original "currency" of gold and resource to skip past the beginning steps so they can come within shouting distance to where investing money would keep them alive.
Well, it's kind of like a perverse fiat currency and a central government with the power to impose regulations and print currency at will.
The fact that the "central government" started printing money / resources once several more tiers of buildings/soldiers/defenses were introduced devalued all that previous investment and work to startling degrees.
To me it was reminiscent of fiat currency and hyperinflation due to printing money.
Just looking for the delta between this and anbox free/anbox cloud/genynotion cloud. No quams about paying for it honestly, just inquiring if any of these formerly paid-only (or build it yourself) features are being offered in the open here.
From what I understand this is aimed only at ARM, so there's no emulation. This is therefore targeting Linux phones, but not Linux on desktop (which is usually run on x86).
From what I saw on docs, it seemed to be agnostic to host linux architecture (x86 or arm host), but it did say (on the desktop guide):
> The apk files you will sometimes find on the internet tend to only have arm support, and will therefore not work on x86_64.
Suggesting that they don't provide cross-abi compatability. If/when they move to Android 11 as the underlying image - it has both x86 and arm translations built into the packaged abi. I suspect that it will be on the user to install any abi translation packages (libhoudini for example) in order to get arm apk's to run on x86 host without qemu.
> The apk files you will sometimes find on the internet tend to only have arm support, and will therefore not work on x86_64.
Suggesting that they don't provide cross-abi compatability. If/when they move to Android 11 as the underlying image - it has both x86 and arm translations built into the packaged abi. I suspect that it will be on the user to install any abi translation packages (libhoudini for example) in order to get arm apk's to run on x86 host without qemu.
That's one way to look at it. Another is that we have this beautiful open source commons that most devs make use of and we would like it to be richer.
Did they edit their comment after your reply? I'm not seeing aspects you refer to (esp the time/skill point)
agreed
That's quite the shopping list
Real use cases/requirements.
Perhaps! My point was that it's quite a large order for the desired price of 0.
Those are just questions. I think the OP would accept the answers "no".
I mean sure he would accept the answer "no", but why even ask the questions in the first place?
That is like going to a used car lot, looking at a car with a tag price of 1000 dollars and asking is it electric, does it have doors that open like wings, does it have level 2 autonomous etc. Sure, you will take no for an answer, but why you be even asking that?
That is like going to a used car lot, looking at a car with a tag price of 1000 dollars and asking is it electric, does it have doors that open like wings, does it have level 2 autonomous etc. Sure, you will take no for an answer, but why you be even asking that?
To me those questions are more like; Does it have wheels, do the wheels have tyres, does it have brakes, is it road legal?
Asking about the existence of such things is not a suggestion that they must be provided at that price. It's simply the baseline criteria for some people to want to use it.
Asking about the existence of such things is not a suggestion that they must be provided at that price. It's simply the baseline criteria for some people to want to use it.
>To me those questions are more like; Does it have wheels, do the wheels have tyres, does it have brakes, is it road legal?
Considering the availability of the demanded product at the respective price points, I think that my analogy is much more accurate than yours.
>Asking about the existence of such things is not a suggestion that they must be provided at that price.
Sure, it is up to you to choose what product you want. But you should still have some awareness about the price of that product in the market. If someone offers a car for 5$ on ebay, I am going to assume it is a toy, not the real thing.
Considering the availability of the demanded product at the respective price points, I think that my analogy is much more accurate than yours.
>Asking about the existence of such things is not a suggestion that they must be provided at that price.
Sure, it is up to you to choose what product you want. But you should still have some awareness about the price of that product in the market. If someone offers a car for 5$ on ebay, I am going to assume it is a toy, not the real thing.
> If someone offers a car for 5$ on ebay, I am going to assume it is a toy, not the real thing.
The whole point of the OP's questions is that they didn't want to assume anything! I don't see the harm in asking these types of questions, even if the most likely answer to each of them is "no".
The whole point of the OP's questions is that they didn't want to assume anything! I don't see the harm in asking these types of questions, even if the most likely answer to each of them is "no".
I am not saying that the questions are outright harmful, just supporting another person's remark that "this comment reads really strangely".
There is no harm in asking whether the 1000$ car at the used car dealership comes with cars that open like wings either, but it would sound strange.
There is no harm in asking whether the 1000$ car at the used car dealership comes with cars that open like wings either, but it would sound strange.
> What's different between this and anbox
I believe Waydroid was originally "anbox-halium"—a rewrite with LXC to get closer to the metal.
I believe Waydroid was originally "anbox-halium"—a rewrite with LXC to get closer to the metal.
Why would anbox need lxc? For Ndk support? How good is it on waydroid?
LXC is needed to run the services that Android provides, for Android applications (Surfaceflinger, Audioflinger etc..)
Android ships with it's own init system that does a lot more than just starting/stopping services. And integrating those services manually into regular Linux desktop's init system would have been painful to say the least.
That's the reason Anbox runs the whole Android subsystem in it's own LXC container - to avoid having to patch the Android init system and various system libraries to load Android libraries from non AOSP paths. (Like /system/ , /vendor etc..)
From what i remember, The original Anbox used patched version of Android frameworks, that sent the application render data to the Anbox session manager running outside the container [1] , which then created the application windows and rendered it there. This was okay on desktop systems, but on mobile phones (Sailfish OS, Ubports devices) that were trying to use Anbox to provide app compatibility, this had a significant amount of overhead, that made it unusable.
Back then there was the sfdroid project, that tried to patch the Android frameworks running inside Anbox Container to directly create Wayland windows and render the applications directly (kind of like how Chrome OS used to do), instead of having the Anbox session manager do it [2,3], bringing back most of the lost performance.
From the looks of it, Waydroid seems to be doing something similar [4]
1. https://github.com/anbox/anbox/blob/master/docs/architecture... 2. https://github.com/sfdroid/anbox/ 3. https://www.youtube.com/watch?v=78N1C2-6t3I 4. https://github.com/waydroid/android_hardware_waydroid/blob/l...
Android ships with it's own init system that does a lot more than just starting/stopping services. And integrating those services manually into regular Linux desktop's init system would have been painful to say the least.
That's the reason Anbox runs the whole Android subsystem in it's own LXC container - to avoid having to patch the Android init system and various system libraries to load Android libraries from non AOSP paths. (Like /system/ , /vendor etc..)
From what i remember, The original Anbox used patched version of Android frameworks, that sent the application render data to the Anbox session manager running outside the container [1] , which then created the application windows and rendered it there. This was okay on desktop systems, but on mobile phones (Sailfish OS, Ubports devices) that were trying to use Anbox to provide app compatibility, this had a significant amount of overhead, that made it unusable.
Back then there was the sfdroid project, that tried to patch the Android frameworks running inside Anbox Container to directly create Wayland windows and render the applications directly (kind of like how Chrome OS used to do), instead of having the Anbox session manager do it [2,3], bringing back most of the lost performance.
From the looks of it, Waydroid seems to be doing something similar [4]
1. https://github.com/anbox/anbox/blob/master/docs/architecture... 2. https://github.com/sfdroid/anbox/ 3. https://www.youtube.com/watch?v=78N1C2-6t3I 4. https://github.com/waydroid/android_hardware_waydroid/blob/l...
Ahh, I think I was mistaken. I think Anbox already used LXC (which was good because it wasn't emulating the whole OS). The key difference that Waydroid brings is that it is written for Wayland. I guess this is an advantage over X because of how Wayland exposes device hardware.
> Can it process that via host hardware support (a la angle or similar)?
You don't need ANGLE for that, Mesa supports OpenGL ES natively.
You don't need ANGLE for that, Mesa supports OpenGL ES natively.
- 3D support is using Mesa, so full GL accelleration on supported hardware (sorry nVidia, your Open-Source game sucks)
- Arm translation is on the radar, and we have solutions in the works. Just nothing ready for the masses yet.
- No Google Play Services as of yet. Some of our builds do use MicroG, Aurora Store, and other FOSS apps & open-source GMS options.
- It uses LXC, so yes, you can mount whatever is needed, we just don't have an exemplary (easy) way to do it yet.
- We are using hardware passthroughs via binder, so eventually Waydroid (Android side) will be able to access the system details available to it. Same with sensor inputs.
- We would all love to get paid, doing what we enjoy. But for this project, we are not even collecting donations yet. Money isn't what is driving this project. That's not saying that collecting donations and sponsorships aren't on our radar, just that it's not a primary focus. Open-Innovation is.
- Arm translation is on the radar, and we have solutions in the works. Just nothing ready for the masses yet.
- No Google Play Services as of yet. Some of our builds do use MicroG, Aurora Store, and other FOSS apps & open-source GMS options.
- It uses LXC, so yes, you can mount whatever is needed, we just don't have an exemplary (easy) way to do it yet.
- We are using hardware passthroughs via binder, so eventually Waydroid (Android side) will be able to access the system details available to it. Same with sensor inputs.
- We would all love to get paid, doing what we enjoy. But for this project, we are not even collecting donations yet. Money isn't what is driving this project. That's not saying that collecting donations and sponsorships aren't on our radar, just that it's not a primary focus. Open-Innovation is.
Awesome, very excited and will be following the project. Let me know when you have a donate button - or if you need testbeds.
We are working on growing our testers from just us, to a few capable users out there currently. Hit us up on Telegram or Matrix and I will try to get that group started soon.
This could be useful for web development. You could download a bunch of Android browsers and test your site(s) with them, without having to do that on a finicky phone (for those who want to do everything on a desktop PC)
You know you have been able to do that for ages using the official android emulator, right?
One thing I've run into with these projects is that they don't work well in a multi user setting. Anbox specifically assumes that only a single user is present in the system and having multiple users with multiple app profiles seems to be entirely unsupported.
I can't find anything about that use case in the description here, but if anyone has tried it I'd love to hear if Waydroid would be a fit for my use case.
I can't find anything about that use case in the description here, but if anyone has tried it I'd love to hear if Waydroid would be a fit for my use case.
Very nice project... but why does the third paragraph has a contenteditable tag set to true?
Lol! How did you notice this?
Thanks for filing the issue. Pushed the update after I got out of work ;)
Followed instructions for 21.04 (distro = "hirsute"), greeted with complaint about binder missing. Found some bug report on the web suggesting I must rebuild my kernel to enable binder. Noped out of there.
Looks like a nice effort though. Is this some problem specific to 21.04 kernel config?
Looks like a nice effort though. Is this some problem specific to 21.04 kernel config?
In Ubuntu kernels the Android modules are named "binder_linux" and "ashmem_linux" so:
sudo modprobe binder_linux
sudo modprobe ashmem_linux
Also if you have secureboot on,you won't be able to load ashmem because it's not signed by default by ubuntu. That is without signing the module yourself. I have waydroid running in 21.04 without any issues.
I have seen an error like that with anbox before, but it was not on Ubuntu. I just had to mount the binderfs and it stopped complaining. Might be worth a try:
mount -t binder binder /dev/binderfs
Sounds better than -the dead- Anbox
If it's simple to set up, I'd like to use this for verifying and accessing private app data from Android backups without having to use a 2nd phone.
Does it support arm64 emulation on an x86_64 host? That way I could just run the backed up apks directly.
Does it support arm64 emulation on an x86_64 host? That way I could just run the backed up apks directly.
Whoa this is awesome, curious if I can run a WhatsApp matrix bridge with this
Does someone know why Arch Linux doesn't come with the binder and ashmem modules enabled by default?
Both are required to run Anbox and Waydroid so you have to switch to another kernel or build one yourself.
Both are required to run Anbox and Waydroid so you have to switch to another kernel or build one yourself.
It will be interesting to see how these kind of solutions compare with emulators for e2e testing of Android apps locally and on CI.
I hope they get this running through Termux now that it supports containers on the latest Lineage OS builds.
[deleted]
Interesting. Might have to see if this can run tasker for automation
Does the Live Captioning feature work in Waydroid?
Is it running on any cloud (aws, gcp, azure)?
Is there a way it will run on a mac M1 ?
looks amazing, wondering if it is possible to run NDK programs? didn't find any related info in docs
without snap and other propretiary stuff? then i would take it.
Snapd is opensource
While snapd is open source, it's main (sole) purpose is to run (proprietary) software sourced from a propietary store.
so now we have waydroid and anbox
It sort of looks like these guys said hey if anbox folks aren’t going to update their android version, let’s fork it and do our own thing? There are some random anbox files in the repo for waydroid.
Waydroid was formerly known as anbox-halium; I believe it was a rewrite of Anbox to use system capabilities more or something, but I’m fuzzy on the details.
(As to what it’s now known as, I’m not actually certain: in most places it’s spelled Waydroid, but there are a number of places where it’s spelled WayDroid instead. Waaaaah! I can’t cope!)
(As to what it’s now known as, I’m not actually certain: in most places it’s spelled Waydroid, but there are a number of places where it’s spelled WayDroid instead. Waaaaah! I can’t cope!)
oh super interesting to know about the anbox-halium history, thanks for that info.
* The good
* The bad
* The ugly: