these files weren't in my project but were auto included in analyze apk?
what are these a and b packages which consumed more space?
I believe those are obfuscated classes.
While obfuscation does not remove code from your app, significant size savings can be seen in apps with DEX files that index many classes, methods, and fields. However, as obfuscation renames different parts of your code, certain tasks, such as inspecting stack traces, require additional tools
You can get more info here
Related
I built same android project by Eclipse + Android plugin on same machine 5 times.
The 1st build's class.dex file and the 3rd build's class.dex file are the same but they're different than the other build.
Although i think class.dex file should be the same but i don't know much about Android compiler process. I wonder if this is about compiler's multi-thread or optimization process.
Any helps would be appreciated.
There are many ways a dex file can be bytewise-different from another, and yet be semantically identical.
For example, in some sections in the dex file, the order of items is not specified, so the item can be placed in different locations in 2 different, but semantically equivalent dex files.
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
When generating signed APKs from the Build menu I end up with the new file app/manifest-merger-release-report.txt. What is this file and should it be version controlled (like ProGuard's mapping.txt)?
That file is generated by the manifest merging step of the Android build. If you're doing a sophisticated build where multiple flavors and build types are coming into play, and especially if you're directing traffic during the merge by explicitly telling the build system how to handle specific manifest attributes, you may find the report useful.
It's not necessary to save this file, since it's only of use if you're trying to diagnose problems during the build. It's not like the Proguard mapping file, which you may need to keep so you can de-obfuscate errors and stack traces that come in from the wild.
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
In the case, if I will
build a project
clean up all binaries
build it again (no source/resources and etc has changed).
Does Proguard guarantee to provide the same mapping.txt file?
ProGuard is deterministic: for the same input, it will generate the same output.
There is one subtlety though: if the operating system lists input files in a directory (notably class files that are not inside an archive) in a different order, then they may be processed in a different order, and the output can be different.
It might actually happen, but i don't think proguard guarantees that.
I found this in the Proguard documentation that will allow you to reuse your mapping.txt to avoid changes on the mappings
-applymapping filename
Specifies to reuse the given name mapping that was printed out in a previous obfuscation run of ProGuard. Classes and class members that are listed in the mapping file receive the names specified along with them. Classes and class members that are not mentioned receive new names. The mapping may refer to input classes as well as library classes. This option can be useful for incremental obfuscation, i.e. processing add-ons or small patches to an existing piece of code. If the structure of the code changes fundamentally, ProGuard may print out warnings that applying a mapping is causing conflicts. You may be able to reduce this risk by specifying the option -useuniqueclassmembernames in both obfuscation runs. Only a single mapping file is allowed. Only applicable when obfuscating.
If you want a guarantee then you have to use the mappings file as input to the obfuscation process. But then you carefully have to check all warnings about conflicts relating to that mapping file. If you ignore that, you may get subtle errors, when working with reflection.