Develop Reference

Enabling ProGuard causes failing signed APK generation?

I have enabled minifyEnabled in my gradle file for using the feature of ProGuard to obfuscates code as a result it throwing some error.
Note: there were 1 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
Warning: there were 309 unresolved references to classes or interfaces.
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
and much more.
I have gone through the ProGuard documentation.i guess this is what happening wrong.am using third party libraries and jars.and it confuses as i have more number of libraries and jars.how can i decide which one should keep in my proguard-rules.pro and which one doesn't ? And what else need to do for using ProGuard successfully and efficiently ?

ProGuard analyzes all the code in your application (that includes libraries) and generates warnings if it sees unresolved references (or other problems, but unresolved references is the important thing here). It is very common for libraries to refer to system or library code that doesn't exist in your project.
For example: Picasso optionally integrates with OkHttp, and has code referring to that library. But if you haven't included OkHttp ProGuard will warn about unresolved references.
A successful build must not have any warnings from ProGuard. ProGuard also checks for reflection, if there are unresolved references found in reflection, ProGuard will generate notes instead of warnings. Both warnings and notes may point to issues with the classpath. You could check the code yourself to see if there's an actual problem, or trust the libraries that their code works on Android (and on your target platform version).
Kevin Schultz opened up a public collection of ProGuard configuration files. His blogpost should help you get started with your configuration file.
http://www.kevinrschultz.com/blog/2014/02/15/proguard-with-gradle/
Do double check the configurations that you copy. They can be a little aggressive sometimes. If possible you want to avoid -dontwarn/dontnote {entire-package} and instead narrow down on the actual problems.

You need to add proguard rules specific to the libraries you use. A compilation of such rules is available at https://github.com/StarWar/android-proguard-snippets/tree/master/libraries
You can also try adding dontwarn directive for packages causing issues. An example of this would be -dontwarn org.codehaus.jackson.**

Is ProGuard really a good way to protect the android application?

Is ProGuard really a good way to protect the android application? I do not think. Please see the following images:
Compile Code
Decompile_Code
Also the variable names did not change and the code is readable easily.

Activity classes are not completely obfuscated. This is because the activities are listed in the manifest and classes referenced there are automagically kept. This is needed because the Android framework accesses these app entry points via reflection.
Read more from here:
The build process runs the tool aapt to automatically create the
configuration file bin/proguard.txt, based on AndroidManifest.xml and
other xml files. The build process then passes the configuration file
to ProGuard. So ProGuard itself indeed doesn't consider
AndroidManifest.xml, but aapt+ProGuard do.

Gradle release build with proguard: java.lang.IncompatibleClassChangeError and java.lang.NoSuchMethodError

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.

remove unused classes with proguard for Android

History/Context
I have a project[1] where size really matters - recently I moved stuff to a shared lib[2] and thought proguard will take care and remove the unused classes because I had a config that was drastically reducing the size but by using the lib i came over the magic 100kb mark so I investigated: classes which I do not use for sure are in the resulting dex file - and even with full name ( not shortened to single-char ) - e.g. I see the SquareView in the dex which I in no way use in the App.
Question
Surprisingly I found in the proguard documentation the following:
The library jars themselves always remain unchanged.
Can I somehow tell/trick proguard (in)to process them? I find this really strange especially because I expect more stuff to be removeable in the lib than in the App itself..
[1] https://github.com/ligi/FAST
[2] https://github.com/ligi/AndroidHelper

The Eclipse/Ant/Gradle build processes in the Android SDK automatically specify your code (from bin/classes) and its libraries (from libs) with the option -injars. This means that the complete application is compacted, optimized, and obfuscated (in release builds, assuming ProGuard is enabled).
The build processes only specify the Android runtime android.jar with the option -libraryjars. It is necessary to process the code, but it should not end up in the processed apk, since it is already present on the device.
So it should all work out automatically. You may still see entire libraries with their original names in processed apks, if your configuration proguard-project.txt contains lines like -keep class org.mylibrary.** { *; }. Such configuration is typically a conservative solution to account for reflection. With some research and experimentation, you can often refine the configuration and get better results. You can figure out why classes are being kept with the option -whyareyoukeeping.

I believe you have to use -injars:
-injars class_path
Specifies the input jars (or wars, ears, zips, or directories) of the application to be processed. The class files in these jars will be
processed and written to the output jars. By default, any non-class
files will be copied without changes. Please be aware of any temporary
files (e.g. created by IDEs), especially if you are reading your input
files straight from directories. The entries in the class path can be
filtered, as explained in the filters section. For better readability,
class path entries can be specified using multiple -injars options.
Source: http://proguard.sourceforge.net/index.html#manual/usage.html

Proguard errors when exporting Android project after updating to ADT 20

After updating to ADT 20 I can no longer successfully export any of my Android projects. I get:
Proguard returned with error code 1. See console
In the console I get tons of the can't find referenced class warnings and occasionally the can't find superclass or interface warning. At the end of the warnings I get something like this:
You should check if you need to specify additional program jars.
Warning: there were 199 unresolved references to classes or interfaces.
You may need to specify additional library jars (using '-libraryjars').
java.io.IOException: Please correct the above warnings first.
at proguard.Initializer.execute(Initializer.java:321)
at proguard.ProGuard.initialize(ProGuard.java:211)
at proguard.ProGuard.execute(ProGuard.java:86)
at proguard.ProGuard.main(ProGuard.java:492)
Each time I attempt to build I get different numbers of warnings (it's not very consistent). Also, when I perform a clean before export, the export completes without producing any warnings, but the resulting APK crashes on launch often due to ClassNotFoundException.
My proguard-project.txt includes the necessary -keep class rules for the Android Support Library and ActionBarSherlock.
I had no problems building this project before ADT 20. I even tried building my last release (which obviously built fine when I released it), but I get the same proguard warnings and failed export.
I've tried adding -libraryjars and/or -dontwarn rules as many other SO questions suggest, but to no avail. It will sometimes build successfully, but the APK created crashes on launch.
Any suggestions?

There is a bug in AAPT where it will only process
<fragment android:name"..." />
but not
<fragment class="..." />
We'll fix AAPT but in the meantime you can use the other attribute and it'll work.

In ADT 20, we use a feature of aapt (see the -G flag) which can create a proguard file which contains keep rules for exactly the custom views used by your code.
The old proguard config files would keep all views. When you used a library project such as the compatibility library, where you might be using only a small subset of the available code, this could end up including a lot of stuff you don't need. By removing the generic keep rules, and adding a new keep file based on your application, your .apks would get smaller since a lot of unused stuff can be removed.
One area where this can go wrong is if you update to Tools 20 (so you have the new smaller proguard-android.txt file), and you continue to use ADT 18. Make sure to use ADT 20, since it will add in not just the proguard files specified in your project.properties setting, but the generated proguard file listing the keep files from aapt -G as well. I believe the ant build will also use the -G feature.
(Note - see http://code.google.com/p/android/issues/detail?id=35107 for any followups on this)

Reportedly, there are problems with a recent update of the Eclipse plugin in the ADT, which doesn't properly recompile all source code. In that case, ProGuard will print out warnings about your program classes (as opposed to the library classes). You should check if the export (and the resulting application) works without ProGuard. You should also check if the Ant build works ("ant release"). That could then be a workaround.