0

I'm currently struggling to keep my service alive when trying to get information about the user for a study. We are using a foreground service, which runs a timer on a 5-sec interval checking a resource of the user. As that resource is only relevant if the screen is on, we could stop the timer whenever the screen goes off. For this, we are using a broadcast service. All in all, this works well. The problem occurs, if the user closes the app and then puts the device on standby -> screen goes off. We would like to stop the timer and restart the timer inside that service if the screen goes on again. Now theoretically that works. I tested it with a counter variable which increments each time the run is called inside the timer. After that, I update my notification and show that variable. If however I close the app and the screen goes off, this variable is no longer updated in the notification and ergo, my resource check is not running. But I found out, that once I restart the app, the variable did indeed increase every 5sec and is then updated in the notification again. Furthermore, it is working if the device is on power/getting charged. So I guess it is a power management thing.

Summary: The ForegroundService/BroadcastReceiver is not acting like I would want to if the app is closed and the screen goes off, even though a part of it is working as intended. Works completely if the device is charging.

Do you have any ideas on how to avoid this behavior and allow the service to rerun the timer correctly so that the methods inside will work again?

Best regards,

Yukko

Tkinter Lover
  • 835
  • 3
  • 19
Yukko
  • 23
  • 5
  • It works, if I manually set the power management of the app. However, as we use the app for a study it would be nice if the user did not have to do that. – Yukko Apr 26 '21 at 16:19
  • To be clear, you're saying you have a repeating 5-second timer that increases a count, and you want that timer to stop while the screen is off? And you want it to restart when the screen comes back on, but it's not visually updating anymore? But that incrementing count is being stored somewhere, and when you fully restart the app, you get the count and it does show the correct number, so the timer was running when it should have been? In that case, it seems like your service is working fine, it's your display logic that isn't reconnecting properly when the app resumes, only when it's restarted – cactustictacs Apr 26 '21 at 16:31
  • Yea correct. However I don't think that it is only the display logic which fails. I also have a method in that timer which sends some data to the server if conditions apply. When deliberately triggering that condition, that call is not done as well. It's just the variable increasing which works. – Yukko Apr 26 '21 at 16:44
  • Does the service have to be running to increase the variable? Like is it literally, delay 5 secs, add 1 to the stored value? Or is it calculated by how much time has passed? I'm asking because if the service is running, doing calculations, it's not destroyed - but some of the stuff it's trying to do might be limited by power management (like delaying network calls so they can be run together) or the foreground state (e.g. restrictions on location access: https://developer.android.com/guide/components/foreground-services#access-restrictions) – cactustictacs Apr 26 '21 at 17:16
  • I don't know a ton about this so I'm just trying to give you things to look into! But honestly if the resumed activity isn't displaying the state correctly, but the state is saved and displays correctly after an app restart, that part at least sounds like something isn't being reconnected properly, and it's still referring to old data somehow – cactustictacs Apr 26 '21 at 17:18
  • Well the variable was just for testing. The timer really only wants to get the current app and act based on that. So every 5 sec we check the current foreground app and act upon that. And yea it is not destroyed, the on destory is never called and the foreground notification stays alive during the whole time. – Yukko Apr 26 '21 at 17:18
  • So is the timer restarting when it should, i.e. when you get the "screen on" broadcast? If that's fine then it sounds like you've got your service running properly, it's just some of the other things (like network calls) that are causing you problems. But I mean, if the service is only doing its timer+updates thing while the screen is on, then the device shouldn't be in a low-power state anyway right? Screen comes on, device is awake, your service starts doing timers and notifications etc... maybe sleep is destroying some of your components, and they aren't reconnecting properly later? – cactustictacs Apr 26 '21 at 17:35
  • Yea, I think once the device goes into sleep mode, the garbage collector removes some resources from my service without restarting them on wake up. The Updating of notification data is once example of this, but the networking probably aswell. – Yukko Apr 26 '21 at 17:53

0 Answers0