Access Point for Dalvik virtual machines

It is better to analyze the code of the Dalvik Virtual Machine from there? As software developers know, each program has a life cycle and a birth point, that is, the entry point of the program. For example, the console program in C language uses the main function as the entry point, and the Java program uses the main function as the entry point. In fact, when the Dalvik virtual machine is started as an application, it also starts from the main function. From the Dalvik Virtual Machine source code directory Dalvik/dalvikvm/Main. c file, you can see the entry function, as shown below:

/*

* Parse arguments. Most of it just gets passed through to the VM.

* JNI spec defines a handful of standard arguments.

*/

Intmain (INT argc, char * const argv [])

{

JavaVM * Vm = NULL;

Jnienv * Env = NULL;

Javavminitargs initargs;

Javavmoption * Options = NULL;

Char * slashclass = NULL;

Int optioncount, curopt, I, argidx;

Int needextra = jni_false;

Int result = 1;

 

Setvbuf (stdout, null, _ ionbf, 0 );

 

/* Ignore argv [0] */

Argv ++;

Argc --;

......

 

Therefore, when compiling a Dalvik virtual machine as a Linux x86 application, you need to pay attention to it. Here is its entry point.

 

Maybe you will ask, why does the Dalvik Virtual Machine need to run the program as an x86 application in Linux? Isn't it running in the arm of the mobile phone platform? This is a good question. In fact, the Dalvik virtual machine runs the x86 application in Linux and is used for development and debugging. It is not used as the entry point from the main function when used as a mobile phone platform. Embedded developers know that developing and debugging on a resource-limited platform is not easy and takes a lot of time. Is there a better way to develop and debug it? The answer is yes. It is to use the current X86 platform, so that a large number of tools and resources can be used for x86, greatly improving development efficiency and making it easier to debug system functions. When developing new features on the Dalvik virtual machine, you can first run and debug on the X86 platform, and then compile and run on the ARM platform. After I modified the code of this virtual machine, I compiled and run it in the system. I found that the time for compiling the entire platform was very long, in the 4-core CPU, 4G memory Linux system, using multi-core compilation technology such as make-j4, also takes several minutes, so every few lines of code modified, add some small functions, you need to compile and test the program once, and the time is too much. Obviously, you need to find another way out. Then, you can use the X86 platform to generate an application for testing. Another problem is the single-step debugging function, which is also troublesome on the ARM platform, and sometimes programs run and run.

 

Next, we will analyze another entry point, that is, the entry point for running Android Dalvik virtual machine on the ARM platform. It is obviously not loaded through the main function, but starts from the service zygote loaded by the initialization process. From the zygote service code, you can see the following code:

Runtime. Start ("com. Android. Internal. OS. zygoteinit ",

Startsystemserver );

Create a Dalvik Virtual Machine Based on the command line parameters, run com. Android. Internal. OS. zygoteinit, and start all Dalvik virtual services. Here, the runtime object is the class appruntime, and the class appruntime inherits the class androidruntime. What is the class androidruntime? Androidruntime is the code in the core framework of the Android platform. It is the cornerstone of JNI implementation. That is to say, all applications in the Dalvik Virtual Machine need to access the underlying system functions through JNI. You can find this class from the following file:

Frameworks/base/CORE/JNI/androidruntime. cpp

In this file, we can see the implementation of the START function called above, as shown below:

/*

* Start the android runtime. This involves starting the virtualmachine

* And calling the "static void main (string [] ARGs)" method inthe class

* Named by "classname ".

*/

Voidandroidruntime: Start (const char * classname, const boolstartsystemserver)

{

Logd ("/n >>>>>>>>>>>>>> androidruntime start </N ");

 

Char * slashclassname = NULL;

Char * CP;

Jnienv * env;

 

Blocksigpipe ();

 

/*

* 'Startsystemserver = true' means runtimeis obslete and not run from

* Init. RC anymore, so we print out the bootstart event here.

*/

If (startsystemserver ){

/* Track our progress through the bootsequence */

Const int log_boot_progress_start = 3000;

Log_event_long (log_boot_progress_start,

Ns2ms (systemtime (system_time_monotonic )));

}

 

Const char * rootdir = getenv ("android_root ");

If (rootdir = NULL ){

Rootdir = "/system ";

If (! Hasdir ("/system ")){

Log_fatal ("No root directoryspecified, And/Android does not exist .");

Goto bail;

}

Setenv ("android_root", rootdir, 1 );

}

 

// Const char * kernelhack = getenv ("ld_assume_kernel ");

// Logd ("foundld_assume_kernel = '% s'/N", kernelhack );

 

/* Start the Virtual Machine */

If (startvm (& mjavavm, & env )! = 0)

Goto bail;

 

/*

* Register Android functions.

*/

If (starregulatory (ENV) <0 ){

LogE ("unable to register all androidnatives/N ");

Goto bail;

}

 

From the code snippet above, we can see that the call function startvm is used to create the Dalvik Virtual Machine and continue to view the code snippet of the startvm function. We can find the following section:

/*

* Initialize the VM.

*

* The JavaVM * is essential per-process, and the jnienv * Is per-thread.

* If this call succeeds, the VM is ready, and we can start issuing

* Jni cils.

*/

Logd ("jni_createjavavm start.../N ");

If (jni_createjavavm (pjavavm, penv, & initargs) <0 ){

LogE ("jni_createjavavm failed/N ");

Goto bail;

}

Logd ("jni_createjavavm end/N ");

 

Result = 0;

 

In this Code, the main task is to initialize the Dalvik Virtual Machine by calling the jni_createjavavm function. The jni_createjavavm function is implemented in the Dalvik/Vm/JNI. c file.

 

By now, we have analyzed another entry point. Through the above learning, we can see that different entries come from the needs of actual development. Through these large code projects, you can learn a lot of development skills to improve efficiency.