IssueTracker

Has anyone re-tried it? We switched back to RUN sdkmanager --package_file=$ANDROID_HOME/packages.txt in our Dockerfile back in March of 2021.

For what it's worth, I did a quick test with the latest CLI: 11076708 (https://developer.android.com/studio#downloads) on OSX and tried it with a simple:

./sdkmanager --sdk_root="../sdk" --package_file=deps.txt

Deps.txt:

platform-tools
extras;google;instantapps
build-tools;35.0.0-rc3

So perhaps this is now resolved? I haven't tried it with more packages

Iirc, The issue we ran into using the rule you suggested was that we were using the type in a generic for Gson deserialization but never referencing the type directly. so the type would be erased in the generic to Object leading to the Gson code to crash.

Morten suggested the rule we have now which somehow ensures the type wasn't removed. The rule is quite complex so I'm not exactly sure why it works better. I think there's a test case that captures this behavior I believe

Benjamin is right that

-if class *
-keepclasseswithmembers,allowshrinking,allowobfuscation class <1> {
  <init>(...);
  @com.google.gson.annotations.SerializedName <fields>;
}

require that both at least one <init> and a @com.google.gson.annotations.SerializedName annotated field is present, whereas the other will keep the <init>'s for all classes with a @com.google.gson.annotations.SerializedName annotated field.

Note that you should probably change <init>(...) to <init>() to match the rules landing in the next version of Gson. Gson only ever use the no-args constructor reflectively.

It seems we mark 184,827 classes as ineligible for class merging due to -if rules. Many of these classes are completely unrelated to gson (e.g., androidx.annotation.Keep). I will try to diagnose why these classes are being marked as ineligible.

Ben, can you check if updating to 8.3.28 resolves the issue?

You may still see a small regression, since https://r8.googlesource.com/r8/+/e98da634de940e3d0098e0467d08af80c532139d is fixing a situation where R8 would not always evaluate -if rules correctly, but hopefully not anywhere near the regression you reported here.

With R8 8.3.28, we observe app size reduced by 90KB.

Btw, Soren when I replaced our Gson rules with the rules from upstream, our app size increases by 600KB.

Here are the rules we are using for GSON:

##---------------Begin: proguard configuration for Gson  ----------
# Gson uses generic type information stored in a class file when working with fields. Proguard
# removes such information by default, so configure it to keep all of it.
-keepattributes Signature

# For using GSON @Expose annotation
-keepattributes *Annotation*

# Prevent proguard from stripping interface information from TypeAdapterFactory,
# JsonSerializer, JsonDeserializer instances (so they can be used in @JsonAdapter)
-keep,allowobfuscation class * implements com.google.gson.TypeAdapterFactory
-keep,allowobfuscation class * implements com.google.gson.JsonSerializer
-keep,allowobfuscation class * implements com.google.gson.JsonDeserializer

# @SerializedName annotation
-keep @interface com.google.gson.annotations.SerializedName { *; }

# Do not strip any field that is annotated with @SerializedName
-keepclassmembers,allowobfuscation class * {
    @com.google.gson.annotations.SerializedName <fields>;
}

# Ensure init methods are preserved if class has @SerializedName annotations
# Ref: https://partnerissuetracker.corp.google.com/issues/280658459#comment4
-if class * {
  @com.google.gson.annotations.SerializedName <fields>;
}
-keepclasseswithmembers,allowobfuscation class <1> {
  <init>(...);
}
-if class *
-keepclasseswithmembers,allowshrinking,allowobfuscation class <1> {
  @com.google.gson.annotations.SerializedName <fields>;
}

##---------------End: proguard configuration for Gson  ----------

Note, when doing this comparison I didn't switch the <init>(...) with <init>() yet.

Thanks for the update. I will mark this as fixed then.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Beta 2
• Android Gradle Plugin 8.3.0-beta02

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

The fixes for this issue are now also available in:

• Android Studio Hedgehog | 2023.1.1 Patch 2
• Android Gradle Plugin 8.2.2

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Comment added by automation: A postmortem has been automatically requested for this issue. Please author a postmortem on IRM. See go/android-postmortem-guidance for more context and details, including how to handle the case when this issue does not need a postmortem. If you have any questions not answered by go/android-postmortem-guidance, please email android-hygiene-tpm@, instead of reassigning the fixed bug. Thank you.

Further fixes for this issue are now available in:

• Android Studio Iguana | 2023.2.1 RC 1
• Android Gradle Plugin 8.3.0-rc01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.