Develop Reference

Why class.dex file is different when build the same source code

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.

Using FFmpegMediaPlayer - Apk size increased by 35MB approx - (without library apk size - 4mb)

Is there a workaround to this, as the size of the apk is drastically increased and the library was added through normal procedure -
(compile 'com.github.wseemann:FFmpegMediaPlayer:1.0.4')
and not through manual inclusion or downloading I wonder whether anyone else has this problem.

if you go to the source code of the library, to the releases page (https://github.com/wseemann/FFmpegMediaPlayer/releases) you'll see that you can manually download to your PC, what is normally being downloaded by gradle and then added to your APK.
There you can see it's 50mb zip, file so it's not crazy to imagine 35mb increase in the APK.
That's because it's not a half dozen Java files, like most libraries are, but this have the compiled binary code of the FFMPEG, compiled for each platform Android uses (arm, x86, 32 and 64bits).
So yeah, final conclusion, if you're really gonna use any ffmpeg based thing, your app will take this extra space.

In what situation would multiple .dex files be created in Android .apk file?

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.

Eclipse to Android Studio Import

I am moving all my source codes to AS as suggested by Android official website. However, the experience is not very good. It is very sluggish as described here. But this is not my ultimate problem for now.
I have resolved many problems such as updating the compileSdkVersion to 23 so that 99 errors of this kind:
Error:(13) Error retrieving parent for item: No resource found that matches the given name 'android:TextAppearance.Material.Inverse'.
could be rectified. But the problems keep on shooting up as I go. Now I have this 64k Dex issue.
Error:The number of method references in a .dex file cannot exceed 64K.
Learn how to resolve this issue at https://developer.android.com/tools/building/multidex.html
I never had this Dex issue while using Eclipse. The source code I have in AS is exactly the same as when it was in Eclipse. The only differences are those gradle changes needed only to work on AS. Any idea why this sudden Dex issue? if I set multiDexEnabled to true, what are the implications?

First of all, make sure you rebuild project, after importing (Build - Clean, Builde - Rebuild Probject). Fixing this issue with limitation methods reference:
android {
defaultConfig {
...
// Enabling multidex support.
multiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.0'
}
And also update you Application.class in java to support MultiDex. See full information here!
UPDATE:
This options ignore on Eclipse, because methods references limit can be calculated from environment (like AS in our case). Why this options doesn't include in Gradle build - still question...
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. In the context of computer science, the term Kilo, K, denotes 1024 (or 2^10). Because 65,536 is equal to 64 X 1024, this limit is referred to as the '64K reference limit'.
Source AS Doc

I suspect your dex error is a result of the growth of a library, but without more info, this is hard to debug. The newest version of Android Studio (2.2) provides an APK analyzer tool that makes the dex limit more transparent.
When using Google Play services APIs you should double check to make sure that you're only including the ones used with these directives
compile 'com.google.android.gms:play-services-fitness:9.6.1'
rather than including everything (full list).
If you need all the libraries you're already depending on then, this is typically resolved by enabling multidex in your development environment (requiring development using a device or emulator with L or greater), but then using minificationEnabled in your release builds such that multidex isn't required in your release APK. This results in a combination of fast debug builds and non-multidex your release builds to prevent slow startup times for your release build.
A bit more info:
When you use native multidex in debug builds (requires minSdk set to L or greater) it results in faster incremental builds because modules and libraries deploy as separate dex files and less processing between deploys.
When you use minificationEnabled in your release build it often eliminates the need for the second dex file because methods from your dependendencies that you don't use are trimmed. This typically results in a single dex nullifying the negative effects of multidex (copying the N+1 dex files on app initialization for < version L devices).

Multidex issue occurs when you use lots of libraries in your project. If your app's code have more than 64k methods then it happens.
When your application and the libraries it references reach a certain
size, you encounter build errors that indicate your app has reached a
limit of the Android app build architecture.
You can refer some links like :
How to enable multidexing with the new Android Multidex support library
http://www.rapidvaluesolutions.com/tech_blog/multidex-issue-or-building-application-over-65k-methods/
https://mutualmobile.com/posts/dex-64k-limit-not-problem-anymore-almost

Cocos2d-js: projects need to be that huge?

I'm trying out cocos2d-js (version 3.0) and even the simplest 'Hello World' project is over 1 gigabyte in size when it is created.
Is this normal? (I have a habit of creating dozens of demo-projects when trying out a new platform, but it looks like I need to get myself a bigger SSD, just for this!)
Also, the size of the apk, when compiled for Android, is about 9 MB. Any ways to reduce this size?

Sadly, yes. I've mentioned this in the community a couple of times to no avail. I believe this files should be referenced/cached in a common location for all projects, but the dev team seems to have other priorities at present.
If you wish to keep your projects you'll be better off heading to their frameworks directory and deleting all folders except cocos2d-html5 (this one should be 5MB only) in there. -
An alternative would be to also delete the cocos2d-html5 folder, place it in a common dir (or use the copy in your install folder) and reference the path properly in your projetc's config file. Keep in mind this option may break code suggesstion/autocomplete in some editors, and throw errors in your webserver when you try to run the project.-
This way, you'll be able to run any of those projects in the browser, and then only add the files neccessary for native compilation in projects you wish to test in the emulator or your device (or compile for publishing). This will sadly take a lot of time to copy and re-generate the files, of course.
As for reducing the size of the .apks... I don't know a way. I know efforts are being made to optimize the binder, and there may be a way to explicitly avoid packaging unused stuff, but I don't know about it.

You can reduce the app size in Cocos2d-js v3.2 released in January. It allows you to exclude the unused modules. Refer to the upgrade guide for more details on how to do this. The minimum apk size for Android is 4.4mb .