Flatpak support

[vchernin]

https://www.flatpak.org/

This would make it hopefully easier to install on non Debian-based distros.

Since Flatpak is a container based system, I'm not sure how easy this is given Waydroid is itself a container.

[mmcnutt]

Waydroid relys on binder and ashmem, which most distros dont enable in their kernels by default. There's probably no reason that you couldn't package libgbinder and the user space components, but for now the stumbling block for people looking for easy Waydroid would be the kernel.

[kevinsmia1939]

Please make app suggestion in flathub forum.

[allaeddineomc]

Waydroid relys on binder and ashmem, which most distros dont enable in their kernels by default. There's probably no reason that you couldn't package libgbinder and the user space components, but for now the stumbling block for people looking for easy Waydroid would be the kernel.

maybe making a waydroid flatpak would make more people notice it and want to use it since they will be confident that installing it is easy and won't break their system or fill it with garbage , than it will be a matter of time for distros to start adding binder and ashmem to their kernels because a distro that can't run mainstream software is a bad distro and distro maintainers know this very well

[vchernin]

Unfortunately doing this will likely be a non-trivial amount of work, because Flatpak itself is a sandboxed container. It's possible Waydroid would have to target a Flatpak container instead of the LXC container for it to work. Otherwise a container within a container is not really feasible.

Still I would be happy to help try write a Flatpak if there's confirmation it's theoretically possible.

[allaeddineomc]

Unfortunately doing this will likely be a non-trivial amount of work, because Flatpak itself is a sandboxed container. It's possible Waydroid would have to target a Flatpak container instead of the LXC container for it to work. Otherwise a container within a container is not really feasible.

Still I would be happy to help try write a Flatpak if there's confirmation it's theoretically possible.

no that's not the case , waydroid can still use lxc as it is when put into a flatpak , running a container inside a sandboxed envirenment isn't anything new , take for example anbox snap , and also note that running a container inside another container have no performance hit what soever , since containers are just an easy to mange chroots that run natively

[kevinsmia1939]

@allaeddineomc
Flatpaking anbox was discuss here.
anbox/anbox#62

It is not trivial to do it and no one manage to do it.

[allaeddineomc]

@allaeddineomc
Flatpaking anbox was discuss here.
anbox/anbox#62

It is not trivial to do it and no one manage to do it.

guys who do snap won't do flatpak just because they hate it , same for flatpak guys won't make a snap because it's not really universal and very slow , they haven't done it not because it's hard but because they don't want

[nsrosenqvist]

Just came across this bit of news that might be of interest, highlighting Flatpak's improved sub-sandbox support: https://www.phoronix.com/scan.php?page=news_item&px=Flatpak-1.12-Released

[krillin666]

Any update on this ? 😁

[rugk]

Indeed it would be nice if you could publish this as a flatpak on flathub e.g.
Flatpaks are a new software distribution mechanism for Linux distros, can thus installed on any distro and are easy to update.
Here is how to get started.

