1、加载Theme出错
这是一篇补充文章，在做动态替换resId的过程中，我发现bag类型的ResTable_entry在使用过程中存在问题。比如style，其parent解析一直有问题，日志如下：
W/ResourceType: Failed resolving bag parent id 0x7d090062 W/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源码中通过搜索上面日志里的内容，我们找到了如下代码：
代码语言：javascript复制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 0xx", parent);
return UNKNOWN_ERROR;
}
...
}可以看到关键函数是lookupResourceId，如果这个函数返回的不是NO_ERROR就会报错。那么来看这个函数的源码：
代码语言：javascript复制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(0xx): No mapping for build-time package ID 0xx.",
(uint8_t)mAssignedPackageId, (uint8_t)packageId);
for (size_t i = 0; i < 256; i ) {
if (mLookupTable[i] != 0) {
ALOGW("e[0xx] -> 0xx", (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
代码语言：javascript复制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 tablen");
return err;
}
}
...
}可以看到当packageId不是0x7F，会新建一个Package结构存入libraryPackages，那么这个libraryPackages有啥用？
我们继续往下看发现flattenLibraryTable函数使用了它，这个函数源码如下：
代码语言：javascript复制status_t ResourceTable::flattenLibraryTable(const sp<AaptFile>& dest, const Vector<sp<Package> >& libs) {
// Write out the library table if necessary
if (libs.size() > 0) {
if (kIsDebug) {
fprintf(stderr, "Writing library reference tablen");
}
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 entries
for (size_t i = 0; i < count; i ) {
const size_t entryStart = dest->getSize();
sp<Package> libPackage = libs[i];
if (kIsDebug) {
fprintf(stderr, " Entry %s -> 0xxn",
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类型，请阅读《...》）
这样我们就知道了，如果resId使用默认的0x7F，则不存在问题；如果不使用默认的0x7F，而且还缺少dynamicRefTable这个映射，则查找parent会出问题。
同时，当用aapt编译资源时，如果resId的packageId不是0x7F，才会添加dynamicRefTable。
由于我们是在resource.arsc生产后才去修改，所以aapt编译时并未加入dynamicRefTable，这就是问题所在，我们需要手动加入它。
那么我们就需要知道它的结构，如下：
代码语言：javascript复制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结构体如下：
代码语言：javascript复制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个
代码语言：javascript复制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. 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。所以在正常编译时我们不需要特别去注意它，但是如果我们手动干预或后期修改了资源索引，就不得不考虑它了。
