I'm new with Proguard and I have problem with setting up project to work with it.
Problem is, that the main code is in one library and the "final" project is some empty project used for localization strings, settings only. Where proguard should be enabled - in library or final project or both?
Structure is like this:
ActionBar,Roboguice... libs -> Main Library -> Localized Project (just resources)
Is there option to obfuscate only the main library? It will be more clear to keep one proguard files for one release of XX localized projects.
Thanks in advance for any hint!
You only need to apply ProGuard to the final project. Shrinking, optimizing, and obfuscating the library beforehand doesn't have any added benefit, unless it reduces the library's size a lot, which may reduce the total processing time if you have many final projects.
Related
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.
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 have a library project which refers two other library projects (Google Play Services and Appcompat). The referencing project has no code just resources. All the code is in this library project. I added proguard configuration for my library project hoping to reduce the size of my binary. It compiles and generates the signed apk fine using ant build. But I see no reduction in binary size. Its exactly the same size as it was without proguard. Also obfuscation occurs only for few of the classes , not all.
What am I missing? Any help is appreciated.
Figured out myself. I configured proguard for the referencing project instead of configuring it in the library. All referenced libraries were automatically taken care of and i was able to shrink the size of final apk by about 30%.
obfuscation does not occur for all classes, some classes are skipped as they need to remain (normal) mainly, the views, and other classes that need to be accessed by external components
also check Proguard config file,
you some classes might be set as skipped by mistake.
So, I've got a handful of "Utility" style classes in some of my projects. I'm curious if I can move them to an Android Library Project that contains all or most of my non-app specific glue code (wrappers and interfaces, mostly).
So, my question is what happens to the files I don't need in that library. I know Android Library Projects basically just copy their code into the other project, so if I say use 25% of the code in my "general purpose" library, will my app actually contain the bytecode for all 100%, or does it properly strip it down to only the stuff I need.
I had some issues with unused classes in Proguard in the past, so I'm just once-bitten, twice shy with the ADT now...
Unfortunately, all your projects will grow when the library is getting bigger - even if most contents of that library are not used. I tested it myself by creating an app A and a library L. If L is a library used in A, the classes.dex file (and therefore the A.apk file) is growing if I add more classes - even if they are not used.
To sum up: Right now I would create a basic library for certain things that are small and that may be used by many projects, and create a new library for every new component that is going to be larger and only is used by some projects. A good candidate for a new library would be a new UI component with multiple images defined in the resources. A good candidate for the base library are commonly-used methods and things like file caches, for example. Compiled code is compressed quite heavily for Dalvik, which you can see here. (The whole presentation is actually fun to watch :-)
Edit: If ProGuard is activated, it will also remove unused code for you. The default proguard.cfg is sufficient. It will not run on the (default) debug built, but when the final .apk is compiled. So it actually is possible!
I have used 3 level deep Android library projects successfully though it is kind of a pain. The primary use-case is when there are a set of resources and classes that you want to share across a few projects. Since I use a version control system, I would rather not use symlinks.
Note that Android Library projects also suffer greatly when dealing with resources. ADT will rebuild R.java once for each library, and each R.java will contain a copy of all resource ids from all libraries. The core problem here is that resources are regenerated for the entire project as a whole, and there is no way to "build a jar" for a dependency as would be expected with normal "libraries". We tried integrating with OpenFeint, and had all kinds of hell dealing with libraries and dependencies. I think we ended up just merging all the OpenFeint source and resource files into our own project and ditching the "Library" project as it was offering little value.
Android Library projects are a clunky way of sharing code between projects and have a number of drawbacks. I've found that everything accomplished with a Library project can also be accomplished with symlinks (symlink source into two projects). I've yet to find a usecase where an Android Library project offered something that wasn't easy to replicate with other, less fragile means.
If I want to distribute a closed paid app, there are differences in decompilation if
a) I compile the code of the library directly with a copy-paste of the src classes in my project
b) I simply add the .jar of the library to my build path
c) I create an android library project and add it to my main project
I have heard that the only advantage of a) is that obfuscators like proguard can obfuscate the whole library code while in b) this is not possible since the classes are yet compiled.... Is this info correct?
and in c) ? is the same case of a) or there is any difference in code security?
The options all produce the same results. ProGuard reads the compiled code from the application project, from any library jars, and from any library projects, and treats it all the same.