Android系统ODEX文件格式解析

对于一个Android的apk应用程序，其主要的执行代码都在其中的class.dex文件中。在程序第一次被加载的时候，为了提高以后的启动速度和执行效率，Android系统会对这个class.dex文件做一定程度的优化，并生成一个ODEX文件，存放在/data/dalvik-cache目录下。以后再运行这个程序的时候，就只要直接加载这个优化过的ODEX文件就行了，省去了每次都要优化的时间。

不过，这个优化过程会根据不同设备上Dalvik虚拟机的版本、Framework库的不同等因素而不同。在一台设备上被优化过的ODEX文件，拷贝到另一台设备上不一定能够运行。

那么，这个对应的ODEX文件到底包含了哪些内容呢？本文就通过分析Android代码中，对应生成ODEX文件的代码，来一步步解释其中的奥秘。

Android是通过dexopt程序对DEX文件进行优化的，除去一些参数的解释，我们选择其中的processZipFile函数作为切入点，这个函数是dexopt程序用来处理一个待优化的apk文件的（代码位于dalvik\dexopt\OptMain.cpp中）：

static int processZipFile(int zipFd, int cacheFd, const char* zipName,const char *dexoptFlags)
{……const char* bcp = getenv("BOOTCLASSPATH");……bool isBootstrap = false;const char* match = strstr(bcp, zipName);if (match != NULL) {……isBootstrap = true;}int result = extractAndProcessZip(zipFd, cacheFd, zipName, isBootstrap,bcp, dexoptFlags);……return result;
}

先来说说这个函数的几个入参，zipFd是要优化的那个apk应用程序的文件句柄，cacheFd是要优化后存放的那个ODEX文件的句柄，dexoptFlags表示的是优化模式。

首先，函数要获得系统中环境变量BOOTCLASSPATH的值（这个值通常是设置在init.rc中）。接下来，还要判断一下是要优化的这个程序是否就是BOOTCLASSPATH中的某一个，我们要分析的是优化自己写的程序，所以isBootstrap的值是false。

该函数接下来调用extractAndProcessZip函数。这个函数看起来比较长，我们可以顺着它的处理逻辑来分段解释一下：

static int extractAndProcessZip(int zipFd, int cacheFd,const char* debugFileName, bool isBootstrap, const char* bootClassPath,const char* dexoptFlagStr)
{ZipArchive zippy;ZipEntry zipEntry;size_t uncompLen;long modWhen, crc32;off_t dexOffset;int err;int result = -1;int dexoptFlags = 0;DexClassVerifyMode verifyMode = VERIFY_MODE_ALL;DexOptimizerMode dexOptMode = OPTIMIZE_MODE_VERIFIED;……err = dexOptCreateEmptyHeader(cacheFd);if (err != 0)goto bail;……

首先，函数中会调用函数dexOptCreateEmptyHeader（代码位于dalvik\libdex\OptInvocation.cpp中）：

int dexOptCreateEmptyHeader(int fd)
{DexOptHeader optHdr;ssize_t actual;……memset(&optHdr, 0xff, sizeof(optHdr));optHdr.dexOffset = sizeof(optHdr);actual = write(fd, &optHdr, sizeof(optHdr));if (actual != sizeof(optHdr)) {int err = errno ? errno : -1;return errno;}return 0;
}

这个函数就是构造了一个DexOptHeader结构体，将结构体中的所有字节全部赋值成0xff。不过，函数内还是给结构体中的dexOffset变量赋了值，其值是DexOptHeader结构体的大小。最后，将其写入要优化成的那个ODEX文件中。当然，这个头几乎是空的，没什么用，后面这个头还会被改写。

我们来看看这个结构体是什么样的（代码位于dalvik\libdex\DexFile.h中）：

struct DexOptHeader {u1  magic[8];u4  dexOffset;u4  dexLength;u4  depsOffset;u4  depsLength;u4  optOffset;u4  optLength;u4  flags;u4  checksum;
};

1）前面的8个字节magic[8]是魔数头，表明这个文件是一个ODEX文件，其会被设置成“dey\n036\0”；

2）接着的4个字节dexOffset表示ODEX文件中包含的那个DEX文件在ODEX文件中的偏移；

3）接着的4个字节dexLength表示ODEX文件中包含的那个DEX文件的长度；

4）接着的4个字节depsOffset表示依赖库列表段的偏移；

5）接着的4个字节depsLength表示表示依赖库列表段的长度；

6）接着的4个字节optOffset表示优化数据段的偏移；

7）接着的4个字节optLength表示优化数据段的长度。

这也就解释了为什么在dexOptCreateEmptyHeader函数中dexOffset会被设置成结构体DexOptHeader的大小，说明在这个DexOptHeader结构体后面紧接着就会放原始的待优化的那个DEX文件。

好，我们还是回到extractAndProcessZip函数中：

    ……dexOffset = lseek(cacheFd, 0, SEEK_CUR);if (dexOffset < 0)goto bail;……zipEntry = dexZipFindEntry(&zippy, kClassesDex);if (zipEntry == NULL) {goto bail;}if (dexZipGetEntryInfo(&zippy, zipEntry, NULL, &uncompLen, NULL, NULL,&modWhen, &crc32) != 0){goto bail;}uncompLen = uncompLen;modWhen = modWhen;crc32 = crc32;if (dexZipExtractEntryToFile(&zippy, zipEntry, cacheFd) != 0) {goto bail;}……

首先，会通过读取ODEX文件的当前指针位置来获得DEX文件偏移的大小（其实没必要，前面看到了，这个偏移一定就是DexOptHeader结构体的大小）。然后，找到这个apk文件中，“class.dex”文件的ZIP项（apk文件其实就是一个zip文件）。通过这个ZIP项，可以获得对应文件的一些信息，包括它的长度、修改时间和CRC校验值。最后，将这个class.dex文件直接写到ODEX文件中去。

分析到这里，可以看出在ODEX文件中，其实是包含了一个完整的DEX文件的。不过在后面的优化步骤中，其中的某些指令会被优化（通过rewriteDex函数，有机会会另外介绍这个），和原始的那个DEX文件已经并不完全相同了。

好，我们接着看extractAndProcessZip函数：

    ……if (!dvmContinueOptimization(cacheFd, dexOffset, uncompLen, debugFileName,modWhen, crc32, isBootstrap)){goto bail;}result = 0;bail:……return result;
}

