接著APKTOOL_DUMMY_ （1） ， 如下圖：
在通過源碼debug后，結論：
Apktool2.4.1? ?brut.androlib.res.decoder.AXmlResourceParser.getAttributeName() 方法侧漓，里面的邏輯有問題表锻，在本樣本APK中故河，問題的原因是在于，從resourceIDs 里面拿不到下標入圖所示的ID值惧互， 進而導致getAttributeNameResource() 的值為0，從而導致value為null喇伯，即拋出上圖異常喊儡。
下面給出這塊代碼在相鄰2版本的源碼：
擴展：工作關系? 樣本APK是合租的CP方發(fā)過來的APK，不方便發(fā)上來稻据，? 不過經(jīng)過我的查看艾猜，理論上是CP經(jīng)過了一些特殊的處理，導致我這邊解包報錯。
在經(jīng)過ApkTool 2.4.0 或 Apktool 2.5.0 回編的APK都能給ApkTool 2.4.1 解包通過010對比AndroidManifest.xml
不難發(fā)現(xiàn)匆赃，因為缺少了16844146淤毛，16844147，16844154 是導致問題的關鍵炸庞，? 然后對比正常APK可得知這些值都是固定的（用到的模板是AndroidResource.bt 更新日期是2017年钱床，模板AndroidManifest.bt更新時間是2019，都有做對比）埠居，查看模板查牌，發(fā)現(xiàn)模板AndroidResource.bt 代碼量更多(主要是添加了映射?即上圖所示)
通過框架文件1.apk 可知
再附上一張圖
AndroidMainfest.png
根據(jù)上面整理可得:
因為APK的清單文件ResourceChunk的ResourceIds數(shù)組里面缺失了16844146（compileSdkVersion）省略...
在用ApkTool2.4.1進行解壓的時候，由于不滿足條件?value.length() !=0 && !android_ns.equals(getAttributeNamespace(index)) 所以需要拿到對應的ResourceId去框架文件1.APK里面去拿到值（compileSdkVersion）滥壕，因為缺少了相對應的值（導致拋出NPE異常解包失斨窖铡）。通過分析不同版本的getAttributeName()方法绎橘，在2.4.1的版本中的更改可能導致解包因上訴解包失斝菜铩（實際上，compileSdkVersion已經(jīng)通過從StringChunk中拿到了）称鳞，所以在2.5.0中明確：只有在StringChunk拿不到涮较，才根據(jù)ResourceId值去框架文件中拿到對應的Value。
至此冈止，文件分享完畢狂票。? ? 之后可能會根據(jù)這個規(guī)律， 想辦法出一個APK給讀者去驗證熙暴。
