Privacy Policy
Better Backups runs entirely on your Android device and the cloud accounts you connect. This page describes the data the app and this website do and do not handle.
No hosted account
Better Backups does not require you to create an account with us. There is no central server holding your backups. The app speaks only to your device's local storage and, if you enable them, the cloud accounts you have personally signed into.
No invasive permissions
The app does not request root, the Accessibility Service, or any other invasive permissions. It uses Android's Storage Access Framework, which means you pick the specific folders to back up — Better Backups cannot see anything else on your device. The other permissions it asks for are INTERNET (to talk to destinations), FOREGROUND_SERVICE and FOREGROUND_SERVICE_DATA_SYNC (upload progress notifications), POST_NOTIFICATIONS on Android 13+, SCHEDULE_EXACT_ALARM (schedule accuracy), ACCESS_NETWORK_STATE (Wi-Fi-only enforcement), and the optional USE_BIOMETRIC (chat-archive unlock).
Cloud destinations use the narrowest scopes available
The app supports five destination types and uses each provider's most restrictive scope:
- Google Drive — the official sign-in flow with the
drive.fileOAuth scope. That scope only lets the app see files it has created itself. The app cannot read your existing Drive contents, your Gmail, your Photos, or anything else in your Google account. - Dropbox — backups are written to a dedicated
Apps/Better Backupsfolder. The app cannot see the rest of your Dropbox. - OneDrive — backups are written to a dedicated app folder under
Apps. The app cannot see the rest of your OneDrive. - WebDAV — your server, your credentials, your folder. The app only talks to the URL you supply, and pins the server's TLS certificate on first use so self-signed setups stay verifiable.
You can revoke any cloud destination's access at any time from the provider's own settings, and the app's Destinations page lets you disconnect or remove a destination locally.
Credentials live in the Android Keystore
Dropbox tokens, OneDrive and Google access tokens, and WebDAV usernames and passwords are stored in EncryptedSharedPreferences, backed by the Android Keystore. On supported phones, the Keystore is hardware-backed (StrongBox or TEE). A copy of the app's data folder, on its own, will not reveal these secrets.
Trust-on-first-use TLS pinning for WebDAV
The first connection to a WebDAV server captures the leaf-certificate SHA-256 fingerprint and pins on it. Every later request must match that exact fingerprint, even if a different but otherwise valid certificate would have been accepted by the system trust store. This means self-signed setups (typical for home Synology and ad-hoc Nextcloud deployments) stay safely verifiable without you having to disable TLS validation. If your server's certificate is genuinely renewed, you re-pin it explicitly on the destination's Edit page.
Local backups stay on your device
Local backups are written to the folder you grant the app access to. They do not leave the device unless you have also enabled a cloud destination. Disabling a cloud destination stops further uploads but does not delete copies that already exist in that account — you are in control of those files.
WhatsApp and Telegram backups stay in the apps' encryption envelopes
Native app profiles read the source app's data files (for example WhatsApp's msgstore.db.crypt15) directly via the Storage Access Framework and copy them as-is. The files stay in the source app's own encryption envelope — Better Backups does not decrypt them, and your WhatsApp encryption key (or Telegram passcode) never enters the app.
Chat archives passphrase is not stored in plaintext
Imported chat exports live in an on-disk database encrypted with industry-standard, audited encryption. The key is derived from a passphrase you choose, using a slow, deliberately expensive process designed to make guessing the passphrase impractical.
By default the passphrase is required again every time the app starts. If you forget it and you have not enabled biometric unlock, the archives cannot be recovered — by design.
Biometric unlock for Chat Archives
You can opt in to unlocking Chat Archives with the same fingerprint or face credential you use to unlock your phone. The app never receives your fingerprint, face image, or any biometric template — those are handled entirely by Android's biometric subsystem. The wrapping key never leaves the device's secure hardware (StrongBox or TEE); the app can only use it after a successful biometric prompt. Disabling biometric unlock wipes the wrapped passphrase from app storage. Changing your screen lock, adding or removing fingerprints, or factory resetting the device may invalidate the Keystore key by design.
Chat archives travel with your backups
If you enable Chat Archives as a media kind on a destination, the encrypted archive files are uploaded alongside the rest of the backup. The destination only ever sees encrypted data: without your passphrase, nothing inside the archive can be read by anyone, including Code Aspect or the cloud provider.
Restoration is initiated by you
Restoring a backup is always an explicit action you take inside the app. The app copies files back into the source folder, and — for native app profiles such as WhatsApp — the source app then performs its own restore step when it is next set up. Better Backups does not perform restores automatically without your input.
No analytics or behavioural tracking
The app and this website do not include a marketing analytics pipeline, behavioural profiling, or a user account database. We do not sell, share, or monetise your data.
This website
This site is a static informational site. It serves no cookies of its own, runs no tracking scripts, and does not contact third-party advertising or analytics services. Web fonts are loaded from Google Fonts, which is subject to its own privacy policy.
Changes
This page can be updated as the app evolves. Material changes will be reflected here. Questions can be sent to hello@codeaspect.uk.