该函数接着调用了dvmContinueOptimization函数（代码位于dalvik\vm\analysis\DexPrepare.cpp中），接着优化：

bool dvmContinueOptimization(int fd, off_t dexOffset, long dexLength,const char* fileName, u4 modWhen, u4 crc, bool isBootstrap)
{DexClassLookup* pClassLookup = NULL;RegisterMapBuilder* pRegMapBuilder = NULL;……off_t depsOffset, optOffset, endOffset, adjOffset;int depsLength, optLength;u4 optChecksum;depsOffset = lseek(fd, 0, SEEK_END);if (depsOffset < 0) {goto bail;}adjOffset = (depsOffset + 7) & ~(0x07);if (adjOffset != depsOffset) {depsOffset = adjOffset;lseek(fd, depsOffset, SEEK_SET);}if (writeDependencies(fd, modWhen, crc) != 0) {goto bail;}……

代码首先通过读取ODEX文件当前末尾的位置，获得了存放所谓依赖（Dependency）库列表的位置。不过，这个依赖库列表必须被存放到64比特对齐的位置，也就是8字节对齐，所以接下来的代码还要计算一下修正后的位置，并把当前文件指针指向那里。接着调用了writeDependencies函数，写入依赖库列表。那么，这个依赖库列表到底是什么东西，该以什么样的格式存放呢？我们接着看writeDependencies函数的实现（代码位于dalvik\vm\analysis\DexPrepare.cpp中）：

static int writeDependencies(int fd, u4 modWhen, u4 crc)
{u1* buf = NULL;int result = -1;ssize_t bufLen;ClassPathEntry* cpe;int numDeps;numDeps = 0;bufLen = 0;for (cpe = gDvm.bootClassPath; cpe->ptr != NULL; cpe++) {const char* cacheFileName =dvmPathToAbsolutePortion(getCacheFileName(cpe));assert(cacheFileName != NULL);numDeps++;bufLen += strlen(cacheFileName) +1;}bufLen += 4*4 + numDeps * (4+kSHA1DigestLen);……

可以看到，所谓的依赖库列表，其实就是全局变量gDvm中bootClassPath变量中存放的所有ClassPathEntry，其实也就是系统环境变量BOOTCLASSPATH中存放的列表。这些指定的库，都会被预先加载进Dalvik虚拟机，供你的程序直接使用。

代码首先将所有的依赖库都遍历一遍，获得该库文件对应的优化文件的绝对路径（依赖库本身也是一个程序，同样是跑在Dalvik虚拟机下的，照样会被优化）。这次遍历其实只是想计算一下到底要开多大的缓存存放全部要写入ODEX文件的数据，所以最后会把这个路径的长度加上1（因为字符串最后要补上“\0”）累加到bufLen变量中。循环结束后，只是得到了所有依赖库路径字符串的长度，还要加上一个头的长度（4个4字节结构体），同时对每个依赖库还要记录下它的SHA1摘要，因此还要加上摘要的长度。

好了，在堆上分配好空间之后，就要开始正式写数据了：

    ……buf = (u1*)malloc(bufLen);set4LE(buf+0, modWhen);set4LE(buf+4, crc);set4LE(buf+8, DALVIK_VM_BUILD);set4LE(buf+12, numDeps);u1* ptr = buf + 4*4;for (cpe = gDvm.bootClassPath; cpe->ptr != NULL; cpe++) {const char* cacheFileName =dvmPathToAbsolutePortion(getCacheFileName(cpe));assert(cacheFileName != NULL);const u1* signature = getSignature(cpe);int len = strlen(cacheFileName) +1;……set4LE(ptr, len);ptr += 4;memcpy(ptr, cacheFileName, len);ptr += len;memcpy(ptr, signature, kSHA1DigestLen);ptr += kSHA1DigestLen;}assert(ptr == buf + bufLen);result = sysWriteFully(fd, buf, bufLen, "DexOpt dep info");free(buf);return result;
}

首先要写入一个头，其主要有4个4字节组成，结构如下：

1）最开始4个字节写的是前面获得的class.dex文件的修改时间；

2）接着的4个字节是class.dex文件的CRC校验值；

3）接着的4个字节是当前Dalvik虚拟机的版本号，对于Android 4.4.2系统来说，其值是27（代码位于dalvik\vm\DalvikVersion.h中）；

#define DALVIK_VM_BUILD         27

4）最后的4个字节是表示到底有多少个依赖库。

注意，这些值都是以小端（Little-Endian）字节序写入的。

接着，代码又遍历了一遍所有的依赖库，对于每一条依赖库来说，都要写入其优化文件名字符串长度、优化文件名字符串还有这个依赖库的SHA1值。

最后，将缓存里的值全部写入ODEX文件中。

好了，写完了依赖库，我们还是回到dvmContinueOptimization函数中：

    ……optOffset = lseek(fd, 0, SEEK_END);depsLength = optOffset - depsOffset;adjOffset = (optOffset + 7) & ~(0x07);if (adjOffset != optOffset) {optOffset = adjOffset;lseek(fd, optOffset, SEEK_SET);}if (!writeOptData(fd, pClassLookup, pRegMapBuilder)) {goto bail;}……

处理的逻辑和前面很像，也还是要8字节对齐，不过这次要写的是所谓的优化数据（Optimization Data）。那么优化数据包含哪些呢？我们接着看writeOptData函数的实现（代码位于dalvik\vm\analysis\DexPrepare.cpp中）：

static bool writeOptData(int fd, const DexClassLookup* pClassLookup,const RegisterMapBuilder* pRegMapBuilder)
{if (!writeChunk(fd, (u4) kDexChunkClassLookup,pClassLookup, pClassLookup->size)){return false;}if (pRegMapBuilder != NULL) {if (!writeChunk(fd, (u4) kDexChunkRegisterMaps,pRegMapBuilder->data, pRegMapBuilder->size)){return false;}}if (!writeChunk(fd, (u4) kDexChunkEnd, NULL, 0)) {return false;}return true;
}

可以看出，代码写了两个数据块（Chunk），再写了一个表示结尾的数据块，就结束了。那么，数据块的结构又是怎样的呢？我们接着看writeChunk函数（代码位于dalvik\vm\analysis\DexPrepare.cpp中）：

static bool writeChunk(int fd, u4 type, const void* data, size_t size)
{union {char raw[8];struct {u4 type;u4 size;} ts;} header;……header.ts.type = type;header.ts.size = (u4) size;if (sysWriteFully(fd, &header, sizeof(header),"DexOpt opt chunk header write") != 0){return false;}if (size > 0) {if (sysWriteFully(fd, data, size, "DexOpt opt chunk write") != 0)return false;}if ((size & 7) != 0) {int padSize = 8 - (size & 7);lseek(fd, padSize, SEEK_CUR);}assert( ((int)lseek(fd, 0, SEEK_CUR) & 7) == 0);return true;
}

可以看到，每一个数据块都有一个8字节的头，前4字节表示这个数据块的类型，后4个字节表示这个数据块占用多少字节的空间。头之后，就是数据块的具体内容。最后，还要保证数据块8字节对齐，适当的在后面填充数据。

数据块的类型主要有三种，分别是（代码位于dalvik\libdex\DexFile.h中）：

enum {kDexChunkClassLookup            = 0x434c4b50,kDexChunkRegisterMaps           = 0x524d4150,kDexChunkEnd                   = 0x41454e44,
};

第一种类型是用来存放针对该DEX文件的DexClassLookup结构，它主要是用来帮助快速查找DEX中的某个类的，想要具体了解的话，可以参考《Dalvik虚拟机中DexClassLookup结构解析》一文。

最后一种类型只是用来表示数据块结束了，没什么好说的。

第二种类型是用来存放针对该DEX文件的寄存器图（Register Map）信息的，它主要用来帮助Dalvik虚拟机做精确GC用的。在《Dalvik虚拟机中RegisterMap结构解析》一文中，我介绍了一下RegisterMap的大致结构以及用处。不过RegisterMap是针对某一个方法的，而DEX文件中有包含了许多类，每个类又有很多方法，这就需要将大量不同的RegisterMap结构按照某种规则存放下来。我们在前面的代码可以看到，这个块的数据是通过一个叫做RegisterMapBuilder的结构体来储存的，而这个结构体又是通过dvmGenerateRegisterMaps函数获得的（代码位于dalvik\vm\analysis\DexPrepare.cpp内的dvmContinueOptimization函数中）：

            ……if (dvmDexFileOpenPartial(dexAddr, dexLength, &pDvmDex) != 0) {success = false;} else {if (gDvm.generateRegisterMaps) {pRegMapBuilder = dvmGenerateRegisterMaps(pDvmDex);if (pRegMapBuilder == NULL) {success = false;}}DexHeader* pHeader = (DexHeader*)pDvmDex->pHeader;updateChecksum(dexAddr, dexLength, pHeader);dvmDexFileFree(pDvmDex);}……

我们先来看看RegisterMapBuilder结构体里有什么（代码位于dalvik\vm\analysis\RegisterMap.h中）：

struct RegisterMapBuilder {void*       data;size_t      size;MemMapping  memMap;
};

没什么特别的，有一个存放数据的data域，一个估计是表明数据大小的size域，还有一个私有的memMap域。

既然什么想要的信息都没有，那接下来我们只能顺藤摸瓜，看看这个结构体中的数据是如何生成的（代码位于dalvik\vm\analysis\RegisterMap.cpp中）：

RegisterMapBuilder* dvmGenerateRegisterMaps(DvmDex* pDvmDex)
{RegisterMapBuilder* pBuilder;pBuilder = (RegisterMapBuilder*) calloc(1, sizeof(RegisterMapBuilder));if (pBuilder == NULL)return NULL;if (sysCreatePrivateMap(4 * 1024 * 1024, &pBuilder->memMap) != 0) {free(pBuilder);return NULL;}size_t actual = writeMapsAllClasses(pDvmDex, (u1*)pBuilder->memMap.addr,pBuilder->memMap.length);if (actual == 0) {dvmFreeRegisterMapBuilder(pBuilder);return NULL;}pBuilder->data = pBuilder->memMap.addr;pBuilder->size = actual;return pBuilder;
}

代码很简单，主要是在内存中开了一个足够大的空间，然后调用函数writeMapsAllClasses对其进行写入，最后将内存空间的地址和实际写入的字节数放到data和size域中。所以，奥秘应该就在函数writeMapsAllClasses函数里（代码位于dalvik\vm\analysis\RegisterMap.cpp中）：

static size_t writeMapsAllClasses(DvmDex* pDvmDex, u1* basePtr, size_t length)
{DexFile* pDexFile = pDvmDex->pDexFile;u4 count = pDexFile->pHeader->classDefsSize;RegisterMapClassPool* pClassPool;u4* offsetTable;u1* ptr = basePtr;u4 idx;pClassPool = (RegisterMapClassPool*) ptr;ptr += offsetof(RegisterMapClassPool, classDataOffset);offsetTable = (u4*) ptr;ptr += count * sizeof(u4);pClassPool->numClasses = count;for (idx = 0; idx < count; idx++) {const DexClassDef* pClassDef;const char* classDescriptor;ClassObject* clazz;pClassDef = dexGetClassDef(pDexFile, idx);classDescriptor = dexStringByTypeIdx(pDexFile, pClassDef->classIdx);clazz = NULL;if ((pClassDef->accessFlags & CLASS_ISPREVERIFIED) != 0)clazz = dvmLookupClass(classDescriptor, NULL, false);if (clazz != NULL) {offsetTable[idx] = ptr - basePtr;if (!writeMapsAllMethods(pDvmDex, clazz, &ptr,length - (ptr - basePtr))){return 0;}ptr = align32(ptr);} else {assert(offsetTable[idx] == 0);}}if (ptr - basePtr >= (int)length) {dvmAbort();}return ptr - basePtr;
}

代码中又涉及到了一个新的结构体RegisterMapMethodPool（代码位于dalvik\vm\analysis\RegisterMap.h中）：

struct RegisterMapClassPool {u4      numClasses;u4      classDataOffset[1];
};

所以，代码首先写入了DEX文件中存放的所有类的个数。接着遍历DEX文件中的所有类，先是填写一个所谓的偏移表，其中的每一项都是4个字节，有几个类就有几项。每一项的值都表示其后的一块数据相对于结构体头之间的偏移。并且那块数据所代表的类在DEX文件中出现的下标，就是这个偏移表的下标。最后，对每一个类，调用writeMapsAllMethods函数，在指定偏移位置写入数据。注意，每个类的数据并不一定是紧挨着存放的，因为每块数据要32比特对齐。

static bool writeMapsAllMethods(DvmDex* pDvmDex, const ClassObject* clazz,u1** pPtr, size_t length)
{RegisterMapMethodPool* pMethodPool;u1* ptr = *pPtr;int i, methodCount;if (clazz->virtualMethodCount + clazz->directMethodCount >= 65536) {return false;}pMethodPool = (RegisterMapMethodPool*) ptr;ptr += offsetof(RegisterMapMethodPool, methodData);methodCount = 0;for (i = 0; i < clazz->directMethodCount; i++) {const Method* meth = &clazz->directMethods[i];if (dvmIsMirandaMethod(meth))continue;if (!writeMapForMethod(&clazz->directMethods[i], &ptr)) {return false;}methodCount++;}for (i = 0; i < clazz->virtualMethodCount; i++) {const Method* meth = &clazz->virtualMethods[i];if (dvmIsMirandaMethod(meth))continue;if (!writeMapForMethod(&clazz->virtualMethods[i], &ptr)) {return false;}methodCount++;}pMethodPool->methodCount = methodCount;*pPtr = ptr;return true;
}

这里又引入了一个叫做RegisterMapMethodPool的结构体（代码位于dalvik\vm\analysis\RegisterMap.h中）：

struct RegisterMapMethodPool {u2      methodCount;u4      methodData[1];
};

也没什么重要的信息，所以还是只能回过头看writeMapsAllMethods函数的实现。通过阅读可以看出，代码遍历了类中所有的函数，不过是以先直接方法后虚拟方法的顺序遍历的（同时还可以看出，一个类中的所有方法数目不能超过65535）。然后对每一个方法调用writeMapForMethod（代码位于dalvik\vm\analysis\RegisterMap.cpp中）函数，顺序的在methodData段写入数据（不用考虑对齐的问题）：

static bool writeMapForMethod(const Method* meth, u1** pPtr)
{if (meth->registerMap == NULL) {*(*pPtr)++ = kRegMapFormatNone;return true;}size_t mapSize = computeRegisterMapSize(meth->registerMap);memcpy(*pPtr, meth->registerMap, mapSize);assert(**pPtr == meth->registerMap->format);**pPtr &= ~(kRegMapFormatOnHeap);*pPtr += mapSize;return true;
}

很简单，直接写入对应方法的寄存器图RegisterMap结构体数据就好了。如果方法没有寄存器图RegisterMap的话，就写入一个字节，值为kRegMapFormatNone（1）。关于RegisterMap的结构以及用处，可以参考《Dalvik虚拟机中RegisterMap结构解析》一文。

最后，再回到函数dvmContinueOptimization中，看看收尾的工作：

    ……endOffset = lseek(fd, 0, SEEK_END);optLength = endOffset - optOffset;if (!computeFileChecksum(fd, depsOffset,(optOffset+optLength) - depsOffset, &optChecksum)){goto bail;}DexOptHeader optHdr;memset(&optHdr, 0xff, sizeof(optHdr));memcpy(optHdr.magic, DEX_OPT_MAGIC, 4);memcpy(optHdr.magic+4, DEX_OPT_MAGIC_VERS, 4);optHdr.dexOffset = (u4) dexOffset;optHdr.dexLength = (u4) dexLength;optHdr.depsOffset = (u4) depsOffset;optHdr.depsLength = (u4) depsLength;optHdr.optOffset = (u4) optOffset;optHdr.optLength = (u4) optLength;
#if __BYTE_ORDER != __LITTLE_ENDIANoptHdr.flags = DEX_OPT_FLAG_BIG;
#elseoptHdr.flags = 0;
#endifoptHdr.checksum = optChecksum;fsync(fd);lseek(fd, 0, SEEK_SET);if (sysWriteFully(fd, &optHdr, sizeof(optHdr), "DexOpt opt header") != 0)goto bail;result = true;bail:dvmFreeRegisterMapBuilder(pRegMapBuilder);free(pClassLookup);return result;
}

