forrestguice / SuntimesWidget

Android app (and widget collection) that displays sunlight and moonlight times.
GNU General Public License v3.0
348 stars 61 forks source link

Phone restart #494

Open islam2hamy opened 3 years ago

islam2hamy commented 3 years ago

Every time i restart my phone , alarm doesn't work And i should turn all alarms off then turn it on again

Xiaomi redmi 4x Miui 11.0.2.0 Android 7.1.2

forrestguice commented 3 years ago

It sounds like BOOT_COMPLETED fails to run for some reason. There are some cases where this is expected (https://stackoverflow.com/questions/20441308/boot-completed-not-working-android), like if the app is somehow in the stopped state - if it was ever force closed at some point, or never initially opened. Since you already had working alarms, that seems far fetched. Maybe the app was updated recently (but no activities opened) - that might result in it being stopped. Its also possible your device has a setting that restricts apps from booting (and this is now toggled on somehow). Just throwing out some guesses.

Anyhow, its currently working for me. I want to confirm that its a special circumstance, or if it happens every time. Did this work reliably for you with past versions, or another device?

Please try this test; schedule an alarm for the next few hours (and verify that the reminder notification is shown). Reboot your phone. The notification should be gone (for the moment). Wait at least 5 minutes, then verify that the reminder notification is shown once again (it usually takes a few minutes before the BOOT_COMPLETED broadcast is received).

In your device's logcat, you should see something like AlarmReceiverService: android.intent.action.BOOT_COMPLETED: schedule all when this is eventually run (or maybe some indication of an error if the notification fails to reappear).

forrestguice commented 3 years ago

I'm reading that stackoverflow answer more carefully.. its likely device specific ("mi" phones are actually mentioned). Maybe listening for android.intent.action.QUICKBOOT_POWERON will fix this..

Or it might be caused by the lockscreen - the app doesn't currently respond to LOCKED_BOOT_COMPLETED and BOOT_COMPLETED isn't run until after the device is unlocked.. So if the device is rebooted, but never unlocked, those alarms would fail to run. They would be eventually rescheduled though (within a few minutes of unlocking the device).

islam2hamy commented 3 years ago

The test is passed , the reminder notification is shown once again

islam2hamy commented 3 years ago

But note that , after schedule an alarm for the next few hours and verify that the reminder notification is shown , and close the app from the recent task manager , the notification disappeared

forrestguice commented 3 years ago

Thanks, that's a really useful detail. I think BOOT_COMPLETED is actually working correctly, but your phone is putting the app in the stopped state whenever its eventually closed (same as a force close). That's one of the conditions that would prevent it from running again in the future.

Repeating the same test, after scheduling an alarm, if you immediately close the app from the task manager, then reboot, the notification probably won't reappear as it should.

I did some searching. It seems this behavior is specific to Xiaomi phones; https://stackoverflow.com/questions/41277671/clear-recent-apps-wipe-the-apps-memory-and-my-receiver-stopped-working

Try the solutions listed here; https://dontkillmyapp.com/xiaomi It references allowing apps to run in the background.. the app doesn't actually run in the background (that notification is a foreground service), but allowing it might be required to avoid it being forcefully stopped.. Or maybe looking in Security app > Permissions > Auto-start is enough to fix it.

islam2hamy commented 3 years ago

I think auto-start fixed it

islam2hamy commented 2 years ago

Hi , Can you please try this bug with this alarms ?

SuntimesAlarms_16-7-22.txt

islam2hamy commented 2 years ago

Please add this permission

android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

I think it will help in that

@forrestguice

forrestguice commented 2 years ago

@islam2hamy Sorry for not replying to this sooner. It sounds like this problem persists (or something similar).. I think the OS is definitely unscheduling those alarms for whatever reason. Those moon phase alarms (or solstices/equinoxes) must be especially vulnerable because they are schedule so far in advance. I think there might be some way to make things more robust. A reboot should reschedule (fix) all alarms.. thinking aloud.. maybe that code should be triggered more frequently.

Regarding android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, the app currently follows the advice given in https://stackoverflow.com/questions/44862176/request-ignore-battery-optimizations-how-to-do-it-right. I don't think including it will fix the problem. It would allow navigating directly to the optimization page, making it significantly easier to whitelist the app (which is definitely required for alarms to work reliably). Also for some reason Google forbids this (but since we don't publish there, that's less important).

islam2hamy commented 2 years ago

Hmm , ok I will continue with "auto-start" for now

forrestguice commented 1 year ago

@islam2hamy I've added the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission to this branch as a test. There should be an unsigned debug apk available. Click Summary (left side) -> Artifacts (bottom) -> App.

I doubt this will have an effect, but there is no harm trying. Maybe some devices check this permission and leave those apps alone. 🤷‍♂️ Since its not allowed on play store, it seems like the kind of permission only a system app would have.

islam2hamy commented 1 year ago

@forrestguice thank you for that , Please note that the implemented permission is : android.settings.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

And it doesn't work for me , the one that work for me is : android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

Since its not allowed on play store, it seems like the kind of permission only a system app would have

I can see this app with the same permission https://play.google.com/store/apps/details?id=com.haz.prayer

forrestguice commented 1 year ago

And it doesn't work for me , the one that work for me is : android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

Woops. I mixed those values up. Sorry about that. It should be fixed now. Here's another link to the debug apk (previously link is also updated).

Since its not allowed on play store, it seems like the kind of permission only a system app would have

I can see this app with the same permission https://play.google.com/store/apps/details?id=com.haz.prayer

What I meant was that play store requires special review/approval for using it. That app must have undergone that process.

I figure a device manufacturer's own apps could declare it without any review, and they might use it as part of their own half baked "battery optimization" (to avoid breaking their own apps). Its just a theory as to why it might work, despite the docs saying something different.

islam2hamy commented 1 year ago

No problem , thank you for the new apk, I will back tomorrow with the feedback

islam2hamy commented 1 year ago

The app asking me to optimizing battery after restarting the phone , why ?? And the alarm doesn't work

forrestguice commented 1 year ago

The app asking me to optimizing battery after restarting the phone , why ??

I'm not sure I follow. Do you mean the alarms activity is showing the "battery optimization" warning? Its a new addition to v0.14.10, shown when the app is listed as "optimized" - it must be "not optimized" for the alarms to work.

The recent commit (47c7294) changes the action on the warning - it should now whitelist the app (something that permission allows). Afterward it shouldn't appear again.

forrestguice commented 1 year ago

Is the app being removed from the battery whitelist after reboot? It might explain why alarms keep failing.

forrestguice commented 1 year ago

I'm looking closely at https://dontkillmyapp.com/xiaomi again.

You mentioned enabling Auto Start earlier; that's Security app > Permissions > Auto-start. Have you also tried the other settings for MIUI 11/12? They should be in Settings -> Apps -> Suntimes; something called Battery Saver that should be set "No Restrictions".

islam2hamy commented 1 year ago

Is the app being removed from the battery whitelist after reboot? It might explain why alarms keep failing.

Yes

islam2hamy commented 1 year ago

I'm looking closely at https://dontkillmyapp.com/xiaomi again.

You mentioned enabling Auto Start earlier; that's Security app > Permissions > Auto-start. Have you also tried the other settings for MIUI 11/12? They should be in Settings -> Apps -> Suntimes; something called Battery Saver that should be set "No Restrictions".

Now , We are testing : android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

So i keep 'Auto-start' off and 'Battery Saver' as default value

That is the point , i need to stop using auto-start and fix it from the suntimes app

Like this app : https://play.google.com/store/apps/details?id=com.haz.prayer

B.t.w. after searching, that was happening because off 'Doze' and this app fixed 'suntimes' probleme after testing it https://www.f-droid.org/packages/com.dosse.dozeoff/

and thier is another permision may fix this if the first one dosen't : PARTIAL_WAKE_LOCK

but i don't need to keep using root , and using alot off apps

forrestguice commented 1 year ago

We are now testing : android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

So i keep 'Auto-start' off and 'Battery Saver' as default value

This is a Xiaomi specific issue for sure. I think those Xiaomi specific settings should be as recommended for it to work. If android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS fixes it, its in addition to those other settings. That permission is supposedly only for whitelisting the app easier. I tried this and its only one click now - I'm now thinking it should be part of the app either way.

Regarding 'auto-start', my impression is that just allows the app to run at boot. Rebooting does restore alarms, but you are right, doing this on a regular basis is not a real fix. If the system would stop killing the alarms then rebooting all the time wouldn't be necessary, which is why I'm wondering if there's anything from https://dontkillmyapp.com/xiaomi we haven't tried.

B.t.w. after searching, that was happening because off 'Doze' and this app fixed 'suntimes' probleme after testing it https://www.f-droid.org/packages/com.dosse.dozeoff/

Interesting. If this works, its something I can recommend to others, or in the help.

PARTIAL_WAKE_LOCK

That is one I want to avoid. It allows turning and keeping the screen on, but we shouldn't need it. The alarms are delivered by notification. The underlying issue is AlarmManager is failing to trigger that notification, but I don't think a wakelock will fix that.

islam2hamy commented 1 year ago

Is the app being removed from the battery whitelist after reboot? It might explain why alarms keep failing.

Yes

Only with the new permission android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS

islam2hamy commented 1 year ago

This is a Xiaomi specific issue for sure. I think those Xiaomi specific settings should be as recommended for it to work. If android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS fixes it, its in addition to those other settings. That permission is supposedly only for whitelisting the app easier. I tried this and its only one click now - I'm now thinking it should be part of the app either way.

Yes i know that , it is Xiaomi issue.

B.t.w. if the alarm type is 'notification' , it is work good with last release The problem now is with alarm type 'alarm'

Originally posted by @islam2hamy in https://github.com/forrestguice/SuntimesWidget/issues/628#issuecomment-1318289517

New release without using "auto-start"

i should turn all alarms off then turn it on again

('notification' & 'alarm')

this was happenig with the old releases without "auto-start"

islam2hamy commented 1 year ago

@forrestguice Will this help ?

https://robertohuertas.com/2019/06/29/android_foreground_services/

forrestguice commented 1 year ago

That was an interesting read - thanks.

I don't consider it a good design pattern though. A "foreground service that never stops running" means a notification in the tray at all times. Since the app would be technically running all the time (even when doing nothing) its also more likely it would show up as using battery. Kind of like all those services (bloatware) you can't disable or remove from a lot of stock devices. In the past when the notification service kept running after it should have stopped, that was a "bug", but it seems this would be doing it intentionally.

islam2hamy commented 1 year ago

Ok no problem , let's avoid it. We don't need "running all the time (even when doing nothing)"

forrestguice commented 1 year ago

Sorry it is my mistake , It wasn't because of the alarm type 'alarm' , it is because of set alarm from "interval midpoints" and "natural hour" .

This makes some sense I think, because there isn't much of a technical difference between the 'alarms' and 'notifications', but there is with the "interval midpoints" alarms. That is separate process that Suntimes communicates with through a ContentProvider.

Is the "Interval Midpoints" app on the "not optimized" list? I guess its possible the ContentProvider might be blocked otherwise. There might also be a line or two in the logcat when it happens.

islam2hamy commented 1 year ago

Is the "Interval Midpoints" app on the "not optimized" list?

Yes Does "Interval Midpoints" app need "android.permission.RECEIVE_BOOT_COMPLETED" ?

forrestguice commented 1 year ago

Does "Interval Midpoints" app need "android.permission.RECEIVE_BOOT_COMPLETED" ?

No, its not needed. Suntimes has the permission, receives that signal, and then queries the addons. I guess "Interval Midpoints" might need your device's "auto-start" permission though - I don't know how those restrictions work, but its plausible its blocking it.

islam2hamy commented 1 year ago

I guess "Interval Midpoints" might need your device's "auto-start" permission though - I don't know how those restrictions work, but its plausible its blocking it.

Ok , I will back tomorrow with the feedback

islam2hamy commented 1 year ago

Doesn't work

Ex. : Set alarm that will be after 4 hours. Turn phone off for 3 hours (with auto start setting if posible). Don't unlock your phone after restart and wait the alarm after 1 houre. Alarm will not work (p.s : seting 'event' alarm from the main app will work)

islam2hamy commented 1 year ago

V. : 0.14.10

forrestguice commented 1 year ago

Don't unlock your phone after restart and wait the alarm after 1 houre.

The app doesn't currently support "direct boot", which is required to run code before the device has been unlocked. So this particular mode of failure is expected - you'll have to unlock the device after a reboot before those alarms get scheduled.

islam2hamy commented 1 year ago

But the event alarm work with me

islam2hamy commented 1 year ago

But the event alarm work with me

@forrestguice Edit : only the last one work for me

IMG

islam2hamy commented 1 day ago

Hello @forrestguice ,

If the "Boot Completed" as a checkbox and it is not checked to be auto , is this will fix this issue ?

forrestguice commented 1 day ago

Which checkbox are you referring to? I don't think I'm familiar with it, so I'm guessing its a Xiomi thing.

My understanding was that this particular device is force stopping the AlarmManager (aggressive battery management), periodically killing the alarms. They get restored later on BOOT_COMPLETED but then Xiomi requires users to check an extra "Autostart" setting to make this work. To complicate things, as of v0.16.3 there are now two "BOOT_COMPLETED" events, one before the device is initially unlocked, and another after unlock. The alarms are only restored after unlock.

Sorry, I'd honestly forgotten this issue was open. The last time I looked closely at it I couldn't find a real solution.

forrestguice commented 1 day ago

Revisiting a previous suggestion from this thread...

An always running foreground service would probably keep alarms alive. It is just such an ugly (anti) pattern! I might add it anyway as an option if it makes these "broken devices" work correctly. I suppose its not so terrible if that is what the user actually wants.

islam2hamy commented 1 day ago

Hmm, sorry for making this confusing

let me make it clear

  1. Set alarm from add-on
  2. restart the phone befaour the alarm time ,without unlock thephone
  3. alarm will not work (didn't test it with v.0.16.3)

    Making "Boot Completed" as a checkbox (manual run) , is just a suggestion to fix this issue