Google Play: Obfuscation 1% — R8/ProGuard & Debug Symbols

[avcr2019]

Hi everyone,

I'm using Adobe Animate + Harman AIR SDK to build and publish my Android app.

For a long time, Google Play was showing these two warnings when I uploaded my AAB:

Warning: There is no deobfuscation file associated with this App Bundle. If you use obfuscated code (R8/proguard), uploading a deobfuscation file will make crashes and ANRs easier to analyze and debug. Using R8/proguard can help reduce app size.

and:

Warning: This App Bundle contains native code, and you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug.

I ignored them because they were only warnings and the app was still accepted and published.

However, now Google Play is showing a new “Needs attention” issue:

App optimization is below our threshold
Improve your percentages in the following categories:
Obfuscation (1%)

It also says:

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.

Unfortunately, this is now affecting my app.

I'm using Adobe Animate + Harman AIR

Has anyone using Harman AIR encountered this new Google Play Obfuscation requirement?

Is there a proper way to enable obfuscation/R8/ProGuard for an AIR Android app?
Is this something that can be configured through the Harman AIR SDK?
Can the AS3/SWF code be obfuscated in a way that Google Play recognizes for this optimization score?
Or is there another recommended solution/workaround for AIR apps?
Any help would be greatly appreciated. Thanks!

AIR SDK version: [51.3.4.3]
Adobe Animate version: [2021]
Google Play target SDK: 36
Obfuscation score: 1%

[avcr2019]

Hello friend, @ajwfrost can you help solve this problem?

[marchbold]

@pol2095 My understanding is that gradle should automatically pull in proguard.txt from an aar and from a jar.

@ajwfrost I'm wondering if we can just embed the proguard configuration inside the jar for an ANE? Though it's likely providing an additional proguard rules section would be helpful.

[pol2095]

@marchbold a file *.pro can be included in the jar too like kotlinx-coroutines-core-jvm-1.11.0.jar in META-INF/proguard/coroutines.pro

@ajwfrost ProGuard can use -include lib/annotations.pro

# Including specific files organized by theme
-include proguard-network.pro
-include proguard-database.pro
-include ../common/proguard-shared.pro

[marchbold]

@pol2095 yes, I was just saying that the gradle build process will pull the proguard configurations from jar/aar so you shouldn't have to extract them into the application proguard file that AIR needs to create.

[pol2095]

@marchbold You're right

[pol2095]

I ported the sh script to Windows
check_obfuscation_win.zip
and to macOS
check_obfuscation_mac.zip

[marchbold]

This issue has been noted in AIR SDK 51.4.1.1

[avcr2019]

The Adverts version I sent you is using the latest sdk, so they have deprecated those methods and are using setAgeRestrictedTreatment instead, eg:

    .setAgeRestrictedTreatment( RequestConfiguration.AGE_RESTRICTED_TREATMENT_CHILD )

More info here: https://developers.google.com/admob/android/targeting

Thanks a lot for the explanation! @marchbold
I have completely removed the deprecated methods and updated my code to use this line exactly as you suggested:
requestConfiguration.setAgeRestrictedTreatment(RequestConfiguration.AGE_RESTRICTED_TREATMENT_CHILD);
The compiler warnings (Warning: 3604) are completely gone now and it successfully compiled!
Just to be 100% sure, is this the absolute correct approach with the new ANE version? It won't cause any ad loading issues or conflicts, right?"

[avcr2019]

Just a thought but have you added the hardware accelerated and contains video flags? eg

<android>
    <manifestAdditions><![CDATA[
        <manifest android:installLocation="auto" >
            <uses-sdk android:minSdkVersion="19" android:targetSdkVersion="36" />
            <uses-permission android:name="android.permission.INTERNET"/>
            
            <application android:hardwareAccelerated="true">
                <meta-data android:name="android.max_aspect" android:value="2.5"/>
                <meta-data android:name="android.notch_support" android:value="true"/>
            </application>

        </manifest>
    ]]></manifestAdditions>
    <containsVideo>true</containsVideo>
    <r8>
        <enabled>true</enabled>
    </r8>
</android>

Thanks for the suggestion! @marchbold
Actually, I didn't try adding hardwareAccelerated="true" because the video has always worked perfectly fine for me in the past without it. The black screen issue (audio playing without video) only started appearing after I enabled R8.
It turns out the issue was that R8 was obfuscating/stripping some core Adobe AIR classes needed to render the video. A friend of mine (@pol2095 ) suggested a brilliant fix. He told me to add custom ProGuard rules to prevent R8 from touching those specific classes.
I created a huawei.pro file with these lines:
code
Proguard
-keep class com.adobe.flashruntime.** { ; }
-keep class air.* { *; }
And then I called it in the application descriptor like this:
code
Xml

