【移動應用開發技術】AndroidStudioAnalyzeAPK一直顯示ParsingManifest解決

一、背景大家都知道，AndroidStudio開發工具自帶了AnalyzeApk，可以很方便的分析Apk文件。具體位于菜單build>>AnalyzeAPK...路徑下，點擊后可以選擇目標路徑下的Apk文件，甚至可以直接將目標APK文件直接拖拽到AndroidStudio中，不到幾秒中時間，馬上就會生成對應的分析結果。例如，微信Apk分析結果是這樣的：又如，支付寶Apk分析結果：瞬間感覺自己很niubility，有沒有？有時候，我們也經常用它來分析自己的Apk，例如，生成的安裝包到底長什么樣子，里面的資源/代碼構成，Manifest中配置是否如預期，又或者方法數，等等。但是，一次突然的機會，發現自己開發的Ap分析不了，一直處于ParsingManifest狀態。一臉懵逼，有木有？二、探因這個問題曾經困惑了我不少時間，之前也沒有具體去研究過。現在又遇到了。瞬間想到魯迅說的一句話：技術路上，會遇到很多看似莫名其妙的問題，細心探究，解決了，就是成長。無視它并避讓過去，看似繞過了問題，實際上失去了一次很好的技術歷練的機會，并且下次很可能還會遇到類似的，甚至一樣的問題，長期看將是困難和停滯。技術路上，會遇到很多看似莫名其妙的問題，細心探究，解決了，就是成長。無視它并避讓過去，看似繞過了問題，實際上失去了一次很好的技術歷練的機會，并且下次很可能還會遇到類似的，甚至一樣的問題，長期看將是困難和停滯。既然先輩都這樣說了，那就，那硬著頭皮解一下？2.1AS日志現在給人的感覺是AnalyzeAPK執行過程中直接停住了，后者長時間一直在分析。但不管怎樣，畢竟是在AS中的操作，先查一下對應的AS日志，看看有沒ParsingManifest或相關的日志信息，可以起到幫助的。Help>>ShowLoginFinder，打開日志，對應時間點看了又看，沒找到ParsingManifest直接相關的，不過，找到了控件顯示先關的日志：2019-08-08

19:21:25,323

[entQueue-0]

INFO

-

ools.idea.apk.viewer.ApkEditor

-

Disposing

ApkEditor

with

ApkViewPanel:

com.android.tools.idea.apk.viewer.ApkViewPanel@7a608115

2019-08-08

19:21:25,323

[entQueue-0]

INFO

-

s.idea.apk.viewer.ApkViewPanel

-

Cleared

Archive

on

ApkViewPanel:

com.android.tools.idea.apk.viewer.ApkViewPanel@7a608115從日志里面可以看出來，AS中對應的AnalyzeApk相關的類名有ApkEditor、ApkViewPanel，包名是com.android.tools.idea.apk.viewer。AS日志部分的有效信息只有這么多了。2.2系統全局搜索AS日志中沒有，那有沒有可能存在有效的信息輸出在了系統其它的地方？于是，直接花點時間，系統全局搜索下。/

grep

-rnl

"Parsing

Manifest"

*輸出信息中有一些警告信息之類的，最終在輸出信息中找到了個相關的：Applications/Android

