Develop Reference

What is the difference between Proguard and R8?

The new version of Android Studio (3.4) just came out and brings with it default support for R8 instead of Proguard. Could someone explain the key differences between the two and any apparent benefits to using R8?

The history of Android build process kept changing and the developers are constantly trying to make it more efficient concerning build time and generated .dex file sizes. So, throughout the history there has been many variation of the process of generating .dex files from .java files.
Before R8 or D8, the Android build process involved these four steps;
SourceCode(.java) ---javac---> Java Bytecode(.class) ---Proguard---> Optimized Java bytecode(.class) ---Dex---> Dalvik Optimized Bytecode(.dex)
Then, the Android developers decided to merge all the steps in between to 1 step called Jack&Jill for optimization. However, this was introduced in 2015 and abandoned in 2017 due to not being flexible enough to work with all the growing development tools.
Then, D8 was introduced, which is a reverting back to original 4 step build process, with an optimized Dex transform. This implementation produced better quality bytecode than dx, with fewer instructions and better register allocation.
Now to R8, which has a similar goal with Jack&Jill as a starting point, merging two of these build steps into one. The Proguard and Dex step. So, instead of first Proguard processing the .class file returning again .class files and Dex/D8 processor taking in .class and returning .dex files, R8 merges these two steps, and takes in .class files, returning .dex files. This tool is still getting better, trying to optimize the build process even more. So, it is smart to migrate your project to R8 now, as it is a still growing tool which will be the default build tool soon. (As can be seen by enabled by default in the upgrade of Android Studio(3.4))
Also, the developers in Google issue tracker are very fast in returning to the issues reported about R8, as they are hungry for feedback and want to perfect this tool.
It has been reported that using R8 produces smaller .dex files, and does a more efficient minification of removing unused classes. This is a plus and a minus in some way. It is a plus obviously because smaller size is always better(in programming!),it is a minus because you have to intricately go through your code, and detect your entry points and reimplement the keep rules in your proguard file accordingly, as R8 introduces a more aggressive minification than Proguard.
For more information you can look into this article which includes very detailed explanation on R8 vs. Proguard: https://www.guardsquare.com/en/blog/proguard-and-r8
Also, this official speech from Google I/O 2018 : https://www.youtube.com/watch?v=x9T5EYE-QWQ&t=1194s
Hope this helps,

ProGuard vs R8
History flow
ProGuard -> R8
// R8 is default optimizer of .class files from Android Studio v3.4
ProGuard[About] is open source product
R8 is a Google product
Target:
minify, shrinking
optimize
obfuscate, renaming
R8
R8 has better performance because convert .class directly into .dex without extra step (optimised .class)
R8 has better compatibility with Kotlin

What is the Purpose of using multidex support library? [ I referred official android site for this.]

I referred the Android Documentation site. for "Multidex" but not getting idea when i use this. and it is mandatory to use this or not.For what purpose we need to use that class??
Thanks..

The purpose of this is to split up your Dex file into multiple Dex files.
The Dex file contains the compiled code of your application.
Android has a problem whereby there is an upper limit on the number of method definitions in a Dex file (64k). This means that once that limit is reached, you cannot expand your application any further.
Before multidex, it was advised to use ProGuard to reduce the number of method definitions by removing methods that aren't used in code. Especially useful when implementing the Google Play Services Framework.
Multidex was then introduced and allows Apps to continue to expand without worrying about method count limits. It does carry the danger of making the App more unstable. Therefore it is advised to try ProGuard first to reduce the method count.

according to documentation:
Android application (APK) files contain executable bytecode files in
the form of Dalvik Executable (DEX) files, which contain the compiled
code used to run your app. The Dalvik Executable specification limits
the total number of methods that can be referenced within a single DEX
file to 65,536, including Android framework methods, library methods,
and methods in your own code. Getting past this limit requires that
you configure your app build process to generate more than one DEX
file, known as a multidex configuration.
https://developer.android.com/studio/build/multidex.html

Shrinking the size of an apk

All the drawable and raw files have 900kbs all together in my application, but the entire size of the application is comming ouut to be 5.5 Mbs. I am working in eclipse and google play services library along with appcompact_v7 library are attached.
How can i shrink the size of my exported apk file. Because my application is way too simple to have 5.5 Mbs.
Thankyou in advance.

