[Android]Dalvik的BOOTCLASSPATH和dexopt流程

浏览数：40 / 时间：2015年06月11日

BOOTCLASSPATH简介
1.BOOTCLASSPATH是Android Linux的一个环境变量，可以在adb shell下用$BOOTCLASSPATH看到。
2.BOOTCLASSPATH于/init.rc文件中export，如果没有找到的话，可以在init.rc中import的文件里找到（如import /init.environ.rc）。
3.init.rc文件存在于boot.img的ramdisk映像中。如果仅仅是修改/init.rc文件，重启后会被ramdisk恢复，所以直接修改是没有效果的。
4.boot.img是一种特殊的Android定制格式，由boot header，kernel，ramdisk以及second stage loader（可选）组成，详见android/system/core/mkbootimg/bootimg.h。

 

boot.img空间结构:

** +-----------------+
** | boot header     | 1 page
** +-----------------+
** | kernel          | n pages
** +-----------------+
** | ramdisk         | m pages
** +-----------------+
** | second stage    | o pages
** +-----------------+


典型的ramdisk文件结构:
./init.trout.rc
./default.prop
./proc
./dev
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data

 

BOOTCLASSPATH的作用
以Android4.4手机的BOOTCLASSPATH为例：
export BOOTCLASSPATH /system/framework/core.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar...
当kernel启动时1号进程init解析init.rc，将/system/framework下的jar包路径export出来。
Dalvik虚拟机在初始化过程中，会读取环境变量BOOTCLASSPATH，用于之后的类加载和优化。

 

Dalvik虚拟机的启动和dexopt流程
从Dalvik虚拟机的启动过程分析 一文可以知道，Zygote会在启动后创建Dalvik虚拟机实例，并进行初始化。

那我们就接着Dalvik虚拟机初始化后开始探究它是如何通过BOOTCLASSPATH来进行dex优化的：

1.1. VM initialization

android/dalvik/vm/Init.cpp

?
1
2
3
4
5
6
7
8
9
10
11
12
13
std::string dvmStartup(int argc, const char* const argv[],
bool ignoreUnrecognized, JNIEnv* pEnv)
{
    ...
    ALOGV("VM init args (%d):", argc);
    ...
 
    setCommandLineDefaults(); // ---> 读取BOOTCLASSPATH
    ...
    if (!dvmClassStartup()) { // ---> 初始化bootstrap class loader
        return "dvmClassStartup failed";
    }
}

 1.2. 读取BOOTCLASSPATH

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
static void setCommandLineDefaults()
{
    const char* envStr = getenv("CLASSPATH");
    if (envStr != NULL) {
        gDvm.classPathStr = strdup(envStr);
    } else {
        gDvm.classPathStr = strdup(".");
    }
    envStr = getenv("BOOTCLASSPATH"); // 读取到BOOTCLASSPATH环境变量<br>
    if (envStr != NULL) {
        gDvm.bootClassPathStr = strdup(envStr);
    } else {
        gDvm.bootClassPathStr = strdup(".");
    }
    ...
}

 就这样，BOOTCLASSPATH的值被保存到gDvm.bootClassPathStr中。

 

2.1. 初始化bootstrap class loader

android/dalvik/vm/oo/Class.cpp

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
bool dvmClassStartup()
{
    ...
     
    /*
    * Process the bootstrap class path. This means opening the specified
    * DEX or Jar files and possibly running them through the optimizer.
    */
    assert(gDvm.bootClassPath == NULL);
    processClassPath(gDvm.bootClassPathStr, true); // 下一步
 
    if (gDvm.bootClassPath == NULL)
        return false;
}

 2.2. 将路径、Zip文件和Dex文件的list转换到ClassPathEntry结构体当中

