拿到一个安卓包，先看什么（10 分钟出结论的检查顺序）

顺序很重要

一个 170MB 的包，全量反编译要十几分钟、吃 4G 内存。先做便宜的检查，有疑惑再往深挖。

第一步：看清单文件（1 分钟）

aapt2 dump badging app.apk | head -30

看三样：

• package 名 + versionCode：确认是不是你要的那个版本
• targetSdkVersion：这是最刺眼的指标。看到一个 2026 年的应用 targetSdk=23（2015 年的水平），
  基本可以判断开发团队很久没维护了
• 权限列表：逐条看，别扫一眼就过

第二步：数权限，并按时髦度分类（2 分钟）

真实案例里拆过一个外卖骑手端的包，53 项权限。分类之后问题一目了然：

正常但要留意：CAMERA（人脸核验）、ACCESS_FINE_LOCATION（派单要定位）、
FOREGROUND_SERVICE（后台保活）

可疑：READ_CONTACTS、READ_PHONE_STATE、GET_ACCOUNTS —— 派单需要通讯录吗？

明显有问题：权限名拼写错误（比如 android.permission.READ_ＦＩＮＥ_LOCATION，中间混了全角字符）。
这不只是难看 —— 声明是错的就意味着实际没生效，说明这块代码没人测过。

第三步：grep 危险配置（3 分钟）

# WebView 的开关
grep -rn "setJavaScriptEnabled\|setAllowFileAccess\|addJavascriptInterface" --include=*.smali .

看到这套组合要警惕：

webSettings.setJavaScriptEnabled(true);
webSettings.setAllowFileAccess(true);
webSettings.setAllowFileAccessFromFileURLs(true);
webSettings.setAllowUniversalAccessFromFileURLs(true);
webView.addJavascriptInterface(bridge, "app");

本地文件能读 + 任意来源能访问 + JS 能调原生接口 = 如果加载了外部网页，等于把原生桥开放了。

再看：

grep -rn "usesCleartextTraffic" AndroidManifest.xml     # 允许明文 HTTP？
grep -rn "android:exported=\"true\"" AndroidManifest.xml  # 哪些组件对外暴露？

第四步：看 native 库（2 分钟）

unzip -l app.apk | grep "\.so$"

.so 里的东西是最难改的，也是最能说明这个应用有多重的：

• libsgmain.so / libsgmiddletier.so / libsgsecuritybody.so → 阿里系安全 SDK，做请求签名和完整性校验
• libFaceLivenessSDK.so / libALBiometricsJni.so → 人脸活体
• libflutter.so → 界面是 Flutter 写的，反编译 Java 层看不到 UI 逻辑

这一步能帮你省掉最大的坑：如果包里有完整安全 SDK，还带服务端校验，
那"改包再装"这条路基本就堵死了 —— 详见下一篇逆向笔记里的对照实验。

第五步：看它是怎么写界面的（2 分钟）

unzip -l app.apk | grep -E "assets/flutter|classes.*dex|assets/index.html"

• 有 assets/flutter_assets/ → Flutter，界面逻辑在 Dart 里，Java 层只有壳
• 有 assets/*.html → H5 页面，改起来容易但也说明核心逻辑在服务端
• 只有 classes.dex → 原生 Java/Kotlin

判断依据很重要：Flutter 或 H5 写的应用，「界面上的报错」往往不是本地崩了，而是请求被服务端拒了。
这时候去翻 smali 找报错字符串是白费劲。

结论

10 分钟能得到的结论：

1. 这个包多久没维护了（targetSdk）
2. 权限合不合理（有没有抄错、有没有多要）
3. WebView 有没有危险配置
4. 它上了多重的安全措施（native 安全库是最强信号）
5. 界面是什么技术写的（决定你该往哪层挖）

先花 10 分钟做这五步，比埋头反编译两小时有用。