setAppInfo()
方法中,将对应的控件内容从原来的Parsing Manifest
改成了对应的包名和版本号等信息。
显然,在代码myNameComponent.append("Parsing Manifest");
与setAppInfo(result);
之间,程序出了问题。
这之间关键的类,主要有apkParser
对象对应的ApkParser
类,还有Archives
类。继续跟踪ApkParser
类,发现其主要也是一个外壳性质的类,apkParser.constructTreeStructure()
方法主要流程来到如下所示位置:
现在,我们发现,无论是此处的ArchiveTreeStructure
类,还是之前的Archives
类,这两个关键线索上的类都不是在这个项目中。根据代码文件中的import
导入,很快,我们发现,线索被定向到了com.android.tools.apk.analyzer
包中。
从包名上来看,com.android.tools.apk.analyzer
应该是Android Tools
中带的一个工具。来到项目iml
文件,我们发现与之相关的构件。其中,组名是:com.android.tools.apkparser
,构件名是:apkanalyzer
。
2.4 工具本体-apkanalyzer
至此,我们先总结下问题的原因。
AS中自带的Analyze APK,实际上是通过集成了插件实现,而插件内部,又通过调用了 Android Tools中的名叫apkanalyzer
的工具实现的分析。因此,想要追溯出现问题的原因,我们需要再去对应追踪下apkanalyzer
。
如果熟悉Android Tools,我们对应去tools目录下找找,很快便能找到apkanalyzer
。及时不熟悉,不知道目录位置也没关系,打不了全局搜索下。
终于,对应的工具本体出现在我们面前。
实际上,如果对Google Developer比较熟悉,或者直接在上面搜索下,也能直接在Analyze APK
页面上找到核心信息,直接指向工具本体—apkanalyzer
。