3

I'm trying to found a best way to perform periodic work in android that will play nicely with doze mode and app standby. I've tried WorkManager with periodic request, it works fine at the beginning (for 15 mins requests) but the time slots diminishes as time goes by, after a week its seems to get triggered only once per day.

What is the best way to get the required behavior and still be doze mode and app standby friendly?

Dima
  • 101
  • 7
  • If you have a server I think FCM this is your best option: https://developer.android.com/training/monitoring-device-state/doze-standby#using_fcm – HedeH Jul 01 '18 at 10:44
  • I thought about it(FCM), but after reading the FCM documentation, I've decided it's not the way, in docs it's stated ". High priority messages generally should result in user interaction with your app. If FCM detects a pattern in which they don't, your messages may be de-prioritized." – Dima Jul 01 '18 at 11:01
  • I also read that, so don't use high-priority, I think it's still your best option... when you get the push, enqueue a `OneTimeWorkRequest` , it will be triggered when the system decides (maybe immediately), but it will trigger eventually. In my app I use both `PeriodicWorkRequest` and `OneTimeWorkRequest` triggered by FCM, they both trigger the same work. – HedeH Jul 01 '18 at 11:46
  • Do you need network access? – HedeH Jul 01 '18 at 11:51
  • In some of the case I do need network access. How often do you send your FCM messages? Doesnt it violate google policies ? – Dima Jul 01 '18 at 12:23
  • I don't use high-priority messages, so no. I send it every hour if the app didn't do it's work. Using this I understand that this work can be delayed (the delay duration is unspecified, depends on many things ), because I'm doing stuff in the background, making network access, and not showing the user anything.. In many cases the work is being triggered only when the device is charging... Sometimes immediately... – HedeH Jul 01 '18 at 12:30
  • Maybe this will help if you can't wait for hours until the work is triggered: https://medium.com/@benexus/background-services-in-android-o-862121d96c95 – HedeH Jul 01 '18 at 13:11
  • @HedShafran, I think this will still put the app in "app standby" mode, and over time diminish the time slot the app gets for it's work ... Did you test it over a week? – Dima Jul 02 '18 at 08:47
  • Yes, but I was targeting sdk 25, I started targeting sdk 27 yesterday, seems to work fine for now.. will let you know in 5 days :) – HedeH Jul 02 '18 at 08:50
  • @HedShafran I would really appreciate if you can comment after the run whole week. – Dima Jul 02 '18 at 13:13

1 Answers1

3

Following our conversation in the question comments, I have updates about my test.

I had to stop it today, but the test length was almost a week as you can see looking at the dates. I can approve that the WorkManager & FCM (without high-priority) was working great for me.

What I did is - regardless of the PeriodicWorkRequest I registered, on every FCM received, I enqueued a OneTimeWorkRequest for the same work registered with the PeriodicWorkRequest

My conditions:

  • targetSDK - 27
  • WorkManager version - 1.0.0alpha04
  • PeriodicWorkRequest, 15 minutes. NetworkType.CONNECTED constraints.
  • com.google.android.gms:play-services-gcm:11.8.0
  • Push (without high-priority) sent every 1 hour if the work didn't run
  • Test devices: Galaxy S8, Huwawei p20 lite, Galaxy S7, Pixel 2. (All running Oreo)
  • The app was killed after installation and I didn't open it at all during the test

The behaviour varied from device to device, but the overall behaviour was as follows:

During the first days (3 for the Galaxy S8 for example) the work ran every ~15 minutes, the rest of the days it ran every 1-5 hrs. For my purpose of background & battery efficient work, it was perfect. And it's better than once a day without the pushes as you described.

HedeH
  • 2,869
  • 16
  • 25
  • Thank you for sharing. This is a great info to have. It is strange though that not high priority FCM makes a change, I assume you handle the fcm by your receiver and not by the OS, which takes your app out of standby mode. – Dima Jul 09 '18 at 09:13
  • The FCM is received by the OS and the OS wakes up the app (even if it's killed) and delivers the FCM. When **not** using **high-priority**, the OS can choose when to wake the app and deliver the FCM, and this can take a few hours in some cases. When the FCM **is high-priority** the OS will wake the app and deliver the FCM immediately, but than you have to show a notification as you already know... – HedeH Jul 09 '18 at 09:46