Tag Archives: proguard

Proguard and AdMob mediation

If you’re an Android developer who uses ProGuard to post-process builds, you already know the improvements it can make to APK size and speed. Just as handy, though, is its ability to obfuscate your compiled code by stripping out debug information and renaming classes, methods, and fields to generic identifiers. It’s a great way to discourage reverse-engineering of your application. If you’re an AdMob publisher who uses mediation, however, you need to take special care when configuring ProGuard in order to avoid obfuscating some of the code used in the mediation process.

AdMob mediation needs two classes to maintain their original names in your final APK: AdUrlAdapter and AdMobAdapter. If either of those has been renamed by ProGuard, it can cause the SDK to incorrectly return “no fill” responses for the AdMob demand in your mediated ad units.

The good news is that it’s easy to avoid this problem. Just add the following two keep options to your ProGuard configuration file:


-keep class com.google.ads.mediation.admob.AdMobAdapter {
    *;
}

-keep class com.google.ads.mediation.AdUrlAdapter {
    *;
}

These options instruct ProGuard to avoid renaming the two classes, and to leave the names of their fields and methods unobfuscated as well. With the original names intact, the mediation system will be able to instantiate them dynamically whenever they’re needed, and your otherwise obfuscated application won’t miss out on any AdMob impressions.

The third-party networks your app mediates may also need certain classes exempted from obfuscation. Be sure to check with those networks to find out if they have recommendations for ProGuard configuration.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

 - , Mobile Ads Developer Relations tags: android, admob_mediation, mobile_ads_sdk