minSdkVersion looks like a reach decision, how old a device your app supports, but it is also a security decision. Supporting very old Android means your app runs on operating system versions that lack modern security protections, may no longer receive patches, and force you to keep insecure-era behavior working. Raising the minimum lifts your whole app onto a stronger baseline, at the cost of dropping users on old devices. The right level is a deliberate trade-off, not a default left as low as possible. Here is why minSdkVersion matters for security, what a low one costs you, and how to choose.
Short answer
Your app's minSdkVersion sets the lowest Android version it runs on, and a low one is a security trade-off: it lets your app run on old Android versions that lack newer security features, may be unpatched and past end-of-life, and force you to support insecure-era APIs and behaviors. Per Android's documentation, raising the minimum improves your security baseline, since more devices have modern protections like the current storage, network, and keystore models, and you can rely on newer secure APIs. The cost is dropping users on older devices, so the right minSdkVersion balances reach against security rather than defaulting to the lowest possible. Set it as high as your audience reasonably allows.
What you should know
- minSdkVersion sets the lowest OS you support: and shapes your security baseline.
- Old Android lacks modern protections: newer storage, network, and key features.
- Old versions may be unpatched: past end-of-life, no security updates.
- Low minSdk forces insecure-era support: you keep old behavior working.
- Raising it strengthens the baseline: at the cost of some old-device users.
Why does minSdkVersion matter for security?
Because the OS version your app runs on determines which security protections are available. Newer Android versions add security features and harden defaults, scoped storage, stricter cleartext-traffic defaults, improved runtime permissions, stronger keystore guarantees, and more, and an app with a low minSdkVersion runs on older versions that predate some of these, so on those devices your app operates with weaker platform protections. Old OS versions also reach end-of-life and stop receiving security patches, so the device itself is unpatched regardless of your app. And supporting old versions can pull your app down to the lowest common denominator, keeping insecure-era APIs and code paths alive to remain compatible. So minSdkVersion is not just about features and reach; it sets the floor of the security environment your app can count on, and a low floor means weaker protections for the devices at the bottom.
What does a low minSdkVersion cost you?
Weaker protections and more legacy burden. The table lists the costs.
| Cost | Why it matters |
|---|---|
| Missing modern security features | Old OS versions lack newer storage, network, and key protections |
| Unpatched operating systems | End-of-life versions no longer receive security updates |
| Supporting insecure-era APIs | You keep old, weaker behavior working for compatibility |
| Larger attack surface | More code paths and older defaults to secure |
| Harder to adopt new protections | You cannot rely on features unavailable on old versions |
The throughline is that the oldest version you support sets your constraints: you cannot depend on a security feature that does not exist on it, you may have to maintain weaker fallback behavior for it, and the devices running it may be unpatched. So a low minSdkVersion does not just widen reach; it widens the range of environments, including insecure ones, your app must function in, which has a real security cost.
How do you choose minSdkVersion?
Set it as high as your audience reasonably allows, weighing reach against the security baseline. Look at the Android version distribution of your actual or expected users and choose a minimum that covers the great majority without dragging support down to ancient, unpatched versions for marginal reach. Raising the minimum lets you rely on modern security features and defaults, drop insecure-era fallback code, and avoid supporting devices that no longer receive patches, which strengthens the baseline for everyone. Treat it as a deliberate decision rather than leaving it at the lowest value a template set, and revisit it over time as old versions fade, since the security benefit of dropping an unpatched version usually outweighs the small reach you lose. Where you do support older versions, be aware which protections are unavailable there and handle those cases carefully. The principle is that a higher floor is a stronger floor.
What to watch out for
The first trap is leaving minSdkVersion at a very low default for maximum reach, which means running on unpatched OS versions without modern protections; choose it deliberately. The second is assuming a security feature is available when your minSdk predates it, so check which protections require which API level. The third is never revisiting minSdk as old versions age out. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces your SDK versions and configuration, which helps you reason about the security baseline your minSdkVersion sets. The choice itself you make in your build configuration.
What to take away
- minSdkVersion sets the lowest Android version your app runs on, and a low one is a security trade-off, not just a reach setting.
- Old Android versions lack newer security features, may be unpatched past end-of-life, and force you to support insecure-era APIs, weakening your baseline.
- Raising the minimum strengthens the security baseline, at the cost of dropping some old-device users, so set it as high as your audience reasonably allows.
- Choose minSdkVersion deliberately, revisit it as versions age out, and use a pre-submission scan such as PTKD.com to reason about the baseline it sets.
