Android Notifications Stop working after 2-3 days

[voidbrain]

On some Android devices (Huawuei P9 Lite for example) if I set a group of local notifications and schedule them, the first 2-3 works, the other doesn't arrive (too old?).

I found https://github.com/evernote/android-job/wiki/FAQ#what-happens-with-jobs-after-the-app-was-forced-killed. Is this the case? Solutions? Maybe reopen the app every time?

Your Environment

• Plugin version: 0.9.0-beta.3
• Platform: Android
• OS version: 7.0
• Device manufacturer / model: Huawuei P9 Lite (dual sim) Emui 5.0
• Cordova version 8.0.0
• Cordova platform version: Android 7.0.0
• Plugin config
• Ionic Version 4.0.0-testing.fa20842b

Expected Behavior

All the notifications should arrive.

Actual Behavior

When a group of notification is scheduled, the first few 2-3 days they works but the following ones does not.

Steps to Reproduce

Create a set of notifications (one per day) and schedule them with this.localNotifications.schedule(this.notifications);

Context

Schedule a set of notifications

Debug logs

Include iOS / Android logs

• ios XCode logs
• Android: $ adb logcat

[voidbrain]

Any help?

[EvertonLenger]

I've been having this same problem for the last 3 weeks.

Now I'm using 0.9.0-beta.3 as well, but I've tried with beta 2 and 1 and encountered the same problem.

If I reinstall the plugin, without changing any code, everything starts to work again, but stops after 2-3 notifications.

My device is a Motorola Moto G 2nd generation with Android 6.0.

[EvertonLenger]

@voidbrain Did you figure out one way to solve it?

[nzolore]

I'm having the same issue, after about two days the notifications stop working and have to be set again. It happens with both {at} and {every} day planned notifications.

[Android@8.0.0, plugin@0.9.0-beta.3, HTC U11 and Samsung S8]

[nzolore]

Anyone?

[rwillett]

We schedule for up to 48 hours in advance, though its normally 36 hours with no problem.

I know it doesn't help you, but I suspect there is an OS issue here.

[Tawpie]

I schedule 60+ days in advance and haven't had problems (although I haven't waited all 60 days!). I don't use every, instead I schedule individual notifications for each day and reschedule all the notifications every time the app is opened. Probably doesn't help you, but our philosophy is that if the user doesn't open the app after a few of these (opening the app will schedule new notifications for the subsequent 60+ days), they've probably lost interest and we have a different problem.

[rwillett]

We use the same method as @Tawpie and have the same views. We never use the every: flag. You can schedule up to 64 notifications on IOS and more on Android. If the user never opens your app after 64 notifications, ask yourself why?

If you need even more sophisticated (or complex) notifications, then use a notification provider.

See the OneSignal SDK as you can post a notification from a user.

https://documentation.onesignal.com/docs#section--postnotification-

Rob

[nzolore]

Thanks for the answers, well in my case the user schedules a reminder every day at a certain time, that's it. There's no need to open the app every time. The 1st/2nd time the notification works well, then it stops. I believe this is not the expected behavior unless I'm missing something.

It looks like if the user doesn't open the app for two days (more than 48h), the scheduled notifications get removed or disabled.

[rwillett]

How does the user schedule a reminder without opening the app? Do you mean the app schedules a reminder?

[nzolore]

Yes obviously the user needs to open the app once to set the notification time.

Any more idea about the issue?

[rwillett]

So when the user opens the app each day, specifically set the notifications by time rather than use the every: flag.

It does appear that various Android manufacturers change the OS slightly, Samsung used to be a nightmare about this but is better. One of the common problems is that Android notifications seems to be the area they change. There are issues about this going back years.

Since the user is opening the app every day, an easy solution is to simply schedule when the user starts the app. You can easily cancel any future ones and reschedule them.

[Tawpie]

Google alludes to an android 'feature' that broadcast intents aren't sent to stopped apps after 48 hours. I'm guessing that based on one person's workaround the plugin could be changed such that this doesn't happen. I'm not certain why the plugin works when you schedule without using every, but perhaps that's a clue for someone that can make a pull request!

[rwillett]

But if the user opens the apps every day as the OP says, that shouldn't be a problem.

[nzolore]

Tawpie: Unluckily it happens also by specifying {at} time. If someone has a workaround which does not rely on "if the user opens the app in the next 48h", it would be cool.

[Tawpie]

@nzolore perhaps you could share the code you use to schedule using at? I use trigger at and haven't had issues.

[Tawpie]

@rwillett I'm guessing the use case is: I open the app and ask for a reminder to "call Mother every day at 10AM". I'd like my phone to remind me forever and don't really want to open the app unless I need to change something.

My approach isn't good for that, so if the plugin isn't working and one can't develop their own pull request to fix it—using an external notification (push) is another option.

