search

MichaelRocks / paranoid

String obfuscator for Android applications.
Apache License 2.0
670 stars 79 forks source link

Possible bug: "Could not initialize class io.michaelrocks.paranoid.grip.ClassesQueryBuilder" #48

Closed AndroidDeveloperLB closed 3 years ago

AndroidDeveloperLB commented 3 years ago

Hello,

Background

Sadly I can't find anything similar to this issue being written anywhere. Basically, I'm trying to offer an obfuscated AAR via a Github&Jitpack, while having the repository on Github to be private.

The problem

I'm having a problem publishing the repository on Jitpack as I get this error:

...
ERROR: No build artifacts found
Expected artifacts in: $HOME/.m2/repository/MySdk/library/unspecified

According to my experience, Jitpack works very well with open sourced repositories, so what I tried is to create a new project with an almost-empty sample and Android-library. The Android-library holds the AAR file inside CallerIdSdkWrapper\library\libs , and later I will check what's going on with Jitpack (hopefully it will be able to handle this).

Thing is, using this workaround (with or without the AAR file) , on the local project that wraps the SDK, I get this error:

Execution failed for task ':library:transformClassesWithParanoidForDebug'.
> Could not initialize class io.michaelrocks.paranoid.grip.ClassesQueryBuilder

As for the gradle files, on the project level I have this:

classpath 'io.michaelrocks:paranoid-gradle-plugin:0.3.3'

On the library level I have this (also tried to add the same to app-level) :

id 'io.michaelrocks.paranoid'

...

//https://github.com/MichaelRocks/paranoid/issues/38
api("io.michaelrocks:paranoid-core:0.3.3")

The AAR file was created while using paranoid already, so this issue seems very weird for me.

How can I made the Android-library use "paranoid" library without having this issue? What could be wrong with it?

AndroidDeveloperLB commented 3 years ago

Hm I might be wrong, but trying this idea again, and this time without adding anything of the paranoid library into anywhere (except the AAR), I think the issue is gone.

Weird. In any case, I think Jitpack can't handle this anyway, because of this issue:

...
> Direct local .aar file dependencies are not supported when building an AAR. The resulting AAR would be broken because the classes and Android resources from any local .aar file dependencies would not be packaged in the resulting AAR. Previous versions of the Android Gradle Plugin produce broken AARs in this case too (despite not throwing this error).
...