Feature proposal: reliable operation after reboot, plus a "peace of mind" feature set

[viktoriasee]

Why I'm writing this

I'm a user, not really a developer. I have a concrete personal need for an app like this — for an independent person living alone, where the realistic goal is that death or incapacitation is noticed within a day or two, not an acute minutes-matter emergency.

To be clear about what this post is and isn't: I'm not pushing for anything on a timeline, and I'm not asking you to adopt a list. You're clearly the one building this — the recent commits, especially the MakeAppWorkBeforeFirstUnlock work, show the project moving in exactly the direction I care about. My hope is just that the app keeps developing; that's the main track, and it's your call.

What I can usefully add is a more detailed account of the requirements from a user's point of view than you'd get from a Play Store review. If it's helpful as a reference — for you, or honestly just for other users trying to understand what the app is for — great. If parts of it are already done, already planned, or things you'd reject, that's fine too; I'd genuinely like to know which. Worst case, if I ever needed something specific badly enough, I'd cobble together a prototype with AI help for my own use — but that's a poor substitute for a real, maintained app, which is why I'd much rather see this one thrive.

Intended scope (frames everything below)

This needs stating plainly, because it shapes which trade-offs are acceptable.

The app is not an emergency system requiring a reaction within minutes or hours. A phone cannot deliver that, and pretending otherwise would be dishonest and dangerous. The realistic purpose is narrower and still valuable:

• Primary case: a person who has died at home is noticed reasonably promptly — within a day or two rather than weeks. Many healthy people who live alone are at peace with mortality but dread the thought of lying undiscovered.
• Secondary case: a person who is confused or injured — not in acute, minute-by-minute danger, but unable to move or communicate — is noticed and checked on.

Target users are independent, broadly healthy people living alone (not necessarily elderly; the situation fits younger people too). People who already have daily home care or are hospitalised don't need this. A reasonable baseline of health and daily phone use is assumed. The setup also assumes an eSIM (without a SIM PIN) rather than a physical SIM — see section A for why this matters to reboot behaviour.

This scope is worth stating in the app description too, gently but clearly. Honest framing protects users from false confidence and is itself a feature.

