Unresolved class name proguard-rules Android Studio 4.0
AndroidProguardAndroid Studio-4.0Android Problem Overview
When I update to Android Studio 4.0 proguard-rules it shows warning Unresolved class name
. Below is example but I sure it still waring the exist class in my project.
-keep class com.squareup.haha.** { *; }
-keep class com.squareup.leakcanary.** { *; }
If I change from **
to *
this warning is gone.
-keep class com.squareup.haha.* { *; }
-keep class com.squareup.leakcanary.* { *; }
Does anyone get this? Should I ignore this warning or it's bug of Android Studio 4.0?
Update
I find it's bug, it already assigned but not resolved https://issuetracker.google.com/issues/153616200
Update July
Google team already analysis and increase priory of this bug, it may be related to a newer version of R8.
Update August
Fixed in AS 4.2 Canary 9
Android Solutions
Solution 1 - Android
> Check this issue: https://issuetracker.google.com/issues/147802433
> `If you right-click on error, there is option "suppress for statement", after that AS adds a comment such as: #noinspection ShrinkerUnresolvedReference -keep class not.existing
And with this comment there is no error for "not.existing".`
Solution 2 - Android
Replace .**
with **
as workaround. No compile error and classes are kept.
-keep class com.squareup.haha** { *; }
-keep class com.squareup.leakcanary** { *; }
Solution 3 - Android
This issue is fixed in Android Studio 4.2 Canary 8. Please find the release notes here https://androidstudio.googleblog.com/2020/08/android-studio-42-canary-8-available.html and check for this issue id #153616200
Solution 4 - Android
A folder and its subfile. I have tested this:
com.xx.xx.* { *; }
I guess that it may contain multiply folders and subfile. I've not tested this:
com.xx.xx.**.* {*;}
Solution 5 - Android
replace
.**
with
.*.*
result
-keep class com.squareup.haha.*.* { *; }
-keep class com.squareup.leakcanary.*.* { *; }
Solution 6 - Android
All of these answers are mere non-sense because:
LeakCanary is being added as debugImplementation
.
- it makes no sense to have rules for classes which do not exist in
release
builds. - it makes even less sense to obfuscate
debug
builds.
In case you may require any of these rules, you've added it to the wrong build-type.