?
1
2
3
4
5
6
static ClassPathEntry* processClassPath(const char* pathStr, bool isBootstrap)
{
    ClassPathEntry* cpe = NULL;
    ...
    　　　　if (!prepareCpe(&tmp, isBootstrap)) {}
}

 2.3. 根据cpe打开文件

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
static bool prepareCpe(ClassPathEntry* cpe, bool isBootstrap)
{
    ...
  
    if ((strcmp(suffix, "jar") == 0) || (strcmp(suffix, "zip") == 0) ||
    (strcmp(suffix, "apk") == 0)) {
        JarFile* pJarFile = NULL;
        /* 打开jar包，找到class.dex或jar包旁边的.odex文件 */
        if (dvmJarFileOpen(cpe->fileName, NULL, &pJarFile, isBootstrap) == 0) {
            cpe->kind = kCpeJar;
            cpe->ptr = pJarFile;
            return true;
        }
    } else if (strcmp(suffix, "dex") == 0) {
        RawDexFile* pRawDexFile = NULL;
        /* 与dvmJarFileOpen函数作用类似，是由它复制过来重构的 */
        if (dvmRawDexFileOpen(cpe->fileName, NULL, &pRawDexFile, isBootstrap) == 0) {
            cpe->kind = kCpeDex;
            cpe->ptr = pRawDexFile;
            return true;
        }
    } else {
        ALOGE("Unknown type suffix ‘%s‘", suffix);
    }
    ...
}

 

3. 打开jar包，找到class.dex或jar包旁边的.odex文件

