oxwivi
commented
6 hours ago That also makes wonder, how is virtual displays handled when this happens. I hope it doesn't continue to exist and consume resources without recourse.
Open oxwivi opened 6 hours ago
oxwivi
commented
6 hours ago That also makes wonder, how is virtual displays handled when this happens. I hope it doesn't continue to exist and consume resources without recourse.
rom1v
commented
6 hours ago Which device is it?
On unexpected disconnection, cleanup should still be executed.
For example, if I run scrcpy --show-touches, and I unplug the USB cable, "show touches" is immediately disabled on the phone.
I have a device (Nexus 5 with Android 6) where the cleanup process is killed before it completes, probably an Android bug. But in general, it works.
That also makes wonder, how is virtual displays handled when this happens
The virtual display is destroyed anyway. Currently, the content (the app launched in virtual display) is also destroyed. In future versions, it would be great to have a flag to keep the running app (moved to the main display for example). See https://github.com/Genymobile/scrcpy/issues/5563#issuecomment-2508906274
oxwivi
commented
4 hours ago Which device is it?
On unexpected disconnection, cleanup should still be executed.
Pixel 8 Pro/GrapeheneOS, but I've observed it many times on my last phone, Motorola Edge 30/LineageOS. (That's why I've left device model as N/A)
Is there anything else I can provide to debug this, or is it being Android bug pretty much confirmed?
The virtual display is destroyed anyway. Currently, the content (the app launched in virtual display) is also destroyed. In future versions, it would be great to have a flag to keep the running app (moved to the main display for example). See https://github.com/Genymobile/scrcpy/issues/5563#issuecomment-2508906274
Oh, good. Yes, keeping the app running would be great.
rom1v
commented
4 hours ago Can you reproduce the problem with scrcpy --show-touches?
oxwivi
commented
4 hours ago I just realized, it might possibly a WONTFIX. When Android decides to roam to a different BSSID, ADB is automatically switched off... I'm guessing server cleanup doesn't have the chance to run before being killed alongside ADB. Perhaps if something like Shizuku was involved, it might be different? But Shizuku also depends on wireless ADB...
Can you reproduce the problem with
scrcpy --show-touches?
I'll try tomorrow (past midnight here). Should be easy for me to reproduce by simply kicking off device from my AP.
rom1v
commented
3 hours ago I'm guessing server cleanup doesn't have the chance to run before being killed alongside ADB.
Yes, it can run when adb is killed. See https://github.com/Genymobile/scrcpy/blob/master/server/src/main/java/com/genymobile/scrcpy/CleanUp.java
Environment
Describe the bug
Whenever ADB disconnects (over Wi-Fi, probably because device changes frequency or roamed to different AP), server-side doesn't appear to restore settings as part of the exit cleanup. For example, when scrcpy is running with the
--stay-awakeand ADB unexpectedly terminates, the Stay awake option in Developer options remains toggled on. Any subsequent scrcpy connection takes this as a base setting and doesn't turn it off when properly exiting either. It has to be manually disabled in Developer options.What is the server-side behavior for unexpected disconnections? Is the exit cleanup only possible with ADB commands from the client-side? I'm hoping it's possible for scrcpy server to detect abrupt disconnections and execute the cleanup routine independent of the client.