- It is very responsive and smooth
- Install just following instructions described
- F-droid works
- Apps installed from F-droid works
- Full screen videos from Newpipe play smoothly
* The bad
- Had to enable "invert colors" to get correct colors
- Mouse scroll is inverted
- Can't choose correct layout of physical keyboard because android thinks there's no physical keyboard connected
- Android gestures on the desktop are annoying
- Can't access whole screen of vertical apps and they appear sideways on my screen
- Multiwindow mode didn't work at first
* The ugly:
- Nothing is actually ugly. Everything mostly works as expected
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.
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.
Well it is a container rather than an emulator. Maybe some parts are emulated, like opengl, but I believe waydroid is a lot "closer to the metal" than anbox is.
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 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.
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.
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?
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.
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).
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.
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.)
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
> 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].
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.
> 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.
> "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.
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.
> - 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.
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.
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.
Is that an issue with the waydroid repository, or with my setup?
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.
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.
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`.
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.
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.
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.
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)
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.
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.
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.
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.
> 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)?
> > 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.
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.
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...
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.
- 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.
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.
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?
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.
>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.
> 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".
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]
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.
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.
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.
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.
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.
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.
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.
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)
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.
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?
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:
Where $version is the kernel version, for -generic kernels they are in the package "linux-modules-extra-${version}-generic" and for -lowlatency "linux-modules-${version}-lowlatency". On -generic the modules-extra may sometimes not be installed by default.
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.
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!)
* The good
* The bad * The ugly: