4

I know that the method setRequiresDeviceIdle(boolean requiresDeviceIdle) makes the job run when the device to be in idle mode.

What I want is the opposite, I want the job to run when the device isn't in idle mode (screen is on and the user is using the phone) and I know that setRequiresDeviceIdle(false) doesn't do the job because saying "false" means that it isn't required so it'll run when it is idle and when it isn't.

student93
  • 307
  • 2
  • 12
  • I don't think that `JobScheduler` has an option for that. – CommonsWare Feb 23 '17 at 22:22
  • 1
    What exactly are you trying to do? – ianhanniballake Feb 23 '17 at 22:30
  • @ianhanniballake I must make an app that collects values from the different sensors while the screen is on and stores them in a file and when there is an internet connection ( second condition besides the screen being on) the file is sent to the server. All this must be done in the backgorund. – student93 Feb 23 '17 at 22:37
  • Why would any user want this? – CommonsWare Feb 23 '17 at 22:55
  • @CommonsWare I'm assigned this project and I don't have much freedom to change the instructions but basically the purpose is to gather a huge amount of information in order for the artificial intelligence algorithms to work. It's a crowdsensing app so it makes sense that the user isn't benefitting from it but I did notice the battery drain that this is causing. I'm working on a way to reduce it but I still have no idea how to gather the maximum ata without consuming so much energy. – student93 Feb 23 '17 at 23:01

1 Answers1

2

This is not possible via JobScheduler. If you wish trigger behavior based on the screen turning on, you must constantly be running (most likely as a foreground service) and programmatically register a BroadcastReceiver listening for ACTION_SCREEN_ON.

Obviously this is memory intensive and a horrible idea for overall system health which is why it is not supported by JobScheduler (not mentioning the significant memory pressure already present during ACTION_SCREEN_ON due to it being one of the conditions of coming out of Android 7.0's light doze).

ianhanniballake
  • 191,609
  • 30
  • 470
  • 443
  • thank you, so I must think of a different approach since this seems to be battery draining. – student93 Feb 23 '17 at 22:55
  • I don't get it, wasn't Job Scheduler really designed to Solve the memory-intensive nature of (custom) Broadcast Listeners? Why then does it not provide a more memory-feasible solution to such problems – Jitin Dec 27 '20 at 20:46