BTW, as teh snap discussion sparked, I personally would prefer flatpak. In contrast to snap, you can also self-host it, so you stay in control, and it is widely supported. (snap is not so nice to setup in many distros and snap's security depends on AppArmor, which is not always available in many distros)
Also – in contrast to snaps – flatpaks do not only claim to be distro-independent, but actually are.
Furthermore even Linux Mint criticizes snap, because you cannot self-host a snap server as it is proprietary and (thus) also cannot modify the packages that are served centralized by Ubuntu.

[Fuseteam]

But snap is distro independent people install it on distros that don't ship it.
Linux mint's blog post is full of misinformation about snap

And the majority in this entire thread has given no real technical details what it would require to setup and lxc container as root and a session as the user as a flatpak.
Snaps and flatpaks simply are not comparable both have their own goals and purposes. Flatpak is simply not fit for waydroid

Anbox is years old, the author is not against commit that enable flatpak support, and it has been noted by a known flatpak contributor that flatpaks cannot get root access, something both anbox and waydroid need to set up their container manager

Additionally in the 5 years since that issue has been opened nobody, not even purism has managed to prove otherwise

[TheEvilSkeleton]

But snap is distro independent people install it on distros that don't ship it.

Err not really. Firstly, Snap hard depends on systemd so any distro that does not use systemd, e.g. Gentoo, Artix, Devuan, etc., are very likely to not work with Snap.

Secondly, Snap relies on AppArmor to sandbox, so if you use Fedora Linux or any dsitro that does not use AppArmor, then the sandboxing is practically nonexistent, so it's really not distro independent.

But I digress, Waydroid Flatpak is unlikely to happen because of the reasons you have mentioned. Flatpak is too restrictive so for now it's impossible, unless we find workarounds.

[Fuseteam]

fwiw snap works fine on fedora and centos both from the red hat line, as seen from the stats people are using it. apparmor and selinux aren't particularly mutually exclusive both can work together.
there are ways to get working on gentoo (it's even mentioned in the link you quoted xd) systemd isn't exactly a monolithic thing in fact ubuntu 16.04, that ran snaps, still shipped upstart :p
ok a mix of systemd and upstart point is not the entirety of systemd is need, just a specific component. if i had to guess which, its systemd mounting mechanism.........but i'm straying offtopic

i honestly don't think we should force waydroid into flatpak, flatpaks are best suited for actual desktop software. and they work great for that, i see no reason for flatpaks to try and match snap's functionalities. the two are made for different usecases, and that's fine

waydroid is more suited as a traditional package anyway, where it can get the access it needs to run. if we have to go to a universal package there is currently only one suitable format. but it appears the community won't appreciate that effort

[TheEvilSkeleton]

fwiw snap works fine on fedora and centos both from the red hat line, as seen from the stats people are using it.

How do you define "fine"? The sandboxing is literally nonexistent because Snap relies on AppArmor, which Fedora doesn't use. And that's anything but fine. This isn't Android where only one MAC is used. We have AppArmor, SELinux and more. Furthermore, distributions that don't even have a MAC pre-installed, like Arch Linux, aren't benefiting from the sandboxing either, unless they install AppArmor.

apparmor and selinux aren't particularly mutually exclusive both can work together.

I don't know of a mainstream distro that uses both, so whether what you're saying is true or false, is impractical at best.

there are ways to get working on gentoo (it's even mentioned in the link you quoted xd) systemd isn't exactly a monolithic thing

Gentoo lets you choose other init systems/service managers, including systemd. However, by default, it uses OpenRC. Many Gentoo users use Gentoo simply because systemd is an option and not an obligation. But my point still stands: you cannot run Snap on systems that aren't using systemd.

in fact ubuntu 16.04, that ran snaps, still shipped upstart :p

Okay?

Really, there are very little reasons for using Snap on the desktop. It's a server package manager poorly adapted to the desktop.

[ShadowJonathan]

Really, there are very little reasons for using Snap on the desktop. It's a server package manager poorly adapted to the desktop.

Interestingly, i disagree, as my experience with snaps has been abysmal for server application management, simply because it does not allow update control. The developers being more and more hostile and dismissive the more i press on this only seems to prove they think they know best for their users, but for server software, administrators simply need full control, which snap doesn't get.

I thought the saving grace would be that snaps "at least" would be more useful on the desktop, for user applications, and left it at that, but alas.

[Fuseteam]

I disagree my experience with snap has been fine, "update control" is less of an issues one you learn of snap's channel system. Also the app awareness system that has been testing.

I won't comment on whether or not sandboxing exists on distros without apparmor, all i know is that it is used on those system and people continue to use it on those systems. Even rocky linux and alma linux made it into the stats. It surely does something right if people are returning to it.
My main point about gentoo and possibly other systemd-less systems is that snap doesn't depend on systemd as a whole(systemd itself isn't a monolithic thing). Snap simply depends on specific pieces of systemd, probably the part that mounts the squashfs images as loop mount devices at boot time, which can be set up without pulling the rest, people are actually doing that out there. Additionally the codebase for snapd, the core of the package management system, is opensource. If people really wanted to they could make it work without apparmor and without systemd.

But let's not turn this into a snap bashing thread, the thread is about flatpak support. And that simply isn't feasible.

[TheEvilSkeleton]

My main point about gentoo and possibly other systemd-less systems is that snap doesn't depend on systemd as a whole(systemd itself isn't a monolithic thing). Snap simply depends on specific pieces of systemd, probably the part that mounts the squashfs images as loop mount devices at boot time, which can be set up without pulling the rest, people are actually doing that out there. Additionally the codebase for snapd, the core of the package management system, is opensource. If people really wanted to they could make it work without apparmor and without systemd.

So what are you getting at and why does it matter to go in the specifics? It's like saying "Flatpak doesn't rely on the Linux kernel as a whole, only some parts". Sure, it's technically correct but at the end of the day, you can't use Flatpak outside of Linux, just like you cannot use Snap outside of systemd.

My only point was that it's not as universal as people may think because it hard depends on systemd for usability and relies on AppArmor for sandboxing. I'm unsure why you are defending Snap, when the issues are pretty clear as to why it's not a good option/alternative.

[zroug]

Flatpak has a portal, which allows applications to run commands outside of the sandbox. Maybe that could work until a more sandboxed approach is possible. It can be used by adding the permission --talk-name=org.freedesktop.Flatpak and then running flatpak-spawn --host.

https://docs.flatpak.org/en/latest/flatpak-command-reference.html#flatpak-spawn
https://docs.flatpak.org/en/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Flatpak

[ShadowJonathan]

I think this issue comes down to two things;

1. Support for flatpak packages to require a module to be installed in/for the kernel.
2. Ability to distribute dkms(?) next to flatpak packages.

I think both could be put forward better with an RFC in https://github.com/flatpak/flatpak, what do y'all think?

[TheEvilSkeleton]

Looks good. If you don't get any response, you can chat with them at https://matrix.to/#/#flatpak:matrix.org.

[gdonval]

Just one thing because people seem to mix things up easily...

It is not trivial to do it and no one manage to do it.

It is. It's just that no one cleary stated the obvious and acted upon it: waydroid and anbox are leaky as hell. They are dependent on special kernels and special kernel configuration and special boot environment.

Once that fact is accepted, it turns out that shipping a kernel with a program is surprisingly easy: you provide a VM. Gnome Boxes for instance ships with qemu, it works well and is self-contained so this much is trivial. With qemu-kvm, there should me almost no CPU performance loss and with virtio-gpu, gpu acceleration should be decent.

Of course, it does not mean waydroid as a project has to be shipped like that.

[ShadowJonathan]

you provide a VM

I don't think that is specifically neccecary, I was reminded of User Mode Linux, where a user can run a linux kernel in usermode as a seperate program. (Now its in the main source tree)

[Fuseteam]

It is. It's just that no one cleary stated the obvious and acted upon it: waydroid and anbox are leaky as hell. They are dependent on special kernels and special kernel configuration and special boot environment.

the "special" kernel you're referring to are likely the ashmem and binder kernel modules, these are requirements of android not of anbox nor waydroid. if you believe "it's trivial to do", by all means do it. this is an 5 year old open issue, discussions have been had in that time. the technically inclined have concluded that it's not technically feasible with to create a flatpak as it stands. no matter how many people say "flatpak +1", "flatpak is awesome", "flatpak is the future", "it's trivial to do, why isn't this done yet" if nobody stands up and actually do something about it it will not be done.

p.s. afaict if we're going into vm territory, we're better off putting lineage os in a kvm and be done with it

[gungwald]

We should not need to have a separate package tool for every different kind of app. I just want to install apps. I shouldn't have to deal with 5 different package tools to get the apps I want installed. What's next, are we going to build a separate package tool for every app? This situation is ridiculous. There should be only one package tool. That is what developers should be demanding, one package tool that can install any kind of app. The snap server is proprietary so that eliminates snaps as an option. Flatpak is the standard. If there are problems that prevent an app from being packaged as a flatpak, those issues should be communicated to the flatpak developers so they can provide the necessary features.

[Fuseteam]

what the heck are you talking about @gungwald? flatpak simply is not a technology made to install something like waydroid. by your own logic, waydroid itself is a package manager.
waydroid app install <name-of-app>.apk is a thing just like apt install <name-of-app>.deb is a thing, give or take paths

flatpak is a technology made to deliver desktop apps, and honestly it is good at what it does because it does one thing and does it well: deliver deliver apps, and it should stay that way :P snap tries to do much more than that, and you see the sentiment as a result of that :P

Stop trying to shove flatpaks and snaps in the same box, they don't fit. they are different technologies that have their own purposes and uses

[kon14]

@Fuseteam Why are you even so irritated over this?
If Waydroid maintainers feel like this issue is not worth keeping open they can always just close it themselves.

Stop trying to shove flatpaks and snaps in the same box, they don't fit. they are different technologies that have their own purposes and uses

Somehow I'm willing to bet none of the people subscribed to this thread care enough to place Snaps in any sort of box.
Expect maybe for that very same garbage bin currently occupied by Mir and every single other case of abandonware Canonical NIH projects.

[Fuseteam]

I'm irritated because people keep asking something of a technology, that it just wasn't designed for.
Flatpak does things well, but isn't a snap alternative. Just like snap isn't a flatpak alternative. They are different technologies for different purposes.

Speaking of NIH, snap was already a thing, then redhat started flatpak, upstart was already a thing, then redhat started systemd ;)
Nothing wrong with that, sometimes tools don't suit particular needs at a particular time. Time being of the essense it is often easier and quick to build an alternative ;)
P.s. Mir is a wayland display server very similar in architecture to xorg, in practice mutter, kwin and friend could stay window managers on top a wayland compositor, instead of reimplementing a wayland compositor of their own ;)

