APKTOOL_DUMMY_ 探讨（1）
使用apktool_2.5.0
记录一个错误，Apktool在进行回编的时候。 APKTOOL_DUMMY_
APKTOOL_DUMMY_ xx 指的是APKTOOL未读值（无法读取的）
手动干预以重新创建样式和/或删除样式是唯一的解决方案。
根据错误找到xmls.xml 如图
第一直觉 手动删除对应的xmls.xml 下的出错Item， 并删除public下对应文件（假设项目没有使用到）
处理，回编正常。
思考：为什么项目会生成这个文件
通过关键字 APKTOOL_DUMMY_ 在Apktool源码全局搜索，发现在ARSCDecoder.addMissingResSpecs() 方法找到如图
根据上图，得出， 当条件 !mMissingResSpecs[i] 为false时 就会执行相关代码， 转而跟踪 mMissingResSpecs[i]
发现对mMissingResSpecs数组的赋值操作都是在 readTableType() 方法下的，并发现关键部
而对readTableType() 的调用都是在readTableTypeSpec() 继续查看发现对readTableTypeSpec() 的调用在readLibraryType() 跟readTablePackage()，而对readLibraryType() 的调用又都在readTablePackage()， 跟着对readTablePackage() 的调用在readTableHeader()
到此，整理信息得出
可知，应分析readTableTypeSpec()
根据代码，可得出：
1、条件type == Header.TYPE_TYPE 为true时 才会调用readTableType()，addMissingResSpecs。
2、满足 if条件的时候 会打印警告， 并根据原有注释可知 跳过TYPE8的块， 然后会对齐该块
再看readTableType() 的代码 看到关键部分
到此，回归到思考上： 为什么项目会生成这个文件
答:满足1的情况下调用readTableType() 当 entryOffset[i] == -1 时 mMissingResSpecs[i] 为 false（mMissingResSpecs数组默认全是true）之后调用 addMissingResSpecs（） 会执行带有关键字 APKTOOL_DUMMY_ 的代码，生成带有关键字 APKTOOL_DUMMY_的文件
得出 生成文件的原因是 entryOffset[i] == -1。
更严谨的说法是， 当存在entryOffset[i] == -1 ，之后调用 addMissingResSpecs（）就会生成文件
因此，对这个回编报错的处理方法可有
1、手动删除处理
2、不调用addMissingResSpecs（）方法， 直接不生成文件
3、手动修改（扩展部分交代）
因为工作上的需要，我选择的是2方法，因为1方法为实现自动化打包（工作需要），需要编写脚本。
在此引出一个思考，可以在解包的时候，不生成文件， 那么， 是否可以在回编的时候不检验文件呢？
扩展: 交代一下背景， 样本APK是在我使用apktool_2.4.1 解包的时候报错
Exception in thread "main" java.lang.NullPointerException
根据异常抛出栈可以看出，问题出在解Manifest文件的时候。所以更新了APKTOOL2.5.0
更新后解包正常，回编出现上诉问题，根据上述解决问题后。
复盘：
在查阅大量资料后，在github上Apktool上的问题上根据关键字 APKTOOL_DUMMY_ 找到了问题 #2104
继续跟踪发现一系列相关问题，如下
#1117 手动干预以重新创建样式和/或删除样式是唯一的解决方案。
#1173 我相信这是“无法解决的”，Apktool在这里无能为力。
#2438 aapt1 doesn't care. aapt2 complains
#2439 APKTOOL_DUMMY_ 样式更改 即2.5.0
有趣的地方出现在 2439的回答上，因此
尝试用了apktool 2.4.0 对同一样本进行相同的操作，发现2.4.0并无抛出任何异常
对比文件
2.4.0
2.5.0
然后，修改2.5.0下的变成 2.4.0 的格式。 回编正常。
到此， 针对#2104又抛出了一个问题，APKTOOL2.5.0 在修复之前问题的情况下，是否又导致了新的问题的产生？
