How to debug Android Framework?

Linus has a famous saying that is widely known: Read the fucking source code. But in fact, to deeply understand the working principle of a certain software, framework or system, just "reading" the code is far from enough. Take the Android Framework as an example. The entire code volume is very large. How to understand those classes with tens of thousands of lines? So what I want to say today is:

Debug the fucking source code!!

I have shared an answer before: What Android compatibility issues have you encountered? There are some very strange problems here, I believe you can never find them just by looking at the code. There is also a series of articles I wrote on the principles of the Android plugin framework, which involve a lot of knowledge of the Android Framework layer. Some friends will ask, how did you learn these principles of the Framework layer? Is there a trick? Yes! That is debugging.

Debugging is a very important skill, needless to say. Today I will share with you my experience of debugging Android Framework. Once you master this skill, no problems at the Java layer can stop you.

Overview

In fact, the whole debugging process is very simple:

• Set breakpoints at appropriate locations in the process you want to debug
• Tracking code (Step in/out/over etc.)

Before we start talking about these two aspects, it is necessary to first briefly understand the basics of debugging. There is a standardized standard for debugging on the Java platform, which is JPDA (Java Platform Debugger Architecture); through the API provided by JPDA, developers can easily and flexibly build Java debugging applications. JPDA mainly consists of three parts: Java Virtual Machine Tool Interface (JVMTI), Java Debug Wire Protocol (JDWP), and Java Debug Interface (JDI).

Debugging a Java program is nothing more than obtaining information about the corresponding Java virtual machine through a debugger. The JDWP mentioned above is the bridge between the debugger and the virtual machine. There is a dedicated jdwp thread inside the dalvik virtual machine. The adbd process of the Android system communicates with the jdwp threads of each virtual machine through a socket. The external debugger communicates with adbd through the adb tool and then completes the communication with jdwp. This is what we usually mean by "attach debugger" - connecting to the specified process that needs to be debugged.

How the debugger works

How to set breakpoints at the right place

The "right place" has two meanings: first, debugging is performed in units of processes. If you need to debug the code running in process A, but attach the debugger to process B, then this breakpoint is completely irrelevant. In addition, for example, if you want to debug Android's multimedia framework, you have to know where the media-related classes are, which means you need to set breakpoints in the correct functions.

How to set breakpoints in the appropriate process?

If we want to debug our own App, it is very simple in Android Studio. At the end of the Run menu, there is an option to attach debugger to android process. After clicking it, a menu will appear and you can select the process you want to debug. However, if you need to debug the code at the Android Framework layer, this will not achieve the purpose - the code at the Framework layer usually runs in other processes (such as ActivityManagerService running in the system_server process), and these processes are usually not debuggable, that is, there will be no system process in the menu of attach debugger to android process, as shown below:

Ordinary undebugable Android devices

Why can't it be debugged? We briefly described the working principle of the debugger above. We know that each virtual machine has a jdwp thread. If this thread refuses to connect to the debugger, you can't debug the process. All Android App processes are forked from the Zygote process. In the android.os.Process class, we can see that there is a sentence in the startup process of the Android process:

 if ((debugFlags & Zygote.DEBUG_ENABLE_DEBUGGER) != 0) { 
 
    argsForZygote.add ( "--enable-debugger" ); 
 
 }

In other words, whether a process can be debugged is determined by the parameters when the process is started; ordinary App processes can be debugged by default if they have a debug keystore, or if you specify debuggable as true in AndroidManifest. For system processes, we can only take system-level measures: make the entire system debuggable - debug version or compile the system with debuggable as 1.

The solution is very simple: use an emulator (or a real device, limited to Nexus series with native Android system, and change the debuggable parameter of the system startup to 1). The process that can be debugged on my Nexus 5 is as follows:

A device that can debug any process

In this way, all Android processes in the system can be debugged; this is very important. For example, if you want to analyze the startup process of an Activity, a considerable part of the code is executed in the process system_server where the ActivityManagerService is located. If you set a breakpoint in another process, you will lose track. For example, if you want to debug the main function of ActivityThread, an attach statement is executed in the main function, and when the attachApplication of AMS is finally called, the code calls the system_server process of AMS through Binder IPC.

It is very important to understand which process the code you want to execute is running in. In Android, due to the existence of the Binder communication mechanism, "process migration" is used very frequently, so you need to have a certain understanding of the binder mechanism; for details, you can refer to my blog: Binder Learning Guide

