How and what exactly converts the java byte-code to dex file in Android ?
I know that the only part Android people have done to save them from licensing issues, making the system fast for execution, low memory need and other more features as it is register based VM.
But what name I can tell to the part it doing so?
Go through bellow url and read all details
Detail URL
The general process for a typical build is outlined below:
The Android Asset Packaging Tool (aapt) takes your application resource files, such as the AndroidManifest.xml file and the XML files for your Activities, and compiles them. An R.java is also produced so you can reference your resources from your Java code.
The aidl tool converts any .aidl interfaces that you have into Java interfaces.
All of your Java code, including the R.java and .aidl files, are
compiled by the Java compiler and .class files are output.
The dex tool converts the .class files to Dalvik byte code. Any 3rd party libraries and .class files that you have included in your project are also converted into .dex files so that they can be packaged into the final .apk file.
All non-compiled resources (such as images), compiled resources, and
the .dex files are sent to the apkbuilder tool to be packaged into
an .apk file.
Once the .apk is built, it must be signed with either a debug or release key before it
can be installed to a device.
Finally, if the application is being signed in release mode, you
must align the .apk with the zipalign tool. Aligning the final .apk
decreases memory usage when the application is running on a device.
Related
As far as I know, both apktool and baksmali are able to produce smali code out of .apk (.dex) files, and apktool makes use of the dexlib2. They are both APK packing/unpacking tools
But still I am not clear what are the main differences between apktool and smali/baksmali. in temrs of functionality with .dex files and extended features?
PS:
One of the difference that I just found out is that apktool is able to work with multiple dex files inside an apk while baksmali cannot (at least for the time being)
I did try to read the source code but due to the lack of experience, I could not really understand the working flow of both tools. I would really appreciate If anyone could suggest some readings or flow charts, etc.
Thank you!
smali/baksmali are an assembler/disassembler pair for the dex format. Baksmali takes a dex file and produces human readable assembly, and smali takes the human readable assembly and produces a dex file.
Apktool is a more general took for unpacking and repacking an apk. It actually uses smali/baksmali under the hood in order to assemble/disassemble the dex file. It also unpacks the binary resources and binary xml files back into the standard textual format, etc.
In short, apktool is for APK files and baksmali is for DEX files.
APK file is a zip archive with specific structure. This represents the Android app. This is what your smart phone or tablet downloads from the market, usually Google Play. The archive consists of the manifest, resources, asserts/data files, native libraries and the DEX file.
DEX file contains the app code. See https://source.android.com/devices/tech/dalvik/dex-format.html for details.
One more thing to say, is that apktool is capable to extract and pack back the resources file. (I believe baksmali doesn't do that, need to check.)
I integrated with DexGuard and ProGuard, generated a signed APK and now I want to verify that the configuration worked as configured:
Use dex2jar (or similar tools) to decompile the app and verify for obfuscation/encryption
Verify the signed APK's size is smaller
Of course, ensure that the app functions as expected (especially for encrypted resources)
Are there any other steps folks here use?
In the past I've confirmed the String/class encryption is working by decompiling/unpacking the .apk (I use Apktool) and then grepping/searching the output files for known secrets/API keys etc. In fact this could be automated.
Here are the various tools one can use (copied straight from DexGuard docs when you get their JAR/License):
dexdump (Android SDK): disassembles Dalvik bytecode to a readable
text format.
aapt (Android SDK): disassembles binary resource XML
files to a readable text format.
baksmali (open source): disassembles Dalvik bytecode to a readable
source format.
smali (open source): assembles this source format
to Dalvik bytecode again.
apktool (open source): disassembles and
assembles entire applications: bytecode, Android manifest files,
resource files, and assets.
dex2jar (open source): converts
Dalvik byte code to Java bytecode.
jad (free): decompiles Java bytecode to Java source code.
As they always say, read the docs!
I am trying to understand why the Android SDK needs the JDK.
The Android SDK is not supposed to have all the JDK Java classes it needs (with potential implementation differences) ?
Does it need it for all the tools included in the JDK ?
Do we use the JDK when we build .dex & .apk files ?
What does it mean to say that Android Java classes must be written with Java 5 or 6 compiler compliance ?
Thanks
The general process for a typical build is outlined below:
The Android Asset Packaging Tool (aapt) takes your application resource files, such as the AndroidManifest.xml file and the XML
files for your Activities, and compiles them. An R.java is also
produced so you can reference your resources from your Java code.
The aidl tool converts any .aidl interfaces that you have into Java interfaces.
All of your Java code, including the R.java and .aidl files, are compiled by the Java compiler and .class files are output.
The dex tool converts the .class files to Dalvik byte code. Any 3rd party libraries and .class files that you have included in your
project are also converted into .dex files so that they can be
packaged into the final .apk file.
All non-compiled resources (such as images), compiled resources, and the .dex files are sent to the apkbuilder tool to be packaged
into an .apk file.
Once the .apk is built, it must be signed with either a debug or release key before it can be installed to a device.
Finally, if the application is being signed in release mode, you must align the .apk with the zipalign tool. Aligning the final .apk
decreases memory usage when the application is running on a device.
From here
The Android SDK uses the JDK to compile your .java files to .class bytecode.
When you build the project all .java files get converted to .class. For which you need JDK.
Now the dx tool of adk converts all .class files to classes.dex file .And this classes.dex file is executed on dalvik virtual machine.
This question already has answers here:
What are .dex files in Android?
(3 answers)
Closed 7 months ago.
When opening an APK file with WinRar (software to open compressed files). I got a bunch of files packed inside the APK. Among them classes.dex is one. My question is what is the role of this file and if we modify/delete the same file will it affect the APK?
.dex file
Compiled Android application code file.
From Android API GUIDES
Android programs are compiled into .dex (Dalvik Executable) files, which are in turn zipped into a single .apk file on the device. .dex files can be created by automatically translating compiled applications written in the Java programming language.
And yes if you will delete those files it will effect APK.
classes.dex is essentially all of the application logic. Code of the given application is written in java and then compiled to class files, then these class files are cross compiled (with many optimisations) to dalvik VM format. Note that there also might be some .so files which are also application code but these are generated when NDK is used.
You can not delete this file. You could however change it by first running this utility https://github.com/JesusFreke/smali which will generate smali code from this compiled dex which is somewhat similar to java and could be understood. You could also use tools ApkOneClick or ApkMultiTool to get Java source from the smali files but these would probably not be perfect and will require further fixing. When you change the code you want you should build the classes.dex again and put them into existing zip/apk file you have. Note that then existing certificate files (META-INF) will not be valid anymore and you will need to delete this folder and resign the apk package in order to instal it on the phone or emulator.
For more info you could check this question too What are .dex files in Android?
Also this is a great tutorial on disassembling dex files using existing tools http://blog.vogella.com/2011/02/14/disassemble-android-dex
What is the role of this file?
The role of classes.dex in Android is similar to that of JAR files in plain Java. It's a file containing bytecodes. In Android case, the bytecode is Dalvik bytecode, which is different from Java bytecode.
If we modify/delete the same file will it effect the apk?
If you modify classes.dex, you are modifying the programs behavior, which may or may not work after a repackage. If you delete classes.dex, then your application doesn't have code and you shouldn't expect it to work.
.dex file in the apk is the compress file which is made up of all the java classes in the application code. Its different than jar file. A jar file is a collection of .class files which are isolated. If we unzip .jar, we get all the classes separately. On the other side, .dex file is a single file made up with all .class file from application code.
Code compilation flow :
multiple .java files --> multiple .classes files --> a single .dex file
.dex files are the executables which are executed by the DVM...Dalvik Virtual Machine, which is a Runtime for Android.
.dex will never include resources. Resources are separately maintained in the /res folder in .apk
I have a JAR library which includes some non source code files in a couple different /src packages (JSON files in this case)
When I add that JAR as a dependency on one of my Android projects and build the apk file, those JSON files are not in the apk or the classes.dex (I ran dex2jar and saw that the files are missing)
How can I tell dex to also include those json files in the output?
AFAIK, a dex file is only designed to hold .class files (and strings). Here is an (old) description of the dex file format. (I was unable to find one on google's site) http://retrodev.com/android/dexformat.html
When google parses your dependency jars at compile time it only pays attention to .class files, since that is what dependencies are for - classes you want to use in your code which aren't defined in your code. I'm not sure it even pays attention to anything else you might have in those jars.
The question you want to ask is not how to tell dex to include the json files (it can't) but how to get those json files into your apk. Unfortunately, if they are stored in a jar I don't know of a way to do this short of setting up something in ant to manually unpack the jar and move the files yourself. Compile-time jar dependencies are not designed to simply copy files into your project package.