The problem
Google Play will require 25% minimum optimization, obfuscation, and shrinking for uploads starting February 2027 (requirements), for any app with DEX over 10 MB.
With the keep rules recommended on this forum, our app measures 19%. R8’s Configuration Analyzer attributes 88% of all locked items to two Zoom rules:
| rule | locked items | share |
|---|---|---|
-keep class us.zoom.** { *; } |
323,972 | 35.9% |
-keep class com.zipow.** { *; } |
243,939 | 27.0% |
Every other keep rule in our project combined is under 5%. As it stands, integrating this SDK makes 81% of an app’s code untouchable by R8 — which will not pass Play from February 2027.
SDK version: 6.5.1.31081 (mobilertc.aar, 38,214 classes)
Verified on: Galaxy S10 5G (SM-G977N), Android 12 — AGP 9.2.1 / R8 9.2.14
What we did before asking
We didn’t just measure it. We tried to derive the rules ourselves by analysing the AAR, and narrowed the blanket keeps to { native <methods>; public protected *; } plus an explicit list of the classes the native layer needs:
| how we found them | classes |
|---|---|
FindClass arguments in .so rodata |
148 |
ACC_NATIVE flag in class files (GetObjectClass(thiz) path) |
521 |
| protobuf field reflection (one pattern rule) | 3,412 covered |
Result, with meeting join, virtual background, screen share, mic/camera toggles, in-meeting chat and participant list all working on a physical device:
| obfuscation | optimization | shrinking | |
|---|---|---|---|
| blanket keep | 19.01% | 18.74% | 19.01% |
| narrowed (659 classes) | 29.94% | 29.66% | 29.95% |
| Play requirement | 25% | 25% | 25% |
Measured from BUNDLE-METADATA/com.android.tools/r8.json in the AAB — the same metric Play reports.
So 25% is reachable. The JNI boundary we could recover is 659 classes, 1.7% of the 38,214 in the AAR.
Why we still cannot ship this with confidence
One class of usage is structurally undetectable from outside the SDK.
When native code receives a Java object as a parameter and reads one of its fields via GetFieldID, nothing records that relationship — the class name is not in any .so, and the class declares no native methods. Neither method above finds it.
We know this because we crashed into one: org.webrtc.voiceengine.AudioPlaybackCiscovered only when the app aborted during meeting audio. We cover it by keepingorg.webrtcwhole, but **we have no way to know how many more exist inus.zoom/com.zipow`.** Recording and breakout rooms are paths we have not exercised.
The same blind spot applies to class names assembled at runtime and to Java-side reflection targets (the AAR contains a us.zoom.reflection.utils package).
The request
Please ship a proguard.txt consumer rules file inside mobilertc.aar.
This is the standard mechanism for Android libraries, and it requires no new engineering on your side — only publishing the JNI and reflection boundary you already know. Every integrator
currently has to guess at it, and none of us can guess correctly.
Your own developer plugin ships an SDK size optimization guide that warns:
Warning: ProGuard/R8 causes crashes with Zoom SDK, even with Zoom’s providtime crashes. Use at your own risk.
We understand the caution. But from February 2027, “use at your own risk” and "s longer compatible positions for an app that integrates this SDK.
This is the same request as Inclusion of ProGuard rules in AAR (May 2024, unresolved) and the Video SDKequivalent — now with measurements.
We can share our full 659-class rule set, the r8.json output for every stage, and the crash traces. We are also glad to test a candidate rule set against our integration and report back.