接著APKTOOL_DUMMY_ （1） ， 如下圖：
在通過(guò)源碼debug后，結(jié)論：
Apktool2.4.1? ?brut.androlib.res.decoder.AXmlResourceParser.getAttributeName() 方法，里面的邏輯有問(wèn)題，在本樣本APK中，問(wèn)題的原因是在于，從resourceIDs 里面拿不到下標(biāo)入圖所示的ID值， 進(jìn)而導(dǎo)致getAttributeNameResource() 的值為0，從而導(dǎo)致value為null，即拋出上圖異常。
下面給出這塊代碼在相鄰2版本的源碼：
擴(kuò)展：工作關(guān)系? 樣本APK是合租的CP方發(fā)過(guò)來(lái)的APK，不方便發(fā)上來(lái)，? 不過(guò)經(jīng)過(guò)我的查看，理論上是CP經(jīng)過(guò)了一些特殊的處理，導(dǎo)致我這邊解包報(bào)錯(cuò)。
在經(jīng)過(guò)ApkTool 2.4.0 或 Apktool 2.5.0 回編的APK都能給ApkTool 2.4.1 解包通過(guò)010對(duì)比AndroidManifest.xml
不難發(fā)現(xiàn)，因?yàn)槿鄙倭?6844146，16844147，16844154 是導(dǎo)致問(wèn)題的關(guān)鍵，? 然后對(duì)比正常APK可得知這些值都是固定的（用到的模板是AndroidResource.bt 更新日期是2017年，模板AndroidManifest.bt更新時(shí)間是2019，都有做對(duì)比），查看模板，發(fā)現(xiàn)模板AndroidResource.bt 代碼量更多(主要是添加了映射?即上圖所示)
通過(guò)框架文件1.apk 可知
再附上一張圖
AndroidMainfest.png
根據(jù)上面整理可得:
因?yàn)锳PK的清單文件ResourceChunk的ResourceIds數(shù)組里面缺失了16844146（compileSdkVersion）省略...
在用ApkTool2.4.1進(jìn)行解壓的時(shí)候，由于不滿足條件?value.length() !=0 && !android_ns.equals(getAttributeNamespace(index)) 所以需要拿到對(duì)應(yīng)的ResourceId去框架文件1.APK里面去拿到值（compileSdkVersion），因?yàn)槿鄙倭讼鄬?duì)應(yīng)的值（導(dǎo)致拋出NPE異常解包失?。Ｍㄟ^(guò)分析不同版本的getAttributeName()方法，在2.4.1的版本中的更改可能導(dǎo)致解包因上訴解包失敗（實(shí)際上，compileSdkVersion已經(jīng)通過(guò)從StringChunk中拿到了），所以在2.5.0中明確：只有在StringChunk拿不到，才根據(jù)ResourceId值去框架文件中拿到對(duì)應(yīng)的Value。
至此，文件分享完畢。? ? 之后可能會(huì)根據(jù)這個(gè)規(guī)律， 想辦法出一個(gè)APK給讀者去驗(yàn)證。
