How does Dalvik worked in Android?

First we take a look at the non-Dalvik process (via “adb shell” and “ps” to identify the processes, and then “cat /proc/xxxx/” to go to the specific running process. For example, for ServiceManager, the virtual memory layout gives:

# cat maps
00008000-0000a000 r-xp 00000000 1f:00 405 /system/bin/servicemanager
0000a000-0000b000 rwxp 00002000 1f:00 405 /system/bin/servicemanager
0000b000-0000c000 rwxp 0000b000 00:00 0 [heap]
40000000-40008000 r-xs 00000000 00:07 187 /dev/ashmem/system_properties (deleted)
40008000-40028000 r-xp 00000000 00:0a 52 /dev/binder
<…>
b0000000-b000f000 r-xp 00000000 1f:00 417 /system/bin/linker
b000f000-b0010000 rwxp 0000f000 1f:00 417 /system/bin/linker
b0010000-b0019000 rwxp b0010000 00:00 0
bef47000-bef5c000 rwxp befeb000 00:00 0 [stack]

And then for Debuggerd, the virtual memory address gives:

# cat /proc/28/maps
00008000-0000c000 r-xp 00000000 1f:00 402 /system/bin/debuggerd
0000c000-0000d000 rwxp 00004000 1f:00 402 /system/bin/debuggerd
40000000-40008000 r-xs 00000000 00:07 187 /dev/ashmem/system_properties (deleted)
<…>
b0000000-b000f000 r-xp 00000000 1f:00 417 /system/bin/linker
b000f000-b0010000 rwxp 0000f000 1f:00 417 /system/bin/linker
b0010000-b0019000 rwxp b0010000 00:00 0
bec8e000-beca3000 rwxp befeb000 00:00 0 [stack]

And next we take a look at the Dalvik-controlled process, eg, Softkeyboard – looking into softkeyboard virtual address space:

# cat maps
00008000-00009000 r-xp 00000000 1f:00 400 /system/bin/app_process
00009000-0000a000 rwxp 00001000 1f:00 400 /system/bin/app_process
0000a000-002d3000 rwxp 0000a000 00:00 0 [heap]
10000000-10001000 —p 10000000 00:00 0
10001000-10100000 rwxp 10001000 00:00 0
40000000-40008000 r-xs 00000000 00:07 187 /dev/ashmem/system_properties (deleted)
40008000-40009000 r-xp 40008000 00:00 0
40009000-402aa000 rwxp 00000000 00:07 283 /dev/ashmem/mspace/dalvik-heap/zygote/0 (deleted)
402aa000-41009000 —p 002a1000 00:07 283 /dev/ashmem/mspace/dalvik-heap/zygote/0 (deleted)
41009000-41038000 r-xs 00000000 1f:00 433 /system/fonts/DroidSans.ttf
41038000-4104c000 rwxp 41038000 00:00 0
4104c000-4104d000 —p 00000000 00:07 285 /dev/ashmem/dalvik-LinearAlloc (deleted)
4104d000-412c2000 rwxp 00001000 00:07 285 /dev/ashmem/dalvik-LinearAlloc (deleted)
412c2000-4154c000 —p 00276000 00:07 285 /dev/ashmem/dalvik-LinearAlloc (deleted)
4154c000-416d0000 r-xs 00000000 1f:00 620 /system/framework/core.jar
416d0000-41a5d000 r-xs 00000000 1f:01 275 /data/dalvik-cache/system@framework@core.jar@classes.dex
41a5d000-41a91000 rwxp 41a5d000 00:00 0
41a91000-41af6000 r-xs 00000000 1f:00 629 /system/framework/ext.jar
41af6000-41bee000 r-xs 00000000 1f:01 276 /data/dalvik-cache/system@framework@ext.jar@classes.dex
41bee000-41e6c000 r-xs 00000000 1f:00 632 /system/framework/framework.jar
41e6c000-42456000 r-xs 00000000 1f:01 277 /data/dalvik-cache/system@framework@framework.jar@classes.dex
42456000-424d4000 rwxp 42456000 00:00 0
<…>
42e1f000-42e60000 rwxp 00000000 00:07 379 /dev/ashmem/mspace/dalvik-heap/zygote/1 (deleted)
42e60000-43b7f000 —p 00041000 00:07 379 /dev/ashmem/mspace/dalvik-heap/zygote/1 (deleted)
43b7f000-43bc0000 rwxp 00000000 00:07 574 /dev/ashmem/mspace/dalvik-heap/2 (deleted)
43bc0000-4489f000 —p 00041000 00:07 574 /dev/ashmem/mspace/dalvik-heap/2 (deleted)
44a9f000-44b9d000 r-xp 00000000 00:0a 52 /dev/binder
44d9d000-44e9d000 rwxs 00000000 00:07 617 /dev/ashmem/CursorWindow (deleted)
44e9d000-44f9d000 rwxs 00000000 00:07 768 /dev/ashmem/CursorWindow (deleted)
<…>
afe00000-afe38000 r-xp 00000000 1f:00 479 /system/lib/libc.so
afe38000-afe3b000 rwxp 00038000 1f:00 479 /system/lib/libc.so
afe3b000-afe46000 rwxp afe3b000 00:00 0
b0000000-b000f000 r-xp 00000000 1f:00 417 /system/bin/linker
b000f000-b0010000 rwxp 0000f000 1f:00 417 /system/bin/linker
b0010000-b0019000 rwxp b0010000 00:00 0
be7ee000-be803000 rwxp befeb000 00:00 0 [stack]

We can see that it is headed by “app_process”.

Reading the source code for “app_process” (notice the comment “interpreted runtime”) – frameworks/base/cmds/app_process/app_main.cpp – we can see that app_process is the thin layer of interpretation for the DEX bytecode:

/*
* Main entry of app process.
*
* Starts the interpreted runtime, then starts up the application.
*
*/

void app_usage()
{
fprintf(stderr,
“Usage: app_process [java-options] cmd-dir start-class-name [options]\n”);
}

status_t app_init(const char* className, int argc, const char* const argv[])
{
LOGV(“Entered app_init()!\n”);

AndroidRuntime* jr = AndroidRuntime::getRuntime();
jr->callMain(className, argc, argv);

LOGV(“Exiting app_init()!\n”);
return NO_ERROR;}

As “jr” AndroidRuntime is already started, callMain() will be called:

status_t AndroidRuntime::callMain(
const char* className, int argc, const char* const argv[])
{
JNIEnv* env;
jclass clazz;
jmethodID methodId;

LOGD(“Calling main entry %s”, className);

env = getJNIEnv();
if (env == NULL)
return UNKNOWN_ERROR;

clazz = findClass(env, className);
if (clazz == NULL) {
LOGE(“ERROR: could not find class ‘%s’\n”, className);
return UNKNOWN_ERROR;
}

methodId = env->GetStaticMethodID(clazz, “main”, “([Ljava/lang/String;)V”);
if (methodId == NULL) {
LOGE(“ERROR: could not find method %s.main(String[])\n”, className);
return UNKNOWN_ERROR;
}
<…>
env->CallStaticVoidMethod(clazz, methodId, strArray);
return NO_ERROR;
}

From above, we can see how the DEX classes’ codes are loaded and CallStaticVoidMethod() will start interpreting the DEX codes.

The possible conclusion is that any C program that does not call the AndroidRuntime() therefore cannot use DalvikVM.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: