Android
AuraScore 81/100

Enterprise Android Security Assessment Checklist

Conduct a comprehensive security and client data leakage audit for professional services Android applications.

Use this checklist when preparing a client-facing Android application for deployment in high-compliance advisory or legal environments. It guides technical leads through cryptographic controls, IPC security, and data leakage risks.

Template

Role: Principal Android Security Architect for professional services client engagements

Context

  • Client organisation: {{client_firm_name}}
  • Application under assessment: {{target_android_app}}
  • Governance standard: {{regulatory_framework}}
  • Identity provider and auth model: {{auth_mechanism}}
  • Handled client data tier: {{data_classification_tier}}
  • Backend transport protocol: {{backend_api_type}}

Task

Produce an exhaustive, production-grade security verification checklist to audit {{target_android_app}} prior to onboarding {{client_firm_name}}'s corporate users, ensuring strict adherence to {{regulatory_framework}} and zero data leakage across untrusted Android subsystems.

Method

  1. Map all local persistence vectors (EncryptedSharedPreferences, Room SQLCipher, Datastore) handling {{data_classification_tier}} data.
  2. Verify Android Keystore implementation, biometric prompt crypto-binding, and hardware-backed key attestation configured for {{auth_mechanism}}.
  3. Audit all inter-process communication (IPC) endpoints, including exported Activities, BroadcastReceivers, Services, and ContentProviders.
  4. Evaluate Network Security Configuration, certificate pinning directives, and cleartext traffic policies governing connections to {{backend_api_type}}.
  5. Inspect clipboard, screenshot prevention (FLAG_SECURE), auto-backup rules, and keyboard cache leakage vectors.
  6. Evaluate memory sanitization for ephemeral cryptographic tokens and corporate session artifacts.
  7. Assess runtime application self-protection (RASP) mechanisms, including root detection, hook detection, and emulator evasion.
  8. Verify third-party analytics and logging frameworks to ensure zero PII or sensitive advisory records escape the client sandbox.

Constraints

  • MUST format all verification items as actionable checkboxes with specific code-level or manifest-level criteria.
  • MUST include explicit Pass/Fail/Mitigation status slots for each line item.
  • MUST NOT recommend deprecated Android cryptographic algorithms or legacy storage permissions.
  • Every verification section must directly reference {{regulatory_framework}} compliance expectations.

Output format

  • Executive Verification Overview (brief score card block)
  • Core Audit Sections: (1) Cryptography & Key Management, (2) Storage & Data Isolation, (3) IPC & Component Exposure, (4) Network & Transport Security, (5) Session & Telemetry Controls
  • Remediation Priority Matrix (Critical / High / Medium)
  • Total checklist items: exactly 18 to 24 discrete verification tasks

Self-review

  • Confirm that all variables ({{client_firm_name}}, {{target_android_app}}, {{regulatory_framework}}, {{auth_mechanism}}, {{data_classification_tier}}, {{backend_api_type}}) are properly contextualized.
  • Validate that all 8 method steps correspond to explicit checklist items.
  • Verify that at least two strict MUST/MUST NOT rules are enforced in the resulting checklist.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-android
professional-services
android-security
mobile-audit
compliance