After uploading an AAB release to Google Play Console, I received the following warning under Monitor and Improve Section:
• Needs attention: DEX code optimization is below our threshold.
• Improve your percentages in the following categories:
• Obfuscation (10%)
• Percentages under 25% in any category of your app may impact your visibility and publishing capabilities on Google Play. To prevent this, optimize your app by the deadline: Fix by Feb 2027.
Issue Details:
Current Obfuscation Score: ~10% (Google Play requires at least 25%).
Since App Inventor handles compiling and packaging on its remote servers—and users do not have access to Gradle files, `proguard-rules.pro`, or R8 configuration—individual creators cannot adjust obfuscation or shrinking rules manually.
Questions:
1. Is the development team aware of this upcoming Google Play technical requirement?
2. Are there plans to update the cloud build server's R8/ProGuard configuration before February 2027 so generated `.aab` packages satisfy the 25% obfuscation/optimization threshold?
Google Play’s new policy (Feb 2027) has a very clear conditional rule:
EITHER keep the uncompressed DEX under 10MB.
OR enable code shrinking with >25% obfuscation.
Since keeping the DEX under 10MB is impossible when using standard extensions (Ads, Firebase, etc.), the only solution is the second option: Enabling code shrinking.
Currently, our builder compiles apps with minifyEnabled false. Because of this, any app over 10MB fails Google's condition and gets the "Code shrinking: not shrunk" warning.
The Fix:
We do not need to figure out how to reduce the DEX size. We need the backend to shrink and obfuscate the code. Niotron has already solved this by enabling R8 on their backend—an 18MB DEX passes perfectly there because it meets the >25% obfuscation rule.
Currently, almost all MIT App Inventor-based platforms are lagging behind in this matter, so the core teams need to work on this urgently and enable it as soon as possible.
Please prioritize enabling server-side R8/ProGuard. This is a compiler configuration issue, not an app size issue.
Google says the new requirements concern memory usage, bitmap usage, DEX optimization, and Zero-Tap Sign-In using Restore Credentials. Enforcement starts in February 2027 for the memory/DEX requirements and April 2027 for Zero-Tap Sign-In.
I am looking into this. One of the issues I have run into is that R8 optimizes the whole Dex file.
Why this matters
In MIT App Inventor apps there are numerous common classes, like for example, the Kawa runtime environment. The buildservers pre-dex most libraries and cache the result. So when you build an App Inventor app, most of the libraries have already been dexed. This makes building both significantly faster and significantly less resource intensive.1
We would not be able to do that with R8. Each build would need to dex all of the libraries, which would cause builds to take significantly longer and we would have to deploy more buildserver resources.2
I'm thinking about perhaps conditionally using R8 if the dex file size is too large using D8. But this is all preliminary.
Footnotes
1 The first build after we restart a buildserver takes significantly longer as it has to Dex all the libraries. Once dexed, they are cached. 2 Which cost us money!
Could we perhaps optimize these common classes while keeping all public classes and their public members, and then cache the dex for future use? I believe we do not need to be concerned about extension classes, as most of them are already optimized.
And what about games? If the uncompressed DEX size is around 25 MB, do we still need to use R8 optimization?
My uncompressed DEX size is 25 MB, and R8 is fully enabled, but my score is still only 31%. I’m confused because if the uncompressed DEX size is under 50 MB, why am I still getting the warning?
I’m no expert on APK compilation, but it seems to me that code optimization involves removing classes that the application doesn't use. If you're optimizing pre-prepared DEX files, wouldn't R8 lack the information needed to determine which classes are actually used in the APK? It seems to me that R8 would need to optimize the entire codebase during the APK compilation process.
I think a conditional approach could be a reasonable middle ground between build performance and server resource usage.
Potential strategy could be:
Build type: Keep using D8 for regular APK exports.
Size-based R8 routing for AABs: For AAB builds, we could first estimate the resulting DEX footprint from the input .class files and .jar dependencies.
Since uncompressed DEX size typically compresses to ~60% of raw byte code size, if the total estimated/actual DEX footprint is under 10 MB , route through D8 (as Google Play does not enforce the 25% obfuscation threshold below 10 MB DEX size).
If the DEX footprint reaches or exceeds 10 MB , switch to R8 to perform code shrinking and obfuscation to satisfy the 25% threshold.
Extension/library ProGuard rules: We would also need to make sure we don't remove classes that are required by extensions or components at runtime. One option would be to automatically pick up rules from extension files such as /files/proguard-rules.pro, if present, and also include proguard.txt files packaged inside AARs.
The main goal here would be to avoid running R8 for every build, especially for smaller projects where it may not provide much benefit, while still having a path for larger apps with heavier dependencies.