Use Android ProGuard tool. The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer.

First, consider switching to Android Studio and using a subset of Google Play Services, for whatever part you are using. The documentation has a "Selectively compiling APIs into your executable" section that covers this.
Second, if you are examining the size of your debug build, bear in mind that release builds use ProGuard to get rid of extraneous Java code, and so your releae APK will be a bit smaller.
Beyond that, Cyril Mottier has a great blog post on "Putting Your APKs on a Diet". However, some of the more powerful techniques, such as eliminating resources from Play Services via resConfigs, require Android Studio.

There are some techniques you could achieve this:
Proguard - to remove unused classes from your final apk
"lint --check UnusedResources " - detect resources that your app has and are not being used
Use helper jar: https://code.google.com/p/android-unused-resources/
You can read this Android official doc for more info : http://tools.android.com/tech-docs/new-build-system/resource-shrinking .

Android Proguard and Android frameworks: is there a conflict?

For the moment I am developing small Android projects to practice with the Android prorgramming. However, once on the market, I would like to obfuscate / optimise the APK thanks to ProGuard. But this tool renames classes to obfuscate the code, so:
Is it safe to use tools like Android Query to write the code?
If it is not safe, what are some framework examples that can be used safely with Pro Guard?
What could be a solution to the problem? Or should I write everything using the good old Android style and forget about a "write less, do more" approach?
How do I identify the tools that are ProGuard-safe from the ones that are not?

I assume you want to use third party libraries (jar files). You could use a 3 step approach:
If the third party jar explicitly supports Android, it will have a proguard configuration. Usually this is a snippet that you merge into your proguard-project.txt.
If there is no such explicit support, you may still try to use the jar, obfuscate and test your app. If errors occur, gradually exclude classes from obfuscation until it works. A common problem is that libraries use reflection to instantiate classes and call methods which breaks after obfuscation.
Exclude the whole library from obfuscation. This will work in any case and proguard will not touch the library at all. (The Android toolchain will still repackage the contents of the jar into your apk which might cause problems.) This will also produce the least obfuscated result and should really be your last resort.
In any case, obfuscation is not a switch that you simply toggle. You'll need to get familiar with proguard config files which involves a learning curve.

With ProGuard, what is the impact on testing strategy?

I've needed to recently introduce ProGuard on Android because of issues with Scala on Android. I need ProGuard for its shrinking feature, which removes classes presumed to be unused. I'm very concerned about the impact of removing classes on testability.
As it stands, I write unit tests that run on the host and acceptance tests that run the fully integrated application on the Android platform.
Normally, I would be comfortable with relatively complete unit test coverage and spotty acceptance test coverage. However, given that in my code I use Guice dependency injection heavily, so far it's been my experience that ProGuard removes code in a manner that's difficult for me to predict. Because of this it's very likely to cause me to introduce bugs.
This leads me to believe that I need to write acceptance/platform tests that achieve full coverage because at any point, there may be a missing class.
Do others have this experience? If so, what has been your testing strategy? Or with experience, do you become more confident that the classes that ProGuard is removing are truly unneeded?

ProGuard will not break your application until it attempts to use reflection or Class#forName on removed classes and/or obfuscated members.
From my experience (with obfuscated Scala on Android too) it is really easy to spot problems caused by ProGuard to your Android application using the simple smoke tests. You know what libraries you include in your project. If some of them uses reflection or Class#forName - perform smoke test on them. Then exclude the necessary classes/members from the ProGuard configuration.
Remember also that you can automatize testing of your obfuscated project using the ActivityInstrumentationTestCase2 and emulator. If you plan to use ProGuard on your project, always perform instrumentation testing on obfuscated APK.
In conclusion - fear not. ProGuard-related problems are relativity easy to spot.

We've been both unit testing and "fully" testing our ProGuard-ed application for quite a while now, and we've had no "real" problems. The only issues we run into is when we use some library methods in our tests that aren't used in the main application; in these cases ProGuard will remove the code from the libraries and we would have to manually add the specific methods to proguard.cfg.
Oh, and we also use Guice :)