Long story short; flatpak cannot be used for waydroid. Both anbox and waydroid require to run a part that needs root. Flatpak does not and should not provide such access, flatpak having a clear separation between a application that runs with root privileges and an applications that has zero root privileges is a good thing, stop asking to kill a good feature

[Fuseteam]

@schklom read what i said again

sadly it is not that lxc requires root........running android inside of lxc requires root

also consider reading the context, just a few posts up i explained that

waydroid..... requires root permissions to start the container while the session has to be started with the regular user.

i guess you could say running waydroid requires 2 users: the root user and the regular user
the container is started by the root user while the session is started by the regular user

if you can submit a PR that manages to start both with just the regular user and are willing to address all regressions that may come up do feel free to do so.

[orowith2os]

Would it be possible to make Waydroid use podman for containers, rather than LXC? It would still require that the kernel has the required modules, I think, but would allow for running Waydroid without root (and a Flatpak can just use the host podman configuration for managing containers).

There might also be the possibility of using bwrap, as the Steam flatpak uses it for the Steam Linux Runtime and Flatpak spawns a separate sandbox for it, so that there's no sandbox-ception.

That said: I'm not familiar with how, exactly, Waydroid works, and have only used podman for using multiple Linux distros at a time. I only have a basic idea of how sandboxing works. Take my ideas with a grain of salt.

