os-issue-tracker
os-issue-tracker copied to clipboard
GrapheneOS
Alarm at the same time as reboot
Phone: Pixel 7 GOS Version: one of the January ones
Lately I woke up at exactly the same time as my alarm was supposed to go off and when I looked at my phone it was booting up and even after logging in the alarm didn't go off.
So it seems that there is a rare edge Case that, when the phone reboots ether caused by installing an update or the auto-reboot feature at exactly the same time as the alarm was supposed to go off, the alarm won't be working. Now that the auto-reboot interval was reduced the risk for that happening increased a lot.
Note that I was not able to reproduce the issue because it is very rare! And maybe I am completely wrong and it is another random bug like https://github.com/GrapheneOS/os-issue-tracker/issues/2487 or https://github.com/GrapheneOS/os-issue-tracker/issues/2822
Auto-reboot default was reduced from 72 hours to 18 hours. You can change the interval at Settings > Security > Auto reboot.
18 hours still means you have to not unlock your device in 18 hours, which it sounds like most people will (unlock their phone once hours before falling asleep) etc.
I am aware of that so either you don't understand the issue or propose this as a solution, but in fact this isn't a solution, rather a ugly workaround and the issue can still occur.
It is not clear what the issue is. Is it that the auto reboot can occur at the same time that the alarm would, thus resulting in the alarm being missed?
If I am understanding that correctly, what is the proposed solution to this?
Yes, that's the issue.
Honestly I have don't know how this can be resolved, but in my eyes it's a problem that should be resolved, thus I opened the issue.
Reviewing the documentation it looks like they already accounted for a reboot maybe?
https://developer.android.com/reference/android/app/AlarmManager#setWindow(int,%20long,%20long,%20android.app.PendingIntent)
The documentation is not clear enough about that. I guess the code of the clock/alarm app has to be changed in order to reschedule the alarm.
ChatGPT proposes the following:
- Register a BroadcastReceiver in your manifest to listen for the BOOT_COMPLETED broadcast.
- When the device boots up, the system sends out the BOOT_COMPLETED broadcast.
- In your BroadcastReceiver, receive this broadcast and re-register any alarms that were previously set using AlarmManager.set() or AlarmManager.setWindow().
Note that I never coded on Android and have very limited knowledge from an expert/developer standpoint
I missed multiple alarms because of this. Its an issue. My threat model relies on autoreboot to be set quite low. Just making the alarm go off after reboot would be a lot better than nothing.
