Wakey Wakey — Privacy Policy
Last updated 6 October 2026
Wakey Wakey is an alarm clock that can also let someone you trust ring your
phone. This policy describes what that requires us to handle, what we keep, and
for how long. It covers the Android app com.undeadstudio.wakeywakey
and the relay service it talks to.
The short version. Your alarms live on your phone. We never see them. The only data that leaves your device is what is needed to deliver a wake-up push to a phone that is not yours: a push token, a hashed PIN, and the message itself, which passes through and is not stored. There is no advertising, no analytics, no tracking, and nothing is sold or shared.
1. What stays on your phone
Your alarms — times, labels, repeat schedules, ringtone choices, snooze settings, and every app preference — are stored locally on your device and are never transmitted. Uninstalling the app deletes them. We have no copy and no way to retrieve them.
2. What is sent, and why
2.1 Remote alarms (only if you turn them on)
Remote alarms are off until you enable them. While enabled:
| Data | Why | Kept for |
|---|---|---|
| Firebase Cloud Messaging registration token | The address Google delivers the wake-up push to. Without it, a remote alarm cannot reach your phone. | Up to 90 days after your device last contacts the relay, then deleted automatically |
| Your PIN and, if you set one, its password | How a sender addresses an alarm to you. | Stored only as a keyed hash — see §3 |
| Display name (optional) | Shown to a sender so they can confirm they typed the right PIN. Leave it blank and nothing is stored. | With the PIN record |
| A device public key | Signs requests so that only your device can act as your device. | Up to 90 days after last contact |
ANDROID_ID |
Abuse prevention only: it limits how many alarms one device can send per day, and it is the only value that survives a reinstall. It is not an account identifier and is never used to build a profile. | Never stored in its original form — see §3 |
2.2 Alarm messages
When someone sends you an alarm they may attach a short message, which appears on your lock screen. That text passes through the relay in order to reach your phone. It is not written to storage, not logged, and not readable after delivery. Once the push is handed to Google for delivery, the relay retains no copy.
When your phone reports back that an alarm was dismissed, snoozed, or missed, that outcome is relayed to the sender using a single-use handle that expires after 15 minutes and is deleted the moment it is used. The outcome itself is not stored.
2.3 Signing in with Google (optional)
Signing in is optional. It does two things: it unlocks paid features, and it keeps your code when you reinstall the app or move to a new phone — that second one works on the free tier too. Every other function of the app, including receiving remote alarms, works fully signed out.
If you sign in, Firebase Authentication receives your Google account identifier, email address, and display name. We use these only to recognise you across devices and to attach any subscription to the right person. We do not email you and there is no mailing list.
While you are signed in, we store a link between your account identifier and your code, so that signing in on another device can give you the same code back. A code belongs to one device at a time: signing in on a new phone moves it there and the previous phone is issued a different code. Signing out leaves your code stored against your account and gives that phone a temporary one instead.
2.4 Purchases
If you buy a subscription, the purchase is processed entirely by Google Play. We never receive your payment details — not your card number, not your billing address. We receive a purchase token that lets us confirm with Google that the subscription is genuine and current.
2.5 Crash diagnostics
The app uses Firebase Crashlytics to report crashes: the error, the stack trace, the device model, the operating system version, and an installation identifier. These reports contain no alarm content, no messages, no PIN, and no password. They exist so that a crash can be fixed.
2.6 Share links
When you share your credentials via a link, the credential travels in the
part of the URL after the #. Browsers never send that portion to a
server, so the credential in a share link never reaches us. The
landing page loads no external resources and sends no credential to our relay.
If the recipient taps Get the app, the page passes the shared
PIN and password to Google Play in the installation link. After installation,
Wakey Wakey retrieves that install referrer to fill the Send form once. This
does not send an alarm automatically. If the handoff is unavailable, the
recipient can reopen the original shared link after installing.
3. How your PIN, password and device ID are protected
None of these is stored in a form that can be read out of our database:
- Your PIN is stored as a keyed hash under a server-side secret. The relay looks you up by recomputing the hash; the hash cannot be turned back into the PIN.
- Your password is stored as a keyed hash under a different server-side secret.
- Your device identifier is hashed on arrival under a server-side secret. The original value is never written down.
One exception, if you sign in. Signing in lets you keep your PIN and its password when you change phones, and giving them back to a new phone means we have to be able to reproduce them — a hash alone could not. So for signed-in users only, we additionally store both encrypted under a server-side key that is not part of the database. A copy of the database on its own does not reveal them. We hold that key, so unlike the hashes above this is data we could in principle decrypt; we use it for one purpose, which is handing your credentials back to you when you sign in. Signed-out users have no such copy stored at all.
The password is kept this way for the same reason as the PIN and not as an extra: returning the PIN on its own would leave your new phone generating a different password, which would stop everyone you had already shared with from being able to wake you.
Someone who obtained a complete copy of our database would hold neither half of any credential. Your push token is never disclosed to any other user — a sender addresses you by PIN and never learns where the push actually goes.
All traffic between the app and the relay is encrypted in transit using TLS, and every request is cryptographically signed by your device.
4. Retention
| Record | Lifetime |
|---|---|
| Device registration | 90 days from last contact, refreshed while you use the app |
| PIN reservation (free tier) | Up to 7 days. The week runs from when your phone first claimed a code, and a replacement inherits what is left of it rather than starting a new one |
| PIN reservation (paid tier) | Kept while your subscription is active. If it ends, 30 days after Google Play finishes trying to renew it — see below |
| Link between your account and your code | Deleted with the code it points at |
| Alarm outcome handle | 15 minutes, or until used |
| Replay-protection records | 2 minutes |
| Alarm message text | Not stored |
What "kept while your subscription is active" means in days. A paid code does not expire while you are subscribed, however long that is, and signing out does not start any clock — your code is waiting for you when you sign back in. If a payment fails, Google Play spends up to 60 days trying to recover it, and we keep your code untouched for all of that time so a recovered payment restores everything. Only once Google reports the subscription has finally ended do we start a 30-day countdown, after which the code is deleted. Resubscribing at any point before that keeps it. That is a maximum of 90 days from the first failed payment.
Expiry is automatic. Nothing depends on us remembering to delete it.
5. Deleting your data
To stop remote alarms reaching you: open the app, go to the Remote tab, and turn off Allow remote alarms. This takes effect immediately and does not depend on the network: your push token is erased from our records, and from that moment nobody can ring your phone with your code — anyone who tries is told the code reaches nobody.
Your code itself is kept, on purpose, so that turning the switch back on gives you the same one. Otherwise every person you had shared it with would have to be given a new code each time you used the switch. What is kept is the same keyed hash described in §3, with no push token attached to it; on the free tier it deletes itself when its seven days are up, and on the paid tier it is governed by the retention table in §4. If you would rather not wait, Get a new PIN on the same screen deletes the old record straight away.
To delete everything we hold for your device: email hammadmanzoorsyed@gmail.com. See below for accounts. Uninstalling also works on its own timescale — with no device contacting us, every record described here expires by itself within 90 days.
To delete local data: uninstall the app. Alarms and settings are stored only on your device.
To delete your account in the app: open the Remote tab, expand Account & privacy, choose Delete account, review the confirmation, and confirm. The relay removes the account and Firebase authentication principal immediately; the app then clears account settings and recent-recipient history on this phone while leaving your local alarms in place.
To request deletion without the app: email hammadmanzoorsyed@gmail.com from the address you signed in with. We will delete the authentication record and associated data within 30 days. Purchase records that Google requires for tax and accounting are held by Google Play, not by us.
What deleting your account removes: the account record itself, the code it owns together with both encrypted halves of that credential, this device's registration and push token, and your display name. On your phone, uninstalling removes the local copies and the list of people you have recently woken.
What it deliberately does not remove, and why. A small number of anti-abuse counters are keyed to a hash of your device identifier rather than to you: the daily limits on sending alarms and on claiming new codes, and the record of when your free week started. They contain no code, no password, no name and no message. They are kept because deleting them on request would turn account deletion into a way to reset those limits at will, which is the exact thing they exist to prevent. They expire on their own within 90 days.
A Pro subscription is separate, and only you can cancel it. Subscriptions are sold and billed by Google Play, not by us, and we cannot cancel one on your behalf. You can delete your Wakey Wakey account immediately, but deletion does not cancel a subscription or stop Google charging you. You are responsible for managing it in the Play Store; Google's instructions are at support.google.com/googleplay/answer/7018481 .
If you later sign in with the same Google account, Firebase creates a new Wakey Wakey account. Deleted credentials, preferences and history do not return. An eligible Google Play purchase can be restored to that new account because the purchase itself is held by Google rather than by Wakey Wakey.
If you do nothing at all, every record described above expires on its own within 90 days of your last use — including a paid code, measured from the point your subscription ends rather than from your last use, since a code you are still paying for is not abandoned data.
6. Who else is involved
We do not sell your data, and we do not share it with anyone for advertising or any other purpose. Three providers process data on our behalf in order to make the service work:
| Provider | What for |
|---|---|
| Google (Firebase Cloud Messaging) | Delivering the wake-up push to your device |
| Google (Firebase Authentication, Crashlytics, Google Play) | Optional sign-in, crash reports, subscription billing, and shared credentials passed through Google Play when installing from an invitation |
| Cloudflare | Running the relay service and storing the records in §4 |
7. Children
Wakey Wakey is not directed at children under 13 and we do not knowingly collect data from them. If you believe a child has provided us with data, contact us and we will delete it.
8. Your rights
Depending on where you live, you may have the right to access, correct, export or delete your personal data, and to object to its processing. Section 5 covers deletion directly. For anything else, email hammadmanzoorsyed@gmail.com and we will respond within 30 days.
9. Changes to this policy
If this policy changes materially, the date at the top changes and the updated version appears at this address. Continuing to use the app after a change means accepting it.
10. Contact
Questions, deletion requests, or anything else: hammadmanzoorsyed@gmail.com
See also the Terms of Service.