[mmcnutt]

@orowith2os I have attempted to get waydroid running in toolbox (which is essentially a frontend for podman) on Fedora Kinoite, and the stumbling block is always exposing the binderfs to the container. I understand this isnt exactly what you are asking as its still an LXC container inside the podman container, but I imagine even dropping android into a podman container is still going to have the same binderfs limitation.

My ultimate goal in trying was avoiding having to layer the waydroid packages on my ostree. Trying to get wd into a flatpak would achieve the same thing too

[godvino]

I had tried running a waydroid image in podman a while ago but it crashed on startup with Init encountered errors starting first stage, aborting because android tries to create devices like /dev/random and /dev/urandom (see here) but podman already creates them (see the OCI specification). Redroid can be used to run android in a podman container (it has some patches to fix booting) but it doesn't seem to work with SELinux,

[Fuseteam]

for what it is worth: waydroid requiring root is not due to lxc. it is due to the way android works.

Android needs the system to run as root and the session to run as the actual user. Remember We're running an operating system in a container. Android is a multiuser operating system. As far as i've understood android working properly depends on there being a root user and a normal user, fully separated from each other in order to work.

This is why if you do sudo waydroid session start waydroid will break.

Getting android itself to work in podman is, as mentioned, essentially Redroid. which has its own limitations compared to waydroid

