HARBOR DESK / 04 / PRACTICE GUIDE

Android security review

Review Android storage, verified links and release artifacts. Keep browser policy models distinct from device verification.

Download guide and workpapers

Original AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.

CODE REVIEW DESK

See the decision through the test.

Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.

Plaintext in a private directory / Weak code

Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.

s=>s.privateDirectory

privateDirectory alone is insufficient. Encryption, Keystore and log/backup boundaries are required together. Fields represent evidence assumptions; the model does not inspect device files or hardware.

Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.

01 / EXPLANATION

Key and token lifecycle

An app-private directory is not encryption. Retain short-lived tokens only as needed; if persistence is required, design authenticated encryption using an Android Keystore key. The example uses a fresh AES-GCM IV on each encryption; the IV is not secret but must not repeat under a key. Examine ciphertext backups, logs, crash reports and screenshots as separate copies.

02 / EXPLANATION

Keystore limits and links

Keystore key material is non-exportable; hardware protection depends on device and configuration. A compromised app context may still invoke the key, so it is not a complete prevention guarantee. App Links require HTTPS, exact host/path policy and OS domain verification together. Check assetlinks.json and signing fingerprints; the application server must still authorize the requested object.

03 / EXPLANATION

Complete verification on a device

Inspect debuggable settings, cleartext policy, exported components and signing chain on the release APK/AAB. Testing a debug build does not verify the release artifact. Test data behavior across reinstall, lock, key invalidation and upgrade. MASVS guides requirements; MASTG supplies testing techniques. The Kotlin fragment is an integration component, not a complete Android app or device lab.

04 / EXPLANATION

Device workpaper: token and links

Use only a synthetic token on the test device. Check its required accessibility after lock, app termination and upgrade, and inspect logs and backup copies. If a key disappears, require safe reauthentication rather than an endless error loop or plaintext fallback. For links, try the correct domain, lookalikes, wrong paths and foreign-tenant tickets. A valid URL still requires the server to deny a foreign record. Record artifact digest, signature, Android version, verification state and observed outcomes. The Kotlin component demonstrates key generation and encryption; it does not implement UI, backup rules or app session management.

Build the evidence yourself.

Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.

Scope and trust boundariesMarkdown · ENTest plan and expected resultsMarkdown · ENFinding and retest recordMarkdown · ENRelease decision and evidence traceMarkdown · EN
Full guide with code, outputs and reasoning ↓

Primary references

Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.