这里主要是重写处于ODEX头部的DexOptHeader结构体中的数据。最开始的魔数是“dey\n036\0”（代码位于dalvik\libdex\DexFile.h中）：

#define DEX_OPT_MAGIC   "dey\n"
#define DEX_OPT_MAGIC_VERS  "036\0"

下面是DEX文件的偏移和长度、依赖库列表的偏移和长度以及优化数据的偏移和长度。下面的flags域说明是用的大端字节序还是小端字节序，一般是小端，所以是0。最后是校验和的值，注意这个校验和不是算整个ODEX文件的，而是只算依赖库列表段和优化数据段的。

最后，画张图将整体结构总结一下：

Android系统ODEX文件格式解析相关推荐

Android init.rc文件格式解析
/****************************************************************************** Android init.rc文件格式解 ...
Android系统 —— image文件解析
Android系统编译之后的打包阶段,会将所有编译出来的有需要的执行文件,库文件以及各种配置文件等打包到各个镜像文件中.有时候我们需要看一下镜像文件中都打包了什么东西,那就可以通过一些方法将其挂载到一 ...
Android系统架构基本模式解析
Android系统架构总共被分为四层,在这里大家就可以通过介绍对这四个层次进行一个深入的解读,以加深大家对这一系统的认识. 如今,大家面对市场中种类繁多的手机必然挑的眼花缭乱.不过,在智能手机占据主要 ...
Android系统原生应用解析之桌面闹钟及相关原理应用之时钟任务的应用(二)
这篇文章主要针对http://android.xsoftlab.net/training/scheduling/alarms.html#tradeoffs中的Scheduling Repeating ...
Android系统原生应用解析之桌面闹钟及相关原理应用之时钟任务的应用(一)
前段时间我一个朋友在面试回来问我:那个公司要5天之内完成一个项目,功能包括每天早上6点开始执行定时任务,大批量图片上传,大批量数据库同步.我心想,后两个功能还好说,可就是每天早上6点开始执行的这种定时 ...
Android 系统稳定性 - ANR 解析
出处: http://rayleeya.iteye.com/blog/1955652 如果你是一个Android应用程序开发人员,你的人生中不可避免的三件事情是:死亡.缴税和ANR.这么说是夸张了,但 ...
Android中三种常用解析XML的方式（DOM、SAX、PULL）简介及区别
XML在各种开发中都广泛应用,Android也不例外.作为承载数据的一个重要角色,如何读写XML成为Android开发中一项重要的技能.今天就由我向大家介绍一下在Android平台下几种常见的XML解 ...
Android中XML数据解析
转载请注明出处:http://blog.csdn.net/yegongheng/article/details/38296207 XML初步今天我们来学习另一种非常重要的数据交换格式-XML.XML ...
【Android 逆向】Android 逆向方法 ( 静态逆向解析 | 函数调用分析 | 动态运行跟踪 | 运行日志分析 | 文件格式解析 | 敏感信息分析 | 网络信息监控 | 环境伪装模拟 )
文章目录一.Android 逆向方法 1.静态逆向解析 2.函数调用分析 3.动态运行跟踪 4.运行日志分析 5.文件格式解析 6.敏感信息分析 7.网络信息监控 8.软件动态调试 9.环境伪装模拟 ...

Android系统ODEX文件格式解析

Android系统ODEX文件格式解析相关推荐

最新文章

热门文章