Privacy Policy

Last updated: October 10, 2026

1. Data controller

Jan Komadowski (LoSoft). Contact: support@incident-detection.com.

2. What data the app processes

Incident Detection detects possible crashes during an activity (cycling, motorcycle riding, running, walking, hiking, driving, or water activities like kayaking or canoeing) and, when one is detected, notifies emergency contacts chosen by the user. An optional Check-in mode offers the same emergency-contact notification without tracking an activity at all — see §10. An optional Gym mode offers a similar no-motion-tracking alternative for workouts where the phone isn't carried, using a self-confirmed timer instead of a periodic prompt — see §11. It also offers an optional Guardian mode, letting two people who both use the app pair their phones over Bluetooth so one can tell whether the other is nearby, with an automatic alert to emergency contacts if they lose each other — see §9. It also offers optional Reminders — predefined or user-created health/activity prompts (drink water, take vitamins, stretch, and more), running either all day or only during a specific activity, which can optionally escalate to the same emergency alert described above if left unconfirmed — see §13. To do this, it processes:

All of the above is stored exclusively on your device by default — the app has no server or backend of its own for any of it, with three opt-in exceptions. §3: if you plan a route in the in-app planner, or turn on automatic route recalculation, the points you chose are sent to a routing relay operated by the developer, which stores and logs nothing it receives and forwards them to a routing server. §12: if you choose to connect a Strava account, session data you select is uploaded directly from your device to Strava's own servers, and a minimal relay operated by the developer is used only to broker that connection — it never sees or stores your session data. §9a: if you separately turn on the remote location beacon, coarse coordinates are sent to a developer-operated relay, which does briefly store them (see §9a for the retention window) — unlike the Strava relay, this one is not a pure passthrough. Absent either opt-in, nothing in the table above is transmitted to or stored by the developer. (Absent the routing opt-in, no route points are sent anywhere either.)

3. Who data is shared with

