做Android原生开发、嵌入式Linux调试或者经常和电视盒子、车机系统打交道的人对ADB和gdbserver这两个名字一定不陌生。电脑上开一个终端跑adb shell进设备再开另一个终端用gdb连上设备里的gdbserver断点、单步、看寄存器一条龙打完收工——这套组合拳熟练之后定位Native层崩溃、疑难卡死效率比靠logcat眼猜高得多。ADB是那条看不见的调试“数据线”负责把主机和设备之间的通道打通gdbserver则是部署在设备端的调试代理替gdb在目标机器上执行读内存、改断点这些脏活。这篇文章我会从环境准备、链路联通、实操调试一直到常见报错排查完整走一遍适合刚开始搞Android逆向、NDK开发或者嵌入式Linux调试的朋友参考。1. 先搞清楚ADB和gdbserver各自是个啥1.1 ADB那条看不见的调试“数据线”ADB全称Android Debug Bridge名字里的Bridge翻译成“桥”非常贴切。它不是一个单一程序而是一整套组件你电脑上敲的adb命令是client端它把指令发给后台的adb server再由server通过USB或者网络找到设备上常驻的adbd守护进程最终完成双向数据传输。很多新人在热词里搜“adb安装”“adb驱动”“adb连接手机”以为ADB只是用来装Apk的这多少有点小看它。ADB能做四类事情文件操作push/pull、shell命令adb shell直接进Linux终端、日志抓取adb logcat、端口转发adb forward。这四件事里前三件是日常高频用法第四件则是把gdbserver整个链路接起来的核心——没有端口转发主机上的gdb根本找不到设备里的调试服务。ADB的另一大优势是跨USB和网络两种物理链路。USB调试适合手机这类方便插线的设备而电视盒子、车机、路由器这类盒子设备经常没有USB调试口这时候用adb connect走Wi-Fi网络反而更顺手。我调试设备时最喜欢先跑adb devices确认USB链路再顺手用adb connect把设备以IP方式加进来两条链路互为备份其中一条断了也不至于整个调试会话中断。1.2 gdbserver把调试器“寄生”到设备上gdb大家可能听过GNU的调试器单步执行、下断点、查看调用栈、修改变量值功能非常全面。但它有个天然短板它是给本机调试设计的在目标设备上跑完整版gdb需要把一整个调试器装进去占用空间大、资源开销高还经常因为没有配套符号库导致调了等于没调。gdbserver就是为了解决这个矛盾被创造出来的。它是一个体积很小的服务程序运行在目标设备上只负责三件事读取目标程序的内存、响应调试端发来的控制指令、把运行状态同步回去。真正干活的是你电脑上的gdb客户端两边通过TCP或者本地socket通信。好处很直接设备上只需要放一个几百KB的小工具不用装完整gdb调试体验却和本地调试几乎一致断点、单步、观察变量全都能用。远程调试的思路可以在生活里找到类比你手边只有一把螺丝刀gdbserver真正会修车的大师傅gdb在店里远程指挥你拧哪颗螺丝、看哪个零件。大师傅不用亲自跑到车旁边螺丝刀也干不了大修但两者配合起来什么毛病都能查出来。这套模式在Android开发里的典型场景就是Native so库崩溃、线上版本偶发卡死、系统进程异常占用CPU这类问题靠加日志还原现场太慢用gdbserver一次性能看到全部执行状态。2. 环境准备先把“手”伸进设备2.1 adb驱动与设备识别这条老坎热搜词里“adb驱动”“adb环境配置”“adb unauthorized怎么解决”占了很大比例说明不少人的调试之旅还没开始就卡在第一步。Windows系统尤其折磨人插上手机以后经常提示驱动安装失败设备管理器里显示的是黄色感叹号的未知设备。我自己装驱动时总结的经验是先装adb命令行工具再插设备然后去设备管理器手动更新驱动选择“从计算机的驱动程序列表中选择”重点找带有“Android Composite ADB Interface”字样的驱动。Linux和macOS情况好不少macOS插上开好USB调试的手机基本上adb devices就能直接识别。Linux偶尔需要在/etc/udev/rules.d/下写一条vendor规则把当前用户加入plugdev或者直接给USB设备放开权限然后重启一下adb服务。这一步配置一次就行之后一直生效。手机第一次连接时屏幕上通常会弹出“是否允许USB调试”的对话框必须点允许并且建议勾选“始终允许来自此计算机的调试”。如果不小心点了取消再插拔可能不会重新弹窗这时候需要在开发者选项里先关闭“USB调试”再重新打开或者选择“撤销USB调试授权”后重新插线。很多电视盒子、智能电视打开ADB的方式更隐蔽系统设置里可能没有直接的“USB调试”而是要连按版本号进入开发者模式再找“ADB调试”或输入设备厂商要求的校验码。不同品牌的入口差别很大但核心都是要在设备本侧先把调试开关打开否则电脑这边再怎么操作都没用。2.2 用adb connect打通Wi-Fi这条网络链路USB链路有一些天然限制数据线长度、接口松动、电脑USB口供电不足都可能导致调试中断。针对电视盒子、车机、开发板这类设备我推荐优先尝试网络链路。首先查设备IP地址和调试端口Android设备默认的调试端口一般是5555。adb connect 192.168.1.90:5555 adb devices如果connect成功adb devices列表里会多出一条“192.168.1.90:5555”的记录状态是device。要是提示unable to connect优先检查PC和设备是否在同一局域网以及设备端的ADB服务是否真的启动。部分电视盒子需要在设置里开启“网络调试”或“无线调试”否则端口虽然存在但不会应答。进入设备后第一件事是用一条命令确认CPU架构这步决定了之后要推送哪个版本的gdbserveradb shell getprop ro.product.cpu.abi输出可能是arm64-v8a、armeabi-v7a、x86_64等。记下这个值后面推送gdbserver时有很大概率能救你一次。2.3 ADB高频命令与调试联动用法调试过程中有一些ADB命令是绕不开的。安装Apk时经常遇到targetSdk版本太低被拒的情况这时用下面的命令绕过限制adb install --bypass-low-target-sdk-block app.apk快速截屏在排查界面卡死时很实用趁设备还没完全无响应先截一张当前画面留作证据adb exec-out screencap -p screen.png抓取日志则是所有调试的兜底手段尤其是Native崩溃logcat里的libc DEBUG输出往往直接给出了崩溃线程和寄存器现场adb logcat -v threadtime app.log adb logcat -v threadtime | grep -E Fatal signal|backtrace|DEBUG这其中的“-v threadtime”会把线程ID和时间戳一起打出来对比多线程交错日志时非常有帮助。ADB的日志抓取和gdbserver的调用栈分析配合起来一个负责广覆盖找线索一个负责精确定位深挖根因。3. 打通ADB与gdbserver完整实操流程3.1 编译带调试符号的目标程序想让gdb在源码级优雅地展示执行过程编译阶段必须做三件事。第一是加上调试信息编译参数里必须有-g否则gdb只能看到一堆汇编和裸地址第二是尽量关闭优化-O0保证变量不会被优化掉断点位置的代码和源码一一对应第三是不要strip符号表很多release版二进制为了减小体积会去掉符号调试时看到的全是地址根本无法定位问题。以ARM64 Android平台为例用NDK里的clang编译一个可执行程序基本参数长这样$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang \ -g -O0 -fno-omit-frame-pointer -pie -o demo demo.c-fno-omit-frame-pointer是为了保留栈帧指针这样gdb在展开调用栈时才有足够信息。实际项目里我更推荐把Debug版本和Release版本分开构建Debug版本带全部调试信息给开发用Release版本做strip和优化给用户用两个版本同时保留符号文件线上出问题后靠符号文件离线还原调用栈这个思路在一些大厂里叫“符号化体系”虽然有点重量级但排查线上问题极其好用。3.2 推送gdbserver和目标程序到设备目标程序编译好后下一步是把gdbserver和目标二进制一起放进设备。设备上的/data/local/tmp目录是调试工具的默认落点因为它通常是可写的而且没有selinux对特定目录的强限制。如果你把文件放到系统分区或者只读目录运行时很可能遇到权限被拒。adb push ./gdbserver /data/local/tmp/ adb push ./demo /data/local/tmp/ adb shell chmod 777 /data/local/tmp/gdbserver /data/local/tmp/demogdbserver从哪里来早期NDK工具链的prebuilt目录里会直接提供各个架构的gdbserver比如android-arm、android-arm64、android-x86_64等子目录。如果你的NDK版本里已经找不到它也可以从Android源码的prebuilts目录里拷贝。注意一个原则gdbserver的架构必须和设备端完全匹配arm64设备就推arm64版本x86模拟器就推x86_64版本跨架构是跑不起来的。3.3 启动gdbserver与ADB端口转发设备端启动gdbserver主要有两种模式。第一种模式是启动新程序并调试它适合复现可稳定触发的崩溃adb shell cd /data/local/tmp ./gdbserver :1234 ./demo此时gdbserver会在1234端口上监听等待gdb客户端连接。它能成功的前提是demo程序本身可以在这个shell环境下正常运行环境变量、动态库路径都得对。第二种模式是attach到已经运行的进程比如某个服务运行到一半卡死或者崩溃前的状态需要原地检查adb shell ps -A | grep demo adb shell /data/local/tmp/gdbserver :1234 --attach PID这里PID是目标进程的进程号。attach模式能直接“钻进”一个已经运行的程序对分析ANR、卡顿、资源泄漏非常有价值但设备权限要求更高后面会专门说。gdbserver启动后还需要在电脑端做一次端口映射adb forward tcp:1234 tcp:1234这条命令把设备上的1234端口映射到主机的localhost:1234本质是在USB链路上变出一根虚拟网线。做完这步主机上所有的调试流量都走ADB通道到达设备不需要知道设备的实际IP哪怕设备只在USB模式也照常工作。3.4 主机端gdb远程调试与常用操作回到电脑上打开另一个终端用gdb连接。这里有一个很容易翻车的细节主机端的gdb必须支持目标架构。调试ARM64设备我一般用gdb-multiarch或者直接用NDK提供的交叉gdb aarch64-linux-android-gdb。如果你用x86的gdb去连ARM64的gdbserver连上也会报错。gdb-multiarch ./demo (gdb) target remote :1234 (gdb) info sharedlibrary (gdb) break main (gdb) continue连接成功后info sharedlibrary能查看主程序和共享库的加载情况。如果动态库有缺失或者路径对不上需要手动指定符号搜索路径。Android的Native程序一般依赖一堆系统so库正确的做法是把App打包出来的so目录加进来(gdb) set solib-search-path /path/to/project/obj/local/arm64-v8a设置完成后在main函数下断点continue运行程序会停在main入口。这时候可以用bt查看调用栈、用frame切换栈帧、用list查看源码、用print打印变量值。整套操作和本地调试几乎一样只是数据通路从主机的进程内存换成了设备的内存。4. 我踩过的坑详细排查实录4.1 连接阶段最常见的报错与检查顺序实战里连接失败大概占调试踩坑的一半而且报错信息非常有迷惑性。比如gdbserver启动后屏幕上直接提示start: not found。原因是gdbserver或目标程序被放进了不支持直接执行的文件系统比如挂在noexec的目录下。解决办法就是把它挪到/data/local/tmp并确认chmod给了执行权限。再比如主机端target remote后立刻报Connection refused。这个报错通常不是设备端的问题而是主机端没有做adb forward或者forward之后端口写错。我建议排查时按顺序走一遍adb devices adb forward --list adb shell netstat -tlnp | grep 1234第一步确认设备还在线第二步确认端口映射存在第三步确认gdbserver确实在端口LISTEN。三步下来基本能定位90%的连接问题。4.2 架构不匹配与Remote packet报错有一类报错很典型主机端gdb刚连上就提示Remote g packet reply is too long看到这行字第一反应不是去查网络而是检查架构。gdb在连接成功后会交换一组寄存器状态如果主机gdb的架构模型和目标程序不一致收到的寄存器数据长度就对不上于是报出这个看似很懵的错误。解决办法是换成支持目标架构的调试器比如gdb-multiarch或者直接用NDK工具链里自带交叉gdb。架构不匹配在设备端同样会有提示比如在arm64设备上执行了一个x86的gdbserver会直接报“Exec format error”。遇到这个报错用adb shell getprop ro.product.cpu.abi确认设备架构再去找对应版本的gdbserver基本可以解决。4.3 attach进程遇到ptrace权限问题怎么办Attach模式调试比自己启动的程序麻烦得多。原因在于Android对ptrace系统调用有严格的权限限制默认情况下一个进程只能被它的父进程或者具有CAP_SYS_PTRACE权限的进程调试。你adb shell连接之后shell用户的权限往往不足以attach系统App或者别的应用进程。常见报错是ptrace: Operation not permitted我的建议是分情况处理。如果只是调试自己开发的App先确认AndroidManifest里设置了android:debuggabletrue调试器才有权限attach如果调试系统服务或者系统App大多数ROM需要root权限在root过的设备上运行adb root把adbd提权再尝试attachpull第三方App到手机上调试时经常需要借助run-as命令以App自身身份启动shell然后再启动gdbserver attach到它的进程这样权限才够。4.4 断点无效和共享库加载延迟的实战解法调试动态库代码时经常遇到断点设了continue却总是停不下来。这不是gdb坏了而是目标so还没加载到内存。Android程序启动后很多so是延迟加载的代码执行到dlopen之前断点所在地址根本不存在。要么先continue到so加载完成再打断点要么用rbreak或者pending breakpoint让gdb在库加载后自动通知。我在Android上调试JNI库时最稳定的做法是在Java层或Native入口处先断下来等到so加载完再重新打断点。4.5 用logcat和gdbserver配合还原崩溃现场gdbserver不是万能的有些场景下程序闪退速度太快还没来得及打断点就已经挂掉了。我的习惯是先看logcat里有没有libc DEBUG信息Android的Native crash通常会打印崩溃时的signal、寄存器值、backtrace甚至已经帮你把调用栈展开好。这种情况先用logcat拿到崩溃现场的初步脉络再回到gdb里复现在疑似崩溃函数入口打断点逐步执行很快就能定位到具体代码行。5. 一套能提高效率的实战技巧5.1 把常用调试命令封装成脚本调试动作重复做三遍以上就应该考虑写成脚本。我自己的流程长期固化成了一个shell脚本检查设备连接、检测ABI、推送gdbserver、设置端口映射、启动gdb客户端。#!/bin/bash ABI$(adb shell getprop ro.product.cpu.abi | tr -d \r) adb push ./gdbserver /data/local/tmp/ adb push ./demo /data/local/tmp/ adb shell chmod 777 /data/local/tmp/gdbserver /data/local/tmp/demo adb forward tcp:1234 tcp:1234 exec gdb-multiarch ./demo这样每次调试都不用重新敲不带重样的命令把精力集中在真正的问题分析上。涉及多个动态库时脚本里还可以顺手settoolchain路径自动加好solib-search-path。5.2 多设备、多进程并发调试的思路当手头有多台设备需要同时调试时USB通道可能成为瓶颈。我的经验是网络调试更适合多设备场景每台设备用不同的IP:5555连接ADB会为每台设备维护独立的通道。调试器层面要做到端口隔离设备A用1234端口设备B用1235端口避免两个gdbserver端口冲突。我自己曾经在自动化测试框架里同时管理六台盒子主控端用一个任务队列维护“设备IP、端口、目标进程”三元组每个调试任务按顺序执行互不干扰。如果是单个程序内部要并发启动多个调试会话思路一样把端口数据参数化即可重点注意别在写脚本时把所有设备配置写死成同一套。5.3 几个值得长期坚持的调试好习惯第一Debug版本一定要保留未strip的符号文件并妥善归档线上版本出现问题时符号文件就是唯一的破案线索。第二调整代码前先保存一份崩溃现场的日志和寄存器快照再动手修改避免掉进“改着改着忘了原始状态”的坑。第三遇到几十MB的超大App优先用gdbserver attach而不是重新启动启动过程本身就会消耗大量时间而attach往往能在几十秒内拉到第一个现场。第四不要在生产环境直接拉调试器生产包一般做了优化和符号剥离调试价值低而且可能因为ptrace限制导致附加失败浪费大量时间。注意gdbserver调试的对象是开发调试包不是用户线上包。用release包调试时因为缺少调试符号和栈帧信息gdb能给出的线索极其有限与其折腾不如先拉一条带符号的debug包复现一次。6. 后续还能玩出什么花样这套ADB加gdbserver的调试链路向上可以接IDE图形化调试Android Studio的Native调试原理上就是它把gdb客户端换成了LLDB底层连的还是ADB和调试服务向下可以延伸到嵌入式Linux设备去掉Android层直接在Linux开发板上跑gdbserver配合主机的交叉gdb一样能调试Linux应用和内核模块。我个人实际用下来最推荐的做法是凡是新设备第一次到手先把ADB链路的连接问题彻底解决然后固化一套“ABI检测、gdbserver推送、端口映射、logcat挂上”四件套脚本。遇到疑难问题第一时间出Native调用栈而不是改代码加日志重新演一遍。熟练之后从出问题到看到调用栈基本不超过两分钟——这个基本功我认为是每一个搞底层调试的人都值得提前练好的。