Studio.app/Contents/plugins/android/lib/android.jar看目錄名，大概是AS插件中對應的Android相關的lib工具包。找到對應位置，用JD-GUI打開對應的jar文件，具體看下一下。通過全局搜索關鍵字ParsingManifest，的確可以定位到具體的ApkViewPanel類，且包名與上面AS日志中都能對的上，但字節碼反解成java過程中有內部錯誤。嘗試著用用jadx打開，因為android.jar包還挺大，時間比較長，、最終雖然ApkViewPanel部分內容可以顯示，但內部依然有部分內部錯誤無法顯示，且ParsingManifest不能直接顯示。2.3GitHub定位與源碼分析不過沒關系，我們試著去找找源碼看看。搜索對應包名：com.android.tools.idea.apk.viewer，選擇java類別，很快，我們找到了對應的源碼位置。/JetBrains/a…正好，AS就是JetBrains主導的產品，Perfect！很快，我們找到了對應ParsingManifest的位置：setAppInfo()方法中，將對應的控件內容從原來的ParsingManifest改成了對應的包名和版本號等信息。顯然，在代碼myNameComponent.append("ParsingManifest");與setAppInfo(result);之間，程序出了問題。這之間關鍵的類，主要有apkParser對象對應的ApkParser類，還有Archives類。繼續跟蹤ApkParser類，發現其主要也是一個外殼性質的類，apkParser.constructTreeStructure()方法主要流程來到如下所示位置：現在，我們發現，無論是此處的ArchiveTreeStructure類，還是之前的Archives類，這兩個關鍵線索上的類都不是在這個項目中。根據代碼文件中的import導入，很快，我們發現，線索被定向到了com.android.tools.apk.analyzer包中。從包名上來看，com.android.tools.apk.analyzer應該是AndroidTools中帶的一個工具。來到項目iml文件，我們發現與之相關的構件。其中，組名是：com.android.tools.apkparser，構件名是：apkanalyzer。2.4工具本體-apkanalyzer至此，我們先總結下問題的原因。AS中自帶的AnalyzeAPK，實際上是通過集成了插件實現，而插件內部，又通過調用了AndroidTools中的名叫apkanalyzer的工具實現的分析。因此，想要追溯出現問題的原因，我們需要再去對應追蹤下apkanalyzer。如果熟悉AndroidTools，我們對應去tools目錄下找找，很快便能找到apkanalyzer。及時不熟悉，不知道目錄位置也沒關系，打不了全局搜索下。終于，對應的工具本體出現在我們面前。實際上，如果對GoogleDeveloper比較熟悉，或者直接在上面搜索下，也能直接在AnalyzeAPK頁面上找到核心信息，直接指向工具本體—/studio/buil…啊哈，饒了半天，原來官方文檔上直接有啊，哭了，有木有？同樣的，通過反編譯工具查看apkanalyzer.jar代碼終究不太方便，且內部也有不少INNERERROR。于是，我們繼續去GitHub上找找。GitHub上搜索到的apkanalyzer相關的零零散散，好像都是個人的，不太官方，也不符合我們的預期。怎么辦呢？源碼不夠，GoogleSource來湊！直接GoogleSource搜索可能的關鍵字，馬上得到了結果。顯然，這正是我們需要的。但此時，如果直接源碼跟蹤下去，還是有難度的。2.5apkanalyzer查因apkanalyzer作為一個工具，是獨立的。在實際使用時可以直接脫離AS環境，GoogleDeveloper官網上也有專門的篇幅進行了介紹。/studio/comm…實際使用時，我們通過不同的命令行命令及參數，可以得到我們期望的結果，如用來分析APK基本屬性，Manifest，dex或資源等。由此，我們可以多試幾個，反正AS中AnalyzeAPK最終用的也是它。在一定的命令上，結果肯定是一樣的。也就是說，通過命令行直接執行apkanalyzer，肯定也會有問題，但有個好處時，命令行執行往往都能拋出對應的錯誤日志。有了進一步的錯誤日志提示，就有了異常棧和關鍵性的真正的錯誤原因信息。那我們就試一試吧。?

bin

apkanalyzer

-h

apk

file-size

Corn-dev-debug.apk

46.9MB

?

bin

apkanalyzer

apk

summary

Corn-dev-debug.apk

com.corn

10300

?

bin

apkanalyzer

manifest

print

Corn-dev-debug.apk<?xml

version="1.0"

encoding="utf-8"?><manifest

xmlns:android="/apk/res/android"

android:versionCode="10300"

android:versionName=""

package="com.mymoney"

platformBuildVersionCode="27"

platformBuildVersionName="8.1.0">

<uses-sdk

android:minSdkVersion="19"

android:targetSdkVersion="26"

/>

<uses-permission

android:name="android.permission.GET_ACCOUNTS"

android:maxSdkVersion="22"

/>...

...

...說明直接分析Manifest文件都是沒有問題的。?

bin

apkanalyzer

dex

list

Corn-dev-debug.apkclasses7.dexclasses6.dexclasses5.dexclasses4.dexclasses3.dexclasses2.dexclasses.dex復制代碼?

bin

apkanalyzer

resources

configs

--type

drawable

Corn-dev-debug.apk

anydpi-v21

anydpi-v26

default

watch-v20

v21

v23

ldpi-v4

mdpi-v4

ldrtl-mdpi-v17

hdpi-v4

ldrtl-hdpi-v17

xhdpi-v4

ldrtl-xhdpi-v17

xxhdpi-v4

ldrtl-xxhdpi-v17

xxxhdpi-v4

ldrtl-xxxhdpi-v17?

bin

apkanalyzer

