Auto-start/Auto-stop Slideshow on Power Connect/Disconnect Not Working

[theQuicker1]

On a tablet running Android 8.1 and the most recent version of PhotoCloud Slideshow v1.13.9, the Auto-start/Auto-stop Slideshow on Power Connect/Disconnect has stopped working.

I have another tablet running Android 6.0 and PhotoCloud Slideshow v1.11 and the Auto-start/Auto-stop Slideshow on Power Connect/Disconnect still works fine.

Also, if possible, it would be nice (for me) if in addition to stopping the slideshow, when disconnecting power, the tablet also locked.

As a workaround on the first tablet, I designed a small program using an app called Automate to start the slideshow on power connect and lock the tablet on power disconnect. The last 4 nodes on the bottom row simulate tapping the screen to hide the home/back buttons.

[mvysny]

Hmm I wonder what happened on Android 8.1. let me try on my phone.

[mvysny]

You're right - doesn't work on my Android 8.1 phone as well. I wonder what is the case for it...

[mvysny]

Hm. If I target Android API 26 or higher (Android 8.0 or higher), the following limit takes place as described at https://developer.android.com/about/versions/oreo/background.html#broadcasts :

Apps that target Android 8.0 or higher can no longer register broadcast receivers for implicit broadcasts in their manifest

Ooookay, so how am I supposed to learn of an implicit broadcast like ACTION_POWER_CONNECTED?

Apps can use Context.registerReceiver() at runtime to register a receiver for any broadcast, whether implicit or explicit.

Great, except it's useless since if the app is not running then the runtime receivers are not effective. Or are they? Investigate.

There are exceptions: https://developer.android.com/guide/components/broadcast-exceptions.html however ACTION_POWER_CONNECTED is not among one of them.

The Migration Guide is laughable. Suggested actions:

• Create the receiver at runtime by calling Context.registerReceiver(), instead of declaring the receiver in the manifest.
• Use a scheduled job to check for the condition that would have triggered the implicit broadcast.

First one is not applicable since it won't start the application. Second one suggests to wake up the application every minute to check if there has been power connected, which would destroy the battery. Good job Google saving the battery :+1:

However, there has to be a way, either by lowering target API to 25, or some other way. @theQuicker1 would you happen to know a solution for this which the Automate app uses please?

[mvysny]

This thread contains some hints on how to proceed: https://stackoverflow.com/questions/56539550/how-to-listen-for-power-connected-android-8 Sounds pretty complicated though:

1. Either I use Service and keep the app in memory all the time, or
2. Or I use JobScheduler and mitigate for the fact that it's only for Androids 21 and higher.
3. Or target Android 25 or earlier.

I hate programming for Android. Because it seems it is being developed by a group of idiots.

[mvysny]

This is getting ridiculous. The JobScheduler with setRequiresCharging(true) fires the job right away after scheduling, if the device is plugged in, and doesn't wait for unplug+plug. I would have to check the battery charging status and defer the Job schedule only after the cable is unplugged. However that's impossible to do when the app is killed by Android while the device is charging. So option 2 doesn't work.

Option 1 requires the app to stay in memory all the time. Fuck it, I'll go with that. If Google wants me to run all the time in memory in order to listen for ACTION_POWER_CONNECTED, then I'll do just that. I just wonder in what universe this saves battery.

[mvysny]

The service needs to be a foreground one and it will show an ugly notification as per Android's requirements.

Fixed in 1.13.10