• The user's mobile carrier — the emergency SMS/MMS text and phone call to the emergency contact are sent directly through Android's system messaging and calling APIs, exactly like any other message or call placed from the user's phone. The developer does not intermediate this transmission and has no visibility into it.
• Google Maps Platform — when the in-app map uses the Google Maps SDK (the default, when available), it communicates with Google's servers to fetch map tiles. Subject to Google's own privacy policy, independent of this app.
• OpenStreetMap Foundation, CyclOSM, and OpenFreeMap — on a device without Google Play Services, or when you choose the "MapLibre (no Google)" map source in Settings, the app instead fetches map tiles from one of these free, no-account community tile providers, depending on the map style you've selected. Same kind of data as the Google Maps Platform row above — the map area being viewed, and the usual network-request metadata (IP address) — sent to a different operator. Each subject to its own operator's privacy policy, independent of this app.
• MapToolKit — same "MapLibre (no Google)" map source setting, when you pick one of the MapToolKit-hosted styles instead of OpenFreeMap. Same kind of data as the row above — no account, no API key. Subject to MapToolKit's own terms and privacy policy, independent of this app.
• MapTiler — same "MapLibre (no Google)" map source setting, when you pick a MapTiler-hosted style. Map requests include an API key identifying the app (not you individually) to MapTiler — the only one of these four community map sources that's keyed. Otherwise the same kind of data as the row above. Subject to MapTiler's own terms and privacy policy, independent of this app.
• Apps you choose when exporting a GPX file — a session's route (and heart-rate/cadence readings, if recorded) can be exported as a GPX file and shared via your device's share sheet to an app you pick, e.g. Strava or Garmin Connect. This only happens when you tap Export, to the app you select — nothing is uploaded automatically. A GPS-free session with no route to put in a GPX (e.g. a treadmill run, or a Gym session) can be exported as a FIT file instead, the same way.
• Strava, Inc. — only if you connect your Strava account (§12). A session's GPS route, duration, activity type, and heart rate/cadence (if recorded) are uploaded directly from your device to Strava's own API as a GPX file, either one at a time (the "Upload to Strava" button) or automatically if you turn on that setting. A GPS-free session (e.g. a treadmill run) has no route to send — instead duration, distance, speed over time, activity type, and heart rate/cadence (if recorded) are sent as a FIT file, once the distance is confirmed (a real treadmill reading, or your own correction after finishing). A Gym session has no distance at all, so only duration, activity type, and heart rate (if recorded) are sent, also as a FIT file. Subject to Strava's own privacy policy. Distinct from a minimal relay server the developer operates solely to complete the OAuth connection itself — that relay never receives or stores your session data, only a short-lived authorization code/token exchange; see §12.
• A relay operated by the developer, and one of three push-delivery transports — only if you separately turn on the remote location beacon (§9a). Coarse coordinates and a timestamp are sent to this relay roughly every 1–5 minutes, which briefly stores them (see §9a's retention window) and forwards a push notification to whichever Guardian(s) you're already Bluetooth-paired with, via whichever transport is active in that Guardian's own Settings (never more than one active on a given phone at once):
  • Google/Firebase Cloud Messaging — the default. Google is used solely as push-delivery transport here — no other Firebase product (Analytics, Firestore, Crashlytics) is integrated into the app — but the notification content isn't end-to-end encrypted on this path, so Google is able to read it, same as before this update.
  • UnifiedPush, via a distributor app you separately install (e.g. ntfy) — used only when Google/Firebase isn't available, or if you choose it explicitly. This is a new third party of your own choosing — whichever UnifiedPush-compatible app you have installed. The notification content is end-to-end encrypted before it reaches the distributor, so it only ever relays unreadable data plus routing metadata (an endpoint address, timing, message size) — it cannot read the coordinates.
  • A direct connection to the developer's own relay, with no third party at all (labeled "Incident Detection (internal)" in the UnifiedPush picker) — used only when neither of the above is available or chosen. Uses the same end-to-end encryption as the UnifiedPush case, though here it adds no confidentiality against the relay itself (which already holds the coordinates as their origin) — only against interception in transit, which is covered regardless by the connection's own encryption.
• incident-detection.com (the developer's own public website) — in-app update check. Once a day (switch it off in Settings if you like), the app sends a plain HTTPS request to a static file on this website to see whether a newer version has been published, and shows a dismissible notice on Home if the installed build is behind. No account and no app- or user-identifying payload: the request carries nothing beyond the usual network metadata (IP address) any web request does, the same category as the map-tile rows above. Deliberately not Google Play's own in-app update API, so it works the same with or without Google Play Services. A long press on the version line of the About screen also offers “Check for updates” (the same request, made when you ask, even if the daily check is off) and “Changes in this version”, which sends one plain HTTPS request to a static file on this website (/changelog/<your version>.json) to show the release notes of the version you have installed. Both only when you open them, with the same network metadata and nothing else.
• The device's text-to-speech engine — only if you turn on spoken navigation or spoken training cues (Settings, both off by default). The text of each navigation instruction (or, for training cues, each step heads-up and zone warning) is passed to whichever text-to-speech engine you set in Android (the Settings screen shows its name). The app itself sends nothing anywhere for this and records no audio. Whether that engine turns the text into speech on the phone or sends it to its own servers depends on the engine and the voice installed, and is governed by that engine's own privacy policy, independent of this app — to keep it entirely on the device, pick an offline voice in Android's text-to-speech settings.
• A routing relay operated by the developer, and the Valhalla routing server behind it — only when you plan a route in the in-app planner, or turn on automatic route recalculation (Settings, off by default). When you tap "Calculate route", the start, destination and stops you chose on the map (the start may be your phone's current position), the way of travelling, the instruction language and your choices to avoid ferries and toll roads are sent over HTTPS to a relay hosted on Cloudflare. With automatic recalculation on, when you stay off an imported route for several seconds, your current position, the route's destination, the positions of the remaining stops and the way of travelling are sent the same way (at most once a minute; a recalculation you choose in the navigation menu sends it once more). The relay forwards the request to a Valhalla routing server operated by the developer or, when that is unavailable, to the public Valhalla routing service run for OpenStreetMap (FOSSGIS), and returns the route. The relay does not store or log what is sent; Cloudflare keeps its usual access logs (IP address, time, URL), and the routing service sees the request without your IP address, only the relay's. Nothing is sent before you tap the button (or while recalculation is off), and a route is saved only if you choose to save it.
• No one else. No analytics, ads, or tracking.

4. System permissions and their purpose

Location source: a Settings choice determines whether location comes from Google Play Services' location client (the default, when available) or Android's own location service directly — offered as a fallback for devices without Play Services (e.g. GrapheneOS, microG-less devices). This does not change what's collected, why, or when — only which on-device API supplies it. If anything, the fallback path involves fewer Google-adjacent components than the default, not more.

Location is read either while a session is actively being tracked, or — separately — while the remote location beacon (§9a) is turned on, both cases via a persistent foreground-service notification shown throughout. No new Android permission is required for the latter: a foreground service already counts as "in the foreground" under Android's location permission model, so this does not use background location access — the same location permission row above covers both cases. The app does not request location access outside either of these persistently-notified contexts.

5. Data retention and deletion

• Data is kept locally until the user manually deletes it (deleting a specific session or an emergency contact) or uninstalls the app, which removes all of the app's data from the device.
• A Factory data reset (Settings → Reset) erases all of the app's data on the device in one step — sessions, routes, contacts, reminders, training plans, messages, photos, settings, pairings, the Strava connection and the app's encryption keys — and cannot be undone. It is confirmed by a warning, a typed word and your device's biometric or screen-lock prompt. Before erasing, the app tries to unregister your Guardian/Tracked relay links on the relay server (best effort; if you are offline you are told and may continue, in which case those links expire on the server under the normal retention rules). Reset all settings only restores default values and keeps your data, pairings and connections.
• Favourite places saved in the route planner stay on the device until you delete them one by one in the planner or uninstall the app.
• Android's Auto Backup is disabled — data is not copied to the user's Google account or anywhere else.
• Photos saved to the device gallery remain there even after the corresponding session is deleted in-app — the user can remove them manually from the gallery.
• Remote location beacon data (if turned on, §9a): the relay keeps only the most recent ~50 points (or ~24h, whichever is smaller) per person sending beacons, pruned automatically on every new point received — never a full history. A daily cleanup job also removes any device/pairing record that's had no activity in 90 days (e.g. an uninstall that never explicitly revoked access). Turning the toggle off stops new points from being sent, but does not itself delete points already on the relay before the retention window naturally clears them.
• Strava tokens (if connected) are deleted from your device immediately when you disconnect your account in Settings. This does not revoke the connection on Strava's side — that requires you to do so separately at strava.com/settings/apps — and does not remove any activity already uploaded to Strava, which you'd need to delete on Strava directly.

6. User rights

Because all data is local, the user has full and direct control: access (session history and contacts screens), rectification (editing a contact), and erasure (deleting a session/contact, or uninstalling the app).

7. Changes to this policy

Changes will be published on this page with an updated "last updated" date above.

8. Contact

For privacy-related inquiries: support@incident-detection.com

9. Guardian mode

Guardian mode and its "let someone track you" counterpart are both off by default and require you to explicitly turn them on and complete a pairing with one or more other people's devices — a Ward's phone can be paired with more than one Guardian at once, each tracked independently.

• What's exchanged during pairing: a display name (chosen freely by each person) and a randomly-generated identifier — not your phone's real Bluetooth hardware address, and truncated before transmission so the receiving phone can't reconstruct the sender's full internal id.
• What's exchanged afterward: only the identifier, broadcast at short range (Bluetooth Low Energy) so each paired Guardian's phone can tell it's still nearby. No GPS location, contacts, or any other app data is exchanged between the two phones at any point — the only data channel between them is this local Bluetooth broadcast.
• GPS route recording: while at least one standing pairing is actively in range (not the single-session mode below), both the Guardian and the Ward record their own GPS route locally for the duration, saved on that phone the same way any other tracked activity is — this route is never transmitted to the other phone or anywhere else. It exists so each phone can show a marker of roughly where it last had confirmed Bluetooth contact with each paired Guardian, if that contact is lost — the Ward keeps one continuous route regardless of how many Guardians are paired, with an independent last-contact marker for each one.
• Heart-rate monitoring (Ward side): if you've paired a heart-rate sensor and turned on heart-rate alerts in Settings, "let someone track you" also monitors your heart rate the whole time it's broadcasting, not only while a Guardian is actually in range, and can trigger the same kind of alert and emergency notification on its own if it detects a sustained abnormal reading. This is the same optional heart-rate monitoring described in §2, just also active during standing or session-scoped Ward-side broadcasting, not only during a recorded session.
• Ending a pairing: from Settings, you can turn off broadcasting entirely or remove a single paired Guardian ("forget"); a Guardian can stop an active watching session from that session's own screen. All of these, along with "Revoke access for everyone" below, first require confirming it's actually you via your phone's own screen lock (fingerprint, face, PIN, or pattern) — so someone else holding your unlocked phone can't silently disable a safety feature you were relying on. This app never sees any biometric data — that confirmation happens entirely within Android/your device's own secure hardware, and the app only ever receives a yes/no answer back. Dismissing a soft lost-signal alert ("I'm OK") and escalating to emergency contacts ("Get help now") both stay a single tap, deliberately ungated, since requiring this confirmation there would work against the feature's own safety purpose. The Ward additionally has a "Revoke access for everyone" control that invalidates every past pairing at once by changing that phone's broadcast identifier, for cases where simply removing pairings isn't enough reassurance (e.g. a former Guardian's phone might still have the old identifier remembered).
• Turning it on for a single session: instead of the standing Settings toggle, the app can also offer to turn "let someone track you" on for just the session about to start, whatever the activity, when a Guardian is already paired but broadcasting is otherwise off — so that if something happens, whoever reaches the location marked by an alert can use the phone's Bluetooth signal to search the immediate area (e.g. off-trail). The same exchange described above applies; it turns back off automatically once that session ends. This mode does not send the automatic "lost contact" alert described next — the paired Guardian isn't expected to be in Bluetooth range for the whole session, so only the on-demand "find my phone" feature (triggered by the Guardian, not automatic) is active.
• If contact is lost: whichever side notices (typically the Ward, so that their own already-configured emergency contacts — not the Guardian's — are the ones notified) gets a countdown to confirm they're safe before an automatic SMS/call goes out, exactly like the crash-detection flow described in §2. Doesn't apply to the single-session mode above. Responding "we're together" to that prompt only silences future alerts for that specific Guardian until you're back in range of each other — it doesn't end the pairing, so you don't need to re-pair after a false alarm.
• Restarting after an app update or device restart: if "let someone track you" was on, the app automatically resumes broadcasting after either of these events, since they can otherwise silently stop it while Settings still shows it as on. This only ever resumes a state you already explicitly turned on — it never turns broadcasting on by itself.

9a. Guardian mode — remote location beacon (optional, off by default)

A second, independent tier layered on top of everything in §9. Where §9 is strictly local (Bluetooth only, short range, no server), this tier is the opposite: it exists specifically for when the two phones are out of Bluetooth range, by relaying sparse location updates over the internet.

• Fully separate opt-in. A dedicated toggle, off by default, independent of every other Guardian mode setting in §9 — turning on "let someone track you nearby" (§9) does not turn this on, and vice versa.
• No separate pairing. This tier does not introduce a new pairing step — it reuses whichever Bluetooth pairing(s) already exist from §9. Turning the toggle on links to every Guardian already Bluetooth-paired at that moment; forgetting a Bluetooth pairing (either side) also cuts off this tier's access for that person.
• What's sent, and how often: while turned on, your device takes a GPS fix roughly every 1–5 minutes and sends it — latitude, longitude, and a timestamp, nothing else — to a relay server operated by the developer.
• What identifies your device to the relay: the same randomly-generated, truncated identifier already described in §9 for Bluetooth pairing — reused as-is, not a new identifier. The relay never receives a name, phone number, or any other identifying detail; it only ever sees this opaque id, coordinates, a timestamp, and whichever push-delivery credential the active transport needs (see below and §3).
• How the linked Guardian finds out: the relay forwards a push notification to every Guardian currently linked, via whichever push-delivery transport that Guardian's own phone has set up in Settings — Google/Firebase Cloud Messaging by default, or, if unavailable or chosen instead, UnifiedPush (via a distributor app installed on that phone) or a direct connection to the developer's own relay with no third party involved at all. See §3 for what each transport exposes to whom — only the Google/Firebase path can read the notification's actual content; the other two only ever see encrypted data (or, for the direct-relay path, no outside party at all). Only one transport is ever active on a given phone at once.
• Retention: unlike the Strava relay described in §12 (which stores nothing at all), this relay does briefly store data — see §5's retention entry for the exact window (~50 most recent points or ~24h, whichever is smaller, auto-pruned; a 90-day cleanup for abandoned pairings).
• Turning it off: stops new points from being sent immediately. Already-sent points are removed from the relay according to the retention window above, not instantly.
• Incident alerts through the app (optional, off by default, its own toggle on the Emergency contacts screen). A phone with no working SIM card but a Wi-Fi or data connection can still reach people. When this is on, an emergency contact can be linked to one of the Guardian phones you have already paired (§9); whenever an alert is triggered the incident type, the time and — if known — the location and heading are also sent, in addition to the SMS, to the relay, which forwards them to the linked Guardian phone(s) only (never to a Guardian who was not linked to a contact, and never to anyone who is not already linked through §9a). It does not need the remote location beacon above to be on: turning the alerts on registers this phone with the relay (as the sending side) and links the Guardians it is already paired with, the same registration the beacon performs, but without sending any location in advance. The same single active push-delivery transport is used; as with location points, only the Google/Firebase path can read the alert's content. The relay keeps a delivery queue of the most recent messages per receiving device (at most 50, shared with the location points' queue, cleared automatically), which is what the direct-connection transport reads; nothing else is stored. The contact ↔ Guardian link is kept only on this device and is removed when the Guardian is forgotten.

10. Check-in mode

Check-in mode is a different way to use the app: instead of tracking a route or motion at all, it periodically asks whether you're OK, at an interval you choose.

• No GPS route, no motion sensors — the opposite of the activity types described in §2's intro. Nothing is tracked while a check-in session is running beyond the timer itself.
• If a check-in goes unanswered, the app takes a single location reading (not a continuous track) and can send the same kind of emergency alert described in §2, to your own already-configured emergency contacts.
• Off by default, like every other mode — you choose it explicitly from the activity picker before starting a session.

11. Gym mode

Gym mode is for workouts where your phone is set down nearby rather than carried — like Check-in mode, it doesn't track a route or motion at all, but it uses a different way of checking on you.

• No GPS route, no motion sensors — the opposite of the activity types described in §2's intro. Nothing is tracked while a Gym session is running beyond the self-check timer itself, and heart-rate readings if you pair a sensor (see §2).
• You confirm you're OK yourself, any time, with a button on the session screen — there's no periodic prompt to answer, just a running 15-minute window that resets every time you tap it.
• If 15 minutes pass without a confirmation, or a paired heart-rate sensor detects a sustained abnormal reading, the app takes a single location reading (not a continuous track) and can send the same kind of emergency alert described in §2, to your own already-configured emergency contacts.
• Off by default, like every other mode — you choose it explicitly from the activity picker before starting a session.

12. Strava upload (optional)

Connecting a Strava account is entirely optional and off by default — this section only applies if you explicitly choose to connect one from Settings.

• What's uploaded: only sessions you choose — either one at a time via the "Upload to Strava" button on a session's summary screen, or automatically for every eligible session if you separately turn on that setting. For a real GPS session, uploaded data is the same route/duration/heart-rate/cadence data already described in §2, sent directly from your device to Strava's servers as a GPX file. A GPS-free session (e.g. a treadmill run) has no route to send — instead duration, distance, speed over time, activity type, and heart rate/cadence (if recorded) are sent as a FIT file, and the distance only once it's confirmed (a real treadmill reading, or your own correction after finishing). A Gym session has no distance at all — only duration, activity type, and heart rate (if recorded) are sent, also as a FIT file.
• What's never uploaded, regardless of settings: Check-in and Guardian sessions (no real workout to upload), and Car and Motorcycle sessions (Strava is a fitness/exercise platform — driving or riding isn't a workout, even though the app tracks it for the same crash-detection purpose as everything else).
• Connecting: opens Strava's own login/consent screen in your browser (standard OAuth). A minimal relay server, operated by the developer solely to complete this connection, briefly handles the authorization code and resulting access/refresh tokens on your behalf — it never logs, sees, or stores your session data, and doesn't persist anything at all. Your own OAuth tokens are stored only on your device, encrypted.
• Disconnecting: available any time in Settings — deletes the stored connection on your device immediately. Does not currently revoke the connection on Strava's side or remove activities already uploaded; both require action directly at strava.com/settings/apps or Strava's own activity deletion.

13. Reminders

Reminders are optional health/activity prompts, unrelated to the crash-detection modes above — a curated predefined set (drink water, take vitamins, stretch your neck, go for a walk, and more) plus any you create yourself, either standalone (running all day, independent of any tracked activity) or tied to a specific activity type (only while a matching session is being tracked).

• Off by default. Every predefined reminder ships turned off — you opt in from the Reminders tab in Settings. A custom reminder you create is enabled immediately, since creating one is itself an explicit opt-in action.
• What's stored: which reminders are turned on, their schedule (specific times of day, or an interval — every N minutes, optionally restricted to a daily hour range for a standalone reminder), and whether escalation is turned on for that reminder. All of this stays on your device — nothing about a reminder's configuration or schedule is ever sent anywhere.
• How a reminder shows: as a notification, or — for a standalone reminder or one during a Gym session — a full-screen prompt, the same style as Check-in's (§10). You confirm with a tap.
• If escalation is on for a reminder and you don't respond in time, or you tap "Get help now" yourself (available on every full-screen reminder prompt, regardless of that reminder's own escalation setting), the app takes a single location reading (not a continuous track) and can send the same kind of emergency alert described in §2, to your own already-configured emergency contacts — exactly like Check-in and Gym mode above.
• Surviving a device restart: a standalone reminder's schedule is restored automatically after your device restarts, since Android clears all scheduled alarms on reboot — see §4's "Receive boot completed" permission row. An activity-linked reminder needs no equivalent handling, since it's only ever active during a session that itself doesn't survive a restart either.
• No GPS route or motion tracking of its own. A reminder tied to an activity only fires while that activity's own session is already being tracked (§2) — reminders themselves add no additional location or motion data collection beyond the single-reading escalation case above.

14. Training plans (optional)

Training lets you follow a structured workout during a Bike or Run session — either one of the app's built-in plans, or one you import as a FIT workout file, the format most fitness watches and coaching tools use. Unrelated to crash detection — nothing here affects it or triggers an alert on its own.

• What's stored: a plan's steps, their duration, and any target (heart rate, cadence, power, or speed) — either an absolute range, a zone number, or a percent of your max heart rate — plus any free-text notes copied from an imported file's author. After a session, a record of what you actually trained against (which step, its target, and when) is kept alongside that session's own stats. All of this stays on your device.
• Heart-rate zone targets: resolving a "zone 3" or "80% of max" style target to a real beats-per-minute range needs your max heart rate and per-zone percent boundaries, which you can optionally set in Settings' Profile tab. This is the same kind of health-related data as the heart-rate readings described in §2, and is used only to display your target range — it has no effect on crash detection.
• Importing a FIT file works the same way as importing a GPX route elsewhere in the app — you pick the file through Android's own file picker, and the app reads it directly. No new permission is needed for this.
• Nothing here is uploaded anywhere. A training plan, once imported or created, and the record of what you trained against, are never included in a GPX/FIT export or a Strava upload (§12) — those only ever contain the session's own recorded route and stats, not the plan you followed alongside it.