寻求Android平台smali代码调试工具：Smalidea的可靠替代方案

针对你遇到的Smalidea断点失效、丢失引用等问题，以下是2018年后更稳定的调试方案：

方案一：Android Studio原生调试器 + Apktool #

这是目前最主流的方案，依赖Android Studio成熟的远程调试能力：

• 反编译APK：用Apktool将目标APK反编译为包含smali代码的项目，执行命令 apktool d target.apk
• 启用调试：修改反编译后项目的AndroidManifest.xml，在<application>标签中添加android:debuggable="true"
• 重新打包签名：执行 apktool b target -o debug.apk，用apksigner对debug.apk进行签名
• 配置调试：
  1. 将签名后的APK安装到设备，启动目标应用
  2. 在Android Studio中点击Run > Edit Configurations，添加Remote JVM Debug配置，端口设为8700（Android默认JDWP调试端口）
  3. 点击调试按钮连接设备，直接在smali文件中设置断点即可调试
• 优势：原生调试器稳定性远高于Smalidea，断点跳转、单步执行逻辑更可靠，不会出现跳过断点或丢失引用的问题

方案二：IntelliJ IDEA + Bytecode Viewer插件 #

适合追求集成度的场景，无需单独使用Apktool：

• 安装插件：在IntelliJ IDEA的插件市场搜索并安装Bytecode Viewer
• 导入APK：通过插件直接打开目标APK，插件会自动反编译并展示smali代码
• 调试配置：
  1. 确保目标APK处于可调试状态（可通过adb shell am set-debug-app -w com.your.package强制开启，无需重新打包）
  2. 启动应用后，通过插件的调试功能连接设备，设置断点即可开始调试
• 优势：集成反编译与调试功能，操作流程更简洁，适合快速调试需求

方案三：Ghidra + ADB（适合深度逆向场景） #

若需结合Native层调试或更底层的分析，可使用Ghidra：

• 导入分析：将目标APK导入Ghidra，完成自动分析后查看smali代码
• 端口映射：通过ADB将设备的JDWP端口映射到本地，执行 adb forward tcp:8700 jdwp:进程ID（进程ID可通过adb shell ps | grep com.your.package获取）
• 远程调试：在Ghidra中配置远程调试连接，指向本地8700端口，设置断点后即可调试
• 优势：支持多语言（Smali、Native）混合调试，适合复杂逆向工程场景

关键注意事项 #

• 可调试状态：无需修改Manifest重新打包时，可执行adb shell am set-debug-app -w com.your.package命令，强制让应用进入可调试模式
• 混淆代码：混淆后的smali代码方法名、变量名被简化，可能导致断点失效，建议优先调试未混淆或已脱混淆的APK
• 端口冲突：调试前关闭其他占用8700端口的工具，避免连接失败

内容的提问来源于stack exchange，提问作者Fnr