I need to use Waydroid to get MFA from my bank, which is basically my only, but crucial use case.
To make use more bearable, I created two icons for it. One does waydroid stop and the other one stops the waydroid container.
However, sometimes after fully stopping Waydroid, my phone fails to suspend. After getting out of battery on the street a few times, I found out a quick check: try to restart the phone. If Waydroid is stuck, I will have on the restart window information that “Waydroid is preventing idle”. If the restart popup is clear, I know the phone will suspend. So far, the only way to truly make Waydroid go away is, of course, to restart. If Waydroid was stuck and I start a new Waydroid session, next time I try to restart Waydroid will be listed in the restart popup twice.
So my questions are:
How could I find what is going on? More specifically, why does it happen only sometimes? I found out that if I Force Quit background applications before stopping Waydroid, sometimes I get rid of the problem.
How can I kill all Waydroid-related processes without restarting the phone? I could then put a script together and add it to the home screen as a shortcut.
I also get this behaviour with Waydroid. Not only does it prevent suspend, but also screen locking. I, too, have found no better workaround than to reboot the host system.
As far as I know, applications use DBus to request this kind of inhibition of idle. Usually it is used for things like media playback, so your screen doesn’t lock in the middle of watching a video, or possibly to prevent the interruption of long-running processes. It seems to me that Waydroid is requesting it but then failing to rescind the request once it no longer requires it. Then, the inhibition stands permanently until the next restart, even after all Waydroid processes are terminated. In other words, my intuition is that Waydroid has a resource leak regarding this feature.
From my limited reading around the topic, I get the impression that Waydroid is likely just passing through a request to inhibit suspend from an app that’s running within Waydroid. I’ve yet to figure out which specific apps cause this and in what specific states. (It does seem to be state-dependent, because I always have the same small set of installed apps and they usually do not cause the problem behaviour.)
Intuitively, I feel like maybe it helps to swipe away all open apps before closing the Waydroid window, and I feel like it usually only gets stuck inhibiting suspend if I leave an app open, but I don’t actually have any data to back that hypothesis up.
This is the last issue that, at least in my case, prevents me from being able to just have my Librem 5 on for days and days and days without worrying about it not suspending. Nowadays, I do a quick reboot check just to see if Waydroid will not prevent my phone from suspending.
Also @patch Do you know a practical way of monitoring DBus resources? I created a custom icon linked to a script that I use to start and stop Waydroid and I could potentially track the created resources and kill them when I stop Waydroid, as I only keep Waydroid running when I actually need it.
D-Bus is just a way for processes to provide an interface to other processes. So, there will be a process that provides the service of managing requests to inhibit idle. Applications communicate with that process via D-Bus and that process keeps a record of who wants to inhibit idle. To dig into this, you would have to work out which D-Bus service is being used and find out what interface that service provides for querying its state. There are various graphical and command-line tools for querying the existence of and interacting with D-Bus services.
It would not surprise me if there are other D-Bus services that provide similar functionality.
Having had a quick browse through the Waydroid source code and seen instances of #include "idle-inhibit-unstable-v1-client-protocol.h", I think Waydroid is probably asking the Wayland compositor to deal with this, rather than calling any D-Bus interfaces itself. The compositor might be in a position to just handle this functionality itself, or hand it off to some library it uses, or some related component of the desktop environment, possibly via D-Bus, or possibly not. The resulting inhibition may still be queryable via D-Bus, if it ends up getting logged by whatever component implements a suitable D-Bus interface, though.
In other words, I don’t fully know what I’m talking about.
Thank you for the lead. I also often don’t know what I am talking about and try to make sense of all the patchy pieces of questionable-quality knowledge in my head. =)
I am abroad now but, next time I am home, when I see the idle issue I will hook my phone to my usb-c screen and try to figure it out.
The annoying thing is that I have not so far been able to reproduce the issue consistently. It seems to almost never happen if I force quit all waydroid applications but it still does sometimes.
Another investigation point is to try using the applications without launching the waydroid main application (with the android UI) and launching them directly from phosh. If this works, perhaps I could leave the waydroid container always running and just force quit the applications from the “Usage” application instead.
This weekend I spent an unreasonable amount of time on this, monitoring dbus, lsof, starting and stopping waydroid multiple times, multiple reboots, and I couldn’t get to it.
Then I went have a look and the default Waydroid desktop shortcut created when installing Waydroid defaults to the first run init thing. Out of curiosity, I changed it to show-full-ui and, so far, the issue has not happened anymore (knock on wood). I don’t know why, but I hope this resolves the problem.
I will let it be for a week before flagging this as solution.
Unfortunately, this issue still happens. Way less often. This is the only issue stopping me of getting multiple weeks of uptime on my Librem 5.
Does anyone know where does the system get the information about applications inhibiting idle session when you try to restart or shutdown? If I could find that out, I could just tweak my waydroid-stop script to kill the pending resource.
I’m not sure whether this is related to Waydroid at all. I just saw a user report that seemed to suggest that inhibitors staying past the client’s lifetime is a thing that happens with other clients as well. Perhaps a phoc issue - but I’m only guessing at this point.
This - and the SD suspend issue - are the two missing bits for me to be able to tell anyone that “yes, you can dump your phone, the L5 is ok”.
The SD workaround works ok, but this is really missing.
Base L5 + ZRAM config + 1TB SD with smart use of mount points + waydroid for my bank and the oddball app I very very rarely need and it is truly fine and I have not missed another phone for more than a year.
i just want to ask why your bank did not support native Linux Desktop Systems? Waydroid use only Mobile apps. But Every Bank in 2025 need to accept Windows, Apple or Linux Systems too through some Browser and another additional 2FA Authentification like a youbikey or some qr-Code generator with your physical Banking Card.
In future it will disappear and we may see more Apple and Android Apps, so its fine that it will work with Waydroid.
Personaly i would use a free Android alternative instead of some Software emulation for Computers. Because i think it was developed as a Software emulation Kid for PCs and not as a virtual replacement for mobile. Which however every Linux and “Apps” for new Hardwere is like the L5.
I liked it mouch to read about the Progress. Thank you for your efford to put your issue into words on this forum.
