|
|
Android Studio如何调试Framework层的代码？
Android框架层的代码庞大且复杂，在分析一些过程的时候经常会跟丢代码，所以希望能够动态调试Framework，已经有编译好了的Android源代码…
关注者
374
被浏览
59,235
6 个回答
关注这个问题一段时间了，强答一下吧；软件开发过程中，只有小部分的时候是编码，大部分的工作都是在调试，Debug是一项非常非常重要的技能，毋庸多言。我这里只给出F ramework中Java代码的调试方法，关于native代码的调试还请高人指点。
OK，回到正题；其实整个调试过程非常简单：
- 在你要调试进程的合适位置打上断点
- 跟踪代码（Step in/out/over等等）
接下来就从这两个方面展开。
如何在正确的地方下断点
「正确的地方」包含两个含义：首先，调试是以进程为单位进行的，如果你需要调试运行在进程A 中的代码，却把debugger attach到了B进程，那么这个断点压根儿就是牛头不对马嘴；另外呢，比如你想调试Android的多媒体框架，你得知道media相关的类在哪吧，也就是说需要在正确的函数里面下断点。
首先，如何在合适的进程下断点？
如果是调试我们自己写的App，在Android Studio里面非常简单，在Run菜单de最后面有一个attach debugger to Android process 的选项，打开之后选择自己需要调试的进程即可；但是，你要是需要调试Android Framework层的代码，这样做是达不到目的的——Framework层的代码通常运行在别的进程（比如ActivityManagerService运行在system_server进程），而这些进程通常情况下是不可调试的，也就是说在attach debugger to android process 的那个菜单里面不会有系统的进程，如下图：
解决这个办法很简单：使用模拟器（真机也行，限Nexus系列刷原生Android系统，注意事项见附录），我的Nexus 5 可以调试的进程如下：
这样，系统中所有的Android进程都可以调试了；这一点很重要，比如你要分析Activity的启动流程，相当多一部分代码是在ActivityManagerService所在的进程system_server执行的，如果你把断点打在别的进程，就会产生跟丢了的情况。在比如，你要调试ActivityThread的main函数，在main函数里面执行了一句attach，最终掉了AMS的attachApplication这时候，代码就通过Binder IPC调用到了AMS的system_server进程。
明白你要执行的代码运行在哪一个进程相当重要，在Android中，由于Binder通信机制的存在，「进程迁移」使用的非常非常频繁，因此需要对binder机制有一定的了解；详细的话可以参考我的博客：
Binder学习指南如何在对应的代码处下断点？
假设我们现在把debugger attach到了正确的进程，那么断点应该下在哪里呢？直观来讲，就是说我需要导入所有的Android源码吗？如果不是应该导入哪些代码，怎么导入？
首先，如果你需要调试的类在sdk里面导出了，你压根儿就不需要再导入源码，Android Studio自动帮你关联了这部分代码（前提是你用SDK Manager下载了sdk的源码，如下图：
比如你要调试ActivityManagerServce类的attachApplication方法，那么很简单；创建一个空的Android项目，SDK版本选择与你要调试的模拟器/真机 的android相同（这很重要，下文会讲述）；然后attrach 到system_server进程，直接在attach_application上面打上断点；随便启动一个app，可以看到我们熟悉的调试界面：
如果这部分类在sdk中没有导入（比如@hide)的，又或者压根儿不是SDK的类，（比如系统app的源码）那应该怎么办呢？ 直接导入这部分代码即可。 不需要是Android项目，普通的Java项目即可；举个例子，假设你想调试原生Android系统的「系统设置」这个程序，改如何做呢？
根据上面的分析，我们首先得知道「系统设置˜」运行在哪一个进程，通常情况下进程名字就是包名；我们查出设置的包名即可，而包名是在源码的AndroidManifeist中声明的，因此，我们查到˜「系统设置」这个程序的源码即可；源码在
https:// android.googlesource.com /，系统App的源码在/packages这个子目录下面，我们一个个找，可以确定「系统设置」的源码在
https:// android.googlesource.com /platform/packages/apps/Settings/；然后我们把这部分代码git clone下来，导入Android Studio：
我们去AndroidManifest中查到，「系统设置」的包名为：com.android.settings，这样我们attach到这个进程 ：
然后，我们随便打一个断点玩一玩，比如进入设置主界面的时候，断下来；我们在AndroidManifest中查到设置程序的入口界面为：Settings，我们在这个类的onCreate里面打一个断线，然后进入设置程序，发现完美滴断下来了：
OK，到这里；应该学会如何在正确的位置打断点了：正确的进程，正确的位置。接下来，要完成调试，还需要一些技巧。
如何跟踪代码？
或许你会说，跟踪代码不就是step in/out/over么，这有什么难的？但其实事情并没有你想象的那么简单，要优雅滴调试，还是需要一些姿势的。
- 行号对应
跟踪代码一个首要的问题是行号对应。如果你在正确位置下了断点，但是跟踪的时候，单步调试，发现运行的代码和Android Studio里面的代码对不上号，那么就很蛋疼；要使得调试器的行号能够对应，必须保证设备上的代码和调试器的代码是同一份；简单来说，需要使用Android的原生系统（模拟器，Nexus系列真机），然后调试器里面使用的SDK版本，必须和设备的系统版本一致。
一定要注意行好对应这一点，这会使调试过程简单很多；那么，如果没有办法，行号对不上，那该如何调试呢？行号对不上也是可以调试的，这里先卖个关子，有赞更新 ^_^
2. 熟练使用断点
断点是有很多种类型的，方法断点，watch point，条件断点都能够很好滴辅助我们调试；如果你连这几个名词都没有听说过，一定要恶补一下；可以参阅我的博客：
Android Studio你不知道的调试技巧到这里，Android Framework的Java层如何调试应该比较清楚了；回到题主的问题：如何调试ActivityThread的main函数？
这个有一点点复杂，因为main函数执行得非常早，在进程启动之后还没来得及attach debugger，这代码估计已经执行了；如果你你自己的app进程，你可以使用Debug.waitForDebugger()这个函数等到调试器；但是Framework的代码就不行了；如楼上所说，这里可以取个巧：main函数会通过Binder IPC到AMS进程的attachApplication函数，你直接在AMS所在的进程system_server对应位置打上断点（上文讲述过的attachApplciation），这个函数执行完毕，就自动回到app进程了，debugger捕捉到断点之后，你可以在app进程里面下断点。
抛砖引玉，若有不妥多多指教～
没有用Android Studio动态调试过android framework的代码，但用Eclipse动态调试android framework的代码以前倒是经常干。
这里主要针对Eclipse环境来回答一下题主的两个问题。
对于第一个，能否只导入framework的代码来动态调试的问题。
答案是可以的。
android framework的代码量本身非常庞大，甚至可以只导入framework的一部分代码来动态调试对应的那一部分代码。比如system server进程，也就是我们在DDMS的设备进程列表中看到的那个system_process进程，会运行主要的系统Service的代码，比如AMS，WMS，PMS等，这些系统Service的代码位于frameworks/base/services/这个位置，我们需要动态调试这些Service的代码的时候就可以只导入这一部分的代码。再比如，android app进程中运行的framework代码，主要位于frameworks/base/core/这个位置，要动态调试这部分代码时也可以只导入这部分代码。
尽管这个时候为android framework或framework的一部分创建的Java Project无法在eclipse中编译通过，但依然有办法动态调试相关的代码。
对于第二个调试设置的问题。
想要动态调试android framework的代码，首先有个前提，即需要将你编译的ROM烧进设备，且要求编译模式是user_debug或eng，也就是你的Eclipse中导入的代码和你的设备上运行的是同一份。
然后是调试设置，针对题主要动态调试ActivityThread的代码这种情形，之前用过的一种思路供参考。
ActivityThread中初始化相关的代码是Android APP进程运行非常早期会执行的代码，而我们知道Android APP的进程是由zygote进程创建的，因而想要直接在这些代码中加断点动态调试比较困难。
但Android APP进程创建起来之后，比较早期的时候就会访问AMS，印象里AMS的attachApplication()方法(frameworks/base/services/java/com/android/server/am/ActivityManagerService.java)在Android APP刚启动时会被访问到，而且是同步访问，也就是说ActivityThread的执行流程通过IPC访问到这个方法，在这个方法结束之前，ActivityThread的执行流程不会继续往前走。因而可以在设备启动完成之后，创建针对于system server，也就是system_process进程的远程调试会话，在这个方法中加断点，从而截断Android APP进程的启动过程，然后再创建针对于Android APP的远程调试会话，在ActivityThread的代码中加断点，进而释放掉system_process的断点来达到题主单步调试Android App的ActivityThread的代码的目的。
创建远程调试会话的过程
比如要调试system_process进程中运行的系统Service的代码。
第一步，创建Eclipse的Java Project，导入android framework中系统Service的相关代码。
第二步，在DDMS中单击选中要调试的进程。
第三步，创建远程调试会话。
右键单击创建的android framework的Java Project，选中“Debug As” -> “Debug Configurations ...”，在弹出来的对话框中找到“Remote Java Application”这一项，并双击它，将直接创建一个远程调试会话。找到“Connection Properties:”，修改其中的Port为8700。
然后点击右下角的“Debug”按钮。
至此则远程调试会话创建完毕，并启动对于前面第二步中选中的进程的调试。
然后呢，就可以愉快的加断点，动态调试system_process进程中运行的framework代码了。
针对Android App进程的远程调试会话的创建
如我们前面所述，断下system_process的AMS中的attachApplication()方法会截断Android App中ActivityThread的执行流程。这个时候，进程的名字都还没有设置，因而在DDMS中可能会看到名字还是“？”的Android App进程。然后参照上面针对system_process进程创建远程调试会话的过程，为Android App进程创建远程调试会话。随后在ActivityThread的代码里加断点，并让system_process中的断点恢复执行，就可以单步调试ActivityThread的代码了。
Android App进程初始化过程中出现的问题，常可以采用这种方式来调试。