Android App Security · Storing Data Safely · Lesson 2 of 5

The Android Keystore

Learn how Android guards encryption keys so even a hacked app can't copy them.

A safe for keys

Encryption scrambles data so only someone with the right key can unscramble it. A key is just a long secret number. That raises an awkward question for app developers: if QuickNotes encrypts your notes, where does it keep the key? If the key sits in a file right next to the notes, anyone who gets the files gets the key too.

Android's answer is the Android Keystore, a system service that holds keys for apps. An app asks the Keystore to create a key, then asks it to encrypt, decrypt or sign data with that key. The app never sees the key itself. Google's documentation calls the key material non-exportable: it never enters the app's own process. The app hands data to a system process, and only the result comes back. Each key belongs to the app that made it.

This changes what an attacker can do. If malware takes control of an app while it's running, it might be able to use the app's keys on that phone, for as long as it stays in control. It can't copy the keys out to use somewhere else.

On many phones the protection goes deeper. Keys can be hardware-backed, meaning they live inside secure hardware that's separate from the main Android system:

• A Trusted Execution Environment (TEE) is an isolated, locked-down area of the phone's main processor that runs its own tiny operating system.
• StrongBox, supported since Android 9, is a separate secure chip with its own processor and storage, built to resist physical tampering. It's slower and supports fewer types of keys, and Google notes most apps don't need it.

When a key is hardware-backed, its key material is never exposed outside that secure hardware, even to Android itself.

Keys that need you

A key the app can use any time is still at risk if the phone is unlocked and something goes wrong. For extra protection, a developer can create a Keystore key that only works after user authentication, meaning you prove it's you with your screen lock PIN, pattern or password, or with a strong biometric such as a fingerprint or face unlock that meets Android's strong biometric rules.

The developer picks how strict the key is:

• Unlocked for a short time after you authenticate, for example for 30 seconds.
• Unlocked for a single operation, so every use needs a fresh fingerprint or PIN. A banking app might do this before approving each payment.

The app shows the standard system prompt, called BiometricPrompt. Your fingerprint itself is never handed to the app. The secure hardware checks it and tells the Keystore whether to allow the key.

There's a useful twist. By default, a key that accepts only biometrics is invalidated when someone adds a new fingerprint or face to the phone. That way, a person who learns your PIN can't enroll their own finger and then unlock your banking app's key. Developers can turn this off, but the default favors safety.

You may come across an older library called Jetpack Security, which offered EncryptedSharedPreferences, an easy way to encrypt an app's settings using a Keystore key. In 2025 Google deprecated all of that library's APIs, pointing developers to the platform's own tools and direct use of the Android Keystore. Apps that already use it keep working, but new apps shouldn't start with it.

The big idea for this course: keep secrets in the Keystore and data in private storage, not secrets in plain files.