使用Android Studio调试AOSP下载下来的源码,记录下调试中发现的几个点
调试android.jar中包含的android.ap.view中的View的measure方法，source源码下载了，死活进不去断点，后来发现在source源码跟android虚拟机的API都是22层级的情况下，使用22的Android 5.1（Google APIs）这个带括号的版本虚拟机可以进断点，同样是22的Android 5.1不带括号的AOSP版本虚拟机反而不能进View的measure断点。
想要调试ActivityManagerService的bindApplication，分析了大量攻略，后来才发现，可以直接导入这一个文件，也不用管导入的是什么工程（Android与java均可），也不用管是否有错误，直接开启虚拟机之后使用AS的attach to process功能就可以直接进断点，只要选中要调试的是system_process进程即可。过程中主要的误导项是断点打在了bindApplication的一开始（为了想一开始就进入省的判断失误），结果断点只要一开始开启调试模式就自动变为失效状态，误以为是源文件不对应，实际上对应源文件与运行时的问题一开始就非常注意，都是严格按版本下载的，但是其实可以打在下面一点的行上就可以进调试的，折腾了半天一直以为根本就没成功（因为一直没进打在方法第一行的断点，一调试就出错），由于问题1的影响还换了好几个版本的虚拟机，都不可以，后来又更换了别的源码文件，还是不可以，偶然在下面打了一个端点，竟然进去了，这才发现还有这种坑。跟源码没关系的，一开始用的源码就是正确的源码，这块没啥问题，主要是断点在不同行可能有的生效，有的就不行。
重点：
使用ddms断点调试或者叫远程调试的时候，只需要保证runtime源码和debug源码一致，不关心导入的debug源代码是否编译通过，是否有错误等等。
只需要机器运行的代码跟我们要调试的代码 “一致” 即可。这部分需要对调试的原理相当清楚。不是所有的代码行都可以打上有效断点。可能某行会出现xx的断点，但是不说明下面的行就打不上断点了，这点非常重要。
有时候不要太相信调试的东西，平时开发的时候也不是没有遇到过，虽然概率很低。