This is the difference between exact and inexact alarns, see again the documentation
Note : Google recommends to use exact alarms wisely to reduce battery consumption. See also Use cases that might not require exact alarms. If you decide to use exact alarms, then the user needs to grant the SCHEDULE_EXACT_ALARM permission, see method AskForScheduleExactAlarmPermission below.
I see that your device is running HyperOS (not the usual MIUI that runs on Xiaomi devices). I found this online:
This strongly suggests towards a device specific behavior, considering the fact that this extension works on other devices running Android 14. You should research more about your phone's (software's) settings.
There aren't many things that can be done to solve this issue in perspective of this extension. Most problems when it comes to background operations are device centered. I've come across many such instances where the background functionality dosent work for no reason on Chinese ROMs, and the solution is often hidden in a obscure varying place lying undocumented.
Here's one more thing you can try:
Open application → Go to recent apps → Lock your app
yes I agree
it is you, who has a device with that exotic OS... you could be the one, who describes not only for the user of your app but also for us what exactly needs to be done for HyperOS... as you can see after doing a Google search, this is a common problem on these devices...
If I buy a paid extension (as you did – and btw, I bought the same some years ago), I will most likely plan to publish the app in the Play Store. If I find that it does not work on one of my 20 test devices (usually one of the critical Chinese devices (Xiaomi)), I will exclude this device and corresponding device types from the Play Store. If it later turns out (through user comments) that other devices are also affected, I will also exclude them from the Play Store.
In my more than 10 years of experience, it is regularly the same exotic devices that are affected and their exclusion has (almost) no impact on my app download numbers (in the Play Store).
The time that you spend days looking for a solution to a problem that is almost irrelevant from a Play Store / publication point of view can really be used more sensibly and profitably.
please tell me, as I understand it, this block opens the application when a notification is triggered (provided that the block is not empty). The question itself is - when a notification is triggered when the phone screen is locked, will the application screen be initialized? or the initialization will only take place after the phone is unlocked (When the phone is unlocked, the application opens after receiving a notification) I hope I have expressed my thoughts clearly.
tests have shown that the application opens when the phone is locked only when a keyword from the notification is specified. so I'm wondering if the application screen will initialize when the phone screen is locked
and also, if I activate this notification once, will it repeat itself every day at the specified time? and I won't need to activate every day again? Am I understanding correctly?
After unlocking the device and clicking the notification, the app starts and the first event to be executed is the Screen1 Initialize event
Yes, if you start a daily repeated alarm, it gets triggered every day at the same time
However you are trying to build a prayer app. There are 5 prayer times every day. And each day the prayer times are different depending on the sun, so in your case it does not really make sense to start a daily repeating alarm...
Also it looks like you have overseen my suggestion.... here is it again
DRY - Don't repeat yourself and start only the next alarm instead of 5.
Be clear about what you want to do at alarm time. You have 3 options, just set the start mode accordingly.
StartMode for alarm time.
Possible values are: 1, 2 or 3. (1 = Only notification, 2 = Start Above Lock Screen or Notification, 3 = Start Always).
Default value is 2.
Now would be a good opportunity to read the documentation and learn about the different start modes. Depending on the start mode, you have to ask for different permissions.
I read the documentation. The problem is that your extension behaves differently on different devices. I'm already confused.
as I wrote differently on different devices. On Android 11, when the phone is unlocked, the notification arrives as expected. but if the phone is locked, then the notification does not arrive, but if you unlock the phone, the application is open. some kind of magic
and the procedure is not so simple. I created a procedure, on Android 14 the time is automatically updated at midnight, everything is fine. but on Android 11 the time is not updated for some reason
To be honest, I didn’t notice this block. thanks, I'll check
One of your devices does have an exotic OS, see the previous answers and get the simple project working on that device before continuing
It looks like you are using startMode 2 (default) but you forgot to create a screen called LockScreen.
From the documentation
Start Above Lock Screen or Notification If the device is locked, the screen called "LockScreen" of the app will be opened above the lockscreen of the device! After closing the app, the device still will be locked. If the device is unlocked, display a notification. After clicking the notification, the app will be started and screen "LockScreen" will be opened. This is the recommended start mode to not disturb the user while using other apps, see also here. Make sure to have a screen called "LockScreen" in your app. It is not possible to open another screen above the lockscreen.
What about trying the lockscreen example project to see how it works?
EDIT: note to self: to avoid confusion, a default value of 1 might have been the better choice...
On Android 14, the extension works even if battery optimization is disabled. You need to enable one autorun setting and no other settings are needed. I don’t understand why it didn’t work for me before.