I have an android library hosted on jitpack, but due to its dependencies requirements it is not built to and AAR file. It just a basic project that you can pull the methods from.
I want to hide the names for the classes, methods, and variables within the project itself without compilation. I understand that I could minify it in the gradle but that would only work once the project is built into and apk or bundle.
Is there a way to post process the code to have the same effect?
I have found the answer I was looking for. Jitpack pre-builds the project after you commit changes. In this compilation process it does take the minification in the gradle and proguard rules into account. Even though I don't distribute an AAR or Jar file, the code still gets hidden in the same way.
In conclusion, Just set up the minification and proguard rules as your normally would and Jitpack will handle the rest.
Related
A project I'm working on contains a lot of external dependencies on 3rd party libraries. While analyzing compiled apk I found out that a package within the app that is supposed to be obfuscated remains clean. When I dived deeper I figured out that merged ProGuard configuration contains a rule breaking obfuscation logic.
None of the project's ProGuard configurations contain this rule. So I assume that it was gotten from one of the dependencies and merged to final configuration.
I look through this question but it seems that the answer is no longer valid for Android Plugin for Gradle 3.0.1 that I'm using because build/intermediates/exploded-aar folder no longer contains any ProGuard configurations.
So I'm wondering:
Is there a way to find what library causes the problem?
Is it still possible to disable a rule from consumer proguard file?
I am using a third party .aar project and they have enabled the proguard in the aar project. And in my Application Project i am enabling Proguard as well and its giving me errors.
So, do i need their(.aar project) proguard rules to be included in my proguard config files or is there any other possibility?
I have read in blogs and posts that the best approach is to include the .aar project without proguard and then run the proguard on aar and application project as a whole.
If i run proguard on Application will it affect the imported library's(already proguarded) code ?
So, do i need their(.aar project) proguard rules to be included in my proguard config files or is there any other possibility?
Quoting the documentation:
You can enable code shrinking on your library by adding a ProGuard configuration file to your library that includes its ProGuard directives. The build tools embed this file within the generated AAR file for the library module. When you add the library to an app module, the library's ProGuard file gets appended to the ProGuard configuration file (proguard.txt) of the app module.
So, if the library module has consumerProguardFiles 'lib-proguard-rules.txt' in its defaultConfig (see the docs), in principle, those rules will get applied automatically.
I have read in blogs and posts that the best approach is to include the .aar project without proguard and then run the proguard on aar and application project as a whole.
AFAIK, that's the typical plan. So, the AAR is left alone, with ProGuard applied on the app.
If i run proguard on Application will it affect the imported library's(already proguarded) code ?
AFAIK, the library's code should not be run through ProGuard.
Is it possible to use Multidex inside a library project? It's not so hard to hit the 65k limit when you have libraries like Dagger, RxJava and Databinding. I'm really stuck here, any help would be really appreciated.
I am trying to 100% validate that this is true but based on how the normal build process works my hypothesis is that because your AAR consists of .class files and the normal android build process includes dexing all project files including libraries (AARs, and JARs) that adding multidex to your library really will just help with making sure that when they library is built in its root project that it is able to multi-dex properly.
Let's say you you build an AAR (which needs Multi-Dex) and then you import that aar into another project. Chances are you are going to need multi-dex on the project consuming the library as well because though the compiler doesn't need to compile the java classes it will still need to dex and do resource compilation on the entirety of the AAR.
I recently migrated a project from Eclipse/Ant to Android Studio/Gradle. I am able to successfully build a signed release version of the project with proguard enabled. However, while testing the release version, I'm getting crashes from certain library projects and jars (which work fine when building a debug version).
For example, when attempting to upload a file to Dropbox (a jar dependency), I get the following error:
java.lang.IncompatibleClassChangeError: interface not implemented
at com.dropbox.client2.session.AbstractSession.sign(SourceFile:238)
at com.dropbox.client2.DropboxAPI.putFileRequest(SourceFile:2199)
at com.dropbox.client2.DropboxAPI.putFileOverwriteRequest(SourceFile:1571)
at com.dropbox.client2.DropboxAPI.putFileOverwrite(SourceFile:1537)
Also, when attempting to sign into Box (a library project dependency), I get the following error:
java.lang.NoSuchMethodError: org.apache.http.conn.params.ConnManagerParams.setMaxTotalConnections
at com.box.restclientv2.BoxBasicRestClient.()
at com.box.boxjavalibv2.BoxRESTClient.()
at com.box.boxjavalibv2.BoxClient.createRestClient()
at com.box.boxjavalibv2.BoxClient.()
at com.box.boxandroidlibv2.BoxAndroidClient.(SourceFile:49)
at com.box.boxandroidlibv2.activities.OAuthActivity.startOAuth(SourceFile:71)
at com.box.boxandroidlibv2.activities.OAuthActivity.onCreate(SourceFile:52)
I have other jars and library projects that work just fine...
Again, there are no issues with either of these when building a gradle debug build (no proguard). I was also able to create a release build with proguard enabled using ant without any issues (able to sign into both Dropbox and Box).
Any ideas?
You appear to be including a version of the org.apache.http library. In principle, this library is already part of the Android runtime android.jar, so you shouldn't add it to your project. ProGuard is probably printing warnings about these duplicate classes.
In practice, it may be a newer version of the library, and some of your code may be using additional classes from this version. You then probably should leave the names of the classes, fields, and methods untouched, to avoid introducing (additional) conflicts:
-keep class org.apache.http.** { *; }
A build process may filter out the classes, or it may be adding the above line, but I don't think the default Android builds currently do either.
You need to -keep Proguard from removing or renaming all the class and method names that it can't determine are referenced from code that it doesn't processes, that are referenced via reflection (e.g. XML references), etc.
Keeping all apache classes may keep more than necessary (which is OK) but it may not be enough to fix all the Proguard issues.
It's good to ask why it worked from your ant build without this -keep. Maybe the ant build didn't actually call Proguard (ant is tricky), maybe it used a different Proguard data file, or maybe the relevant libraries changed in the meantime. You can debug that by listing hypotheses and testing them. E.g. if you put a malformed command in the Proguard data file then run the ant build, you can tell whether it actually runs Proguard or not.
I'm trying to setup proguard for my Android project. My application project has very little code in it, but references a library project which has the vast majority of the code and any other external jars. That being said, I'm not sure how to setup proguard to take this into account. Right now my proguard config file is just the Android example from the ProGuard site. I've been searching around, but haven't found a lot or any documentation on using proguard with library projects, just jars. I'm new to proguard, so any push in the right direction would be great. Thanks.
It makes sense to me to specify proguard settings for a library (like which library files shouldn't be obfuscated) in the library project. I've found that I also need to include proguard configurations from my library modules in my application. To do this, I added the following to the defaultConfig section in my library's build.gradle
apply plugin: 'com.android.library'
android {
defaultConfig {
consumerProguardFiles 'proguard-rules.pro'
}
}
and then configured the proguard-rules.pro file in my library module to keep the names of important serialized classes.
See also consumerProguardFiles gradle reference
Edit
As #BornToCode points out, a different answer (originally posted here) better explains how library projects are handled by Proguard. Additionally, this referenced question has more interest and more overall reputation than that linked in my original response. The quote:
Library projects by themselves don't run ProGuard, so they don't use
any configuration.
Application projects obfuscate the entire code base, including any
referenced libraries, so they need proper configuration for the
application code and for the library code.
Old Answer (not wrong, just probably not the best approach)
The library projects is more of a convenient way of linking a project to its jar in Eclipse. When you build the project, the only component of the library project that is visible to your compiler is the jar file.
If you want to obfuscate that jar, check out this post:
How to obfuscate an Android library (.jar file) using Proguard in Eclipse