Develop Reference

Periodic Work manager not showing notification on android pie when not charging or screen off

I have an app that should show a notification every 2 hours and should stop if user has already acted upon the notif. Since background services are history now, I thought of using WorkManager ("android.arch.work:work-runtime:1.0.0-beta01") for the same.
My problem is that although the work manager is successfully showing the notifications when app is running, but it won't show notification consistently in the following cases(I reduced the time span from 2 hours to 2 minutes to check the consistency):
when app is killed from the background.
device is in screen off.
state device is in unplugged state(i.e not charging).
By consistency , i mean that the notifications show at least once in the given time span. for 2 minutes time span, the freq of notifications went from once every 4 minutes to completely not show any notification at all. for 2 hours timespan( the timespan that i actually want), its been 4 hours and i haven't got a single notification. Here is the Code i am using for calling WorkManger:
public class CurrentStreakActivity extends AppCompatActivity {
...
#Override
protected void onCreate(Bundle savedInstanceState) {
...
setDailyNotifier();
...
}
private void setDailyNotifier() {
Constraints.Builder constraintsBuilder = new Constraints.Builder();
constraintsBuilder.setRequiresBatteryNotLow(false);
constraintsBuilder.setRequiredNetworkType(NetworkType.NOT_REQUIRED);
constraintsBuilder.setRequiresCharging(false);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
constraintsBuilder.setRequiresDeviceIdle(false);
}
Constraints constraints =constraintsBuilder.build();
PeriodicWorkRequest.Builder builder = new PeriodicWorkRequest
.Builder(PeriodicNotifyWorker.class, 2, TimeUnit.HOURS);
builder.setConstraints(constraints);
WorkRequest request = builder.build();
WorkManager.getInstance().enqueue(request);
}
....
}
Here is the worker class(i can post showNotif(..) and setNotificationChannel(...) too if they might be erroronous):
public class PeriodicNotifyWorker extends Worker {
private static final String TAG = "PeriodicNotifyWorker";
public PeriodicNotifyWorker(#NonNull Context context, #NonNull WorkerParameters workerParams) {
super(context, workerParams);
Log.e(TAG, "PeriodicNotifyWorker: constructor called" );
}
#NonNull
#Override
public Result doWork() {
// Log.e(TAG, "doWork: called" );
SharedPreferences sp =
getApplicationContext().getSharedPreferences(Statics.SP_FILENAME, Context.MODE_PRIVATE);
String lastcheckin = sp.getString(Statics.LAST_CHECKIN_DATE_str, Statics.getToday());
// Log.e(TAG, "doWork: checking shared preferences for last checkin:"+lastcheckin );
if (Statics.compareDateStrings(lastcheckin, Statics.getToday()) == -1) {
Log.e(TAG, "doWork: last checkin is smaller than today's date, so calling creating notification" );
return createNotificationWithButtons(sp);
}
else {
Log.e(TAG, "doWork: last checkin is bigger than today's date, so no need for notif" );
return Result.success();
}
}
private Result createNotificationWithButtons(SharedPreferences sp) {
NotificationManager manager =
(NotificationManager) getApplicationContext().getSystemService((NOTIFICATION_SERVICE));
String channel_ID = "100DaysOfCode_ID";
if (manager != null) {
setNotificationChannel(manager,channel_ID);
showNotif(manager, channel_ID, sp);
return Result.success();
}
else {
return Result.failure();
}
I am using a xiaomi miA2 androidOne device with Android Pie(SDK 28). There are a few other things that are troubling me:
What can i possibly do to know if my WorkManager is running? Other that just wait for 2 hours and hope for a notification. I actually tried something like that, keeping my phone connected to pc and checking android studio's logcat every now and then. It DOES run all the logs when the worker is actually called, but i don't think that's a correct way to test it, or is it?
In the above Code, the setDailyNotifier() is called from the onCreate() every time the app is opened. Isn't it Wrong? shouldn't there be some unique id for every WorkRequest and a check function like WorkManger.isRequestRunning(request.getID) which could let us check if a worker is already on the given task??If this was a case of AsyncTask, then boy we would have a mess.
I have also checked #commonsware's answer here about wakelock when screen is off, but i remember that work manager does use alarm manager in the inside when available. So what am I missing here?

Few comments:
WorkManager has a minimum periodic interval of 15minutes and does not guarantee to execute your task at a precise time. You can read more about this on this blog.
All the usual background limitation you've on newer Android releases are still relevant when you use WorkManager to schedule your tasks. WorkManager guarantees that the task are executed even if the app is killed or the device is restated, but it cannot guarantee the exact execution.
There's one note about the tasks being rescheduled when your app is killed. Some OEM have done modification to the OS and the Launcher app that prevents WorkManager to be able to accomplish these functionality.
Here's the issuetracker discussion:
Yes, it's true even when the phone is a Chinese phone.
The only issue that we have come across is the case where some Chinese OEMs treat swipe to dismiss from Recents as a force stop. When that happens, WorkManager will reschedule all pending jobs, next time the app starts up. Given that this is a CDD violation, there is not much more that WorkManager can do given its a client library.
To add to this, if a device manufacturer has decided to modify stock Android to force-stop the app, WorkManager will stop working (as will JobScheduler, alarms, broadcast receivers, etc.). There is no way to work around this. Some device manufacturers do this, unfortunately, so in those cases WorkManager will stop working until the next time the app is launched.

As of now , i have this app installed for last 8 days and i can confirm that the code is correct and app is working fine. as said by pfmaggi , the minimum time interval for work manager to schedule the work is 15 minutes, so there is a less chance that the WorkManager would have worked as expected in my testing conditions( of 2 minutes ) . Here are some of my other observations:
Like I said in the question that i was unable to recieve a notification for 4 hours even though i have passed the repeat interval as 2 hours. This was because of Flex Time. I passed in the flex time of 15 minutes and now it shows notifications between correct time interval. so i will be marking pfmaggi's answer as correct.
The problem of repeated work request can be solved by replacing WorkManager.getInstance().enqueue(request) with WorkManager.getInstance().enqueueUniqueWork(request,..)
I was still unable to find a way to test the work manager in the way i have described.

How to run service every 30 mins forever using Firebase JobDispatcher?

Till now, I have used AlarmManager to send HTTP request every 30 minutes. But recently, I faced warning in Google Play Console: Excessive Wakeups. When I read warning details, it said that AlarmManager waking devices up excessively.
Then I researched on what else I could use to send request every 30 minutes. In result, I found this documentation. It recommends to use JobScheduler or JobDispatcher. First of all, I tried to use JobScheduler - but it required API 21 which is not okey for me. I need to support devices from API 16 in my current project. Then I decided to use JobDispatcher.
This is my JobService:
public class MyJobService extends JobService {
#Override
public boolean onStartJob(final JobParameters params) {
Log.d("JobDispatcherLog", params.getTag()+ " STARTED");
jobFinished(params, true);
return true;
}
#Override
public boolean onStopJob(JobParameters params) {
Log.d("JobDispatcherLog", params.getTag()+ " STOPPED");
return false;
}
}
This is where I am creating job which is supposed to run service every 30 minutes.
FirebaseJobDispatcher dispatcher =
new FirebaseJobDispatcher(new GooglePlayDriver(this));
RetryStrategy retryStrategy =
dispatcher.newRetryStrategy(
RetryStrategy.RETRY_POLICY_LINEAR, 1800, 86400);
Job job = dispatcher.newJobBuilder()
.setService(MyJobService.class)
.setTag("very-important-job")
.setLifetime(Lifetime.FOREVER)
.setReplaceCurrent(true)
.setRetryStrategy(retryStrategy)
.setConstraints(Constraint.ON_ANY_NETWORK)
.build();
dispatcher.mustSchedule(job);
I tested this code and got following result in LogCat:
03-16 18:01:08.540 D/JobDispatcherLog: very-important-job STARTED
03-16 18:43:41.747 D/JobDispatcherLog: very-important-job STARTED
03-16 20:12:01.361 D/JobDispatcherLog: very-important-job STARTED
As you can see it is not running every 30 minutes.
My question: Is this normal behaviour for JobDispatcher? How to run service exactly every 30 minutes? If it is not possible, what else I can use to implement before stated function?

You can reduce the time window in which your job could be triggered. It can help you to control a little the time margin in which your job must trigger.
// Create a new FirebaseJobDispatcher with the driver
FirebaseJobDispatcher dispatcher = new FirebaseJobDispatcher(driver);
// Building the Job.
Job yourJob = dispatcher.newJobBuilder()
.setService(YourJobService.class) // The Job service that will execute.
.setTag(YOUR_JOB_TAG) // Unique Tag.
.setLifetime(Lifetime.FOREVER) // To make it last "forever".
.setRecurring(true) // To make it repetitive
/* setTrigger is your time window. You can adjust the SYNC_FLEXTIME_SECONDS to reduce the window a little. But it is not guaranteed to be .*/
.setTrigger(Trigger.executionWindow(ALARM_INTERVAL_SECONDS, ALARM_INTERVAL_SECONDS + SYNC_FLEXTIME_SECONDS))
.setReplaceCurrent(true) // To make it to overwrite a previous job created with the same tag.
.build();
NOTE: Be aware that if your are going to use FirejobDispatcher (or JobScheduler) then there will not be guarantees that your service will trigger exactly each 30 min.
If you want a more precise "alarm" then you must incline in using AlarmManager + Foreground Service. Be aware that AlarmManager for Android 6 or later will have a little delay (in other words the alarm will not trigger in exactly 30 minutes).

When to call JobScheduler.schedule()

What I want to implement is a background service that fetch data from the server every hour. I expect this service can run periodically after the boot. Thus, I choose to use JobScheduler to implement this function.
val jobScheduler = getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
val builder = JobInfo.Builder(1, ComponentName(this, PullDataJob::class.java))
.setPeriodic(1000L * 60 * 60) // one hour
.setRequiredNetworkType(NETWORK_TYPE_ANY)
.setPersisted(true)
jobScheduler.schedule(builder.build())
This is my currently code, which is placed inside onCreate(). However, I find that if I put the JobScheduler.schedule() in onCreate(), the service will be automatically executed every time I open the application.
Where is the best place to put the code above to make the service run periodically even if the user never opens the application after system boot?

Hakeem is right, you should only schedule it once.
In case you schedule a job with the same JobId twice, the documentation states following:
Will replace any currently scheduled job with the same ID with the new information in the JobInfo. If a job with the given ID is currently running, it will be stopped.
But i would solve the problem different to the way hakeem did. Instead of saving this information in a Sharedpreference you should use the JobScheduler to determine if the job with your id has been scheduled already. This way you are more robust and will reschedule the job in case some weird thing happened and your job is not scheduled anymore.
Code:
public static boolean isJobServiceOn( Context context ) {
JobScheduler scheduler = (JobScheduler) context.getSystemService( Context.JOB_SCHEDULER_SERVICE ) ;
boolean hasBeenScheduled = false ;
for ( JobInfo jobInfo : scheduler.getAllPendingJobs() ) {
if ( jobInfo.getId() == RETRIEVE_DATA_JOB_ID ) {
hasBeenScheduled = true ;
break ;
}
}
return hasBeenScheduled ;
}
When scheduling the Job you can then just use this function to determine if the job i currently scheduled or not.

Your job is executed periodically (once every hour), so once it's run the first time, JobScheduler.schedule() should never be called again.
Accomplishing this is quite easy, once you call JobScheduler.schedule() for the first time, register the fact that it's been scheduled, and only run the scheduling method when you're sure your job have never been run before.
public static final String IS_JOB_FIRST_RUN = "job scheduled";
...
SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(this);
if (preferences.getBoolean(IS_JOB_FIRST_RUN, true)) {
// your code
JobScheduler.schedule();
preferences.edit().putBoolean(IS_JOB_FIRST_RUN, false).apply();
}

Is it possible to re-schedule job within your job

I'm using Evernote's JobScheduler. The library provides a way to set a periodic job, however that has a minimum interval of 15 minutes between repetitions.
I want to be able to send a user's location to the server every few minutes (maximum 3, minimum 2). Is it technically OK to schedule your old job again and again after the job is done? Something like this:
protected Result onRunJob(Params params)
{
// my actual job runs here
schedulePeriodicJob();
return Result.SUCCESS;
}
private void schedulePeriodicJob()
{
jobId = new JobRequest.Builder(ScheduleJob.TAG)
.setExact(TimeUnit.MINUTES.toMillis(2))
.setBackoffCriteria(TimeUnit.MINUTES.toMillis(1), JobRequest.BackoffPolicy.LINEAR)
.build()
.schedule();
}
Or should I simply use a foreground service to achieve this?

Evernote job scheduler is based upon JobScheduler, GcmNetworkManager or AlarmManager depending on the context/device/playservices version. Whatever the implementation, APIs exposes the following method:
public JobRequest.Builder setPeriodic(long intervalMs, long flexMs)
I would use this one instead of "manually" rescheduling job. I also don't think your setBackoffCriteria call would not work without setting recurring job at APIs level.

cwac-wakeful collides with wakelocks

I have a quite strange issue with a cwac-wakeful library and wakelocks.
In my app, I'm using cwac-wakeful to periodically download a data from a web server and this works very well. But when somewhere in the app I acquire a wakelock (even when the set alarms were cancelled), cwac-wakeful starts to behave a little odd - it starts a job at full hours exactly every 5 minutes (14:00, 14:05...), regardless of set repeating interval.
Releasing the wakelock gives no effect and the only method to fix this is to completely restart the application.
I know that cwac-wakeful takes advantage of wakelocks while performing a job, so maybe the problem is here.
Here is a class that implements the AlarmListener.
public class ServiceWaker implements WakefulIntentService.AlarmListener
{
private static final Logger log = Logger.getLogger(ServiceWaker.class);
public ServiceWaker()
{
log.info("New ServiceWaker");
}
#Override
public void scheduleAlarms(AlarmManager alarmManager, PendingIntent pendingIntent, Context context)
{
SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(context);
long syncFrequency = Long.parseLong(prefs.getString("sync_frequency", "1"));
syncFrequency = syncFrequency * 60 * 1000;
log.info("Alarm scheduled with a repeat interval:" + syncFrequency);
alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
SystemClock.elapsedRealtime()+60000, syncFrequency, pendingIntent);
}
#Override
public void sendWakefulWork(Context context)
{
log.info("Sent wakeful work");
WakefulIntentService.sendWakefulWork(context, CheckServiceWakeful.class);
}
#Override
public long getMaxAge()
{
return AlarmManager.INTERVAL_FIFTEEN_MINUTES*2;
}
}
Details:
Target SDK: 17
Minimum SDK: 12
Compile SDK: 17
BuildTools version: 19.0.3

Late answer but I forgot to post it after I found out the solution.
The problem was an energy manager in my mobile. I have 3 battery plans available:
Energy saving - runs only essential services
Smart - prolongs the battery life by doing some optimization with wake locks, I have had this plan set to active
Normal - everything runs normally
"Smart" plan was responsible for this issue. As I have read somewhere, when set to active, the system tries to batch wake locks and network tasks, so the mobile is not continuously being waken. Thus my task was being re-scheduled with a longer period, in order to run it with another tasks every - for example - 15 minutes.