Keep rules for attribution SDKs — and how to verify them from a built APK

Why R8 breaks attribution SDKs

Attribution SDKs (AppsFlyer, Adjust, Branch, Singular, Kochava…) do three things minification hates:

• Reflection. They load classes by name at runtime — often assembled from a string — so the shrinker never sees the reference and deletes the class.
• Entry points your code never calls. Deep-link receivers, install-referrer receivers and content providers are invoked by the OS.
• Their own model classes. Serialising request bodies by field name breaks the moment names are renamed.

The symptom is nasty because it is silent: the app builds, launches and looks fine. You find out days later, in a dashboard, with no crash report to point at.

The keep rules — a working baseline

Vendor docs list their own rules. The point of writing them out is why each block exists, so you can judge whether yours is complete. Consumer rules inside an AAR are merged automatically — but only if the library declares them, and only for that library's own code.

# Attribution SDKs: keep the public surface and what they reach by name
-keep class com.appsflyer.** { *; }
-keep class com.adjust.sdk.** { *; }
-dontwarn com.appsflyer.**
-dontwarn com.adjust.sdk.**

# OS-invoked entry points (not "called" from your code)
-keep class * extends android.content.BroadcastReceiver { *; }
-keep class * extends android.content.ContentProvider { *; }

# Anything serialised by field name
-keepclassmembers class * {
    @com.google.gson.annotations.SerializedName <fields>;
}
-keepattributes Signature, *Annotation*, InnerClasses, EnclosingMethod

The two mistakes that cost the most: dropping -keepattributes (breaks reflection and generics-based serialisation even when classes survive), and keeping only com.appsflyer.AppsFlyerLib instead of the whole package — the reflection targets live elsewhere in it.

Verify it in the APK you ship, not in source

Source-tree checks pass while the shipped artifact is broken: release builds apply different rules, and Play serves split APKs. Check the artifact instead.

# 1. Is the package still in the DEX, unobfuscated?
unzip -p app.apk classes.dex > /tmp/c.dex
strings /tmp/c.dex | grep -E "com/(appsflyer|adjust)/" | head

# 2. With a decompiler, find the real entry points
jadx -d out app.apk
grep -rIl "com.appsflyer.AppsFlyerConversionListener\|com.adjust.sdk.Adjust" out/ | head

# 3. Is the receiver still declared? (it can be stripped from DEX *and* manifest)
aapt2 dump xmltree app.apk --file AndroidManifest.xml | grep -iE "referrer|install|receiver"

Three outcomes, three different bugs — don't fix the wrong one:

• Names gone from the DEX → your keep rule isn't applied to the release variant (check the variant-specific proguard-rules.pro and consumerProguardFiles).
• Names present, receiver missing from the manifest → manifest merging or a tools:node="remove" is dropping the entry point.
• Both present, still no attribution → it isn't minification. Check Play Install Referrer availability, network, and consent gating before touching rules again.

Reading someone else's app

The same check runs in reverse. When you decompile a competitor and don't find an attribution SDK's classes, the honest conclusion is usually "present but obfuscated", not "not used" — because tight keep rules and renaming look identical from the outside. Telling those two apart is the part automated SDK scanners get wrong most often, and it's why a teardown lists evidence per SDK rather than a bare name.

Want this done for a specific app? Send a Google Play link and get the full reverse-engineering report — SDK list, ad networks, API endpoints, architecture — as PDF + Markdown in about 2 hours. $29 for one app, $19 each for three or more.

Disclosure: this page is published by AppXray, which sells that report. The keep rules and verification steps above are complete and free to use without it.