Android App Hardening Checklist

A published Android app can be unpacked and studied by anyone, and what they find — API keys, endpoints, debug switches — becomes a way into your backend. Paste your AndroidManifest.xml and the app-level build.gradle (Groovy or Kotlin) to check for the settings that make that easiest.

AndroidManifest.xml and/or build.gradle

Findings

About this tool

This checker reads the text of your Android manifest and Gradle build file and flags settings that help an attacker analyze or tamper with your app: debuggable builds, cleartext HTTP, app data backup, components that other apps can start, code shrinking and obfuscation turned off in the release build, and API keys or secrets written into the files. Comments are ignored, so a commented-out setting does not count.

It is a text-pattern check that runs in your browser. Nothing you paste is sent to a server, and secret values are never shown in the output.

How it works

Manifest checks: android:debuggable="true" and android:testOnly="true" (danger); android:usesCleartextTraffic="true" (danger); android:allowBackup set to true or missing from the <application> tag (caution; the default is true); android:exported="true" components (caution, with the count); and activity, service, receiver or provider elements that have an <intent-filter> but no android:exported attribute (danger: apps targeting Android 12 / API 31 or higher will not install).
Gradle checks: if a release { … } block is found, code shrinking is judged from that block only (minifyEnabled / isMinifyEnabled), and debuggable set to true inside it is flagged as danger. Without a release block, any minifyEnabled false in the text is reported as a caution, because the tool cannot tell which build type it belongs to. Turning minification off in the debug build is normal and is not flagged when a release block exists.
Secrets: AWS access key IDs (AKIA…), Google API keys (AIza…) and assignments such as apiKey = "…" or secret: "…" with a value of 8 or more characters. Only the number of matches is shown. A Google API key in an Android app is sometimes meant to be public; restrict it to your package name and signing certificate in the Google Cloud console.
Settings that are good (debuggable not set, backups off, shrinking on in release) are shown as OK, so you can see what was actually checked.
The tool cannot see your code, your signing setup or your server. It does not replace testing the built APK with a tool such as MobSF or a manual review.

FAQ

Q. Is it a problem that minifyEnabled is false in my debug build?

A. No. Debug builds are usually left unminified so that stack traces are readable. What matters is the release build, which is what users download.

Q. Does obfuscation protect my API key?

A. Not really. R8 or ProGuard renames classes but string constants stay readable in the APK. Do not rely on obfuscation to hide a secret. Keep real secrets on your server and give the app short-lived, restricted credentials.

Q. What does exported mean?

A. An exported component can be started or bound to by other apps. Components that do not need to be reachable from outside should say android:exported="false". Since Android 12 you must state it explicitly for any component with an intent filter.