true
/Users/avcr/Desktop/app/rules/huawei.pro

The result was perfect! The app compiled successfully, the video now plays flawlessly with both sound and picture, and to top it off, the Google Play Obfuscation percentage is now at a great 91%!
Just wanted to share this solution with you in case anyone else faces the same issue with AIR, R8, and video rendering. Thanks again for your time and help!

[avcr2019]

Setting <containsVideo>true</containsVideo> causes a black screen. To fix this, I had to add :

-keep class com.adobe.flashruntime.** { *; }
-keep class air.** { *; }

and fdb work correctly now

Thank you so much, @pol2095 !
Your solution worked perfectly! I added those two lines to my custom ProGuard file, and the black screen issue is completely gone. The video now plays flawlessly with both picture and sound, and fdb is working exactly as it should.
and this the result

I just have a few quick questions to fully understand this:
Is this the official workaround we should rely on from now on? Or do you think Harman will fix this internally in a future AIR SDK update (maybe by including these rules by default)?
Is this method 100% safe to rely on for production apps on Google Play?
Are there any other specific -keep rules I need to add for the AIR engine, or are these two lines enough?
Thanks again for your brilliant help, you really saved my day! @pol2095

[pol2095]

@avcr2019 To know if we need more rules, we can only find out by testing. Harman can easily add them to "proguard-rules.pro"

[marchbold]

Great work @pol2095 @avcr2019 !! Hopefully there's a simple set of rules the AIR team can put together to resolve this.

[pol2095]

I tried to obfuscate my ANE SAF but I chose another way, I obfuscated the JAR directly :
in build.gradle.kts(:app) :

buildTypes {
  release {
    isMinifyEnabled = true
      proguardFiles(
        getDefaultProguardFile("proguard-android-optimize.txt"),
        "proguard-rules.pro"
      )
   }
}

and in proguard-rules.pro :

# Keep the Adobe AIR native interface so it doesn't break ANEs
-keep class com.adobe.fre.** { *; }
-keep class * implements com.adobe.fre.FREExtension { *; }

@ajwfrost I needed to obfuscate the JAR because ADT adds a ProGuard file automatically, but it's not necessary to add :

# Keep any classes that implements the FRE interfaces
-keep class * implements com.adobe.fre.FREContext { *; }
-keep class * implements com.adobe.fre.FREFunction { *; }

It's just necessary to use :

# Keep the Adobe AIR native interface so it doesn't break ANEs
-keep class com.adobe.fre.** { *; }
-keep class * implements com.adobe.fre.FREExtension { *; }

Note: Java @0verride methods are automatically kept by ProGuard/R8 because of -keep class com.adobe.fre.** { *; }

[kidsacademyteam]

Will we now have "deobfuscation file" to upload to Google with .aab?

[ajwfrost]

Ah, so we hadn't yet got the code in there to copy out the mapping file. That will be in our next release but I'll see if I can put a patched version of ADT here shortly that will include three updates:

• the mapping.txt file will be copied to the output file location
• the proguard rules will only be applied in release builds
• the rules are updated per the above discussions (not the Huawei things, but the other flash/fre namespace changes)

thanks

[marchbold]

Thanks Andrew (Huawei things are Adverts ANE specific and already handled in our prerelease version)

[avcr2019]

Thanks Andrew (Huawei things are Adverts ANE specific and already handled in our prerelease version)

Thank you for your cooperation and assistance. @ajwfrost @marchbold
Okay, this means that in the next update, the problem will be resolved without using any lines like these

 <r8>
            <enabled>true</enabled>
            <proguardFile>/Users/avcr/Desktop/app/rules/file.pro</proguardFile>
        </r8>

    and which contains:
    -keep class com.adobe.flashruntime.** { *; }
    -keep class air.** { *; }

Because, unfortunately, the videos won't work without those two lines.

Thx

[ajwfrost]

The built-in proguard file is updated for those extra lines, but you would still need to enable it with your app descriptor:

 <r8>
            <enabled>true</enabled>
 </r8>

At some point we'll make it opt-out, but for now it's still an opt-in feature...

thanks

[avcr2019]

The built-in proguard file is updated for those extra lines, but you would still need to enable it with your app descriptor:

 <r8>
            <enabled>true</enabled>
 </r8>

At some point we'll make it opt-out, but for now it's still an opt-in feature...

thanks

That’s great. @ajwfrost
Alright, we’ll wait for the next update Harman SDK to test it out and let you know the results.
thanks

[marchbold]

This issue has been noted in AIR SDK 51.5.1.1