Currently, the wake command aquires a wakelock for a split second in switchScreenOn() that causes the device to come out of standby. However, if you have configured a screensaver in Android, the `isScreenOn() will return true, and the unlock will not do anything.
Would it be acceptable to have a { wake: true }, always aquire this wakelock (instead of checking if the screen is on), and also send an intent to regain focus to wallpanel?
I have my tablet configured to display a slideshow of family pictures, but I want my front door camera to pop up when the doorbell rings. I can popup the camera feed fine by sending the command as I've described here, but if the screensaver is on, it isn't stopped, so I still don't see the camera feed.
Currently, the wake command aquires a wakelock for a split second in
switchScreenOn()
that causes the device to come out of standby. However, if you have configured a screensaver in Android, the `isScreenOn() will return true, and the unlock will not do anything.If the wake command is received, I don't see harm in aquiring the wakelock for a split second anyway. Also, I'm not totally sure that just aquiring this wakelock is sufficient to stop the screensaver. According to this stackoverflow, it isn't: https://stackoverflow.com/questions/40342372/proper-way-to-start-and-stop-daydream-service-from-activity
Would it be acceptable to have a
{ wake: true }
, always aquire this wakelock (instead of checking if the screen is on), and also send an intent to regain focus to wallpanel?I have my tablet configured to display a slideshow of family pictures, but I want my front door camera to pop up when the doorbell rings. I can popup the camera feed fine by sending the command as I've described here, but if the screensaver is on, it isn't stopped, so I still don't see the camera feed.