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.
Related
When I build big multi module project, result apk contains a lot of dex files. 35 on debug version and 15 on release. Most of files has far less methods and references then 65k.
Is there any way to compact dex files?
I also analysed several famous applications from google, instagram, and others. They all have 4-6 almost full dexes. Nothing like we have. So looks like compaction is possible
We also suspect that such big amount of dex files can slowdown application startup. Is it the case?
When I run application on android 4 device, I can literally see in logs how dex files getting unpacked. I didn't profile it, but looks like the speed is more or less the same for every file, may be i wrong here.
AGP 3.4, Gradle 5.5
on debug version:
dex metrics on release version:
I am particularly new to the Android Security Realm and trying to understand how Android, during installation(and execution) of an apk file, validates its integrity.
Just to try my hands on, I tried recompiling an apk with three .dex files and changing one byte of of the contents in the header section of only one of the classes.dex using a Hex Editor before signing it.
The App installed on the device with almost no complaints but with much shorter time as it usually does.
On trying to run the App, as expected, it crashed complaining it can't find the Application class and the required .dex file isn't present in the /system/... path.
I want to understand why the App installed successfully in the first place and Android didn't complain of corruption during installation. Also, What are the checks which Android is actually placing during the installation which detects this corruption.
P.S.: I changed one byte in the SHA-1 header of one of the .dex file(classes.dex particularly)
As you found, an invalid dex file won't cause installation to fail. Typically, as part of the installation process, art will optimize and compile the dex file - the result of which is an oat file. It's during this process that the dex file is checked for integrity.
You can take a look at art's source to see what kinds of verification it performs on the dex file. See e.g. here, but elsewhere as well.
there
I'm currently study Ajadx project and have found out there could be more than one classes.dex file.
Is there anyone who knows why and perhaps the evolving Android development history about it?
Thank you!
The maximum .dex (Dalvik Executable) operation (not dex size) for Java is 4G (means, 4 GigaBytes).
The "multidex enabled" means the system can create more than one dex files on need.
When happens dex operation?
It happens whenever you create apk (means, in apk build).
The maximum single dex size is 65K (means, 65 KiloBytes).
Note: 8K dex file can cross 65K dex operations if there are so many concurrent executions in your application. You could get the similar error even though you set total (max.) dex operation size is 4G. See this picture:
It is fine in build projects, but, you get this error when you try to build APK.
To solve this, you need to enable multidex. After you enable multidex and when you build, Android Studio generates corresponding first dex file from first 65K dex operation memory, 2nd dex file from second 65K dex operation memory and so on.
Now, when you change your build.gradle to enable multidex, you can build your APK.
Now, you apk file is ready. You uncompress your apk file and go inside that folder. You can see something like below picture. See this picture
You see, there are two dex files: classes.dex and classes2.dex. First classes.dex file is (in my example) is 8.3MB which is output of first 65K concurrent dex operations. And, the second classes2.dex file is output of rest dex operations which (We don't know exactly but we know it is less than 65K).
In this way, the overall dex operations for total dex files is 4G (4GB), which you asked here.
Hope, I gave your answer.
I am definitely a noob at understanding this as of now, I noticed usually that the apk file is much smaller than my Android Projects. How is that happening? Is it always like this? I got this doubt while I was compressing an entire project to zip file, it was showing that the disk size is 128MB...(noticed it then the first time) whereas the actual apk is only 22.4 MB. why is this difference?
An APK is an Android application package file. Each Android application is compiled and packaged in a single file that includes all of the application’s code (.dex files), resources, assets, and manifest file. The APK file is basically a .zip file
Your project contains all of your source files and files used only by the IDE. The apk only contains compiled files which are smaller.
Also, images/resources etc are compressed in the apk.
Android projects (in general) contain source code, which gets compiled to class files that end up in the APK.
Compiled files are smaller than the source code - for example they strip all the comments out of the file (you do include comments in your source files don't you!)
In addition to the other answers, you're probably using something called ProGuard which further compresses your project by shortening field names, removing dead (unused) code, merging classes, and dozens of other tricks.
Check out the FAQ for more about ProGuard.
It has to do with how Android compiles your project. It basically dumps the bulk, compresses the resources, and compiles everything into a simple binary. It will happen with almost every type of programming, your final build will usually be smaller than your total project (unless you include outside sources in your build). There is a lot of bulk in code that get's stripped during compilation.
I met this error when i built my modified Android source. (version 4.1.1_r6)
Dex framework
[dx] trouble writing output: Too many methods: 65867; max is 65536. By package:
I know the solution for this problem is that spliting framework into smaller package files to reduce the number of methods in framework.jar. It requires some modifications in .mk files but Android make file system is quite complicated.
I hope that anybody give me some instructions to do that.
Thanks