no alarms after reboot

[viktoriasee]

Describe the bug

If the device shuts down there is no alarm. Shutdowns occur because of different reasons:

• Reboots are to be expected either triggered by updates
• or by auto-reboot.
• If the battery is empty the app will stop working as well without notification of the contacts.

Expected behavior

1. The best option would be that the app would continue to operate before first unlock. I am not sure if this is possible technically. But alarms from the clock app work BFU.
2. Additionally there should be a SMS sent before shutdown. The text should be different than a normal alarm. I.e. "Device shutting down. Alarm function disabled"
3. Ideally there would be another SMS sent automatically after first unlock stating that the alarm is active again.

Affected versions

Auto-reboot is currently on all phones with Google Play Services >=25.14 but with a long interval. It is part of GrapheneOS where the default interval is 18h but much shorter intervals can be chosen by the user. Automatic reboots after an update are standard for all Android devices I am aware of.

[keepalivedev]

Can you tell me what kind of phone you have, the OS version and the Keep Alive version? The alarms should get re-created after a reboot, even if the phone is never unlocked... If you can send the debug logs to dev@keep-alive.io I can take a look to see if there is anything that would indicate if or why they didn't get re-created.

[viktoriasee]

Of course I tested with the latest version since it is a test install. I run GrapheneOS but I am not the target person so it does not matter. If the app runs only on certain phones this should be written in the doc so one can buy a phone that fits the requirements.

@keepalivedev : You say the alarms should get re-created BFU. But does that mean you can send an SMS BFU? This would surprise me! And I would absolutely recommend to write it in the doc. I am irritated by the word re-created. It is standard that app settings are persistent over a reboot. They are not deleted and must be re-created, isn't it? Same shoud be true for Android system settings.

I made a little research on the low battery shutdown feature. There seems to be an event that is pshed before shutdown but time is too short to send an sms. So the alarm must be triggered by a battery level high enough to provide time to send an SMS. I.e. 5%.

We can debate whether this is a bug or a feature request. I think technically it is a feature request but from a users perspective it misses the minimal functionality to recommend it for live use. But I find the app very promising.

[keepalivedev]

Settings persist across reboots but the app uses Android's AlarmManager to schedule the 'check-in' alarms and those do not persist across a reboot. On Android they are able to be re-created before first unlock but I am not sure if it is the same with GrapheneOS.

I didn't really consider whether an SMS could be sent before first unlock because Android does not typically reboot without user interaction, though I realize it can happen under certain circumstances. Scheduled reboots was not something I considered either.

I will look into adding some kind of wording to indicate that reboots or low battery may interfere with the app's ability to function. I am not sure if there is anything that can be done by the app itself to prevent or mitigate those scenarios but I am open to suggestions.

[viktoriasee]

Thanks for considering. I am just an average user no programmer. Though I am an engineer and have some basic understanding of risk analysis. I think that an app like the one you develop must be started by a risk analysis. Risk redcution is based on three pillars:

1. Make it unlikely for the app to fail
   Basically good programming practices. Few dependencies. The app should check periodically that the neccessary permissions are granted. Some OS like Graphene remove permissions when an app is inactive.
2. If it fails, make it easy for the user to discover
   That means for me that there must be a kind of heartbeat function for the supervisor. Otherwise the target person may uninstall the app by accident or it stops being compatible after an os update and the target person never gets notified. Another reason would be that the carrier contract gets suspended because the target forgets to pay the bill or top-up the prepaid account. This is especially important because this app is designed to never do something as long as everything is fine. This calls for a companion app for the supervisor. This app will read sms from KeepAlive that are just warnings (low battery, reboots, heartbeat). It must alarm the supervisor if 2h after a low battery alarm no heartbeat is received. Or 5 min after a scheduled reboot. Or if a heartbeat SMS is delayed 2h. Assuming you set a 24h heartbeat SMS interval plus one after every startup.
3. Mind common cause failures
   Here comes the battery thing. If the target person is unable to use the phone he/she will also be unable to charge the phone. Some phones don't last for one full day and some users do not want to charge daily. So it is well possible that a shutdown is the consequence of the user not charging the phone because of an incident. Therefore it is important to have error handling for this cause.

According to Googles Gemini it is technically feasible to program an app that sends an SMS before first unlock. This must be done using the directBoot API and you must save the target number and time in the DeviceProtectedStorage. Such an app will need the permission SCHEDULE_EXACT_ALARM and the alarm type should be RTC_WAKEUP. There are no specific restrictions for GrapheneOS.

[viktoriasee]

Are you willing to follow up on this project within the next few months?

[keepalivedev]

1. During the initial setup the app requests that you disable Unused App Restrictions aka App Hibernation to prevent the OS from removing permissions automatically. I have been considering adding a periodic check to ensure that the app has the necessary permissions but I have not gotten around to it yet.
2. By companion app, do you mean another app on the same device or something external to the device?
3. The app is designed to be entirely device-based, if it runs out of battery there is nothing the app can do.

I appreciate the ideas but I am not sure they are feasible given the app's design. I can look into proactively notifying the user if permissions are revoked but the other suggestions would all require some kind of external server that would be able to operate separately from the app. I develop this app in my free time and don't charge for it and would not be able to support any kind of backend infrastructure.

[viktoriasee]

2. By companion app, do you mean another app on the same device or something external to the device?

I meant an app on the phones of those receiving the SMS.

3. The app is designed to be entirely device-based, if it runs out of battery there is nothing the app can do.

That makes your app unique because all the other ones are cloud based. A low battery does not come unnoticed. It seems trivial to me for a programmer to fetch the battery state and send an alarm if the level is too low.

I appreciate your development very much and I do not think there is a need for a backend infrastructure.

Have you thought about using AI to modify the code in order to meet the suggestions above? Like Google IDX?

[keepalivedev]

2. By companion app, do you mean another app on the same device or something external to the device?

I meant an app on the phones of those receiving the SMS.

That could potentially work as a failsafe but I am worried it could lead to false positives if it was alerting the receiving user just because the phone of the person with Keep Alive installed ran out of battery. I have also heard from several users that they don't want the receiving user to know about Keep Alive at all unless it is actually necessary.

3. The app is designed to be entirely device-based, if it runs out of battery there is nothing the app can do.

That makes your app unique because all the other ones are cloud based. A low battery does not come unnoticed. It seems trivial to me for a programmer to fetch the battery state and send an alarm if the level is too low.

Yes, it would be easy to check the battery level but I do not feel that that is something that Keep Alive should be responsible for.

Have you thought about using AI to modify the code in order to meet the suggestions above? Like Google IDX?

Yes I have been using ChatGPT/Claude to help with coding for the last year or two. It is very easy to add code and new features but the hardest part for me is testing because I need to be 99.999% certain that any changes are not going to cause the app to fail. And, because of the way Keep Alive operates and Android OS restrictions, it is very hard to design tests against the core functionality, namely the setting and triggering of alarm timers under various conditions.

[viktoriasee]

I am worried it could lead to false positives if it was alerting the receiving user just because the phone of the person with Keep Alive installed ran out of battery.

Well that's why one would send a different message stating the condition of the alarm. It is not "just because". The reason for the phone running out of battery may as well be the person not being able to respond.

I have also heard from several users that they don't want the receiving user to know about Keep Alive at all unless it is actually necessary.

Such a feature should have an on-off toggle. But off is not the safe default. Not having a kind of "heartbeat" between the sending an receiving phone is a bad idea. It will fail when needed. It is like doing backups and never trying to restore anything.

it would be easy to check the battery level but I do not feel that that is something that Keep Alive should be responsible for.

Whose responsibility is it in your opinion?