[rwillett]

@Tawpie But thats not going to work forever so at sometime the user is going to have to open the app to reschedule, whether it's in 2, 20 or 200 days. So it's just a question of when...

The use of every has been a constant problem as long as I can remember, certain manufacturers modify the core OS to suit their needs, Android is getting more standard than it used to be, Samsung were s nightmare around Android 4, but it's a perennial problem.

The easiest (for some relative value of easiest) solution is to use a push provider and generate the notifications from a server. Though now I think about it, I have a better solution:

1. Download and install the OneSignal Cordova SDK. OneSignal is free to use for any use.
2. Generate an app id for OneSignal for Android and IOS using their dashboard.
3. Set up OneSignal in the app. The code is pretty simple to use.
4. Don't forget to get permission from the user for GDPR.
5. Generate the scheduling in the app and push that schedule to OneSignal. Whilst OneSignal expects you to use a server, and we do, there's no need for simple notifications.
6. That's it.

A simple and free solution that works, takes about an hour to do.

Rob

[nzolore]

@Tawpie You guessed right, here's some working code tested right now on my device:

cordova.plugins.notification.local.schedule({ foreground:true, title: "The title", text: "the text", smallIcon: 'res://ic_stat_k.png', trigger: {at: moment().add(1, 'minute').toDate()} });

Change 1 minute with some date in the future, say one week, close the app without opening it for a week, the notification will not show up. At least on the two devices I tested.

@rwillett thanks for suggesting OneSignal and your mini-tutorial, I am going to try it.

[nzolore]

The only problem I see with OneSignal is that it's network dependent, while my app offers full offline support. I am impressed by how hard it is in 2018 to build a cross platform alarm clock like app.

[nzolore]

@rwillett

Generate the scheduling in the app and push that schedule to OneSignal

Hi Rob, don't you mind showing me how to do this? I could not find any example code. I can still hardly believe that there is no solution without involving an external service.

Lore

[rwillett]

See https://documentation.onesignal.com/docs/cordova-sdk#section--postnotification-

window.plugins.OneSignal.getIds(function(ids) {
  var notificationObj = { contents: {en: "message body"},
                          include_player_ids: [ids.userId]};
  window.plugins.OneSignal.postNotification(notificationObj,
    function(successResponse) {
      console.log("Notification Post Success:", successResponse);
    },
    function (failedResponse) {
      console.log("Notification Post Failed: ", failedResponse);
      alert("Notification Post Failed:\n" + JSON.stringify(failedResponse));
    }
  );
});

I have not tested this but we might write the code in the next few weeks to see if this is a viable option.

[nzolore]

Thanks, and here is the scheduling parameters I was looking for: https://documentation.onesignal.com/reference#section-delivery

Unfortunately it's not possible to set repeating notifications {every} day like mentioned above.

[rwillett]

Then write the code to send out 200 notifications at a time. Pretty simple code.

You appear to be looking for a technical solution out of the box that doesn't exist, so work around the problem.

[nzolore]

Thanks for your advice rwillett, you're right there is no out of the box solution. The workaround may look simple code, but I find it somehow inefficient. I think it's worth spending some time finding a reliable java-side solution to make repeated notifications working locally.

I found this article useful: https://stacktips.com/tutorials/android/repeat-alarm-example-in-android

Cheers

[rwillett]

Unclear why a free commercial push solution that requires minimal coding (circa 2-3 hours), gives you enormous flexibility (schedule what you want, when you want, at individual device level), with full and free commercial support that works, is inefficient.

We jumped at their solution and are converting our system to use it.

Rob

[nzolore]

Well, I don't want to fire at onesignal, but flexible, free, commercial doesn't mean efficient. Efficient means to use as less resources as possible, here we are involving an external service which depends on Internet, setting up hundreads of push notifications, using bandwidth, database storage, server resources, to make a simple alarm clock on a device which has already more cpu power and memory used by humans to get to the moon.

However I find OneSignal a good advice for many other tasks, such as complex push management as you said, and it's surely flexible, I am going to use it too in other applications.

[rwillett]

I'll close the thread.

Best of luck.

[nzolore]

The issue however remains, if anyone has an idea how to solve it, it will be much appreciated. I am going to do some more tests and post any successful results.

[Tawpie]

Agreed, the issue does still remain—I have one (1) user that's experiencing this on a Galaxy S7 that was purchased in Spain. You wouldn't think that "where the phone was purchased" would matter, but all of our US sourced Android devices continue to receive notifications without problem. It's just the Spanish one that stops getting notifications after 3 days. We're chalking it up to ¡¡¡Samsung!!! and moving on but @nzolore isn't imaging it!

[rwillett]

This is one of the reasons I hate Samsung and their version of Android.