Closed nostra13 closed 2 years ago
Hello! Nice to see you again :smiley:
I checked the Gradle docs and I think the -keeppackagenames
should solve the problem. As a result, the packages will stay with their original names, which will not conflict with your application.
I'll check it again and create a new version ASAP
I guess -keeppackagenames
can do the thing but please ensure there will be no a.a.a...
classes after obfuscation. it's better to keep all HelpCrunch lib classes under com.helpcrunch.library
package to prevent conflicts.
@nostra13 The new version 3.1.5 is already available. There should be no naming problems now. I did not add additional modifiers for Proguard and removed the previous ones :+1:
@TalbotGooday what you had fixed in this version, by adding proguard rules like keeppackagenames??
@chintan-soni-cko I don't remember to be honest. But I can find later. Why?
Actully I am facing the same problem in my SDK. I have been trying for the last 2 days. Not fixed yet. I greatly appreciate your help.
@chintan-soni-cko actually I found what was changed. We've used modified socket.io
lib a long time ago 'cause original crashed and it was outside of the main package. After the obfuscation socket package had path like a.a.a.a
. Our solution was to remove socket.io
sources 'cause as it turned out at that time socket.io-guys fixed the error. I this case we just started using a gradle dependency and removed -flattenpackagehierarchy
. So there was no 'good solution'
Anyway, I suggest to check this issue https://github.com/onfido/onfido-android-sdk/issues/177. They used repackageclasses
flag witch I believe can help
-repackageclasses [package_name]
Specifies to repackage all class files that are renamed, by moving them into the single given package. Without argument or with an empty string (''), the package is removed completely. This option overrides the -flattenpackagehierarchy option. It is another example of further obfuscating package names. It can make the processed code even smaller and less comprehensible. Its deprecated name is -defaultpackage. Only applicable when obfuscating.
Counter-indication: classes that look for resource files in their package directories will no longer work properly if they are moved elsewhere. When in doubt, just leave the packaging untouched by not using this option.
Note: On Android, you should not use the empty string when classes like activities, views, etc. may be renamed. The Android run-time automatically prefixes package-less names in XML files with the application package name or with android.view. This is unavoidable but it breaks the application in this case.
@TalbotGooday Thank you very much for the sharing in detailed solution.
As I see HelpCrunch provides not unique obfuscated classes again (https://github.com/helpcrunch/android-sdk-demo/issues/33). Can we return to discussion to use -flattenpackagehierarchy
or -repackageclasses
during HelpCrunch lib obfuscation process?
I proposed to use
-flattenpackagehierarchy
to organize obfuscated classes from you lib (https://github.com/helpcrunch/android-sdk-demo/issues/33) but I found out that this instruction is exposed to all consumers. As a result all my classes are obfuscated and moved tocom.helpcrunch.library
package.So please use
-flattenpackagehierarchy
for preparing your AAR library but not include-flattenpackagehierarchy 'com.helpcrunch.library'
into proguard.txt inside AAR.I guess it can be done by separated file for consumers: