Android Manifest Security Flags: debuggable, allowBackup, Cleartext and Exported
An Android app's manifest is a short file that declares a lot of security decisions. A handful of settings, debuggable, allowBackup, cleartext traffic, exported components and the target SDK, tell you quickly whether a build was prepared carefully, and they are exactly what the APK analyzer's health check looks at.
android:debuggabledefaults to false and should stay false in any release build.[1]android:allowBackupdefaults to true; Android recommends setting it explicitly, and false turns off cloud backups and device-to-device transfers.[1][2]- Cleartext HTTP has been disabled by default since Android 9 (API level 28).[3]
- Since Android 12, components with intent filters must declare
android:exportedexplicitly.[4]
Why the manifest is worth reading first
The manifest is the one file every APK must have, it is cheap to read, and it is where a developer states what an app exposes and allows. Reading it will not reveal everything an app does, since behavior lives in code, but it shows the configuration decisions that are hardest to get away with hiding. Our guide to analyzing an APK shows how to decode it.
android:debuggable
This attribute controls whether the app can be debugged, even when running on a device in user mode. It is true if it can be and false if not, and the default is false.[1]
Warning sign: debuggable="true" in a published app. A debuggable app lets someone attach a debugger and inspect its memory and behavior, which is intended for development only.
Debug builds are debuggable by design, which is normal for a developer's test build. It is a finding only when it appears in something distributed as a release.
android:allowBackup
This attribute controls whether the app takes part in Android's backup and restore. If it is set to false, no backup or restore of the app is ever performed, which disables cloud backups and device-to-device transfers, even for a full-system backup taken with adb.[1] The default is true, and Android's Auto Backup documentation recommends setting the attribute explicitly in the manifest rather than relying on the default.[2]
Why it matters: by default Auto Backup includes files such as shared preferences and files in the app's internal storage,[2] so anything sensitive an app keeps there can end up in a backup. Apps that handle credentials, tokens or PIN data should turn backup off or define explicit backup rules that exclude them.
Cleartext traffic
Whether an app may use unencrypted HTTP depends on the Android version it targets: up to Android 8.1 (API level 27), cleartext support is enabled by default, and starting with Android 9 (API level 28) it is disabled by default. Apps that need cleartext traffic must opt in.[3]
An app that opts in with usesCleartextTraffic="true", or allows cleartext for broad domains in its network security config, can send data in a form anyone on the network may read. The same configuration file is where certificate pinning lives; see our guide to SSL pinning.
android:exported and intent filters
An exported activity, service, receiver or provider can be reached by other apps on the device. If a component uses intent filters, Android 12 and higher require an explicit android:exported value, and an app that leaves it out cannot be installed.[4] Exported does not mean insecure, since launcher activities and accessibility services must be exported, but each exported component is an entry point worth understanding, ideally guarded by a permission. See deep links for the most common case.
Target SDK and permissions
targetSdkVersion. It tells you which platform behavior changes the app has opted into. A very old target means it may not get newer protections, such as the cleartext default above.minSdkVersion. The oldest Android version the app supports, which often explains why legacy settings remain.- Permissions. The list of what the app can request. Read it against what the app does, as explained in our permissions guide.
A five-minute manifest checklist
| Check | Safe default |
|---|---|
| debuggable | Absent or false |
| allowBackup | False, or explicit backup rules that exclude sensitive data |
| Cleartext traffic | Not allowed |
| Exported components | Only those that must be, each with an explicit value and a permission where possible |
| Deep links | Verified App Links with narrow patterns |
| Target SDK | A recent API level |
| Permissions | Only what the features need |
The APK analyzer reads all of these and summarizes them in its health check, so you can run the list on any APK in seconds. For the wider picture, our security best-practices checklist covers what the manifest cannot show. These settings map onto the code-quality and platform-interaction controls in OWASP's MASVS.[5]
Frequently asked questions
What does android:debuggable do?
It controls whether the app can be debugged, even on a device in user mode. It defaults to false and should stay false in release builds, because a debuggable app can be inspected with a debugger.
Should allowBackup be true or false?
If the app stores anything sensitive, set it to false or define explicit backup rules that exclude that data. The default is true, and Android recommends setting the attribute explicitly.
What happens if allowBackup is false?
No backup or restore of the app is performed, which disables cloud backups and device-to-device transfers, even a full-system backup taken with adb. Users would have to set the app up again on a new phone.
Is cleartext HTTP allowed on Android?
Not by default on Android 9 (API level 28) and higher. An app must opt in to allow it, and doing so means traffic can be read on the network, so it should be avoided.
Why must exported be declared on Android 12?
To remove ambiguity. Android 12 and higher refuse to install an app whose components use intent filters without an explicit android:exported value, which forces developers to decide.
Is an exported component a vulnerability?
Not by itself. Many must be exported, such as launcher activities. It becomes a problem when a component does something sensitive and is reachable without a permission or input validation.
Does a debuggable flag mean an app is malicious?
No. It usually means a developer's test build was shared, which is a hygiene issue rather than proof of bad intent. It is still a reason not to trust that build for sensitive data.
What is targetSdkVersion?
It states which Android version the app was built for, which decides which platform behavior changes apply to it. A recent target means the app gets newer protections by default.
Can the manifest alone prove an app is secure?
No. It shows configuration, not behavior. Code can still mishandle data. Use the manifest as a quick screen, then look deeper at anything that stands out.
- <application> element — Android Developers — debuggable and allowBackup definitions and defaults.
- Back up user data with Auto Backup — Android Developers — default of true, the recommendation to set it explicitly, and what is backed up.
- Network security configuration — Android Developers — cleartext enabled up to API 27 and disabled by default from API 28.
- Behavior changes: Apps targeting Android 12 — Android Developers — explicit android:exported requirement for components with intent filters.
- OWASP MASVS — MASVS-CODE and MASVS-PLATFORM — code quality and platform-interaction controls.