[orowith2os]

I can have a (seemingly) rootful environment, inside of a rootless container. I don't think Android needing to run as root and the session as the user will change anything. All I can see that needs changing is for some bwrap/podman-specific things, and then it could work properly, although I'm not all that familiar with how it would be done.

[Fuseteam]

there are a lot of ways to have a fake "rootful" environment, that doesn't necessarily mean android will behave in it. i suppose this could be explored through the redroid project, which has as goal to run android in an OCI container (unlike waydroid's goal, which is to run as many android apps as seamlessly as possible on desktop linux)

[pktiuk]

waydroid's goal, which is to run as many android apps as seamlessly as possible on desktop linux

Easy to setup and use package for my distro is in my opinion a pretty important part of a seamless experience. (for now only debian-based distros have official packages)

It is a very good idea to get to know from redroid what is needed for android working properly in container which may be helpful with packaging it info flatpak.

[Fuseteam]

Easy to setup and use package for my distro is in my opinion a pretty important part of a seamless experience. (for now only debian-based distros have official packages)

sure but that also means that most apps just work, forcing android in a permission scheme it was not build for will break apps. Why don't you try redroid first? see where it's limits are compared to waydroid. Perhaps we could be wrap redroid in a waydroid like wrapper.....but i suppose that's a whole different project

also how much easier can you get than

sudo deb-get install waydroid
sudo systemctl start waydroid-container-manager
systemctl start --user waydroid-session-manager

huh? that last one isn't a thing yet? guess i know what my first pr will be........if nobody beats me to it xd

[pktiuk]

sure but that also means that most apps just work, forcing android in a permission scheme it was not build for will break apps.

I know that flatpak package will be not very reliable at the very beginning, but in the long time it may be worth the effort to have it done.
Do we have for now any single thing (interface/API/permission) which we can point at and tell that it is blocker and packaging into flatpak is not possible until they (people behind flatpak or bwrap) will fix it?
It would be a good justification to leave flatpak packaging for now.

Why don't you try redroid first?

Redroid is a similar case. Docker is not the way software should be provided to end-users.

[orowith2os]

If permissions are an issue, the Flatpak can be unlocked a lot more than you'd think, since you can just enable the permissions in the manifest. I think it would be ideal to first figure out how to get Android working inside of bwrap, and THEN work on making a Flatpak. AFAIK the current method Waydroid uses is similar to bwrap, so should be easy enough.

[Fuseteam]

I know that flatpak package will be not very reliable at the very beginning, but in the long time it may be worth the effort to have it done. Do we have for now any single thing (interface/API/permission) which we can point at and tell that it is blocker and packaging into flatpak is not possible until they (people behind flatpak or bwrap) will fix it? It would be a good justification to leave flatpak packaging for now.

the issue is, as stated multiple times in the thread, in order for android to work correctly you need a root user and a session user.
flatpaks cannot run one process as root and one process as a regular user, as it is made for desktop applications. Desktop applications shouldn't be doing this kind of sourcery, and shouldn't need to.

Redroid is a similar case. Docker is not the way software should be provided to end-users.

people are suggesting packing android in a podman container, this essentially what redroid already does.

Since nobody seems to have given redroid a try yet, let give you guys some motivation to give it a try:

i'll go on a limp and say that redroid has no hardware access: no camera, no gps, no bluetooth, no mic, no sensors whatsoever (something waydrotd does have).

why do i expect that? because it is my understanding that on linux, access to the hardware mentioned is managed by processes started by the root user.

now......anyone care to confirm or deny this?

[orowith2os]

Again, a Flatpak can be unlocked to allow host access (camera, bluetooth, mic, host filesystem), and it can be in a seemingly root environment, so that should work from my understanding. The only way to know if it would actually WORK is if someone were to make a bwrap-compatible image of Android and give it a try. Judging from what I've been told, it only needs to disable a few lines of code to start.

[Fuseteam]

if you believe you can make a packaged version using the redroid container work, then by all means do try ;)

[lifeiscontent]

