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.

Android: Why is the size of apk file smaller than the entire project

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.

splitting jars into multiple dex files

I am working with the Apache POI jars and since they have more than 65000 methods, they do not compile and I get the error:
trouble writing output: Too many methods: 65561; max is 65536. By
package:...
I followed this tutorial, but I didn't understand how exactly it would work on the jars and split them as I still get the same error when I run build.xml
Could someone please tell me how I can split the jars into multiple dex files?

For POI only it could be enough to include the line
dex.force.jumbo=true
in project.properties.
It worked for me until I added Drive SDK.

Android Error "Conversion to Dalvik format failed with error 2"?

I am using flurry sdk in my application, before adding this flurry jar file it's working fine with out any errors. after adding flurry jar file in libs folder i am getting this error when i am compiling application in Eclipse.
trouble writing output: Too many methods: 70205; max is 65536. By package:
5 android.accessibilityservice
1 android.animation
2 android.annotation
315 android.app
136 android.content
28 android.content.pm
47 android.content.res
35 android.database
14 android.database.sqlite
8 android.gesture
113 android.graphics
44 android.graphics.drawable
1 android.graphics.drawable.shapes
11 android.location
27 android.media
40 android.net
1 android.net.http
1 android.net.wifi
96 android.os
[2013-03-04 16:42:13 - myapp] Conversion to Dalvik format failed with error 2
I have idea about how to solve error 1 but this is the new error for me unable to solve. i searched a lot did't get any solution for this.
when i remove this jar file it's working fine. if it has in libs not able to run the application.
Why i am getting this error.? what is the sollution for this..

Since the error is trouble writing output: Too many methods: 70205; max is 65536, "the sollution for this" is to reduce your method count by about 10%.
Usually this is the fault of having too many JARs with too many methods, though it is certainly conceivable that you wrote tens of thousands of methods yourself.
Try to find some JAR that you do not need and remove it. For example, you can use ProGuard to report the dead code within your app -- perhaps there is a dependent JAR of some library that the library ordinarily needs, but the way you happen to use the library is not needed.
ProGuard itself can also be used just to remove that dead code from your app, without all the normal obfuscation stuff. However, this is not part of the normal build process, so you'd have to somehow cook up an Ant script for this.

I was having that error because I was including Google Apis into my project.

What I have observed is, we should not put jars file directly inside a folder like
libs/x.jar
When I created a sub-folder within the libs or any folder for that sake like
libs/temp/x.jar
You can load how many jar files in that temp folder. That way I was able to avoid the error. It just need not be libs folder itself. The name can be anything.
This has to be done only if the jar files are high in number. Otherwise you can put directly in the libs folder.

Editing framework.jar in android

I'm trying to modify framework.jar. My purpose is to modify the contents of SQLiteDatabase.java inside this jar. I've googled this quite a lot, and found that the way is to edit the .smali file and repackage and pushing the updated jar to the system. But the source of .smali seems to be hard enough to edit (as it's assembly code), so I was wondering if there's any other workaround to avoid this, and edit the Java source instead and then pushing it to the device. I'd really appreciate some help, thanks.

One possible hybrid approach might be to download a version of AOSP as close to what's used on your device as possible, make the changes you want to SQLiteDatabase.java in the AOSP source, and then build a framework.jar from AOSP, disassemble it with baksmali, and then copy over the SQLiteDatabase.smali from the AOSP build to your device-specific framework.jar.
There's one other kink you should be aware of - If your device is pre-odexed/pre-oated, then you'll need to deodex the entire framework and all pre-odexed/pre-oated apps, because modifying framework.jar will invalidate any existing oat/odex file.