android/dalvik/vm/JarFile.cpp

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
int dvmJarFileOpen(const char* fileName, const char* odexOutputName,
    JarFile** ppJarFile, bool isBootstrap)
{
    ...
  
    /* Even if we‘re not going to look at the archive, we need to
     * open it so we can stuff it into ppJarFile.
     */
    if (dexZipOpenArchive(fileName, &archive) != 0)
        goto bail;
    archiveOpen = true;
  
    /* If we fork/exec into dexopt, don‘t let it inherit the archive‘s fd.
     */
    dvmSetCloseOnExec(dexZipGetArchiveFd(&archive));
  
    /* First, look for a ".odex" alongside the jar file.  It will
     * have the same name/path except for the extension.
     */
    fd = openAlternateSuffix(fileName, "odex", O_RDONLY, &cachedName);
    if (fd >= 0) {
        ALOGV("Using alternate file (odex) for %s ...", fileName);
        /* 读、验证header和dependencies */
        if (!dvmCheckOptHeaderAndDependencies(fd, false, 0, 0, true, true)) {
            ALOGE("%s odex has stale dependencies", fileName);
            free(cachedName);
            cachedName = NULL;
            close(fd);
            fd = -1;
            goto tryArchive;
        } else {
            ALOGV("%s odex has good dependencies", fileName);
            //TODO: make sure that the .odex actually corresponds
            //      to the classes.dex inside the archive (if present).
            //      For typical use there will be no classes.dex.
        }
    } else {
        ZipEntry entry;
  
tryArchive:
        /*
         * Pre-created .odex absent or stale.  Look inside the jar for a
         * "classes.dex".
         */
        ...
}

 

 4.读、验证opt的header，读、验证dependencies

android/dalvik/vm/analysis/DexPrepare.cpp

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
bool dvmCheckOptHeaderAndDependencies(int fd, bool sourceAvail, u4 modWhen,
u4 crc, bool expectVerify, bool expectOpt)
{
     ...
    /*
     * Verify dependencies on other cached DEX files.  It must match
     * exactly with what is currently defined in the bootclasspath.
     */
    ClassPathEntry* cpe;
    u4 numDeps;
 
    numDeps = read4LE(&ptr);
    ALOGV("+++ DexOpt: numDeps = %d", numDeps);
    for (cpe = gDvm.bootClassPath; cpe->ptr != NULL; cpe++) {
        const char* cacheFileName =
            dvmPathToAbsolutePortion(getCacheFileName(cpe));
        assert(cacheFileName != NULL); /* guaranteed by Class.c */
 
        const u1* signature = getSignature(cpe);
        size_t len = strlen(cacheFileName) +1;
        u4 storedStrLen;
 
        if (numDeps == 0) {
            /* more entries in bootclasspath than in deps list */
            ALOGI("DexOpt: not all deps represented");
            goto bail;
        }
 
        storedStrLen = read4LE(&ptr);
        if (len != storedStrLen ||
            strcmp(cacheFileName, (const char*) ptr) != 0)
        {
            ALOGI("DexOpt: mismatch dep name: ‘%s‘ vs. ‘%s‘",
                cacheFileName, ptr);
            goto bail;
        }
 
        ptr += storedStrLen;
 
        if (memcmp(signature, ptr, kSHA1DigestLen) != 0) {
            ALOGI("DexOpt: mismatch dep signature for ‘%s‘", cacheFileName);
            goto bail;
        }
        ptr += kSHA1DigestLen;
 
        ALOGV("DexOpt: dep match on ‘%s‘", cacheFileName);
 
        numDeps--;
    }
 
    if (numDeps != 0) {
        /* more entries in deps list than in classpath */
        ALOGI("DexOpt: Some deps went away");
        goto bail;
    }
    ...
}

 

实际应用
打通了Dalvik dexopt的这个流程，那这到底又有什么用呢？
让我们看看实际开发过程中的手机升级binary后无法boot到Home界面的log：

 1 AndroidRuntime >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
 2 AndroidRuntime CheckJNI is ON
 3 dalvikvm DexOpt: Some deps went away
 4 dalvikvm /system/framework/core-junit.jar odex has stale dependencies
 5 dalvikvm DexOpt: --- BEGIN ‘core-junit.jar‘ (bootstrap=1) ---
 6 dalvikvm DexOpt: load 42ms, verify+opt 25ms, 143956 bytes
 7 dalvikvm DexOpt: --- END ‘core-junit.jar‘ (success) ---
 8 dalvikvm DEX prep ‘/system/framework/core-junit.jar‘: unzip in 1ms, rewrite 126ms
 9 dalvikvm DexOpt: mismatch dep name: ‘/data/dalvik-cache/system@framework@[email protected]‘ vs. ‘/system/framework/conscrypt.odex‘
10 dalvikvm /system/framework/bouncycastle.jar odex has stale dependencies
11 dalvikvm DexOpt: --- BEGIN ‘bouncycastle.jar‘ (bootstrap=1) ---
12 dalvikvm DexOpt: Some deps went away
13 dalvikvm /system/framework/core-junit.jar odex has stale dependencies
14 dalvikvm DexOpt: load 33ms, verify+opt 350ms, 681812 bytes
15 dalvikvm DexOpt: --- END ‘bouncycastle.jar‘ (success) ---
16 dalvikvm DEX prep ‘/system/framework/bouncycastle.jar‘: unzip in 57ms, rewrite 548ms
17 dalvikvm DexOpt: mismatch dep name: ‘/data/dalvik-cache/system@framework@[email protected]‘ vs. ‘/system/framework/conscrypt.odex‘
18 dalvikvm /system/framework/ext.jar odex has stale dependencies
19 dalvikvm DexOpt: --- BEGIN ‘ext.jar‘ (bootstrap=1) ---
20 dalvikvm DexOpt: Some deps went away
21 dalvikvm /system/framework/core-junit.jar odex has stale dependencies
22 dalvikvm DexOpt: mismatch dep name: ‘/data/dalvik-cache/system@framework@[email protected]‘ vs. ‘/system/framework/conscrypt.odex‘
23 dalvikvm /system/framework/bouncycastle.jar odex has stale dependencies

根据前面的流程，结合log我们就可以分析出，DexOpt: mismatch dep name: ‘/data/dalvik-cache/system@framework@[email protected]‘ vs. ‘/system/framework/conscrypt.odex‘是错误所在，是由于data/dalvik-cache/下的dex cache文件和system/framework/下的jar文件验证依赖关系时候对应不上。

从函数dvmCheckOptHeaderAndDependencies()可以得知，BOOTCLASSPATH和cache必须是完全一致的
尝试删除所有cache文件，重启还是不行。那么应该想到BOOTCLASSPATH和实际的system/framework/的jar包不一致，才会导致和其生成的cache不一致。
对比一下果然不一致，issue trouble-shooted.

解决方法：把对应boot.img也烧进去，这样BOOTCLASSPATH就能更新一致，dex优化就能正确进行下去。

[Android]Dalvik的BOOTCLASSPATH和dexopt流程,,5-wow.com

郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。

标签： Android iOS 移动互联 终端开发

相关文章

随机文章

您可能还喜欢

您可能还喜欢