Develop Reference

Installation process of .apk within ART. Difference from Dalvik VM installation process

Recently I answered this question, where was described whole installation process of .apk file to android phone. The one thing it was about using Dalvik VM. And now I'm wondered is installation process is exactly same using ART? What are the differences?
I mean the work of PackageManager, path, convertion to dex format etc.
Googling didn't give much info, only about performance power, managing memory and something similar.
I would be very thankful if someone with knowledge could share this information.

Android apps come in the .apk file format, with Java classes converted into DEX bytecode. The DEX bytecode format is independent of device architecture and needs to be translated to native machine code to run on the device. This is the same for both the ART and the Dalvik runtimes.
The most significant change from Dalvik to ART is that Dalvik is based on Just-in-Time (JIT) compilation, while ART is based on Ahead-of-Time (AOT) compilation.
With the Dalvik JIT compiler, each time when the app is run, it dynamically translates a part of the Dalvik bytecode into machine code. As the execution progresses, more bytecode is compiled and cached. On the other hand, ART is equipped with an Ahead-of-Time compiler. During the app’s installation phase, it statically translates the DEX bytecode into machine code and stores in the device’s storage. This is a one-time event which happens when the app is installed on the device.
Performance
The most important benefit of ART runtime over Dalvik runtime is that the app runs faster on ART. Because DEX bytecode has been translated into machine code during installation, no extra time is needed to compile it during the runtime. The app starts faster as well when launched with ART for the same reason.
Because Dalvik requires extra memory for JIT code cache, an app occupies a smaller memory footprint when it runs on ART.
Battery Life
With Dalvik runtime, the JIT compilation is CPU bound. Because of AOT compilation, ART frees the CPU from translating DEX bytecode to machine code during the app’s execution, thus reducing energy consumption. Using ART leads to a longer battery life, which is the time interval when a battery recharging is needed.
Installation Time
Because the AOT compiler translates DEX bytecode into machine code during the app installation, an app takes longer to install on a device with ART runtime. Considering the benefits of faster execution and shorter launch time we discussed in the previous section, this extra time which happens only once during the app’s installation is well worth it.
Storage Footprint
With ART runtime, the AOT compiler translates the app’s DEX bytecode into machine code and stores it in the device’s storage. The pre-compiled binary occupies more space than the DEX bytecode. Thus results in a larger storage footprint comparing with Dalvik runtime.
Summary
To this point we have introduced the new ART runtime for Android. We also discussed its benefits and compromises, centralizing in its Ahead-of-Time compilation and performance improvement. Currently released for preview and still under active development and optimization, at this point of time we cannot provide a quantitative conclusion on how much performance gained by switching to ART Runtime. One thing for sure is ART will replace Dalvik as the Android runtime on the x86 based devices.
Source.

In dvm architecture, at each time when the application launches the entire application byte code converted into dex and then execute the dex files. So when at each Time of launch same thing going to done, so to overcome this problem ART comes into picture. In ART while at the time of application installation only converts byte to Dex and then at every launch execute that same dex files, here no need to require conversion at each launch., so less time take to launch an app in ART compare to dvm.

Native translation of dex formatted code in android

For my static analysis I want to know one thing. My question is while we are running an android app does android OS translates the optimized Dex instructions to native instructions on the go? If so can someone shed some light on the scenario?

android OS translates the optimized Dex instructions to native instructions on the go?
Almost yes
According to Wikipedia: Dalvik (software) as of Android 2.2, Dalvik has a just-in-time compiler (JIT) and according to Wikipedia: Android Runtime ART introduces use of the ahead-of-time (AOT) compilation by performing it upon the installation of an application.

Android app is native or JavaVM code?

Probably an stup!## question.
I dont know nothing about developing apps for Android, but I was wondering if the applications for Android, when they are compiled, the code generated is PURE ANDROID NATIVE CODE, or is Java Virtual Machine compatible code.
Thanks a lot.

