分析APK时，AndroidManifest.xml适合先于大段代码阅读。它能告诉我们应用声明了哪些权限、包含哪些组件，以及哪些入口可能与其他应用交互。JEB Decompiler可以把安装包中的二进制清单解码，配合代码视图继续追踪。阅读时也要分清声明与实际行为：申请了录音权限，不代表程序已经录音；组件允许外部访问，也不能直接认定存在安全问题，后面还需要查看实现。

　　一、JEB Decompiler怎么查看AndroidManifest.xml

　　直接解压APK得到的清单可能无法作为普通文本阅读。在JEB中，应打开APK解析后的清单节点，而不是停留在原始文件的字节视图。

　　1、打开APK中的清单文件

　　①点击【File】→【Open】，选择目标APK，等待解析完成。

　　②在【Project】树中展开APK节点，找到解码后的【AndroidManifest.xml】或对应清单节点，双击打开。

　　③查看页面是否已经显示【manifest】、【application】等XML元素。如果当前是原始字节内容，返回项目树，选择解析后的清单节点。

　　④若工程里只有【classes.dex】，重新通过【File】→【Open】载入完整APK。单独的DEX不包含应用清单。

　　META-INF目录下的MANIFEST.MF属于签名相关文件，与AndroidManifest.xml用途不同。文件名相近，分析对象却不能混用。

　　2、确认包名、版本和SDK信息

　　先认准安装包，再阅读权限。同一应用的不同版本，清单内容可能发生变化，旧版本结论不宜直接套用。

　　①在【manifest】中查看【package】、【android:versionName】和【android:versionCode】，记录当前应用及版本。

　　②找到【uses-sdk】，查看【android:minSdkVersion】和【android:targetSdkVersion】，了解应用声明的系统要求。

　　③在【application】中查看【android:name】，确认是否指定了自定义Application类。

　　④遇到【android:label】等字段引用字符串资源时，到解析后的资源中查找对应内容，避免把资源编号当作显示文字。

　　二、JEB Decompiler清单中的权限和组件信息如何分析

　　清单较长时，可以先查权限，再找入口，随后阅读访问限制。这样留下的是有待追踪的对象，不必把所有声明都抄一遍。

　　1、分清使用权限与自定义权限

　　①查找【uses-permission】，阅读【android:name】，整理应用声明使用的权限。

　　②查看同一条声明是否带有【android:maxSdkVersion】，判断它是否只针对部分系统版本。

　　③查找【permission】，查看应用自行定义的权限名称及【android:protectionLevel】。

　　④在各组件的【android:permission】中查找这些权限，确认它们被用于保护哪些入口。

　　uses-permission表示应用需要使用某项权限，permission则是在定义权限。前者不能证明权限已经授予，后者也不能单凭名称判断保护强度。比如一个听起来很敏感的自定义权限，仍要结合保护级别和组件引用来看。

　　2、按组件类型寻找功能入口

　　①在【application】下分别查找【activity】、【service】、【receiver】和【provider】，查看页面、服务、广播接收器及内容提供者。

　　②阅读组件的【android:name】，复制类名，到DEX代码树中定位对应实现。

　　③在【intent-filter】中查找值为android.intent.action.MAIN的【action】，以及值为android.intent.category.LAUNCHER的【category】，识别桌面启动入口。

　　④如果入口位于【activity-alias】，继续查看【android:targetActivity】，找到它指向的Activity。

　　⑤组件名以点开头时，结合【package】还原完整类名，再与代码中的类对应。

　　桌面入口适合帮助理解启动流程，但应用还可能通过广播、服务或外部链接进入其他业务。只阅读启动Activity，容易漏掉这些路径。

　　3、查看组件的外部访问条件

　　导出组件本身并不异常。分享、登录回调等功能可能需要外部调用，分析时应关注它接收什么，以及接收之后做了哪些验证。

　　①查看组件的【android:exported】和【android:enabled】，同时检查【application】层面的相关配置。

　　②对允许外部访问的组件，查看【android:permission】，确认调用方是否需要持有指定权限。

　　③展开【intent-filter】，阅读【action】、【category】和【data】，了解声明的请求匹配条件。

　　④【android:exported】没有明确填写时，结合组件类型、目标SDK与设备系统版本核对规则，不要统一视为关闭。

　　⑤根据【android:name】进入实现，检查外部参数、登录状态和调用者身份等校验。

　　4、单独检查Provider的数据访问设置

　　①在【provider】中查看【android:authorities】，记录内容访问使用的标识。

　　②对照【android:permission】、【android:readPermission】和【android:writePermission】，区分读写限制。

　　③查看【android:grantUriPermissions】及【grant-uri-permission】，了解是否允许临时授权访问URI。

　　④按【android:name】找到实现，阅读查询、写入或打开文件等相关方法。

　　Provider没有对外导出，也可能通过临时URI授权共享指定内容。因此，数据访问范围需要结合权限与授权机制判断，不能只停在exported字段。

　　三、JEB Decompiler怎么结合代码验证清单信息

　　清单适合提供线索，代码才能说明线索对应的功能。第三方SDK可能带入权限和组件，运行时注册的对象也未必直接列在清单里。

　　1、从声明追到实际调用

　　①复制组件的【android:name】，在DEX代码树中找到对应类，打开反编译结果。

　　②选中需要追踪的方法或字段，按X打开交叉引用，再双击引用位置继续阅读。

　　③对【uses-permission】中的权限，查找权限检查、授权请求与相关功能调用，确认它出现在哪条业务路径。

　　④遇到反编译结构不清楚的代码，对照反汇编内容，检查分支和参数传递。

　　没有搜到权限字符串，不能直接判定功能没有使用。权限检查可能被封装，部分实现也可能位于本地库或动态加载代码中，需要沿调用关系继续确认。

　　2、补查清单以外的情况

　　①搜索registerReceiver相关调用，确认是否存在未列入【receiver】声明的动态广播接收器。

　　②查找组件启用、禁用相关代码，与【android:enabled】的初始值对照。

　　③如果安装包来自拆分分发，核对当前是否只有【base.apk】，以及所需功能模块是否齐全。

　　④记录结论时，分别注明【AndroidManifest.xml】中的声明、代码中的调用位置和运行时观察结果，保留判断依据。

　　总结

　　JEB Decompiler把清单、资源与代码放在同一个分析环境中，便于从组件声明继续追踪功能实现。面对类名混淆、代码量较大的APK，先读AndroidManifest.xml，可以减少漫无目的地翻找。不过，权限是否获批、入口能否调用、数据是否对外共享，都需要更多信息佐证。希望这些方法能帮助大家把清单读得更明白，也能在继续分析代码时找到合适的切入点。后续若有相关需求，欢迎联系我们咨询了解。