When an Android App Bundle hits Play Console size limits, the number that matters is the compressed download size of your base module, which Google Play caps at 200 MB, so an app whose base exceeds it fails or warns at upload. You have two routes. The first is to reduce the app's size with code and resource shrinking and smaller assets, which is the preferred fix because a smaller app also installs more reliably. The second is to move the excess out of the base download using Play Feature Delivery for optional features and Play Asset Delivery for large assets, both of which let your app go well beyond 200 MB while keeping the base under the limit. For most apps, shrinking is enough; for large games or media apps, delivery services carry the bulk.
Short answer
The limit is on what a device downloads, not on the file you upload. Per Google's app size guidance, the compressed download size of the base module generated from your app bundle must be no more than 200 MB, and larger apps can exceed that only by using Play Feature Delivery and Play Asset Delivery. Per Android's reduce app size guide, you lower the size with code and resource shrinking and efficient assets. So first shrink the app, and if it is genuinely large, split optional features into feature modules and move big assets into asset packs so the base stays under 200 MB.
What the size limit is
Google Play limits the compressed download size of your app's base module to 200 MB, which is the amount a device actually downloads to install the base of your app, and exceeding it is what triggers the size error at upload. The typical message names the module that is too big, usually the base, and asks you to reduce it. So the check is not on the raw app bundle you upload but on the download Play generates from it for a device.
There are related limits worth knowing. Any feature module delivered on demand must also stay within that compressed download size when it is fetched, and the total of the compressed APKs required to install your app has its own much larger ceiling. But the one that stops most uploads is the 200 MB base download, so that is the number to design around. Getting the base under it, by shrinking or by moving content out of it, is the whole task.
Why the limit is on the download, not the bundle
A common source of confusion is that the app bundle you upload can be larger than 200 MB while still being fine, because the limit applies to the per-device download, not the upload. Play uses your app bundle to generate optimized downloads tailored to each device, stripping out resources and code the device does not need, and the 200 MB cap is on that generated download. So a bundle that contains assets for many densities and architectures can be sizeable while each device's slice stays small.
This is why the fix is about the base download rather than the upload file. You are not trying to make the uploaded bundle smaller for its own sake; you are trying to make the base download Play produces for a device fit under 200 MB. Understanding that distinction points you at the right levers, shrinking what ends up in the base and moving optional content into modules and asset packs that are delivered separately, rather than at the upload size.
Option 1: reduce your app size
The first and best option is to make the app smaller, because a smaller base download is not only under the limit but installs more reliably and reduces uninstalls. Enable code shrinking with R8, which removes unused code, and turn on resource shrinking to strip unused resources. Convert images to efficient formats such as WebP, compress or downsample large media, and remove libraries and assets you do not actually use, since unused dependencies are a frequent source of bloat.
So audit what is inflating the base: large images, bundled media, and heavy libraries are the usual culprits. Shrinking often brings an app comfortably under 200 MB without any structural change, which is why it is the first thing to try. It also has no downside for users, unlike growing the app, so even if you later adopt delivery services, keeping the base lean with shrinking and efficient assets remains worthwhile.
Option 2: Play Feature Delivery
If your app has large optional features, Play Feature Delivery lets you split them into feature modules that are not part of the base download, so the base stays small. A feature module can be delivered at install time, conditionally based on device criteria, or on demand when the user needs it, and only the base plus the features a device requires count toward that device's base download. So a big feature used by some users does not have to inflate the download for everyone.
This suits apps with distinct, separable capabilities that not every user needs immediately. You move the heavy, optional parts into their own modules, and Play delivers them separately, which keeps the base under the limit. Each on-demand module also has to meet the compressed download restriction when fetched, so you size modules accordingly, but spreading a large app across the base and feature modules is a clean way to stay within the base limit while shipping everything.
Option 3: Play Asset Delivery
For apps and especially games with large assets, textures, audio, video, or level data, Play Asset Delivery is the tool designed to carry that bulk outside the base. Asset packs are delivered by Play at the right time, install-time, fast-follow, or on demand, with much higher size allowances than the base module, so gigabytes of game assets can ship through asset packs while the base stays small. Play Asset Delivery also supports texture compression format targeting so each device gets assets in the format it handles best.
So if your size problem is content rather than code, moving large assets into asset packs is the fix, keeping the base download under 200 MB while the assets are delivered separately and optimally. This is the standard approach for large games, which routinely exceed the base limit many times over in total size. Using asset delivery rather than cramming assets into the base is what makes a large game distributable through the app bundle at all.
Options at a glance
Matching your kind of bloat to the right tool guides the fix. The table below maps them.
| Your situation | Best option | Effect |
|---|---|---|
| General bloat, unused code and assets | Reduce app size with R8 and resource shrinking | Base fits under 200 MB |
| Large optional features | Play Feature Delivery | Features leave the base download |
| Large game or media assets | Play Asset Delivery | Assets ship in packs, base stays small |
| Slightly over the limit | Shrink assets and images first | Often enough on its own |
| Many gigabytes of content | Asset Delivery, or a content CDN | Bulk delivered outside the base |
Read the first row as the default: shrinking the app resolves most size-limit failures without restructuring anything.
Fix checklist
Working through these steps gets an oversized app bundle under the limit. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Find the base size | Note the module the error flags, usually base | [ ] |
| Enable shrinking | Turn on R8 and resource shrinking | [ ] |
| Optimize assets | Use WebP and compress large media | [ ] |
| Remove unused code | Drop libraries and assets you do not use | [ ] |
| Split optional features | Use Play Feature Delivery for big features | [ ] |
| Move large assets | Use Play Asset Delivery for game media | [ ] |
The step teams skip most is enabling shrinking, since R8 and resource shrinking frequently bring the base under 200 MB with no restructuring at all.
Where a scan fits
Getting under the size limit is a build and packaging task, but the smaller build you produce is worth a security check, which is independent of its size.
A scanner like PTKD.com analyzes your Android build and flags security issues such as exposed keys, over-broad permissions, and risky third-party code, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not shrink your app or configure delivery, which are your build setup. Since auditing what is in your app to reduce size overlaps with auditing it for security, a size cleanup is a natural moment to scan the build, and removing unused libraries often improves both size and security at once.
What to take away
- Google Play limits the compressed download size of your app bundle's base module to 200 MB, and exceeding it fails or warns at upload.
- The limit is on the per-device download Play generates, not on the app bundle file you upload, so the fix targets the base download.
- Reduce the app first with R8 code shrinking, resource shrinking, WebP images, and by removing unused libraries and assets, which also helps install rates.
- For large apps, use Play Feature Delivery to move optional features out of the base and Play Asset Delivery to ship large game or media assets separately.
- Match the tool to the bloat, shrink for general size, feature modules for optional features, asset packs for content, and use a tool like PTKD.com to scan the leaner build.
