Bug 1455411 - Waydroid on Fedora
Summary: Waydroid on Fedora
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2055301 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-25 04:30 UTC by eric
Modified: 2022-08-21 20:48 UTC (History)
96 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-20 00:11:38 UTC
Type: Bug


Attachments (Terms of Use)
lucente waydroid log 20220308 (3.97 KB, text/plain)
2022-03-08 14:57 UTC, Rich Lucente
no flags Details
lucente journal log 20220308 (175.77 KB, text/plain)
2022-03-08 16:11 UTC, Rich Lucente
no flags Details
lucente waydroid logcat 20220308 (1.97 MB, text/plain)
2022-03-08 16:21 UTC, Rich Lucente
no flags Details
chris_waydroid_log (3.98 KB, text/plain)
2022-03-20 19:59 UTC, chris
no flags Details
chris_waydroid_logcat (147.83 KB, text/plain)
2022-03-20 19:59 UTC, chris
no flags Details
logcat (251.61 KB, text/plain)
2022-03-30 10:24 UTC, thebudget72
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1546896 0 unspecified CLOSED Snaps using classical confinement 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker FC-383 0 None None None 2022-01-31 07:50:28 UTC

Internal Links: 1546896

Description eric 2017-05-25 04:30:17 UTC
Request Fedora support for Anbox:
https://github.com/anbox/anbox

needs dkms packages for ashmem and binder kernel module to work on fedora.

Corresponding anbox issue:
https://github.com/anbox/anbox/issues/85

Comment 1 Jan Kurik 2017-08-15 06:27:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 2 Hedayat Vatankhah 2017-09-18 19:43:54 UTC
It'd not happen, since Fedora doesn't allow third party kernel modules.