A. Reliable operation after reboot (relates to #156)

This is the capability I care about most, and it's clearly what the recent work targets — so most of this is probably already done or in progress. I'm including it for completeness and to flag the one part I, as a user, can't tell from the outside.

1. Operate through BFU. A directBootAware receiver/service, listening for LOCKED_BOOT_COMPLETED, with alarm state in device-protected storage so the alarm survives a reboot without unlock. (This looks like exactly what the MakeAppWorkBeforeFirstUnlock work does.)
2. The open question I'd love clarity on: whether an outbound SMS actually sends in the before-first-unlock state — as opposed to the alarm logic merely running. That's the point no alarms after reboot #156 raised, where it reportedly didn't work on GrapheneOS. The README says the app "can still send an alert before the screen is unlocked"; I'd just like to understand whether that's confirmed on GrapheneOS specifically. I'm on GrapheneOS with an eSIM and happy to test on real hardware if a build is available.
3. Keep the saved alarm state fresh while the device is in use. The README honestly notes the alert can fire "even if you were using the device right before the reboot," because the decision relies on the last saved alarm state. If that state is only updated on lock/unlock, a reboot during active use can leave it stale. Refreshing it on every unlock and periodically (every ~5 minutes) until the screen locks would close that false-alarm window. (I may be misreading how it's maintained — this is a guess from the README, not the code.)
4. Signal recovery. A short SMS after the first unlock following a reboot, confirming the alarm is active again.

(The battery-low case is related but distinct — see section F.)

Why eSIM, no SIM PIN: BFU operation depends on cellular connectivity being available before first unlock. With a physical SIM that has a PIN set — the norm in many countries, since a stolen SIM otherwise allows costly fraudulent use — the device needs a SIM-PIN replay after an unattended reboot to restore cellular service, and whether that completes before first unlock is uncertain. An eSIM avoids this: nothing to remove and reuse elsewhere, so no SIM PIN is needed, and the radio is available in BFU. (Confirmed in practice on GrapheneOS with an eSIM: incoming calls are received in the BFU state after auto-reboot.) This establishes only that the radio is up; whether the app may use it to send an outbound SMS in BFU is the item in point 2.

B. Configurable timers with sensible ranges

The inactivity and wait timers clearly already exist. As a user I'd want roughly:

• X — inactivity before warning: 1 hour to 3 days, ~20 steps.
• Y — warning countdown before alert: 0 to 3 hours, ~20 steps.
• Z — periodic "still active" heartbeat interval: 6 hours to 7 days, ~20 steps. (Tied to the heartbeat in section E.)

C. The warning-and-alert flow

This is essentially the existing "Are you there?" flow; listing it so the whole picture is in one place.

1. After X without an unlock, a notification warns that an alert SMS will be sent after Y, showing Y as a live countdown.
2. If unlocked within Y, the notification disappears and the X timer restarts. (A simple full reset on unlock keeps things lean; an explicit acknowledgement could be a later option.)
3. If not unlocked within Y, the alert SMS is sent, with the alarm state in device-protected storage so it survives a reboot.
4. False-alarm follow-up: after an alert is sent, a one-tap option to send a second SMS to the same recipients saying it was a false alarm.

D. Messages, recipients, and delivery

• Multiple recipients and custom alert text already exist.
• All message texts user-editable, including the new message types (reboot/recovery, battery-low, battery-restored, heartbeat).
• Resilient delivery / send retry. A failed send (e.g. no signal — the realistic "fell in the basement" case) shouldn't be silently dropped; it should be retried until it succeeds. Carrier-side retry only helps after a message reaches the SMSC — it doesn't cover the sending device having no connectivity at the moment of the attempt. Such retry would need to survive a reboot (device-protected storage).
• WiFi Calling (VoWiFi) as a recommended prerequisite. Where the carrier supports it, enabling WiFi Calling lets ordinary SMS (the user's own number, any recipient) go out over WiFi when cellular is weak or absent — covering the "no cellular but WiFi present" case, with no code change since the system routes SmsManager transparently. Worth recommending in setup docs. It does not solve the BFU case (section A): it uses the same telephony/IMS stack, so before-first-unlock availability is the same open question. This means carrier VoWiFi, not RCS (RCS would add a recipient-side dependency).

E. Heartbeat / liveness

Every Z, a heartbeat SMS (e.g. "still active"). This is the foundation of the only real defence against silent total failure — see the honesty note below.

Plus, on the first unlock after the app (re)starts, a "reactivated" SMS.

F. Battery handling (refines the #156 discussion)

• When the battery falls to a configurable threshold, a "battery low, alarm will stop working soon" SMS. Per no alarms after reboot #156 this threshold must be high enough to leave time to actually send (a shutdown event leaves too little time).
• If that message has been sent and the device is later charged back above a configurable level (e.g. 50%), a "phone charged again" SMS.
• Plugging in to charge also resets the X timer, since it counts as a sign of life.

G. Activity detection (relates to #125, with reservations)

Lock-screen unlock is the primary liveness signal and works well here: a healthy person unlocks at least once a day, and unlocking is a deliberate act (fingerprint/PIN/pattern), not an accidental touch. It's also simple, which has real value. I'd keep it as the default.

Motion/accelerometer detection (#125) is worth considering only as an optional additional signal, with a caveat: people often leave the phone on a table rather than carrying it, so motion absence isn't a reliable proxy for inactivity. Opt-in, not a replacement for the unlock signal.

H. Permission survival

Android may revoke permissions for unused apps, silently disabling the alert. The app already documents disabling "Pause app activity if unused." Worth making this a prominent, guided onboarding step rather than a README note, since a revoked permission is another form of silent failure.

I. Graduated / escalating recipients (relates to #40)

Optional, later: if the first recipient doesn't respond, escalate to additional recipients after a delay. Depends on a recipient-side acknowledgement mechanism (see companion app) and isn't needed for a first version.

---

The honest limitation: silent failure

The whole thing is a chain: device detects inactivity → sends alert → recipient reacts. If a link fails silently — phone fully dead (battery, defect, no signal at its location), permissions revoked, app killed by an aggressive battery manager — then nothing is sent, and on the recipient's side "all is well" and "the system is dead" look identical. Silence is indistinguishable from safety.

The heartbeat (section E) is the right defence in principle: it turns silence into an expected, missed signal. But it only works if someone on the recipient side notices the absence of an expected heartbeat — and a human won't reliably remember "the last sign of life was Tuesday." That's what a companion recipient app is for. The recipient app sensibly comes after the sender app; until it exists, the sender-only version should state that it detects inactivity on a functioning phone and doesn't protect against complete device failure.

Companion recipient app (future, sketched for completeness)

• Watches for missing heartbeats and raises a local alarm when one fails to arrive (closes the silent-failure gap).
• Makes alert notifications hard to miss — relates to Multiple notifications #153 (notifications get overlooked): repeating, loud, non-dismissable until acknowledged, distinct from ordinary notifications.
• Provides recipient acknowledgement, which enables the graduated escalation in section I.

Out of scope (deliberately)

• No cloud, no accounts, no server. A core value, not a gap to fill. (A peer-to-peer endpoint — e.g. a relative's phone — would be the preferred direction over any server.)
• No claim of acute, minutes-to-hours emergency response. The scope note is binding.
• No dependency on Google Play Services. GrapheneOS without sandboxed Play is a primary target, so functionality should rely on AOSP APIs only (SmsManager, AlarmManager, Direct Boot APIs, WifiManager, BatteryManager), consistent with the app's F-Droid presence.

[viktoriasee]

Is there a release candidate / test build I could try?

Separate from the spec above — a practical question.

The recent commits look like release preparation: changelogs added, version number bumped, build settings updated, a GitHub Action for builds, and a lot of new tests. The last published release (F-Droid 1.3.3, Nov 2025) predates the MakeAppWorkBeforeFirstUnlock work, so testing the current stable build wouldn't tell me anything about the before-first-unlock behaviour.

Is there any way to get a release candidate or test build — an APK from main, a CI artifact, or a pre-release tag? I'd like to test the reboot / before-first-unlock behaviour on real GrapheneOS hardware with an eSIM, which seems difficult to verify any other way, and report back what I find. Happy to file structured results (device, OS version, SIM type, BFU vs. after-unlock) if that's useful.

If a build isn't available to share, no problem — I can look into building from source. But if you already produce one, that's the fastest path to a useful test.

[keepalivedev]

I think this is because the app was side loaded via an APK instead of from the Fdroid store. Claude says to try: Android Settings → Apps → Keep Alive Lite → ⋮ menu → Allow restricted settings. That may work but its not guaranteed.

app usage data has always been a required permission for the app to function and has always used UsageEvents to check for activity.

[viktoriasee]

I never use F-droid but always sideload over Obtanium. And indeed this solved the problem. Installing the app from file manager is different from installing it over Obtanium. I do not understand why. I will now test the BFU SMS and report back.

[viktoriasee]

BTW my claude tells me that there would be two less permission hungry alternatives to app usage data:

• register a receiver on ACTION_USER_PRESENT does not need a permission but directBoot, which is enabled by default in the new version anyways.
• polling KeyguardManager.isDeviceLocked() and isKeyguardLocked() does not need a permission either.

I do not understand this, just repeating the advice.

[viktoriasee]

I can confirm the BFU SMS is sent! Well done, I think you are the first to explore this poorly documented feature! The notification did work BFU (with sound) and the text was readable on the sender BFU.

Just a hint: The notification currently is "please confirm you are alive". This text is a logical contradiction since you cannot expect an answer from a dead person. I suggest renaming the text to something like "please confirm you are well no later than 1:23 PM", adressing the healthy user.

I know it sounds paradoxical that I’m urging here for the app to be marketed primarily for deaths, whilst at the same time urging that the subject of death be treated with sensitivity. However, I believe that even people who are generally at peace with their own passing do not want to be reminded of it every time their phone is updated or restarted.

[keepalivedev]

Thanks for confirming! Also I updated the wording based on your recommendation and pushed the official 1.5.1 release.

[viktoriasee]

Scope clarification: relationship to smartwatches / wearables

One more scope point worth making explicit, alongside the existing "find, not rescue" framing.

The gap between phone-based and wearable-based detection

A smartwatch with fall detection, heart rate, and other body-worn sensors can do things a phone sitting on a table or in a pocket fundamentally cannot: detect a fall within seconds, monitor vital signs continuously, and react on a timescale of minutes rather than hours. KeepAlive works on a much coarser signal — device interaction — over a much longer timescale.

This isn't a flaw to fix; it's a different tool for a different situation. But it means the choice between "wearable" and "phone-based inactivity monitoring" is a real trade-off, not a minor implementation detail, and users should be making it consciously rather than defaulting to KeepAlive without realizing what a wearable would additionally catch.

Suggested framing

KeepAlive is best positioned for:

• People who have made a deliberate choice not to wear a smartwatch (cost, comfort, aesthetics, or privacy concerns about a cloud-connected wearable).
• As a complement to a smartwatch, covering the gaps where it doesn't apply — most obviously while it's charging, but also for anyone not ready to commit to wearable-based monitoring as their primary safety net.

It's a weaker choice for someone who would otherwise get a smartwatch and is only avoiding one because they haven't considered the alternative — in that case, they should at least be making an informed choice, not settling for the phone-based approach as a default they didn't know had a stronger alternative.

Where this could live

Same reasoning as the existing "find, not rescue" scope statement — README, F-Droid and PlayStore listing, and/or in-app onboarding, wherever that one ends up. Not proposing a code change, just flagging that this trade-off deserves the same explicit treatment as the other scope boundaries already documented here.

[viktoriasee]

Scope clarification: alpha/beta status given current gaps

Related to the "find, not rescue" framing already in this thread — a similar honesty question applies to the app's overall maturity, not just its scope.

Observation

Across the issues raised in this discussion and elsewhere (reboot re-arming causing false alarms, the full-screen intent setting having no effect, no post-alert acknowledgement, BFU-SMS reliability still landing), several of the gaps sit on the app's core path: reliably detecting inactivity and reliably alerting someone. These aren't polish items — they're the central promise of the app.

At the same time, KeepAlive is listed on the Play Store and F-Droid as a regular, finished app, with no version qualifier or maturity warning visible to someone installing it.

Why this might matter

For most apps, a rough edge means annoyance. Here, a gap in the core path means: nobody gets alerted, and the user believes they're covered when they aren't. That asymmetry is exactly the reasoning already behind the "find, not rescue" scope statement — the same honesty argument could apply to current reliability, not just intended scope.

Not proposing a specific label

Not suggesting a particular fix here (alpha/beta tag, changelog-based "known limitations" section, in-app disclaimer, or nothing at all) — that's a judgment call for you as maintainer, weighing user trust against adoption, and you're better placed to make it than I am. Raising it as a discussion point because the underlying tension (visible maturity vs. actual reliability on the core path) seemed worth naming explicitly, in the same spirit as the other scope clarifications here.