Android App Security Best Practices

Android gives every app a strong sandbox, but the sandbox can't protect you from your own design decisions. Security has to be built into how you store data, talk to servers, expose components and handle authentication, and it has to assume the device and the APK can be inspected by an attacker.

Security layers

Core principles

• Never trust the client. Enforce authorisation, prices, limits and business rules on the server.
• Minimise data: collect, store and log only what you need.
• Least privilege: request minimal permissions, and export minimal components.
• Defence in depth: combine controls, because each one can fail.

Network security

<network-security-config>
    <!-- Disallow cleartext HTTP everywhere (default for targetSdk 28+, made explicit here) -->
    <base-config cleartextTrafficPermitted="false" />
    <!-- Allow user-installed CAs only in debug builds, e.g. for proxy debugging -->
    <debug-overrides>
        <trust-anchors>
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
</network-security-config>

<application android:networkSecurityConfig="@xml/network_security_config" ... >

Never ship a custom TrustManager that accepts all certificates or a HostnameVerifier that returns true. Consider certificate pinning only with a rotation plan. See Certificate Pinning.

Data storage

• Keep sensitive data in app-private storage, never on shared external storage.
• Encrypt secrets and sensitive data with Keystore-backed keys. See Encrypted Data Storage and Secure Token Storage.
• Exclude sensitive files from backups.
• Clear user data on logout.

Secrets

Anything in the APK is extractable, including BuildConfig fields, resources, native libraries and obfuscated strings. Keep real secrets on servers and use short-lived, scoped tokens. See Secure API Keys and Secrets.

Components and intents

<activity android:name=".internal.DebugMenuActivity" android:exported="false" />

<receiver android:name=".SyncReceiver" android:exported="false" />

<!-- Public deep-link entry: exported, but validate all incoming data -->
<activity android:name=".DeepLinkActivity" android:exported="true">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="https" android:host="yunoktech.com" android:pathPrefix="/orders/" />
    </intent-filter>
</activity>

val orderId = intent.data?.lastPathSegment
    ?.takeIf { it.matches(Regex("^[A-Z0-9]{4,20}$")) }   // allow-list format
    ?: return finish()
// Then load the order through the authenticated API, which enforces ownership server-side.

• Use PendingIntent.FLAG_IMMUTABLE unless mutability is required.
• Use explicit intents for internal communication.
• Protect custom permissions with signature protection level when sharing between your own apps.

WebViews

• Keep JavaScript disabled unless needed. Never enable file access from file URLs.
• Load only your own trusted HTTPS content, and restrict navigation to allowed hosts.
• Avoid addJavascriptInterface with untrusted content. Prefer WebViewCompat.addWebMessageListener with origin allow-lists.

UI and logs

// Prevent screenshots and recent-apps thumbnails on screens showing sensitive data
window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)

• Never log tokens, OTPs, personal data or full API responses in release builds.
• Mark password fields correctly (KeyboardType.Password or the password input type) so keyboards don't learn them.

Release and supply chain

• Enable R8 (it raises the effort of reverse engineering, but isn't a security boundary).
• Use Play App Signing, and protect upload keys. See App Signing.
• Keep dependencies updated, remove unused SDKs, and review SDK data collection.
• Use Play Integrity on the server for high-value actions.

Priorities by app type

Frequently asked questions

Conclusion

Android security is layered: server-side authority, TLS-only networking, sandboxed and encrypted storage, minimal exported components with validated input, safe WebViews and logging, and a secure release pipeline. Fix the common mistakes first, then deepen for higher-risk apps.

Next step: understand the foundation of on-device cryptography in Android Keystore Explained.