For those of you wanting to run Andriod games on Steam Deck via Waydroid, it's currently possible, but a pretty hairy process. https://gitlab.com/popsulfr/steam-deck-tricks/-/tree/main#android-via-waydroid

[darkmastermindz]

For those of you wanting to run Andriod games on Steam Deck via Waydroid, it's currently possible, but a pretty hairy process. https://gitlab.com/popsulfr/steam-deck-tricks/-/tree/main#android-via-waydroid

This is the link I've been looking for! Thanks. Although flatpack support would be amazing to bring Waydroid to target the steam deck in a simpler manner.

[aleasto]

Running android in Flatpak would be an entirely different project.
Flatpak is not just a packaging spec. Waydroid works by sharing the host device nodes to the android container, while flatpak has the exact opposite intention.
Not going to happen here.

[orowith2os]

psssst, you can close something as not planned instead of completed

[RaptaG]

Disclaimer: I'm really sorry for anybody subscribed to this issue getting notified.

Is there anybody which would be willing to create and maintain a sandboxed, flatpak/flathub version of Waydroid? This is not a direct question to the maintainers/developers of Waydroid but to anyone with the motivation, skills and time to maintain such a project.

[RokeJulianLockhart]

The Flatpak sandbox can be almost entirely bypassed. All one needs to so is use flatpak overrides to grant access to the host system, and any mandatory aspects of the sandbox which remain can simply be ignored by using host process spawners.

I don't know whether this has already been covered since I've only read the top responses, but most of what I've read has demonstrated a general lack of research.

(I hope this doesn't.)

[westurner]

Why would it need to bypass the Flatpak sandbox security features?

…

On Mon, Apr 17, 2023, 7:09 PM rokejulianlockhart ***@***.***> wrote: The Flatpak sandbox can be almost entirely bypassed. All one needs to so is use flatpak overrides to grant access to the host system, and any mandatory aspects of the sandbox which remain can simply be ignored by using host process spawners. I don't know whether this has already been covered since I've only read the top responses, but most of what I've read has demonstrated a general lack of research. (I hope this doesn't.) — Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMNS4R45T253NLKO7DYBDXBXEUNANCNFSM5ERUZ5OA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Wladefant]

Here is a request on flathub: https://discourse.flathub.org/t/waydroid-android-apps-on-linux-request/2040

[Fuseteam]

guys, please read the thread before posting. It has been discussed, including why it is unfeasible to package waydroid as a flatpak. That's the least amount of research you can do, there's a reason this issue is closed.

Waydroid works as well as it does because how it is build.
flatpaks work as well as they do because they strongly defined their scope.

The way waydroid is build does not fit in the scope flatpak defined.

changing the scope of flatpak will ruin what it is good at, so that shouldn't be done.

changing the way waydroid is build will result in a whole new project and will likely function differently (see dock-droid which does fit in the scope of flatpak)

[westurner]

Is Bluetooth passthrough possible with dock-droid (KVM w/ X11 forwarding FWICS)? #155 https://github.com/sickcodes/dock-droid

…

On Mon, Jul 24, 2023, 6:16 PM Rahammetoela Toekiman < ***@***.***> wrote: guys, please read the thread before posting. It has been discussed, including why it is unfeasible to package waydroid as a flatpak. That's the least amount of research you can do, there's a reason this issue is closed. Waydroid works as well as it does because how it is build. flatpaks work as well as they do because they strongly defined their scope. The way waydroid is build does not fit in the scope flatpak defined. changing the scope of flatpak will ruin what it is good at, so that shouldn't be done. changing the way waydroid is build will result in a whole new project and will likely function differently (see dock-droid which *does* fit in the scope of flatpak) — Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMNS2S7BP6LYDPTB25JW3XR3X2JANCNFSM5ERUZ5OA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Fuseteam]

@westurner that is a question for dock-droid and out of scope for this thread

[rugk]

see dock-droid which does fit in the scope of flatpak

Ah, okay, then why does nobody ask there for a flatpak?

Fixed that now, so everyone who has subscribed here can unsubscribe and subscribe there ( 😉 ):
sickcodes/dock-droid#22