Android Talk: How Android Uses and Installs Apps

Many of us power users have asked a similar question: “How does Android work with apps and programs?”. Well, that’s what I’m here to tell you.

Many of you have probably heard, that Android uses Java. But have you ever heard anyone saying that Minecraft (The Linux .Jar) works on Android? No, you haven’t. And you most likely never will. This is because Android uses the so-called ‘Dalvik-VM’, VM meaning Virtual Machine. Yes, you got that: Virtual machine. Java doesn’t work natively on a computer. It runs in its own little cosy-cub. That’s why many people see such a potential in Java – That’s also one of the reasons the Android team chose to use Java. But because Android (usually) runs on ARM-based devices, one cannot simply install Java to the system and expect everything to work. So instead, they decided to use Dalvik.

Dalvik is the process virtual machine (VM) in Google’s Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed. – Wikipedia.

Jut from reading that, most of you will get a brief idea, of what Dalvik really is. But let’s ask a different question. Why are the apps installed using a Java virtual machine?

This question is actually quite simple to answer. We have all had this problem: We use a program on our beloved computer and all of a sudden, the whole system crashes and requires a reboot. This can have multiple causes, but the main one, however, is that the process had an internal error, while trying to attach to a specific piece of memory. But this can only happen in natively-running apps. Apps that run in a virtual machine can also crash, that’s not what I’m trying to say at all, but when the apps crash in a virtual machine, it’s virtual. It does not affect the system – Only the virtual computer. But as good as a virtual machine can be at some times, it also has many pros. One of the… how can I put this? Superior arguments for not using a virtual machine is speed. Sure, if you’ve got a computer with a bucket-load of power, it should get easy tasks done, right? Not necessarily. A virtual machine still runs as a program which has to request access to different memory locations which then allow the virtually-running program to request access to memory from the virtual machine which then asks the host OS for the needed space. Even though this usually only takes a second or two, per operation that is, it can be really annoying when different requests are pending for an answer. That’s where native code is much better. Native code only has to request for a memory location once, and then never again. That means less queuing and more speed – Ultimately resulting in more responsiveness.

Here comes a question to you, the readers: If you were a program, with the choice to choose whether it gets run in a virtual machine or natively on the OS, which would you choose. To make the decision a bit harder, you are approx. 50MB in size, your main task is IO (In-out) and you process large files (Pictures, renders, archives, videos, etc. …) and you’ve just gone into beta.

Let us know in the comments!



Leave a Reply

Your email address will not be published. Required fields are marked *

*