resource.arsc二进制内容解析之 Dynamic package reference

1、加载Theme出错

2、aapt中的特殊处理

3、RES_TABLE_LIBRARY_TYPE

4、dynamicRefTable位置

5、验证dynamicRefTable

6、总结

1、加载Theme出错

这是一篇补充文章，在做动态替换resId的过程中，我发现bag类型的ResTable_entry在使用过程中存在问题。比如style，其parent解析一直有问题，日志如下：

W/ResourceType: Failed resolving bag parent id 0x7d090062W/ResourceType: Attempt to retrieve bag 0x7d090114 which is invalid or in a cycle.

经过一些粗暴的尝试，发现解决不了问题，看来需要祭出绝招了——看源码。

因为是与theme有关，所以我们追踪theme是怎么加载出来的，过程不说了，最后追踪到AssetManager.applyThemeStyle()，这个函数则是一个native函数，这就需要去底层代码看，源码：

android_frameworks_base/android_util_AssetManager.cpp at master · hushnymous/android_frameworks_base · GitHub

在源码里可以看到引用了ResourceType，这个源码：

https://github.com/aosp-mirror/platform_frameworks_base/blob/07735797a235ed98d182d0a40c8bdce4d92f9f0a/libs/androidfw/ResourceTypes.cpp

在ResourceType.cpp源码中通过搜索上面日志里的内容，我们找到了如下代码：

ssize_t ResTable::getBagLocked(uint32_t resID, const bag_entry** outBag,
uint32_t* outTypeSpecFlags) const
{...status_t err = grp->dynamicRefTable.lookupResourceId(&resolvedParent);if (err != NO_ERROR) {ALOGE("Failed resolving bag parent id 0x%08x", parent);return UNKNOWN_ERROR;}...
}

可以看到关键函数是lookupResourceId，如果这个函数返回的不是NO_ERROR就会报错。那么来看这个函数的源码：