Comment 3 Chuck Ebbert 2017-09-19 01:11:39 UTC
(In reply to Hedayat Vatankhah from comment #2)
> It'd not happen, since Fedora doesn't allow third party kernel modules.

ashmem and binder are in the official kernel sources. Maybe Fedora could have a kernel-modules-experimental package?

Comment 4 Hedayat Vatankhah 2017-09-19 12:13:27 UTC
Oops, sorry, I thought that they are not in the official kernel.

Comment 5 Hedayat Vatankhah 2017-09-19 12:13:46 UTC
Oops, sorry, I thought that they are not in the mainline kernel.

Comment 6 Laura Abbott 2017-09-20 00:11:38 UTC
Yes the drivers are in the mainline tree but I'm not excited about turning them on. ashmem is still very much in staging and the status of its replacement is kind of nebulous. While binder has moved out of staging, it's still tightly bound to libbinder in userspace. Enabling both of these in Fedora also increases the potential attack surface for exploits.

Anbox support should be going through Fesco for approval and have an owner to drive it, similar to the virtualbox drivers. This is not something the Fedora kernel maintainers can take up at the moment. I'm going to close this bug for now but if someone wants to drive this per https://fedoraproject.org/wiki/Changes/Policy this bug can be reopened.

Comment 7 eric 2017-09-20 01:58:42 UTC
Literally every bit of an OS makes it less secure. By this reasoning, why not remove the ability to do iptables -F, chmod 777 or sudo rm -rf /. Unlike anbox, Those are all present in the default install. Dkms makes anbox opt-in. This is consistent with Unix philosophy to provide the mechanism, not the policy. 

> This is not something the Fedora kernel maintainers can take up at the moment. I'm going to close this bug for now but if someone wants to drive this per https://fedoraproject.org/wiki/Changes/Policy this bug can be reopened.

I thought the whole concept of the Fedora <-> RHEL divide was to be a staging ground for the new stuff. Please reopen it, if driving it means I have to create a wiki page for it I'll do it.

Comment 8 Mosaab Alzoubi 2017-09-20 07:10:41 UTC
I'm with Eric. So I think time to close it not came yet.

Comment 9 Peter Robinson 2017-09-20 08:53:42 UTC
(In reply to eric from comment #7)
> Literally every bit of an OS makes it less secure. By this reasoning, why
> not remove the ability to do iptables -F, chmod 777 or sudo rm -rf /. Unlike
> anbox, Those are all present in the default install. Dkms makes anbox
> opt-in. This is consistent with Unix philosophy to provide the mechanism,
> not the policy. 

Fedora doesn't do DKMS in the core distro, if you want that functionality it goes into rpmfusion.

And something like iptables is not the same as opening the OS up to android malware.

> > This is not something the Fedora kernel maintainers can take up at the moment. I'm going to close this bug for now but if someone wants to drive this per https://fedoraproject.org/wiki/Changes/Policy this bug can be reopened.
> 
> I thought the whole concept of the Fedora <-> RHEL divide was to be a
> staging ground for the new stuff. Please reopen it, if driving it means I
> have to create a wiki page for it I'll do it.

It is, it's also nothing to do with RHEL. There's a lot of things done in Fedora but ultimately, as Laura mentioned, if you wish to do it yourself as an official change you can follow the policy linked and have it go through the Engineering Steering Committee (FESCo) for review and then have someone implement it.

A feature such as Anbox isn't as simple as enabling a few kernel modules and your done, it requires userspace and maintenance and contacts to deal with security CVEs etc

Comment 10 Mosaab Alzoubi 2017-09-21 06:12:47 UTC
> Fedora doesn't do DKMS in the core distro, if you want that functionality it 
> goes into rpmfusion.


The two modules we talking about are included in Kernel not separated ones !!! 

> A feature such as Anbox isn't as simple as enabling a few kernel modules and 
> your done, it requires userspace and maintenance and contacts to deal with 
> security CVEs etc 

It's not new package to do this !!!

Comment 11 Nerijus Baliūnas 2017-09-21 11:46:13 UTC
It does not matter. If Fedora does not want to include them, you should ask rpmfusion.

Comment 12 Chuck Ebbert 2017-09-21 13:50:51 UTC
Greg KH had this to say about binder today:

"To be fair, lots of people, including myself, have always said, "never
run binder on a system that is not a 'real' Android system" for a
variety of good reasons, including security issues.

"Now around the 4.10 or so kernel release, most of those issues were
resolved, and with 4.14, all of those have been taken care of (that I
know of), so this should be allowed."

So at least for binder the obvious security problems that would have stopped it from being included have been fixed.

Comment 13 Levente Farkas 2017-09-21 14:29:33 UTC
(In reply to Peter Robinson from comment #9)
> (In reply to eric from comment #7)
> > Literally every bit of an OS makes it less secure. By this reasoning, why
> > not remove the ability to do iptables -F, chmod 777 or sudo rm -rf /. Unlike
> > anbox, Those are all present in the default install. Dkms makes anbox
> > opt-in. This is consistent with Unix philosophy to provide the mechanism,
> > not the policy. 
> 
> Fedora doesn't do DKMS in the core distro, if you want that functionality it
> goes into rpmfusion.
> 
> And something like iptables is not the same as opening the OS up to android
> malware.

the original request said dkms but imho it was an accident. it should have to compiled as a kernel module for fedora (like all other kernel modules).

about the userspace anbox is s totally different issue and probably a separate bugzilla. but if the kernel module already included external or corp repos can add support for anbox.

Comment 14 Laura Abbott 2017-09-21 17:50:41 UTC
It's clear there is a lot of interest in Anbox on Fedora. As has been stated, just enabling the kernel modules isn't enough though as there are userspace components as well. This needs to go through the change process https://fedoraproject.org/wiki/Changes/Policy so everything can be reviewed and provide the best experience for Fedora.

To the binder point, I've been following binder for years. I'm thrilled with the progress it has made to get cleaned up and usable outside of Android. This is the bare minimum of usability though and my completely biased opinion is that enabling it still needs careful review and someone to advocate for it. The change process is designed to provide a path for options like this.

Comment 15 eric 2017-10-01 05:35:04 UTC
Someone else might want to create the wiki page. I couldn't get past the captcha on signup page.

Comment 16 rcmin17 2018-02-20 03:28:20 UTC
(In reply to Laura Abbott from comment #14)
> It's clear there is a lot of interest in Anbox on Fedora. As has been
> stated, just enabling the kernel modules isn't enough though as there are
> userspace components as well. This needs to go through the change process
> https://fedoraproject.org/wiki/Changes/Policy so everything can be reviewed
> and provide the best experience for Fedora.
> 
> To the binder point, I've been following binder for years. I'm thrilled with
> the progress it has made to get cleaned up and usable outside of Android.
> This is the bare minimum of usability though and my completely biased
> opinion is that enabling it still needs careful review and someone to
> advocate for it. The change process is designed to provide a path for
> options like this.

Please, people, participate in moving this process forward, if you would like to see Anbox on Fedora!

@Neal, so do you actually know what the story with some folks apparently able to make it work with snapd-2.30, but not early versions, was?

> See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1546896

(Indeed.)

Comment 17 Neal Gompa 2018-02-25 15:42:50 UTC
(In reply to rcmin17 from comment #16)
> (In reply to Laura Abbott from comment #14)
> > It's clear there is a lot of interest in Anbox on Fedora. As has been
> > stated, just enabling the kernel modules isn't enough though as there are
> > userspace components as well. This needs to go through the change process
> > https://fedoraproject.org/wiki/Changes/Policy so everything can be reviewed
> > and provide the best experience for Fedora.
> > 
> > To the binder point, I've been following binder for years. I'm thrilled with
> > the progress it has made to get cleaned up and usable outside of Android.
> > This is the bare minimum of usability though and my completely biased
> > opinion is that enabling it still needs careful review and someone to
> > advocate for it. The change process is designed to provide a path for
> > options like this.
> 
> Please, people, participate in moving this process forward, if you would
> like to see Anbox on Fedora!
> 
> @Neal, so do you actually know what the story with some folks apparently
> able to make it work with snapd-2.30, but not early versions, was?
> 
> > See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1546896
> 
> (Indeed.)

The Anbox installer script might be doing something along the lines of DKMS, but as far as I knew, the scripts are Ubuntu specific, so I would expect it to not work...?

Comment 18 Justin M. Forbes 2018-07-23 15:00:08 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs.

Fedora 27 has now been rebased to 4.17.7-100.fc27.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28.

If you experience different issues, please open a new bug report for those.

Comment 19 rugk 2018-09-05 17:08:57 UTC
Any progress here?

Comment 20 Neal Gompa 2019-01-12 16:28:18 UTC
With the introduction of binderfs in Linux 5.0, it looks like it's in a good shape for enablement.

I don't know if any progress was made on ashmem, though. My understanding is that both are required for this.

Comment 21 Laura Abbott 2019-01-13 16:29:12 UTC
Yes, there has been good progress. I still want this to go through as a feature change for Fedora.

Comment 22 vrag 2021-05-20 14:47:48 UTC
(In reply to Laura Abbott from comment #21)
> Yes, there has been good progress. I still want this to go through as a
> feature change for Fedora.

Is there any further updates on this?

Comment 23 deadrat 2021-06-26 17:06:17 UTC
> Is there any further updates on this?

None yet, it looks like.

Comment 24 deadrat 2021-06-26 17:19:37 UTC
Looks like, the Fedora folks weren't very thrilled to bring these modules to the fedora due to these components being in early stages. But I hope things have changed recently. I would like to help in any way I can, so I will first start reading about the process. But if there's anyone in this thread who can point me in the right direction, that would be of great help to me. Thanks.

Comment 25 sheepdestroyer 2021-06-26 18:56:45 UTC
I tried Re-CCing and needinfo labbott who reported not wanting to enable aformentionned kernel modules in their current state as of 2019, but her account is disabled according to bugzilla error message.

Maybe those modules situation is better now?
Who can answer to that?

I can not "Needinfo" current assignee Kernel-maint either, as I also receive the message "account is disabled".

Comment 26 Peter Robinson 2021-06-26 19:16:15 UTC
> Maybe those modules situation is better now?

The situation is not currently any better the last I looked a few months ago.

Comment 27 Filippe LeMarchand 2021-06-27 18:58:20 UTC
AFAICT Debian has both ashmem and binder enabled in their kernel, for the later they apply a patch to allow building it as a loadable module. I suppose they consider the modules in good enough shape to include in a stable distro?

Comment 28 Peter Robinson 2021-06-28 07:39:06 UTC
(In reply to Filippe LeMarchand from comment #27)
> AFAICT Debian has both ashmem and binder enabled in their kernel, for the
> later they apply a patch to allow building it as a loadable module. I
> suppose they consider the modules in good enough shape to include in a
> stable distro?

You would have to ask Debian.

For Fedora this needs someone to do the work, maintain it in the long term, deal with bugs/issues/etc. No one has stepped up to do that work.

Comment 29 Neal Gompa 2021-06-28 13:49:27 UTC
(In reply to Filippe LeMarchand from comment #27)
> AFAICT Debian has both ashmem and binder enabled in their kernel, for the
> later they apply a patch to allow building it as a loadable module. I
> suppose they consider the modules in good enough shape to include in a
> stable distro?

The patch for building them as loadable modules needs to be upstreamed too.

Comment 31 Boyd 2021-07-31 10:19:22 UTC
Is Waydroid in the same boat as anbox?  Would be realy awesome to see Fedora support this.

https://www.xda-developers.com/waydroid-android-apps-on-linux/

Comment 32 Justin M. Forbes 2021-08-05 19:33:57 UTC
From a kernel standpoint, if someone gets the patch to build binder and binderfs as modules upstream, I don't mind turning them on. Until that happens, I am not particularly interested in carrying them as built-in.  And no, they can't be subpackages, or handled separately since they do require built-in.  Without that patch, they would require a separate kernel build.  Ashmem has a similar problem, it needs the patch to build as a module upstreamed, and additionally it needs to move out of staging. There was discussion at Plumbers in 2018 about how to get ashmem out of staging, but it seems no one cared enough to follow up.

Comment 33 sheepdestroyer 2021-08-06 06:16:31 UTC
(In reply to Justin M. Forbes from comment #32)
> From a kernel standpoint, if someone gets the patch to build binder and
> binderfs as modules upstream, I don't mind turning them on. Until that
> happens, I am not particularly interested in carrying them as built-in.  And
> no, they can't be subpackages, or handled separately since they do require
> built-in.  Without that patch, they would require a separate kernel build. 
> Ashmem has a similar problem, it needs the patch to build as a module
> upstreamed, and additionally it needs to move out of staging. There was
> discussion at Plumbers in 2018 about how to get ashmem out of staging, but
> it seems no one cared enough to follow up.

I tried to write to Debian in July on the bug entry related to these patches, to ask for upstreaming them, but got bounced (Your message wasn't delivered to 901492.org because the address couldn't be found, or is unable to receive mail. The response from the remote server was: 550 Unknown or archived bug).

Does anyone know to contact, and who to contact at Debian to ask this again?

My bounced email to Debian :

---------- Forwarded message ---------
From: sheepdestroyer <sheepdestroyer>
Date: Sun, Jul 11, 2021 at 6:15 PM
Subject: Upstreaming the patch to make binder and ashmem buildable as modules
To: <901492.org>


Hello,

Could you consider upstreaming the patch to make binder and ashmem buildable as modules [0] ?
This seems to be one of the blockers for Fedora to enable Anbox [1]

[0] https://salsa.debian.org/kernel-team/linux/-/raw/master/debian/patches/debian/android-enable-building-ashmem-and-binder-as-modules.patch

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1455411

Best regards

Comment 34 Neal Gompa 2021-08-09 11:46:47 UTC
So I tried the Debian patch and it doesn't work, so I've been rewriting it as a patch series that is potentially upstreamable: https://github.com/Conan-Kudo/linux/commits/5.14-rc4-binder-and-ashmem-modules

Unfortunately, it doesn't yet work (but at least I can make ko files, even if there's tons of unresolved symbols...).

Comment 35 Neal Gompa 2021-09-24 17:24:59 UTC
So now there's Waydroid, a fork of Anbox that's more performant and leverages Wayland: https://waydro.id/

Also, today, I was in LPC in the Android MC asking about this, and Greg Kroah-Hartman recommended to me that we just ship binder as a built-in so that binderfs is available. He assures that there are no issues about shipping it on conventional Linux systems as a built-in and is namespace/container-safe.

As for ashmem, the Greg and the Android team folks said we shouldn't need it unless we intend to support old Android apps through the Google Play Store, as ashmem is long-deprecated in Android. As I don't think Fedora Mobile will go through Google Play Store certification, I think we could get away without having it.

If you think it's fine, I can work with the Fedora KDE and Fedora Mobile SIGs to come up with a plan and a Change proposal for enabling this and getting Waydroid into Fedora.

Comment 36 Yajo 2021-09-25 05:46:23 UTC
Woah! That'd be awesome.

Comment 37 thebudget72 2021-10-16 23:44:00 UTC
@Neal Gompa yes, getting Waydroid into Fedora would be very nice. Thank you.

Comment 38 Rich Lucente 2021-11-01 13:26:48 UTC
I have a customer looking to transition to running android apps on x86_64 with an alternate linux distro. It's not entirely clear how this is going to be accomplished but I suspect its either a VM or thin shim layer similar to Anbox.

The APK they want to run is here ... https://www.civtak.org/ ... with the APK file here ... https://drive.google.com/drive/folders/1nf97w1N870gm4PYPEEwO78OLPt8J9Ty7

How can I determine if this app requires ashmem, per the above discussion on only including binderfs in the OS?

Comment 39 Neal Gompa 2021-11-01 20:36:08 UTC
(In reply to Rich Lucente from comment #38)
> I have a customer looking to transition to running android apps on x86_64
> with an alternate linux distro. It's not entirely clear how this is going to
> be accomplished but I suspect its either a VM or thin shim layer similar to
> Anbox.
> 
> The APK they want to run is here ... https://www.civtak.org/ ... with the
> APK file here ...
> https://drive.google.com/drive/folders/1nf97w1N870gm4PYPEEwO78OLPt8J9Ty7
> 
> How can I determine if this app requires ashmem, per the above discussion on
> only including binderfs in the OS?

So, it's not *that* simple: Android applications *typically* get access through the libcutils API, and that could be patched to use memfd (probably what we want) or compiled to use the stub tmp-based implementation (*might* work?). If it opens /dev/ashmem directly (which some older apps do), it'll fail when you try to use the app if ashmem isn't available.

My understanding is that Android *itself* has moved away from it, and aside from the pinning API, all of the functions can be reimplemented using memfds.

Reference:

* Slides on plan to get rid of ashmem from LPC 2018: https://www.linuxplumbersconf.org/event/2/contributions/227/attachments/51/58/08._ashmem_-_getting_it_out_of_staging.pdf
* ashmem-backed ashmem API: https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-dev.cpp
* tmp-based ashmem API: https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-host.cpp

Comment 40 Ricardo Biehl Pasquali 2021-11-02 19:05:42 UTC
(In reply to Neal Gompa from comment #35)
> So now there's Waydroid, a fork of Anbox that's more performant and
> leverages Wayland: https://waydro.id/
> 
> Also, today, I was in LPC in the Android MC asking about this, and Greg
> Kroah-Hartman recommended to me that we just ship binder as a built-in so
> that binderfs is available. He assures that there are no issues about
> shipping it on conventional Linux systems as a built-in and is
> namespace/container-safe.

In order to avoid kernel recompiling and replacement, I wonder whether the
binderfs (and ashmem) are straightforward to implement using CUSE (character
device in userspace).

> As for ashmem, the Greg and the Android team folks said we shouldn't need it
> unless we intend to support old Android apps through the Google Play Store,
> as ashmem is long-deprecated in Android. As I don't think Fedora Mobile will
> go through Google Play Store certification, I think we could get away
> without having it.

Ashmem as CUSE would drop the need for ashmem maintenance within the kernel.

Comment 41 Rich Lucente 2021-11-12 14:57:21 UTC
(In reply to Neal Gompa from comment #39)
> > How can I determine if this app requires ashmem, per the above discussion on
> > only including binderfs in the OS?
> 
> So, it's not *that* simple: Android applications *typically* get access
> through the libcutils API, and that could be patched to use memfd (probably
> what we want) or compiled to use the stub tmp-based implementation (*might*
> work?). If it opens /dev/ashmem directly (which some older apps do), it'll
> fail when you try to use the app if ashmem isn't available.

I reached out to the ATAK developers on the development channel of their discord server (https://discord.gg/wNHJ9YZ). This was their reply ...

> simple test would be run atak and cat /proc/pid/maps and see if there are any ashmem file descriptors open or grep -rn ashmem <your_atak_checkout>
>
> user@user-VirtualBox:~/code/atak-4.4.0/AndroidTacticalAssaultKit-CIV/atak-civ$ grep -rni ashmem .
> user@user-VirtualBox:~/code/atak-4.4.0/AndroidTacticalAssaultKit-CIV/atak-civ$ 
>
> looks like no on the latter
>
> starlte:/ # cat /proc/`pgrep -o atak`/maps | grep -i ashmem
> 767d211000-767d231000 rw-s 00000000 00:01 56115                          /dev/ashmem/shared_memory/CF7E72E19B07127D1788E9E628881011_4909_4909 (deleted)
> 76b57a8000-76b57b2000 rw-s 00000000 00:01 40479                          /dev/ashmem/shared_memory/F3757D2B31C4F77750636CDFD5B14D43_4909_6378 (deleted)
> 770fcef000-770fcf3000 r--p 00000000 103:02 3829                          /system/lib64/ashmemd_aidl_interface-cpp.so
> 770fcf3000-770fcf4000 --xp 00004000 103:02 3829                          /system/lib64/ashmemd_aidl_interface-cpp.so
> 770fcf4000-770fcf5000 rw-p 00005000 103:02 3829                          /system/lib64/ashmemd_aidl_interface-cpp.so
> 770fcf5000-770fcf7000 r--p 00006000 103:02 3829                          /system/lib64/ashmemd_aidl_interface-cpp.so
> 770fd17000-770fd18000 r--p 00000000 103:02 4009                          /system/lib64/libashmemd_client.so
> 770fd18000-770fd19000 --xp 00001000 103:02 4009                          /system/lib64/libashmemd_client.so
> 770fd19000-770fd1a000 rw-p 00002000 103:02 4009                          /system/lib64/libashmemd_client.so
> 770fd1a000-770fd1b000 r--p 00003000 103:02 4009                          /system/lib64/libashmemd_client.so
> 77a4973000-77a4974000 r--s 00000000 00:01 30908                          /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted)
> 77a4a2a000-77a4a2b000 rw-s 00000000 00:01 45854                          /dev/ashmem/GFXStats-4909_749_3470 (deleted)
> 77a52b6000-77a52b7000 r--s 00000000 00:01 30908                          /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted)
> 77a56d5000-77a56d6000 r--s 00000000 00:01 30908                          /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted)
> 77a95c0000-77a95c1000 r--s 00000000 00:01 30908                          /dev/ashmem/5027b323-2b64-4982-b8f0-0108973614ee_749_749 (deleted)
>
> looks like yes on the first
> 
> ashmem is part of gnu/linux you should be able to just toggle the CONFIG_ in your kernel and recompile
> maybe even have it as a module with like sudo modprobe ashmem_linux

So no direct reference to ashmem in the source code but it's still being used by the application. Does this mean the memfd patch would remove the dependency?

Comment 43 Neal Gompa 2021-11-12 18:23:49 UTC
(In reply to Rich Lucente from comment #41)
> 
> So no direct reference to ashmem in the source code but it's still being
> used by the application. Does this mean the memfd patch would remove the
> dependency?

Yes. If libcutils is patched in the Fedora Android userspace build, then we'd be set for this application.

Comment 44 vrag 2021-12-03 12:01:54 UTC
A patch dropping ashmem completely might take some time... until then enabling ashmem by default would be better!

Comment 45 Neal Gompa 2021-12-03 12:52:11 UTC
(In reply to vrag from comment #44)
> A patch dropping ashmem completely might take some time... until then
> enabling ashmem by default would be better!

That's not going to happen.

Comment 46 vrag 2021-12-03 13:05:26 UTC
(In reply to Neal Gompa from comment #45)
> (In reply to vrag from comment #44)
> > A patch dropping ashmem completely might take some time... until then
> > enabling ashmem by default would be better!
> 
> That's not going to happen.

The patch or enabling ashmem

Comment 47 Neal Gompa 2021-12-03 13:39:42 UTC
(In reply to vrag from comment #46)
> (In reply to Neal Gompa from comment #45)
> > (In reply to vrag from comment #44)
> > > A patch dropping ashmem completely might take some time... until then
> > > enabling ashmem by default would be better!
> > 
> > That's not going to happen.
> 
> The patch or enabling ashmem

Enabling ashmem.

Comment 48 thebudget72 2021-12-04 17:48:10 UTC
Is there any progress on this?

Comment 49 Rory Renton 2022-01-03 00:59:03 UTC
is there any way I can help get Waydroid on Fedora?

sounds like the 2 major issues of ashmem and binder are fading away?

Comment 50 Rory Renton 2022-01-03 12:01:41 UTC
After looking around and researching a little, it looks like Binder is not a problem. Only Ashmem is...

Can I suggest that if Ashmem is only needed for older android apks that we concentrate on a MVP that doesn't include Ashmem, as later some workaround could be added if possible.

That would allow us to concentrate on bundling a functional (MVP) version of waydroid, that you can enhance with Ashmem if you desire support.

Comment 51 Neal Gompa 2022-01-04 11:23:07 UTC
(In reply to Rory Renton from comment #50)
> After looking around and researching a little, it looks like Binder is not a
> problem. Only Ashmem is...
> 
> Can I suggest that if Ashmem is only needed for older android apks that we
> concentrate on a MVP that doesn't include Ashmem, as later some workaround
> could be added if possible.
> 
> That would allow us to concentrate on bundling a functional (MVP) version of
> waydroid, that you can enhance with Ashmem if you desire support.

That's the plan. Binder got enabled in the Fedora kernels with 5.15.

Comment 52 Rory Renton 2022-01-04 18:58:48 UTC
(In reply to Neal Gompa from comment #51)
> That's the plan. Binder got enabled in the Fedora kernels with 5.15.

Great!

Trying to get up to speed on the Ashmem problem, reading the waydroid page "...ships with a minimal customized Android system image based on LineageOS". Instead of making Fedora ready to run waydroid how it currently is, would it not be better to recompile the Android image waydroid uses to not reference Ashmem and instead use a GNU/Linux equivalent? then catch direct usage of Ashmem and redirect it to a CUSE for legacy apps.

Anything I can help with? I'm pretty much a user-space only C programmer, but willing to learn.

Comment 53 Neal Gompa 2022-01-05 10:32:51 UTC
(In reply to Rory Renton from comment #52)
> (In reply to Neal Gompa from comment #51)
> > That's the plan. Binder got enabled in the Fedora kernels with 5.15.
> 
> Great!
> 
> Trying to get up to speed on the Ashmem problem, reading the waydroid page
> "...ships with a minimal customized Android system image based on
> LineageOS". Instead of making Fedora ready to run waydroid how it currently
> is, would it not be better to recompile the Android image waydroid uses to
> not reference Ashmem and instead use a GNU/Linux equivalent? then catch
> direct usage of Ashmem and redirect it to a CUSE for legacy apps.
> 
> Anything I can help with? I'm pretty much a user-space only C programmer,
> but willing to learn.

Well, basically all that needs to be done is libcutils needs a version of https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-dev.cpp using memfds, as I mentioned in comment 39.

So once an implementation is contributed to AOSP and backported to LineageOS for Waydroid, we can start doing something here.

Comment 54 thebudget72 2022-01-28 08:17:00 UTC
Any good news on this?

> Well, basically all that needs to be done is libcutils needs a version of https://android.googlesource.com/platform/system/core/+/refs/heads/master/libcutils/ashmem-dev.cpp using memfds, as I mentioned in comment 39.

Is there some ashmem 2 memfds guide I can follow to get the job done?

Comment 55 Alessandro Astone 2022-02-11 23:05:06 UTC
I've helped bring ashmem-less support to waydroid. It's now merged in master.
For the record, aosp already had an ashmem-to-memfd translation layer which just needed to be enabled.
There is one important bug with chromium which is being tracked here https://bugs.chromium.org/p/chromium/issues/detail?id=1296216
While that gets (hopefully) sorted out I'm working on packaging waydroid and the lineageos image for fedora.

Comment 56 Rory Renton 2022-02-12 09:22:02 UTC
you hero! I'm really excited about testing this. I'll help bug-test it, as I'm far too busy programming other things atm.

Comment 57 Justin M. Forbes 2022-02-16 17:59:18 UTC
*** Bug 2055301 has been marked as a duplicate of this bug. ***

Comment 58 Alessandro Astone 2022-02-26 17:38:12 UTC
You may start trying out my copr https://copr.fedorainfracloud.org/coprs/aleasto/waydroid/

Comment 59 Markus Rathgeb 2022-02-26 17:41:00 UTC
Would it be possible to add the Fedora 36 chroot?

Comment 60 Alessandro Astone 2022-02-26 17:43:54 UTC
(In reply to Markus Rathgeb from comment #59)
> Would it be possible to add the Fedora 36 chroot?

Not as simple as clicking a button since I edit the selinux-policy package which is on a different tag in f36, but i'll work on it

Comment 61 Alessandro Astone 2022-02-26 19:09:34 UTC
(In reply to Markus Rathgeb from comment #59)
> Would it be possible to add the Fedora 36 chroot?

Done

Comment 62 Markus Rathgeb 2022-02-26 19:13:34 UTC
Thank you, I will give it a try.

Comment 63 Markus Rathgeb 2022-02-26 20:00:05 UTC
Installation and init went fine.
After some clicks in the full UI it seems the LineageOS ends in an endless loop.
What I have done?
Start some preinstalled apps (contacts, clock, browser) and at least the settings app. In the settings app I tried to add another language for the keyboard and while scrolling the list of languages it seems to crash.
Where should it be reported at all?
It could be related to
* Fedora 36 beta
* Waydroid on Fedora
* Waydroid in general
* ...

The journal contains messages like this:

Feb 26 20:53:31 m3800.localdomain init: Service 'bootanim' (pid 5958) exited with status 0
Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/init.rc:815)
Feb 26 20:53:31 m3800.localdomain init: starting service 'exec 19 (/bin/rm -rf /data/per_boot)'...
Feb 26 20:53:31 m3800.localdomain libprocessgroup: Failed to make and chown /acct/uid_1000: Read-only file system
Feb 26 20:53:31 m3800.localdomain init: createProcessGroup(1000, 6427) failed for service 'exec 19 (/bin/rm -rf /data/per_boot)': Read-only file system
Feb 26 20:53:31 m3800.localdomain init: SVC_EXEC service 'exec 19 (/bin/rm -rf /data/per_boot)' pid 6427 (uid 1000 gid 1000+0 context default) started; waiting...
Feb 26 20:53:31 m3800.localdomain init: Service 'exec 19 (/bin/rm -rf /data/per_boot)' (pid 6427) exited with status 0 waiting took 0.010000 seconds
Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/system/etc/init/flags_health_check.rc:7)
Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/system/etc/init/init.waydroid.rc:6)
Feb 26 20:53:31 m3800.localdomain init: processing action (sys.boot_completed=1) from (/system/etc/init/logd.rc:32)
Feb 26 20:53:31 m3800.localdomain init: starting service 'logd-auditctl'...
Feb 26 20:53:31 m3800.localdomain libprocessgroup: Failed to make and chown /acct/uid_1036: Read-only file system
Feb 26 20:53:31 m3800.localdomain init: createProcessGroup(1036, 6452) failed for service 'logd-auditctl': Read-only file system
Feb 26 20:53:31 m3800.localdomain init: Service 'logd-auditctl' (pid 6452) exited with status 0

Feb 26 20:53:31 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set
Feb 26 20:53:31 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set
Feb 26 20:53:31 m3800.localdomain Waydroid.desktop[41078]: [20:53:31] Android with user 0 is ready
Feb 26 20:53:32 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set
Feb 26 20:53:32 m3800.localdomain kernel: binder: 41489 RLIMIT_NICE not set
Feb 26 20:53:32 m3800.localdomain apexd: Can't open /product/apex for reading : No such file or directory
Feb 26 20:53:32 m3800.localdomain init: Received control message 'start' for 'gsid' from pid: 5990 (system_server)
Feb 26 20:53:32 m3800.localdomain init: Received control message 'stop' for 'gsid' from pid: 5990 (system_server)
Feb 26 20:53:32 m3800.localdomain init: Sending signal 9 to service 'gsid' (pid 1372) process group...
Feb 26 20:53:32 m3800.localdomain libprocessgroup: Successfully killed process cgroup uid 0 pid 1372 in 0ms

Feb 26 20:53:36 m3800.localdomain init: Received control message 'stop' for 'idmap2d' from pid: 5990 (system_server)
Feb 26 20:53:36 m3800.localdomain init: Sending signal 9 to service 'idmap2d' (pid 92) process group...
Feb 26 20:53:36 m3800.localdomain libprocessgroup: Successfully killed process cgroup uid 1000 pid 92 in 0ms




The "Problem Reporting" GUI of fedora shows: "android.hardware.graphics.composer quit unexpectedly"

Comment 64 Neal Gompa 2022-02-26 23:50:26 UTC
(In reply to Alessandro Astone from comment #58)
> You may start trying out my copr
> https://copr.fedorainfracloud.org/coprs/aleasto/waydroid/

I've sent your SELinux policy patch on BinderFS policy upstream: https://github.com/fedora-selinux/selinux-policy/pull/1100

Comment 65 Rory Renton 2022-02-28 11:46:12 UTC
tested it, working well so far!

Comment 66 jakob 2022-02-28 17:11:57 UTC
(In reply to Alessandro Astone from comment #58)
> You may start trying out my copr
> https://copr.fedorainfracloud.org/coprs/aleasto/waydroid/

Thanks! 

Issues I noticed so far:

 * I can't drag applications across screens (although it works if I drag the application using the activities overview)
 * sometimes the physical keyboard stops working, and I need to restart the waydroid session to fix it
 * waydroid complains "Failed to start Clipboard manager service" -> "pip install pyclip" fixed this

Kernel: 5.16.11-200.fc35.x86_64
Gnome: 41.6

Comment 67 thebudget72 2022-03-07 01:27:39 UTC
For me it gets stuck here:

```
$ waydroid show-full-ui
[02:07:50] Starting waydroid session
```

Comment 68 Alessandro Astone 2022-03-07 10:35:33 UTC
(In reply to thebudget72 from comment #67)
> For me it gets stuck here:
> 
> ```
> $ waydroid show-full-ui
> [02:07:50] Starting waydroid session
> ```

You'll find useful logs in `waydroid log` or `sudo waydroid logcat` or `dmesg`

Some general issues may be: nvidia drivers (not compatible), waydroid-selinux not installed

Comment 69 thebudget72 2022-03-07 10:45:33 UTC
Yeah I'm using NVIDIA drivers :)

Will wait until they become compatible.

Thanks!

Comment 70 Rich Lucente 2022-03-07 15:55:02 UTC
Trying on Fedora 35 with latest updates and aleasto copr packages. Also, did `pip install pyclip` before launching `waydroid show-full-ui`. The command `waydroid log` includes:

(000802) [10:48:13] New background process: pid=2534, output=background lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory - Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem"

And no android ui appears. I'll retry with Fedora 36 beta soon.

Comment 71 Alessandro Astone 2022-03-07 16:29:13 UTC
(In reply to Rich Lucente from comment #70)
> The command `waydroid log` includes:
> 
> (000802) [10:48:13] New background process: pid=2534, output=background
> lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory -
> Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem"

That is not relevant. Feel free to share full logs.

Comment 72 Rich Lucente 2022-03-08 14:57:00 UTC
Created attachment 1864638 [details]
lucente journal log 20220308

Comment 73 Rich Lucente 2022-03-08 14:57:46 UTC
Created attachment 1864639 [details]
lucente waydroid log 20220308

Comment 74 Rich Lucente 2022-03-08 14:59:37 UTC
(In reply to Alessandro Astone from comment #71)
> (In reply to Rich Lucente from comment #70)
> > The command `waydroid log` includes:
> > 
> > (000802) [10:48:13] New background process: pid=2534, output=background
> > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory -
> > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem"
> 
> That is not relevant. Feel free to share full logs.

Logs attached. Please let me know if you need additional information.

Comment 75 Alessandro Astone 2022-03-08 15:03:51 UTC
(In reply to Rich Lucente from comment #74)
> (In reply to Alessandro Astone from comment #71)
> > (In reply to Rich Lucente from comment #70)
> > > The command `waydroid log` includes:
> > > 
> > > (000802) [10:48:13] New background process: pid=2534, output=background
> > > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory -
> > > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem"
> > 
> > That is not relevant. Feel free to share full logs.
> 
> Logs attached. Please let me know if you need additional information.

I don't have access to `journal log 20220308`, but the other one looks fine.
Share `sudo waydroid logcat` too

Comment 76 Rich Lucente 2022-03-08 16:11:58 UTC
Created attachment 1864675 [details]
lucente journal log 20220308

Comment 77 Rich Lucente 2022-03-08 16:20:19 UTC
(In reply to Alessandro Astone from comment #75)
> (In reply to Rich Lucente from comment #74)
> > (In reply to Alessandro Astone from comment #71)
> > > (In reply to Rich Lucente from comment #70)
> > > > The command `waydroid log` includes:
> > > > 
> > > > (000802) [10:48:13] New background process: pid=2534, output=background
> > > > lxc-start: waydroid: utils.c: safe_mount: 1198 No such file or directory -
> > > > Failed to mount "/dev/ashmem" onto "/usr/lib64/lxc/rootfs/dev/ashmem"
> > > 
> > > That is not relevant. Feel free to share full logs.
> > 
> > Logs attached. Please let me know if you need additional information.
> 
> I don't have access to `journal log 20220308`, but the other one looks fine.
> Share `sudo waydroid logcat` too

Sorry about that, I accidentally made that private. There should be a public attachment now. I also attached the `waydroid logcat` output as well (but from a separate session).

Comment 78 Rich Lucente 2022-03-08 16:21:03 UTC
Created attachment 1864676 [details]
lucente waydroid logcat 20220308

Comment 79 Alessandro Astone 2022-03-08 16:35:58 UTC
(In reply to Rich Lucente from comment #78)
> Created attachment 1864676 [details]
> lucente waydroid logcat 20220308

Relevant logs:
03-08 16:16:51.680    70   156 E GRALLOC-GBM: failed to create BO, size=1680x864, fmt=5, usage=4
03-08 16:16:51.680    87   749 E GraphicBufferAllocator: Failed to allocate (1680 x 864) layerCount 1 format 5 usage b00: 5
03-08 16:16:51.680    87   749 E BufferQueueProducer: [BootAnimation#0] dequeueBuffer: createGraphicBuffer failed
03-08 16:16:51.680   237   240 W EGL-MAIN: failed to dequeue buffer for window

I see you're running this in kvm. You can try following this guide: https://docs.waydro.id/faq/get-waydroid-to-work-through-a-vm

Comment 80 Rich Lucente 2022-03-08 16:44:48 UTC
(In reply to Alessandro Astone from comment #79)
> (In reply to Rich Lucente from comment #78)
> > Created attachment 1864676 [details]
> > lucente waydroid logcat 20220308
> 
> Relevant logs:
> 03-08 16:16:51.680    70   156 E GRALLOC-GBM: failed to create BO,
> size=1680x864, fmt=5, usage=4
> 03-08 16:16:51.680    87   749 E GraphicBufferAllocator: Failed to allocate
> (1680 x 864) layerCount 1 format 5 usage b00: 5
> 03-08 16:16:51.680    87   749 E BufferQueueProducer: [BootAnimation#0]
> dequeueBuffer: createGraphicBuffer failed
> 03-08 16:16:51.680   237   240 W EGL-MAIN: failed to dequeue buffer for
> window
> 
> I see you're running this in kvm. You can try following this guide:
> https://docs.waydro.id/faq/get-waydroid-to-work-through-a-vm

That worked! Thank you so much. I was running Fedora in virtualbox on my mac, so the changes in the FAQ were all that was needed.

Comment 81 chris 2022-03-15 17:16:20 UTC
I am on fedora 35 (fully updated), installed waydroid from the copr and I am getting 

Failed to get service waydroidplatform, trying again...

when I run waydroid show-full-ui. That is because the "WayDroid container is STOPPED", running sudo waydroid container start shows

[19:01:13] Failed to load ashmem driver
[19:01:13] modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/5.16.13-200.fc35.x86_64
[19:01:13] Failed to load Ashmem driver

and it hangs there. 

waydroid log shows the same:

(019211) [19:01:13] % modprobe ashmem_linux
modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/5.16.13-200.fc35.x86_64
(019211) [19:01:13] Failed to load ashmem driver
(019211) [19:01:13] modprobe: FATAL: Module ashmem_linux not found in directory /lib/modules/5.16.13-200.fc35.x86_64
(019211) [19:01:13] Failed to load Ashmem driver
(019211) [19:01:13] % chmod 666 -R /dev/binder
(019211) [19:01:13] % chmod 666 -R /dev/vndbinder
(019211) [19:01:13] % chmod 666 -R /dev/hwbinder
(019211) [19:01:13] Container manager is waiting for session to load
(013902) [19:01:13] Failed to get service waydroidplatform, trying again...

Comment 82 Neal Gompa 2022-03-18 20:55:00 UTC
The SELinux policy changes have been merged into Fedora's SELinux policy: https://github.com/fedora-selinux/selinux-policy/commit/7235bb05e41e54e8723b10819e1326fbcb754c9a

I hope to see it land soon in Fedora. :)

Comment 83 thebudget72 2022-03-19 07:41:21 UTC
Are the NVIDIA proprietary drivers going to be supported?

Will it be available on the Fedora official repos? :D

Comment 84 Alessandro Astone 2022-03-19 09:44:18 UTC
(In reply to thebudget72 from comment #83)
> Are the NVIDIA proprietary drivers going to be supported?
> 
> Will it be available on the Fedora official repos? :D

You can fallback to software rendering with https://docs.waydro.id/faq/get-waydroid-to-work-through-a-vm

Comment 85 Peter Robinson 2022-03-19 19:26:37 UTC
(In reply to thebudget72 from comment #83)
> Are the NVIDIA proprietary drivers going to be supported?

This is actually off topic for this bug.

> Will it be available on the Fedora official repos? :D

I think you know the answer to that.

Comment 86 chris 2022-03-20 19:58:02 UTC
After restarting, waydroid still doesn't launch but it says the container is running.

I saw an issue on github that seemed similar https://github.com/waydroid/waydroid/issues/61 but it was mostly with AMD. I am running on integrated intel.

I include my waydroid log & sudo waydroid logcat here, I don't really understand how to troubleshoot. If I shouldn't be commenting here, please correct me.

Comment 87 chris 2022-03-20 19:59:04 UTC
Created attachment 1866992 [details]
chris_waydroid_log

Comment 88 chris 2022-03-20 19:59:37 UTC
Created attachment 1866993 [details]
chris_waydroid_logcat

Comment 89 Alessandro Astone 2022-03-20 20:21:43 UTC
(In reply to chris from comment #88)
> Created attachment 1866993 [details]
> chris_waydroid_logcat

You need to enable vsyscall32

Comment 90 Chris White 2022-03-22 16:54:26 UTC
> Are the NVIDIA proprietary drivers going to be supported?
They will not. Android drivers are compiled in Bionic C. The Nvidia Proprietary drivers are compiled in glibc. This creates a compatibility problem. So unless a translation layer is created, it's completely out of anyone's hands except Nvidia. This issue is explained in [1]. You are best off using the opensource drivers if you want to use Nvidia with waydroid so you can use mesa for hardware acceleration. However; it currently seems broken [2] which leaves you with either your integrated GPU or software rendering at the moment.
 
[1] https://github.com/waydroid/waydroid/issues/278
[2] https://wiki.archlinux.org/title/Waydroid#GPU_Requirements

Comment 91 thebudget72 2022-03-30 10:24:02 UTC
For me it gets stuck on "[12:20:50] Starting waydroid session".

I attach the logcat.

Comment 92 thebudget72 2022-03-30 10:24:50 UTC
Created attachment 1869303 [details]
logcat

Comment 93 thebudget72 2022-03-30 11:23:41 UTC
I have upgraded the images with `waydroid upgrade`, rebooted, and it is now working :)

Comment 94 thebudget72 2022-03-30 11:24:37 UTC
>> Will it be available on the Fedora official repos? :D

> I think you know the answer to that.

I actually don't know because the instructions from Astone say it contains proprietary software

Comment 95 Alessandro Astone 2022-03-30 11:37:21 UTC
(In reply to thebudget72 from comment #94)
> >> Will it be available on the Fedora official repos? :D
> 
> > I think you know the answer to that.
> 
> I actually don't know because the instructions from Astone say it contains
> proprietary software

I don't speak for @leagal, but:
The LineageOS images contain ffmpeg and possibly other projects with problematic licenses, it's hard to check them all since we're talking about ~800 individual components. Also there's a cmdline option to download images that include google proprietary software (google mobile services).
As long as the download of non free software is user prompted and the rpm itself does not contain any links to it, it's not an issue.
We will need to find a good way to handle it.

Comment 96 thebudget72 2022-06-12 09:48:31 UTC
any news on this?

Comment 97 Alessandro Astone 2022-06-12 09:53:36 UTC
(In reply to thebudget72 from comment #96)
> any news on this?

I'm working with upstreams to solve some usability issues i consider important enough to hold from submitting the package to fedora.

Comment 98 thebudget72 2022-06-12 09:56:40 UTC
Thanks Alessandro!

Comment 99 thebudget72 2022-08-06 08:42:40 UTC
any news?

Comment 100 Alessandro Astone 2022-08-21 20:48:37 UTC
I've submitted a package review request at https://bugzilla.redhat.com/show_bug.cgi?id=2120119


Note You need to log in before you can comment on or make changes to this bug.