CtrlK
BlogDocsLog inGet started
Tessl Logo

android-security-best-practices

Apply Android app security guidance around secrets, storage, network trust, exported components, and least privilege.

57

Quality

48%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/android-security-best-practices/SKILL.md
SKILL.md
Quality
Evals
Security

Android Security Best Practices

When To Use

  • Use this skill when the request is about: android security review, secret handling android app, exported component security android.
  • Primary outcome: Apply Android app security guidance around secrets, storage, network trust, exported components, and least privilege.
  • Read references/patterns.md when you need the attack-surface checklist or the storage/network/component decision matrix.
  • Read references/scenarios.md for manifest, backup, WebView, and release-hardening review paths.
  • Handoff skills when the scope expands:
  • android-modernization-upgrade
  • android-ci-cd-release-playstore

Workflow

  1. Inventory the attack surface first: exported components, intent/deep link entry points, file sharing, WebView usage, local storage, logs, backups, and network trust config.
  2. Remove avoidable risk before hardening details: prefer platform pickers and choosers, internal storage, server-issued short-lived tokens, and least-privilege permissions instead of shipping broad access or long-lived secrets.
  3. Lock the remaining boundaries explicitly with android:exported, component permissions, FileProvider, networkSecurityConfig, debug-only trust anchors, and immutable PendingIntents.
  4. Review sensitive surfaces that often regress in Android apps: WebView JavaScript bridges, backup/data extraction rules, cleartext exceptions, log redaction, and same-developer IPC assumptions.
  5. Validate the release posture with reproducible checks, then document residual risks and whether backend enforcement or Play Integrity is advisory or blocking.

Guardrails

  • Treat client-side secrets as recoverable by attackers; move trust decisions and privileged API access server-side whenever possible.
  • Export components only when there is a real external caller, and permission-protect or signature-protect them when the contract is private.
  • Use network security config to scope debug trust anchors or cleartext exceptions instead of broad manifest toggles.
  • Redact logs, review backups, and keep sensitive data out of shared external storage by default.

Anti-Patterns

  • Hiding API keys in resources, the NDK, or obfuscation and calling that secure.
  • Leaving android:exported or intent filters ambiguous on launchable or IPC components.
  • Sharing files through raw file paths or overly broad storage permissions instead of FileProvider and system surfaces.
  • Pinning certificates without an operational rotation story or fallback plan.

Review Focus

  • Exported activities, services, receivers, and providers with clear ownership and caller expectations.
  • Secrets, tokens, and backend trust assumptions.
  • Network trust, debug overrides, cleartext usage, and certificate handling.
  • File sharing, backups, logs, and user-data leakage paths.
  • Abuse signals such as Play Integrity only as layered defense, never as the sole authorization model.

Examples

Happy path

  • Scenario: Audit manifests and sharing surfaces for explicit exports, permissions, and FileProvider usage.
  • Command: rg -n "android:exported|android:permission|FileProvider|grantUriPermissions" examples

Edge case

  • Scenario: Catch insecure backup or network defaults before a release candidate goes out.
  • Command: rg -n "networkSecurityConfig|usesCleartextTraffic|allowBackup|fullBackupContent|dataExtractionRules" examples

Failure recovery

  • Scenario: Separate app hardening from modernization or release-pipeline requests.
  • Command: python3 scripts/eval_triggers.py --skill android-security-best-practices

Done Checklist

  • Every externally reachable component has explicit exposure and caller constraints.
  • Secrets, tokens, and trust decisions are not relying on obscurity in the client app.
  • Network, backup, logging, and sharing behavior have explicit release-safe defaults.
  • Residual risks and any backend dependencies are documented with clear follow-up work.

Official References

Repository
krutikJain/android-agent-skills
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.