Question on local scheduled notify notifications not sending after android reboot.

[theaitechnician]

Hi Marco,
First of all, thankyou for the great work. It’s really an amazing alternative to expo-notifications, appreciate your work.

I have used notify to make the notifications, however I seem to come into some problems and issues.

All the functions works, except when we reboot the android device. After that the scheduled notifications does not fire at scheduled time.

So I would like to know, if notify-kit actually support the scheduled android local notifications being able to send properly after the restart of device. Or is this just the limit of react native app, and would require some push notifications to send notifications reliably after restart, without app being open?

If it does support, is there any specific formats or pipelines required for this to work?
I am using individual Timestamp one shot triggers, or it needs something like a recurring type for daily reminders for it to work properly after reboot?
Please Let me know if u need extra info.

Would really appreciate your help, i am stuck on the notifications for half a month now. was using expo notifications before, but research shows its actually not reliable, so i turned to notify.

P.s Also downloaded your amazing app GymBroTools, and gave a 5 star review :)

Further info:
Library version: react-native-notify-kit ^10.4.4
Expo SDK: ~54.0.33 / React Native 0.81.5

Trigger type: TriggerType.TIMESTAMP (oneshot and reschedule) (Affect what RebootBroadcastReceiver has to restore)

Step 1 — Device reboots
Android wipes all AlarmManager alarms. Every scheduled notification is gone from the OS.
Step 2 — BOOT_COMPLETED broadcast fires
Android sends android.intent.action.BOOT_COMPLETED to all registered receivers. notify-kit's RebootBroadcastReceiver is supposed to catch this.
My current state: withBootReceiver.js plugin injects an override entry in the app manifest to force exported="true" on app.notifee.core.RebootBroadcastReceiver.

1. How slots are scheduled (scheduler.ts)
   await notifee.createTriggerNotification(
   {
   id: notifId, // deterministic: ${reminderId}_${fireDate.getTime()}
   android: {
   channelId: 'practice_reminders',
   smallIcon: 'notification_icon',
   pressAction: { id: 'default', launchActivity: 'default' },
   },
   },
   {
   type: TriggerType.TIMESTAMP,
   timestamp: slot.fireDate.getTime(),
   alarmManager: {
   type: AlarmType.SET_EXACT_AND_ALLOW_WHILE_IDLE,
   },
   },
   );

Channel setup:
await notifee.createChannel({
id: 'practice_reminders',
name: '練習提醒',
importance: AndroidImportance.HIGH,
sound: 'default',
vibration: true,
vibrationPattern: [400, 400],
lights: true,
lightColor: '#1a3a5c',
});

Have 50 total trigger and notification limit
checkPermissions() uses notifee.getNotificationSettings() to read both authorizationStatus (POST_NOTIFICATIONS) and settings.android.alarm (SCHEDULE_EXACT_ALARM).
android.permission.SCHEDULE_EXACT_ALARM
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
android.permission.POST_NOTIFICATIONS
android.permission.VIBRATE

Plugin fixed (confirmed with androidmanifest in decompiled app):
RebootBroadcastReceiver — exported="true"







TaskBroadcastReceiver — exported="true" — also fixed

[marcocrupi]

Hi @theaitechnician, thanks for the detailed report, and thank you also for the GymBroTools review. I really appreciate it.

Yes, react-native-notify-kit is intended to support Android local scheduled trigger notifications across a normal device reboot.

A future one-shot TriggerType.TIMESTAMP trigger is part of the supported path. You do not need to convert it to a recurring/daily trigger only to survive a reboot, and push notifications are not required for this local scheduling case.

I also validated this path on my side with both:

• a bare React Native smoke app
• an Expo CNG/prebuild development build

In both cases, the trigger was scheduled before reboot, the device was rebooted, and the Android alarm was re-armed after reboot.

So I would not treat TriggerType.TIMESTAMP one-shot triggers as the problem by default.

The next thing I would check is the final Android integration in your app.

A few important points:

