接着APKTOOL_DUMMY_ （1） ， 如下图：

在通过源码debug后，结论：

Apktool2.4.1   brut.androlib.res.decoder.AXmlResourceParser.getAttributeName() 方法，里面的逻辑有问题，在本样本APK中，问题的原因是在于，从resourceIDs 里面拿不到下标入图所示的ID值， 进而导致getAttributeNameResource() 的值为0，从而导致value为null，即抛出上图异常。

2.4.1Debug

010查看

下面给出这块代码在相邻2版本的源码：

2.4.0

2.4.1

2.5.0

扩展：工作关系  样本APK是合租的CP方发过来的APK，不方便发上来，  不过经过我的查看，理论上是CP经过了一些特殊的处理，导致我这边解包报错。

在经过ApkTool 2.4.0 或 Apktool 2.5.0 回编的APK都能给ApkTool 2.4.1 解包通过010对比AndroidManifest.xml

2.4.1不能解包

2.4.1能解包

正常的APK包 

不难发现，因为缺少了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给读者去验证。