Define the requirement precisely
“Hardware-backed” can refer to different protected execution environments. StrongBox, where supported, is a distinct option with capability and performance constraints. Your application should state whether hardware backing is mandatory, preferred or simply recorded as a risk signal. Keystore documentation.
Do not infer this property from the device brand, Android version or the presence of an APK signing certificate. Runtime key storage and package signing are separate concerns.
Inspect the generated key's properties
Use the platform's KeyInfo APIs for the key type and supported OS level. On newer API levels, inspect the reported security level rather than relying only on older boolean checks. Consult the current reference and guard version-specific APIs appropriately.
Record the result in a test report without exporting private-key material. A request to generate a StrongBox-backed key can fail on unsupported devices or for unsupported parameters; handle that failure deliberately.
Choose a fallback policy before shipping
| Product requirement | Sensible behavior |
|---|---|
| Hardware backing is mandatory | Explain incompatibility or restrict the sensitive feature |
| Hardware backing is preferred | Fall back only under an explicitly approved policy |
| Security level informs risk | Report the property to the appropriate decision layer without claiming absolute trust |
Silently retrying with weaker storage while still displaying “hardware secured” misrepresents the application's protection.
Remember what hardware does not solve
Hardware-protected keys do not automatically prevent an authorized process from asking the key to perform an operation. Authentication requirements, allowed purposes, validity conditions and application logic still matter.
Likewise, ciphertext may be copied, restored or corrupted. Your data lifecycle needs recovery and error handling independent of where the key resides. Cryptographic design guidance.
Validate on real supported devices
Test key generation, authorized use, authentication changes, process restarts and recovery. Include a device where the preferred hardware capability is absent so the fallback or refusal path is exercised, not merely documented.
APKLint can support a code or API review, but a static APK report cannot establish the runtime protection level of a key that will be generated on an unknown user's device. Treat hardware backing as a measured property with a defined policy, not a marketing label inferred from the APK.
Sources and further reading
Reference review: 22 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