It has its own virtual machine, Dalvik.

Most apps for Android are Java apps. They are compiled to .class files by the Java compiler, then the dx compiler takes the .class and compiles them to .dex files, which are executable by the Dalvik VM on Android (which is the Java VM).
Although the Dalvik VM is made to run Java code, it is significantly different than the standard Java VM on your computer. The standard VM is a "stack based" machine, whereas the Dalvik VM is "register based".
You can also make apps with the NDK, and write them in C or C++. This is not Java compatible in any way (although you can interface the native C code with the Java code with JNI).

There are at least three ways to do it:
All Java
All Native
Half Java, half native. Android libraries can be written in C and compiled into native code, then called from Java. Your application could be a mix of both, if you wish.
More info: http://en.wikipedia.org/wiki/Android_software_development#Native_development_kit

Why does Android need a Virtual Machine(DVM)?

Virtual Machines are used for running apps on different OS(Java compiles code into OS independent .class files which is interpreted into bytecode). Since android apps run on the same OS (i.e Android), it doesn't require a VM (I could be wrong here). Then why does it need a Dalvik VM?

Android Platform can run on different architectures - ARM, MIPs and x86. To abstract out the need to compile binaries for each architecture VM comes into play. It also does memory management for the developer.

We need someone to compile and convert the java classes into bytecode which can be executed by the interpreter.
It is similar to JVM ... you have .java files which will be compiled by java compiler into .class files. the .class files are nothing but bytecode which will be run by the JVM. JVM can reside on any platform(windows,linux or unix).
In android too the files are compiled into .dex files and run by DVM. just to give an idea, when is application is installed, the Android OS assigns unique linux user id, a DVM is assigned for each app. So in short each app has own linux process, DVM and linux user id.
The java files are compiled into .dex files which consume less memory compared to .class files.
Now assume 10 applications are having 10 individual DVM's and the OS has 10 process to handle.
The dispatcher or scheduler in the android OS is responsible for handling these 10 processes....which is why we have android activity life cycle.
You need DVM to maintain the running state of each process(each app).

Why android needs a virtual machine is on the basis that Google engineered Android API to vastly use a Java interface. Java itself is usually run on a virtual machine.
The JVM itself is a stack machine based VM while Android's VM (called Dalvik) is a register based VM (this is for the sake of less code generated and faster speed to get better performance out of whatever device is using Android)
The purpose of a virtual machine is to be able to abstract hardware by simulating it. If you make a virtual machine and compile it to work on every possible hardware, you get what originally made Java rise to popularity: write once run anywhere portability.
You could write code, without having to change it and run it on any hardware that your virtual machine can run on.
Digressing, Android is mostly built in C (and C++?) but the API that manipulates the OS is interfaced through Java, thus you require a virtual machine.

What is Android and why did they create a new VM?

Android's embedded OS relies on the
Linux kernel for core system services
but is not embedded Linux and thus
standard utility libraries like for
example GNU C are not supported. The
Java framework is used to write
Android applications but Android is
not Java. Standard Java libraries such
as Swing are not supported.Android has
a Virtual Machine known as Dalvik, so
when the Java class files are
generated, this are translated to
Dalvik Executable files known as .dex
files. From this point this files are
not treated as java bytecode but as
.dex files.
So I have three questions:
Now I know what Android is not,
so, what is Android?
What are
core system services?
Why did they choose .dex files
upon Java bytecode? I mean why did
they took the work to translate or
combine .class files to .dex files?

The What is Android? article on the developer site describes best what Android is.
Why did they choose .dex files upon
java bytecode? i mean why did they
took the work to translate or combine
.class files to .dex files?
That is because they needed a more efficient virtual machine. Their virtual machine called DalvikVM was optimized for low memory requirements.
You can read more about the DalvikVM in this Wikipedia entry. Make sure to checkout the external links section on that page.