Compare their responsibilities
| System | Where it operates | What it is for |
|---|---|---|
| Android Keystore provider | On the Android device | App cryptographic operations with controlled keys |
| JKS or PKCS12 signing store | Developer or CI environment | Signing release or upload artifacts |
| Play App Signing | Google's distribution workflow | Managing APK signing for Play delivery |
An APK cannot retrieve the private production signing key from its embedded certificate. Likewise, creating a device-side Keystore alias does not create a key that can sign the next Play release. Keystore system, app signing.
Use runtime Keystore for a defined security purpose
Typical uses include generating a non-exportable encryption or signing key and applying authorization restrictions appropriate to the feature. The app can request cryptographic operations without receiving raw private-key material in the usual way.
That protection does not automatically secure every byte of application data. You still need a suitable encryption mode, correct nonce/IV handling, safe storage of ciphertext and a policy for authentication or key invalidation.
Design the data lifecycle before writing code
Decide what happens when the app is reinstalled, the device is restored, a user changes authentication settings or a key becomes unavailable. A secure key that cannot decrypt restored ciphertext requires an intentional recovery path—not a crash or silent data loss.
For account-backed data, reauthentication or resynchronization may be more appropriate than retaining a reusable password locally. Do not add encryption as a substitute for questioning whether the secret needs to be stored at all.
Avoid outdated abstraction assumptions
Android's current cryptography guidance notes the deprecation of the Jetpack security-crypto APIs. Do not copy an old EncryptedSharedPreferences example and label it the default current recommendation without evaluating the migration and platform requirements.
Prefer supported platform primitives and a design reviewed for the application's threat model. A few lines of encryption code are not a complete secure-storage implementation.
Inspect the right evidence
An APK signing-certificate viewer can identify the package's public signing metadata, not the security level of runtime-generated Keystore keys. Runtime key properties need to be checked on the actual device. APKLint can help review code or sensitive API usage, but it cannot certify hardware-backed key storage from a static certificate report.
Name the key according to the job it performs
Imagine a team discussing a lost key during a release. First determine whether they mean the upload credential in CI, the distribution signing identity or a key generated by the app on one device. Those losses have different owners and recovery paths. A device-side alias cannot replace an upload key, and a certificate extracted from an APK contains no private signing material.
The Android Keystore guide describes runtime keys and their authorized operations. Keep a small key inventory with the purpose, alias or build-system reference, creation location and recovery owner. Avoid putting private values in that inventory; the goal is to identify responsibility without creating another secret store.
Follow one encrypted note through its lifecycle
For a local-note feature, generate or retrieve the intended runtime key, encrypt a synthetic note and retain the ciphertext metadata required by the chosen design. Restart the process and confirm that the same supported key entry can open the record. A successful immediate encrypt/decrypt operation does not test persistence or alias lookup.
Now simulate a missing key entry in a disposable test installation. The app should distinguish this condition from an empty note and follow its recovery policy. Generating a new key under the same alias does not make old ciphertext decryptable. Silently replacing the record would turn a key-lifecycle failure into unexplained user data loss.
Review how an application update changes the record format. Store a version that allows the app to select the proper interpretation, and migrate only after reading and validating the old record successfully. Preserve recovery options when the migration cannot complete; a new algorithm name in source code is insufficient evidence that existing records remain readable.
Use current cryptography guidance when selecting supported primitives and libraries. Document which device tests establish runtime behavior and which build checks establish release signing. Keeping those evidence streams distinct prevents an APK certificate report from being misrepresented as proof that a user's local encryption key is protected or recoverable.
Sources and further reading
- Android Developers: Android Keystore system
- Android Developers: Cryptography
- Android Developers: Sign your app
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