status_t DynamicRefTable::lookupResourceId(uint32_t* resId) const {uint32_t res = *resId;size_t packageId = Res_GETPACKAGE(res) + 1;if (packageId == APP_PACKAGE_ID && !mAppAsLib) {// No lookup needs to be done, app package IDs are absolute.return NO_ERROR;}if (packageId == 0 || (packageId == APP_PACKAGE_ID && mAppAsLib)) {*resId = (0xFFFFFF & (*resId)) | (((uint32_t) mAssignedPackageId) << 24);return NO_ERROR;}// Do a proper lookup.uint8_t translatedId = mLookupTable[packageId];if (translatedId == 0) {ALOGW("DynamicRefTable(0x%02x): No mapping for build-time package ID 0x%02x.",(uint8_t)mAssignedPackageId, (uint8_t)packageId);for (size_t i = 0; i < 256; i++) {if (mLookupTable[i] != 0) {ALOGW("e[0x%02x] -> 0x%02x", (uint8_t)i, mLookupTable[i]);}}return UNKNOWN_ERROR;}*resId = (res & 0x00ffffff) | (((uint32_t) translatedId) << 24);return NO_ERROR;
}

先从resId中获取packageId，然后经过有三个if语句，我们一个个来看。

第一个，如果packageId是APP_PACKAGE_ID且不是lib，return NO_ERROR，这里APP_PACKAGE_ID是一个常量0x7F，因为我们动态替换成了0x7D，所以不执行这里。

第二个，如果packageId是0 或 packageId是APP_PACKAGE_ID且是lib，return NO_ERROR，这里重新组合了resId，将原packageId替换成了mAssignedPackageId，mAssignedPackageId即是resource.arsc文件中Package头部中的那个PackageId，我们已经动态替换成了0x7D。但是由于不满足if条件，所以这里也不执行。

第三个，从mLookupTable中获取一个translatedId，如果translatedId是0，则return UNKNOWN_ERROR；否则重新组合了resId，将原packageId替换成了translatedId。

当我们执行到这里，获取的translatedId一定是0，所以才会报出上面的错误。

这样我们找到原因所在，即mLookupTable中缺少translatedId的数据。

那么如何才能让数据正确？由于mLookupTable使用地方很多，而且还存储这其他数据，所以调查起来有些困难。

2、aapt中的特殊处理

这样就又走进死胡同了？我想到另外一个方案，即直接修改aapt源码来修改resId，那么那个方案既然可以，我们是不是可以看看差别在哪里？

那么方案很简单，修改代码也不多，没有看到什么特殊处理，那么一定是aapt源码中有一些处理。在aapt源码中搜索0x7F

（为什么要搜索0x7F，因为aapt一定是判断resId的packageId是不是0x7F，如果不是有一些特殊处理）

可以找到如下代码：

https://github.com/aosp-mirror/platform_frameworks_base/blob/master/tools/aapt/ResourceTable.cpp

status_t ResourceTable::flatten(Bundle* bundle, const sp<const ResourceFilter>& filter,const sp<AaptFile>& dest,const bool isBase)
{...// The libraries this table references.Vector<sp<Package> > libraryPackages;const ResTable& table = mAssets->getIncludedResources();const size_t basePackageCount = table.getBasePackageCount();for (size_t i = 0; i < basePackageCount; i++) {size_t packageId = table.getBasePackageId(i);String16 packageName(table.getBasePackageName(i));if (packageId > 0x01 && packageId != 0x7f &&packageName != String16("android")) {libraryPackages.add(sp<Package>(new Package(packageName, packageId)));}}...if (isBase) {status_t err = flattenLibraryTable(data, libraryPackages);if (err != NO_ERROR) {fprintf(stderr, "ERROR: failed to write library table\n");return err;}}...}

可以看到当packageId不是0x7F，会新建一个Package结构存入libraryPackages，那么这个libraryPackages有啥用？
我们继续往下看发现flattenLibraryTable函数使用了它，这个函数源码如下：

status_t ResourceTable::flattenLibraryTable(const sp<AaptFile>& dest, const Vector<sp<Package> >& libs) {// Write out the library table if necessaryif (libs.size() > 0) {if (kIsDebug) {fprintf(stderr, "Writing library reference table\n");}const size_t libStart = dest->getSize();const size_t count = libs.size();ResTable_lib_header* libHeader = (ResTable_lib_header*) dest->editDataInRange(libStart, sizeof(ResTable_lib_header));memset(libHeader, 0, sizeof(*libHeader));libHeader->header.type = htods(RES_TABLE_LIBRARY_TYPE);libHeader->header.headerSize = htods(sizeof(*libHeader));libHeader->header.size = htodl(sizeof(*libHeader) + (sizeof(ResTable_lib_entry) * count));libHeader->count = htodl(count);// Write the library entriesfor (size_t i = 0; i < count; i++) {const size_t entryStart = dest->getSize();sp<Package> libPackage = libs[i];if (kIsDebug) {fprintf(stderr, "  Entry %s -> 0x%02x\n",String8(libPackage->getName()).string(),(uint8_t)libPackage->getAssignedId());}ResTable_lib_entry* entry = (ResTable_lib_entry*) dest->editDataInRange(entryStart, sizeof(ResTable_lib_entry));memset(entry, 0, sizeof(*entry));entry->packageId = htodl(libPackage->getAssignedId());strcpy16_htod(entry->packageName, libPackage->getName().string());}}return NO_ERROR;
}

可以看到向resource.arsc文件中写入了一个RES_TABLE_LIBRARY_TYPE类型的数据结构。

这个RES_TABLE_LIBRARY_TYPE在网上的resource.arsc解析相关文章中几乎没有被提到，而且网上的那张神图中也看不到这个结构。

3、RES_TABLE_LIBRARY_TYPE

那么它是什么？我们来看看找到的一些蛛丝马迹：

chunk	type	note
Table header	RES_TABLE_TYPE = 0x002
Resource strings	RES_STRING_POOL_TYPE = 0x001	e.g. 'Hello World!'
Package header	RES_TABLE_PACKAGE_TYPE = 0x200	Rewrite entry: package id
Type strings	RES_STRING_POOL_TYPE = 0x001	e.g. 'attr', 'layout', etc.
Key strings	RES_STRING_POOL_TYPE = 0x001	e.g. 'activity_main', etc.
DynamicRefTable	RES_TABLE_LIBRARY_TYPE = 0x0203	Insert entry for Android 5.0+
Type spec	RES_TABLE_TYPE_SPEC_TYPE = 0x0202
Type info	RES_TABLE_TYPE_TYPE = 0x0201	Rewrite entry: resource entry value

In Android 5.0+ needs to set the dynamicRefTable for lookup bag parent.

5.0以上需要对二进制文件加入“资源包id映射”数据段，以使得能正确查找到主题等bag的parent。

根据上面的我们大概知道这个“资源包id映射”是5.0之后才加入的，所以网上那么比较陈旧的文章中没有提及。它的作用就是正确的查找bag类型Entry数据的parent。

（至于什么是bag类型，请阅读《resource.arsc二进制内容解析之 RES_TABLE_TYPE_TYPE》）

这样我们就知道了，如果resId使用默认的0x7F，则不存在问题；如果不使用默认的0x7F，而且还缺少dynamicRefTable这个映射，则查找parent会出问题。
同时，当用aapt编译资源时，如果resId的packageId不是0x7F，才会添加dynamicRefTable。

由于我们是在resource.arsc生产后才去修改，所以aapt编译时并未加入dynamicRefTable，这就是问题所在，我们需要手动加入它。

那么我们就需要知道它的结构，如下：

struct ResTable_lib_header
{struct ResChunk_header header;// The number of shared libraries linked in this resource table.uint32_t count;
};

首先header包括两部分，一个是ResChunk_header结构体，一个是包含的映射个数。
ResChunk_header结构体如下：

struct ResChunk_header  {  //当前这个chunk的类型  uint16_t type;  //当前这个chunk的头部大小  uint16_t headerSize;  //当前这个chunk的大小  uint32_t size;  };

这个结构体就不细说了，其中type就是RES_TABLE_LIBRARY_TYPE
紧接着header，就是映射表了，每一个映射都是一个ResTable_lib_entry结构，一共有count个

struct ResTable_lib_entry
{// The package-id this shared library was assigned at build time.// We use a uint32 to keep the structure aligned on a uint32 boundary.uint32_t packageId;// The package name of the shared library. \0 terminated.char16_t packageName[128];
};

映射结构也很简单，packageId+packageName，但是注意packageId占固定4byte大小，而packageName则占固定256byte大小（2byte一个字符，一共128个字符），当然一般packageName都不会这么长，多余的用0补充。

4、dynamicRefTable位置

上面我们知道了dynamicRefTable的结构，那么它在文件中处于什么位置呢？又与哪些数据有联系？
根据网上的神图我重新做了一张更完整更准确的结构图，补充了dynamicRefTable，如下：

这样看到比较清晰了，dynamicRefTable是整个Package结构中的一部分，与Package中的其他结构是并列的，所以不会影响。但是加入dynamicRefTable会影响Package头部中的块大小，以及文件header中的文件大小。

那么如果下面还有另外一个Package数据块，则会有影响么？

答案是不会，因为与位置相关的数据，比如偏移量，一般都是相对于该数据块头部的。

5、验证dynamicRefTable

这样dynamicRefTable的结构就分析完了。那么我们如何知道resource.arsc文件中是否存在这种结构？

我们可以使用aapt反编译一下打包好的apk

./aapt d resources /Users/.../app-debug.apk

会得到如下数据：

Package Groups (1)

Package Group 0 id=0x6d packageCount=1 name=com.example.bennu.testapp

DynamicRefTable entryCount=1:

0x6d -> com.example.bennu.testapp

Package 0 id=0x6d name=com.example.bennu.testapp

type 1 configCount=2 entryCount=12

spec resource 0x6d020000 com.example.bennu.testapp:drawable/arrow: flags=0x00000000

spec resource 0x6d020001 com.example.bennu.testapp:drawable/fio: flags=0x00000000

spec resource 0x6d020002 com.example.bennu.testapp:drawable/fit: flags=0x00000000

spec resource 0x6d020003 com.example.bennu.testapp:drawable/fith: flags=0x00000000

spec resource 0x6d020004 com.example.bennu.testapp:drawable/fo: flags=0x00000000

spec resource 0x6d020005 com.example.bennu.testapp:drawable/ft: flags=0x00000000

spec resource 0x6d020006 com.example.bennu.testapp:drawable/fth: flags=0x00000000

spec resource 0x6d020007 com.example.bennu.testapp:drawable/test_bg_java: flags=0x00000000

spec resource 0x6d020008 com.example.bennu.testapp:drawable/test_bg_xml: flags=0x00000000

spec resource 0x6d020009 com.example.bennu.testapp:drawable/xo: flags=0x00000000

spec resource 0x6d02000a com.example.bennu.testapp:drawable/xt: flags=0x00000000

spec resource 0x6d02000b com.example.bennu.testapp:drawable/xth: flags=0x00000000

config (default):

resource 0x6d020007 com.example.bennu.testapp:drawable/test_bg_java: t=0x03 d=0x00000000 (s=0x0008 r=0x00)

resource 0x6d020008 com.example.bennu.testapp:drawable/test_bg_xml: t=0x03 d=0x00000001 (s=0x0008 r=0x00)

config xhdpi-v4:

resource 0x6d020000 com.example.bennu.testapp:drawable/arrow: t=0x03 d=0x00000003 (s=0x0008 r=0x00)

resource 0x6d020001 com.example.bennu.testapp:drawable/fio: t=0x03 d=0x00000004 (s=0x0008 r=0x00)

resource 0x6d020002 com.example.bennu.testapp:drawable/fit: t=0x03 d=0x00000005 (s=0x0008 r=0x00)

resource 0x6d020003 com.example.bennu.testapp:drawable/fith: t=0x03 d=0x00000006 (s=0x0008 r=0x00)

resource 0x6d020004 com.example.bennu.testapp:drawable/fo: t=0x03 d=0x00000007 (s=0x0008 r=0x00)

resource 0x6d020005 com.example.bennu.testapp:drawable/ft: t=0x03 d=0x00000008 (s=0x0008 r=0x00)

resource 0x6d020006 com.example.bennu.testapp:drawable/fth: t=0x03 d=0x00000009 (s=0x0008 r=0x00)

resource 0x6d020009 com.example.bennu.testapp:drawable/xo: t=0x03 d=0x0000000a (s=0x0008 r=0x00)

resource 0x6d02000a com.example.bennu.testapp:drawable/xt: t=0x03 d=0x0000000b (s=0x0008 r=0x00)

resource 0x6d02000b com.example.bennu.testapp:drawable/xth: t=0x03 d=0x0000000c (s=0x0008 r=0x00)

可以看到有dynamicRefTable的相关数据，如果没有则表示不存在这类数据。

6、总结

dynamicRefTable的存在很重要，影响了bag类数据的parent部分。但是有一个前提，即资源索引不使用默认的0x7F。所以在正常编译时我们不需要特别去注意它，但是如果我们手动干预或后期修改了资源索引，就不得不考虑它了。