1. NotifyKit already declares RECEIVE_BOOT_COMPLETED and app.notifee.core.RebootBroadcastReceiver in its own Android manifest. In a normal Expo prebuild/dev-build setup, those entries should be merged into the generated Android project.

2. Your custom withBootReceiver.js plugin may not be necessary. It is worth checking carefully because if it replaces the receiver declaration instead of preserving NotifyKit’s original receiver block and intent filters, it could accidentally break reboot recovery.

3. Some Android vendors delay or suppress BOOT_COMPLETED unless the app has autostart/background permissions enabled. In that case, the receiver may not run immediately after reboot even if the manifest is correct.

4. If SCHEDULE_EXACT_ALARM is not granted, NotifyKit falls back to an inexact alarm instead of failing. Reboot recovery can still work, but exact fire timing is not guaranteed.

Could you share a bit more package-specific information?

• Device model and Android version/API level
• OEM skin, for example Pixel/AOSP, Samsung OneUI, Xiaomi/HyperOS, Oppo/ColorOS, Vivo, Huawei/Honor
• The final merged/decompiled manifest block for app.notifee.core.RebootBroadcastReceiver, including its intent filters
• The permissions section from the final manifest
• Logcat around reboot filtered by your real package name and NOTIFEE
• dumpsys alarm before and after reboot, filtered by your real package name
• Whether opening the app once after reboot causes the triggers to be recovered
• Whether the issue also reproduces with only 1-5 scheduled triggers, before testing around 50

That should tell us whether BOOT_COMPLETED is not reaching your app, whether the custom manifest plugin is changing the receiver setup, or whether there is a real runtime issue to investigate.

[theaitechnician]

@marcocrupi Thanks for the detailed answer, we have made some progress. Here's what i find:

Xiaomi12(android: 13 TKQ1.220807.001)(MIUI: 14.0.3) (API Level via ADB: 33)
HuaweiP10( Android 9: EMUI:9.1.0)

What the Plugin did:
expo.modules.taskManager.TaskBroadcastReceiver: exported: true
app.notifee.core.RebootBroadcastReceiver exported: true
expo.modules.notifications.service.NotificationsService exported:true

so without the plugin those would be false and i believe it makes the app unable to listen to the boot signals. at least that's what the ai say, but i do see some evidence saying even false works.

confirmed from the permissions section from decompiled manifest. :
RECEIVE_BOOT_COMPLETED
SCHEDULE_EXACT_ALARM
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

Logcat of the ai analysis is uploaded. But I think the ai analysis of that is just fine, u can read that first, and see if that covers what u want to look for.

notifee_logcat_findings.md

2 key findings:

Finding 1 — Root Cause Confirmed: MIUI Autostart Suppression

With autostart OFF, the log shows MIUI's BroadcastQueueInjector explicitly blocking the app:

W/BroadcastQueueInjector: Unable to launch app 
com.cangjieking.cangjielearner for broadcast 
Intent { act=android.intent.action.BOOT_COMPLETED }: 
process is not permitted to auto start

BOOT_COMPLETED never reaches any receiver in the app. This is why notifications silently fail after reboot — the entire app is gated at the MIUI layer before Android even attempts delivery. This is not a manifest issue, not a code issue. MIUI blocks it unconditionally for apps without autostart permission.

With autostart enabled, notifications fire on schedule successfully. This is the confirmed fix.

---

Finding 2 — BOOT_COMPLETED Reaches TaskBroadcastReceiver, Not RebootBroadcastReceiver

With autostart ON, BOOT_COMPLETED is delivered, but only to TaskBroadcastReceiver:

09:19:10  ActivityManager: Start proc for broadcast 
          {com.cangjieking.cangjielearner/expo.modules.taskManager.TaskBroadcastReceiver}
          caller=android

09:19:11  broadcast end Intent { act=android.intent.action.BOOT_COMPLETED 
          cmp=com.cangjieking.cangjielearner/expo.modules.taskManager.TaskBroadcastReceiver }

