Fixed
Status Update
Comments
js...@google.com <js...@google.com> #2
Yes, we're ignoring it currently: https://r8.googlesource.com/r8/+/refs/heads/master/src/main/java/com/android/tools/r8/shaking/ProguardConfigurationParser.java#63
https://www.guardsquare.com/en/products/proguard/manual/usage#dontusemixedcaseclassnames
```
Specifies not to generate mixed-case class names while obfuscating. By default, obfuscated class names can contain a mix of upper-case characters and lower-case characters. This creates perfectly acceptable and usable jars. Only if a jar is unpacked on a platform with a case-insensitive filing system (say, Windows), the unpacking tool may let similarly named class files overwrite each other. Code that self-destructs when it's unpacked! Developers who really want to unpack their jars on Windows can use this option to switch off this behavior. Obfuscated jars will become slightly larger as a result. Only applicable when obfuscating.
```
```
Specifies not to generate mixed-case class names while obfuscating. By default, obfuscated class names can contain a mix of upper-case characters and lower-case characters. This creates perfectly acceptable and usable jars. Only if a jar is unpacked on a platform with a case-insensitive filing system (say, Windows), the unpacking tool may let similarly named class files overwrite each other. Code that self-destructs when it's unpacked! Developers who really want to unpack their jars on Windows can use this option to switch off this behavior. Obfuscated jars will become slightly larger as a result. Only applicable when obfuscating.
```
js...@google.com <js...@google.com>
mk...@google.com <mk...@google.com> #3
This should be fixed ToT and in version 1.5.35.
Description
extracting: shrunk/d/a/b/a/B.class
replace shrunk/d/a/b/a/b.class? [y]es, [n]o, [A]ll, [N]one, [r]ename:
I'm using com.android.tools:r8:1.3.52 from