files

list

Corn-dev-debug.apk

Exception

in

thread

"main"

java.util.zip.ZipError:

invalid

END

header

(bad

central

directory

offset)

at

com.sun.nio.zipfs.ZipFileSystem.zerror(ZipFileSystem.java:1605)

at

com.sun.nio.zipfs.ZipFileSystem.initCEN(ZipFileSystem.java:1045)

at

com.sun.nio.zipfs.ZipFileSystem.<init>(ZipFileSystem.java:130)

at

com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:117)

at

java.nio.file.FileSystems.newFileSystem(FileSystems.java:326)

at

java.nio.file.FileSystems.newFileSystem(FileSystems.java:276)

at

com.android.utils.FileUtils.createZipFilesystem(FileUtils.java:538)

at

com.android.tools.apk.analyzer.Archives.openInnerZip(Archives.java:48)

at

com.android.tools.apk.analyzer.ArchiveTreeStructure.create(ArchiveTreeStructure.java:100)

at

com.android.tools.apk.analyzer.ArchiveTreeStructure.create(ArchiveTreeStructure.java:65)

at

com.android.tools.apk.analyzer.ApkAnalyzerImpl.filesList(ApkAnalyzerImpl.java:803)

at

com.android.tools.apk.analyzer.ApkAnalyzerCli$Action$6.execute(ApkAnalyzerCli.java:430)

at

com.android.tools.apk.analyzer.ApkAnalyzerCli.run(ApkAnalyzerCli.java:163)

at

com.android.tools.apk.analyzer.ApkAnalyzerCli.main(ApkAnalyzerCli.java:130)終于，在用命令顯示Apk內所有文件列表的時候出現了問題。并且有對應的調用棧信息拋出。從調用棧中我們發現，命令行的調用方式，是通過ApkAnalyzerCli中的main方法去接收命令參數的。在ApkAnalyzer.jar同級的目錄中，我們發現了有對應的ApkAnalyzerCli.jar，其作用，就是基于ApkAnalyzer.jar基礎上封裝的一個Client，以方便程序被外部調用執行，如通過命令行的方式等。并且，突然間發現，此處的棧信息與之前GitHub上JetBrains/android項目中分析到的源碼位置相同~！！at

com.android.tools.apk.analyzer.ArchiveTreeStructure.create(ArchiveTreeStructure.java:100)看來，這就是真實的原因所在了。2.6項目查因ArchiveTreeStructure主要作用是分析apk文件中的檔案文件樹形結構，且從最終拋出的錯誤信息可以看出：Apk包中zip文件出現的問題，zip文件頭部信息無效。java.util.zip.ZipError:

invalid

END

header

(bad

central

directory

offset)抓住這一關鍵點，那就好辦了。直接搜索整個項目中的.zip文件，發現還真有不少。并且存在于assets目錄下。主要存放的是一些資源。直接解壓縮.zip文件，發現有問題，果然，此處有問題的.zip文件導致apkanalyzer在分析Apk過程中，分析到這些.zip文件出現了問題。.zip格式顯然是不符合.zip規范的，那么，具體是什么問題呢？查找到項目使用到這些文件的代碼位置。淚奔了，有木有？！2.7核驗到現在位置，整體邏輯已經很清晰了。項目中因為存在移除了表示zip格式的頭字節的zip文件，導致在使用AndroidStudioAnalyzeAPK分析Apk時，出現程序錯誤，從而只顯示ParsingManifest。究竟對不對呢，可以以簡單方式核驗下。1，通過移除此類有問題的.zip文件，重新打包，發現可以使用AndroidStudioAnalyzeAPK進行分析了，直接使用apkanalyzer命令行分析時，也木有問題。2，使用二進制修改工具，將這類有問題的.zip文件對應的四個字節的頭信息給補上。此處推薦使用HexFriend工具，可以直接以十六進制修改對應的二進制文件內容。HexFriend打開zip文件后，發現文件頭字節中，確實不符合zip規范。zip文件頭四個字節是固定的，504B0304,用來表示的是對應的zip格式。于是，我們手動補上試試。保存后，發現.zip文件可以通過系統工具解壓了。替換后再次打包驗證，發現可以AndroidStudioAnalyzeAPK可以正常分析，apkanalyzer可以直接使用。三、解決項目中之所以此處將zip文件頭四個字節去除存放，當時主要考慮是安全性問題。然后通過代碼的形式在拷貝過程中，去補上對應的字節信息