接着APKTOOL_DUMMY_ （1） ， 如下图：
在通过源码debug后，结论：
Apktool2.4.1 brut.androlib.res.decoder.AXmlResourceParser.getAttributeName() 方法，里面的逻辑有问题，在本样本APK中，问题的原因是在于，从resourceIDs 里面拿不到下标入图所示的ID值， 进而导致getAttributeNameResource() 的值为0，从而导致value为null，即抛出上图异常。
下面给出这块代码在相邻2版本的源码：
扩展：工作关系 样本APK是合租的CP方发过来的APK，不方便发上来， 不过经过我的查看，理论上是CP经过了一些特殊的处理，导致我这边解包报错。
在经过ApkTool 2.4.0 或 Apktool 2.5.0 回编的APK都能给ApkTool 2.4.1 解包通过010对比AndroidManifest.xml
不难发现，因为缺少了16844146，16844147，16844154 是导致问题的关键， 然后对比正常APK可得知这些值都是固定的（用到的模板是AndroidResource.bt 更新日期是2017年，模板AndroidManifest.bt更新时间是2019，都有做对比），查看模板，发现模板AndroidResource.bt 代码量更多(主要是添加了映射 即上图所示)
通过框架文件1.apk 可知
再附上一张图
AndroidMainfest.png
根据上面整理可得:
因为APK的清单文件ResourceChunk的ResourceIds数组里面缺失了16844146（compileSdkVersion）省略...
在用ApkTool2.4.1进行解压的时候，由于不满足条件 value.length() !=0 && !android_ns.equals(getAttributeNamespace(index)) 所以需要拿到对应的ResourceId去框架文件1.APK里面去拿到值（compileSdkVersion），因为缺少了相对应的值（导致抛出NPE异常解包失败）。通过分析不同版本的getAttributeName()方法，在2.4.1的版本中的更改可能导致解包因上诉解包失败（实际上，compileSdkVersion已经通过从StringChunk中拿到了），所以在2.5.0中明确：只有在StringChunk拿不到，才根据ResourceId值去框架文件中拿到对应的Value。
至此，文件分享完毕。 之后可能会根据这个规律， 想办法出一个APK给读者去验证。
