Hi Kalesh, On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote: > Thanks for raising this. > > Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is > also now deprecated. Android autosuspend is initiatiated from the > userspace system suspend service [1]. > > A runtime config sounds more reasonable since in the !PM_AUTOSLEEP > case, it is userspace which decides the suspend policy. > > [1] https://cs.android.com/android/platform/superproject/+/bf3906ecb33c98ff8edd96c852b884dbccb73295:system/hardware/interfaces/suspend/1.0/default/SystemSuspend.cpp;l=265 Bingo, thanks for the pointer. So looking at this, I'm trying to tease out some heuristic that wouldn't require any changes, but I don't really see anything _too_ perfect. One fragment of an idea would be that the kernel treats things in autosuspending mode if anybody is holding open a fd to /sys/power/state. But I worry this would interact with non-autosuspending userspaces that also hold open the file. So barring that, I'm not quite sure. If you also can't think of something, maybe we should talk about adding something that requires code changes. In that line of thinking, how would you feel about opening /sys/power/userspace_autosuspender and keeping that fd open. Then the kernel API would have `bool pm_has_userspace_autosuspender(void)` that code could check. Alternatively, if you don't want refcounting fd semantics for that, just writing a "1" into a similar file seems fine? Any strong opinions about it? Personally it doesn't make much of a difference to me. The important thing is just that it'd be something you're willing to implement in that SystemSuspend.cpp file. Jason
