接著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給讀者去驗證。