Android encrypts the device’s storage at rest, but that protection ends when the phone is unlocked. After that, anything your app wrote in plain form can be read by a rooted process, copied by a backup or pulled from a cache. Data that identifies a person, authorises an action or carries regulated content needs its own encryption. Otukan encrypts app files, databases and preferences with keys generated in Android Keystore, hardware-backed where the device supports it, and decrypts only at the step that needs the data, after runtime checks pass. This page covers Android only; iOS storage is protected separately.
Data inventory
Encryption starts with knowing what the app writes. Otukan runs the inventory with your engineers, because the surprises are usually in caches and third-party libraries rather than in the code your team wrote.
| Location | Typical content | What Android does by default | What Otukan adds |
|---|---|---|---|
| App-private files | Documents, downloads, exported reports | Sandbox by app identity; at-rest disk encryption | Per-file encryption with Keystore-protected keys |
| Local databases | Messages, transactions, offline records | Same sandbox and disk encryption | Database encryption with a wrapped data key |
| Key-value preferences | Tokens, user IDs, feature flags | Stored as plain values in the sandbox | Encrypted entries; sensitive tokens moved out of plain storage |
| Response and web view caches | Account pages, images, API responses | Kept until cleared by the app or system | Encryption or clearing at sign-out, per your rule |
| Shared storage | Files other apps can open | Readable by apps with the right access | A review of what should never leave private storage |
Libraries inside your app write data too. The inventory includes analytics, crash reporting and web view components, so nothing sensitive sits outside the plan.
Deciding what to encrypt
Not every byte needs the same treatment. Otukan helps your team sort stored data into three groups. Data that identifies a person, authorises an action or falls under a retention rule is encrypted. Data the app can fetch again, such as cached pages, is cleared at sign-out or after a set period of inactivity you define. Data with no sensitivity, such as layout preferences, stays as it is. Sorting first puts encryption where it protects something and leaves the rest of the app untouched. The classification is recorded, so a reviewer can see why each location was treated the way it was.
Key lifecycle
Origin
Keys are generated inside Android Keystore on the device. They are not shipped in the app package and not fetched from a server in plain form, so there is nothing to extract from the download.
Storage
Keystore keys cannot be exported by the app. On devices with a trusted execution environment or a dedicated security chip, key material stays in that hardware. Data keys are stored only in wrapped form.
Use
Keys can carry conditions, such as requiring a recent user authentication before they unlock. Otukan applies those conditions to the data that deserves them, such as offline records or stored documents.
Rotation
Rotation replaces the Keystore key and re-wraps the data keys under it. Your team decides the trigger, and the test plan checks that rotation survives updates and interrupted sessions.
Runtime boundary
Encrypted data is only as safe as the moment it is decrypted. Otukan draws that boundary clearly.
| Moment | Data state | Who can reach it | Otukan control |
|---|---|---|---|
| App closed | Encrypted on disk | Only code running as your app, through Keystore | Keystore-bound keys |
| App open, idle | Encrypted on disk; keys unused | Your app only | Decryption deferred until needed |
| Sensitive step | Decrypted in app memory | Your app, or a hook or debugger if present | Runtime checks before decryption; memory clearing after use |
| Sign-out | Caches and keys removed as set | No protected data left to decrypt | Clearing rules and key deletion |
Testing follows the same boundary. On supported physical devices, your engineers and Otukan confirm that protected files are unreadable when copied off the device, that a fresh install and an update keep data accessible to the genuine app, that a restore leads to clean re-enrolment, and that sign-out removes what it should.
A hooked or debugged process can read what the app itself can read, so Otukan checks the runtime before handing over plaintext. For stored secrets, see mobile app secrets protection. The wider Android picture is covered on Android app security.