How to set breakpoints at the corresponding code?

Assuming that we have attached the debugger to the correct process, where should we set the breakpoint? Intuitively speaking, do I need to import all the Android source code? If not, which code should I import and how should I import it?

First of all, if the class you need to debug is exported in the SDK, you don’t need to import the source code at all. Android Studio automatically associates this part of the code for you (provided that you downloaded the source code of the SDK using SDK Manager, as shown below:

SDK manager download source code

For example, if you want to debug the attachApplication method of the ActivityManagerServce class, it is very simple; create an empty Android project, and select the same SDK version as the emulator/real device Android you want to debug (this is very important, which will be discussed below); then attrac to the system_server process, and set a breakpoint directly on attach_application; start any app, and you can see the familiar debugging interface:

Debug attachApplication

What should you do if this part of the code is not imported in the SDK (such as @hide), or is not a class of the SDK at all (such as the source code of the system app)? Just import this part of the code. It does not need to be an Android project, a normal Java project will do; for example, suppose you want to debug the "System Settings" program of the native Android system, how do you do it?

According to the above analysis, we first need to know which process "System Settings ˜" runs in. Usually, the process name is the package name; we can find out the package name of the settings, and the package name is declared in the AndroidManifeist of the source code. Therefore, we can find the source code of the "System Settings" program; the source code is at https://android.googlesource.com/, and the source code of the system App is under the /packages subdirectory. We search one by one and finally determine that the source code of "System Settings" is at https://android.googlesource.com/platform/packages/apps/Settings/; then we git clone this part of the code and import it into Android Studio:

Debug Settings

We go to AndroidManifest and find that the package name of "System Settings" is: com.android.settings, so we attach to this process:

attach setting process

Then, we randomly set a breakpoint to play around, for example, when entering the main interface of settings, we break down; we find in AndroidManifest that the entry interface of the settings program is: Settings, we set a breakpoint in onCreate of this class, and then enter the settings program, and find that it breaks down perfectly:

Success at setting breakpoint

OK, here you should learn how to breakpoint at the right place: the right process, the right place. Next, to complete the debugging, you need some skills.

How to track code?

Maybe you will say, isn't code tracking just step in/out/over? What's so difficult about that? But in fact, things are not as simple as you think. To debug elegantly, you still need some skills.

Line number correspondence

One of the most important issues in code tracing is line number matching. If you set a breakpoint at the right location, but when tracing and debugging, you find that the running code and the code in Android Studio do not match, it will be very annoying. To make the debugger line numbers match, you must ensure that the code on the device and the debugger are the same. In short, you need to use the native Android system (emulator, Nexus series real machine), and the SDK version used in the debugger must be consistent with the device system version.

What if the line numbers don't match?

Be sure to pay attention to the line number correspondence, which will make the debugging process much simpler; if there is no way, the line numbers do not match, how to debug?

The primary problem caused by inconsistent line numbers is that problems may occur when setting breakpoints; for example, you set a breakpoint on line 100 of TestClass, but because the line numbers do not correspond, the 100th line of code that is actually executed may be a meaningless blank line or in the next function, so the breakpoint does not play its due role.

To solve the problem of line matching, method breakpoints must be used; we set a breakpoint directly at the entrance of a function, so that even if the line number does not match, it can be broken at the correct entrance, which is very important.

The problem of how to set breakpoints has been solved. If the line numbers do not correspond, how can we know where the execution is and how can we view local variables?

Observe the stack frame

On the left side of the Android Studio debugger, the stack frame of each thread execution is displayed, which contains rich information about the current thread:

You can see which line of code is actually being run and which function is currently being run. Next, when you step into/out, you cannot use the number of lines of source code as the basis, but the number of lines of code displayed in this stack frame.

Be proficient in using breakpoints

OK, now we can debug with breakpoints correctly regardless of whether the line numbers match. There are many types of breakpoints, method breakpoints, watch points, and conditional breakpoints, all of which can help us debug very well. If you haven't heard of these terms, you must learn more about them. You can refer to my blog: Android Studio debugging tips you don't know. I won't repeat them here.

If you have carefully read this article and the link I provided, you should be familiar with debugging techniques. Next, you can select the code at the Framework layer and debug it manually to deepen your understanding. In the future work process, continue to strengthen the practice of debugging techniques and make it a conditioned reflex for you to solve complex problems. You will definitely get twice the result with half the effort! Also remember:

Debug the fucking source code.