app.notifee.core.RebootBroadcastReceiver receives no direct BOOT_COMPLETED call in either boot session. Notifications still fire correctly, so the recovery path is running through TaskBroadcastReceiver rather than through notifee's native receiver. Whether RebootBroadcastReceiver should also be receiving BOOT_COMPLETED independently is worth confirming on your end.

Whether opening the app once after reboot causes the triggers to be recovered:
I have made a fall back logic for this, so i am not sure if this is your fallback or mine, but opening the app will make the notifications appear.

After that i did more investigating, and on the xiaomi12, i have finally be able to trigger the notification after the restart of device, the key was :

On MIUI 14, there is a new permission to start from the background for each app, in Settings > Apps > Your app > App permissions > Background autostart. If i set that then the scheduled notifications fire.

Then i look at other apps as well, some never have to do this on autostart, yet they are still able to send local notifications, so i am still investigating. if there are better ways to do it, it seems a lot of android manufacturers, suppress the boot signal, and the app will never receive it, and what is worst is, every manufactor have some different settings to this. So i am trying to find an alternative way to make this work, but i am currently adding the instructions to the phone for these.

For future lookers: dontkillmyapp.com is a good source to look for a solution or some guides for it, but it seems not all are accurate, so do your due diligence with manufactory and it would change with time.

So Marco, what do u think? How best to approach this? i think we need to make some documentations on this for future users as well, if the only solution is to guide them to allow auto start.

[marcocrupi]

Thanks for the follow-up. This is very useful.

Your MIUI finding makes sense. If MIUI logs:

process is not permitted to auto start

then the app process is blocked before Android can deliver BOOT_COMPLETED to any receiver inside your app package. In that situation NotifyKit cannot re-arm the alarms at boot time, because the app is not allowed to start.

So yes, on Xiaomi/MIUI, enabling Autostart / background startup is the practical mitigation for this class of issue. The fact that notifications start working after enabling Autostart is a strong confirmation that the main problem is the OEM background-start policy, not TriggerType.TIMESTAMP.

About TaskBroadcastReceiver: that receiver belongs to Expo, not to NotifyKit’s native reboot recovery path. Seeing expo.modules.taskManager.TaskBroadcastReceiver in the logs means Expo is receiving that broadcast, but it does not prove that NotifyKit’s app.notifee.core.RebootBroadcastReceiver also ran. It also does not prove it failed to run, because the log capture/filter may simply not show it.

The best package-specific things to check are still:

• app.notifee.core.RebootBroadcastReceiver
• NOTIFEE
• RebootReceiver
• NotifeeAlarmManager
• InitProvider
• BOOT_COMPLETED
• BOOT_COUNT
• your exact app package name

I would also be careful with the conclusion that exported="false" automatically means the receiver cannot receive boot broadcasts. NotifyKit already declares its reboot receiver in the library manifest, and Expo prebuild/CNG should merge it into the generated Android project. A custom plugin should normally not be required for the NotifyKit boot receiver.

If you keep the custom plugin, the important thing is that it preserves the original receiver declaration and intent filters. Replacing the receiver block can be risky.

From the library side, I do not think this points to a runtime fix right now. If the OEM blocks the app from starting at boot, no notification library can immediately re-arm alarms from BOOT_COMPLETED. The best practical approach is:

1. document the OEM Autostart/background-start requirement clearly;
2. guide users to the correct vendor settings when needed;
3. keep a cold-start recovery path for when the app is opened after reboot;
4. make sure the final merged manifest still contains the NotifyKit receiver and permissions.

I agree that this should be documented for future users. I have been improving the docs around Android reboot recovery, exact-alarm fallback, Expo manifest merge, and OEM restrictions, because this is a common source of confusion.

For your app, I would treat MIUI Autostart as the confirmed root cause on Xiaomi. The remaining question is whether your successful recovery with Autostart ON is coming from NotifyKit’s native receiver, Expo TaskManager, your own fallback logic, or a combination of these. Package-specific logcat and dumpsys alarm are the best way to distinguish that.