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.
Apply the fallback decision to the actual generated key
Suppose a sensitive feature prefers StrongBox but permits another documented security level on supported devices. A device capability flag is only the beginning of that decision. Generate the key using the required parameters, handle a failed request and inspect the resulting key's properties before assigning the feature's displayed protection state.
The KeyInfo reference documents the reported key properties. Guard APIs for the device versions you support and record the actual security level available for that key. Do not reuse a capability result obtained for a different algorithm or earlier key as proof of the new key's protection.
Exercise the branch that the flagship device misses
Include a supported test device or controlled test condition where the preferred implementation cannot satisfy the request. Confirm that the product either follows its declared fallback or refuses the sensitive operation clearly. A generic catch block that always retries with weaker parameters can contradict a requirement that hardware protection is mandatory.
Measure the latency of the actual operation the feature performs. A successful single signing request does not establish that a burst of concurrent requests will meet the screen's responsiveness target. Keep cryptographic work away from UI-blocking paths and test cancellation or navigation while a result is pending.
Verify any authentication requirement separately. A hardware-protected key still needs an appropriate usage policy, and the app must associate the authorized operation with the user's intended action. Test a canceled authentication prompt and an expired authorization condition, then confirm that no successful transaction is displayed from a stale callback.
Retain the device software, key parameters, reported security level and observed operation outcome with the test. Avoid storing private-key material or complete sensitive payloads in the report. A statement about hardware backing should be traceable to this particular key and policy, with its tested limitations, rather than inferred from a phone model's marketing description or the success of an unrelated APK signature check.
Sources and further reading
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
