training android debugging · training android debugging 3 basic terms on android ©1989-2016...

Training Android Debugging

TRACE32 Online Help

TRACE32 Directory

TRACE32 Index

TRACE32 Training ............................................................................................................................

Training Android Debugging ........................................................................................................

Training Android Debugging ..................................................................................................... 1

Introduction ............................................................................................................................. 2

Basic terms on Android .......................................................................................................... 3

Android Components 3

VM Awareness 3

Setting up a script for Android debugging ........................................................................... 4

Capture of commands for a script 4

Linux OS Awareness setup (steps and commands) 5

Setup the Linux OS Awareness 6

Setup the symbol autoloader 7

Boot the system 7

VM Awareness setup (steps and commands) 7

Load the Dalvik VM symbols 7

Scan the MMU page table of “zygote” 8

Define symbols for the Dalvik VM Interpreter 8

Load the Dalvik awareness 9

Configure JAVA extensions for Dalvik 9

Pre-load Java class information from DeX files 10

Additional background information 11

Set Dalvik VM Interpreter internal debug status 11

Example Android setup script 12

Debugging Android ................................................................................................................. 14

VM Dalvik Features 14

List Virtual Machine Threads 14

View virtual machine thread stack 14

Display the stack frame for a selected VM thread 16

Examples 18

Debug daemon from main 18

Debugging the frame buffer 19

Debugging JNI calls 20

Training Android Debugging 1 ©1989-2016 Lauterbach GmbH

Training Android Debugging

Version 24-May-2016

Introduction

The focus of this training is “VM-aware debugging” of Android systems, and also includes examples for “native” debugging.

Please refer to ”Training Linux Debugging” (training_rtos_linux.pdf) for in-depth information about debugging Linux.

Please note that “VM-aware debugging” is still under development.

Training Android Debugging 2 Introduction ©1989-2016 Lauterbach GmbH

Basic terms on Android

Here we describe essential basics and terms related to Android and Android Debugging.

1. Android components

2. VM Awareness

Android Components

Android is a software stack for mobile platforms, and consists of:

1. Linux kernel and kernel modules

2. Native processes (executed machine code), e.g. the Linux shell “sh”, Android services, e.g. rild and vold, and the Dalvik VM process “zygote”.

3. Native Libraries e.g. the Dalvik VM library (libdvm.so), JNI, Binder, HAL.

4. Java applications (apps). On Android, each Java application runs in its own Dalvik Virtual Machine instance.

For more information about debugging the native parts of Android (bootloader, Linux kernel, kernel modules and native processes and Libraries), please refer to ”Training Linux Debugging” (training_rtos_linux.pdf).

VM Awareness

A “Virtual Machine” is not a real machine in hardware, with a fixed instruction set, a register file, memory controller and debug logic.

For the CPU, it is “only” an application program, operating on data that is interpreted by the application as the instruction stream for a (non-real) “virtual” machine.

For the processor, the VM “program code” is just data.

To find out which program currently runs in the virtual machine and which values its variables and objects have, the debugger first needs to read memory content of the real machine. Then the debugger must find, analyze and interpret the data structures of the virtual machine itself. Thus the debugger needs to “know” the virtual machine structure; it needs to be “aware” of the virtual machine.

Additionally, for debugging, Virtual Machines are a “moving target” problem. Unlike “real hardware”, they can - and will - be changed and implemented differently by different people, depending on current platform and market requirements. The Dalvik Virtual Machine (DVM) is no exception. This made it necessary to implement Dalvik VM Awareness as a TRACE32 Extension, so that it can be easily adapted - e.g. by a customer or third party - to a concrete DVM platform and/or implementation.

Training Android Debugging 3 Basic terms on Android ©1989-2016 Lauterbach GmbH

Setting up a script for Android debugging

This chapter covers the typical steps to configure TRACE32 for convenient Android Debugging. Thedemonstration target for our explanation is the PandaBoard ES2.1 with an OMAP4430 (dual Cortex-A9)SoC.

The following pages will show the setup by now step by step:

1. Capture of commands to later use them in a script

2. Linux OS Awareness setup (steps and commands)

3. VM Awareness setup (steps and commands)

4. Sample Android setup script

Capture of commands for a script

Often it is useful to record the commands issued and the settings made in the graphical user interface (GUI) right from the start of a TRACE32 session. For this, first you should open a LOG file:

A log file records all commands - until you close it - that you execute in TRACE32, even menu selections and relevant mouse-clicks.

In contrast, the ClipSTORE and STORE <file> commands save only specified parameters (e.g SYStem settings) that you can reload later by executing the automatically generated script file.

The HISTory command only records the commands from the command line. But it offers a quick access to the commands which were already issued during your current session. Use the cursor-up key or the mouse to select commands from the HISTory list.

LOG.OPEN <file> Create and open a file for the commands to be logged. The default extension for LOG-files is (.log)

LOG.CLOSE Close the LOG-file

STOre <file> SYStem Create a PRACTICE batch file to restore the SYStem settings

ClipSTOre SYStem Copy the commands to restore the SYStem settings into the clipboard

HISTory.type Display the command history

Training Android Debugging 4 Setting up a script for Android debugging ©1989-2016 Lauterbach GmbH

Linux OS Awareness setup (steps and commands)

As already mentioned, Android is based on the Linux kernel. Debugging the native part of Android does not differ from pure Linux debugging. This training will shortly explain the steps for Linux setup in TRACE32. You can find more in-depth information in “Training Linux Debugging” (training_rtos_linux.pdf).

Debugger reset and setup

If you restart debugging during a debug session, you can not be sure the state of the debugger is exactly what you want. To make sure you have a sound foundation for further debugging, use the RESet command - for a complete session restart -, or the specific reset commands for each individual debugger function.

After this you need to setup the debugger to connect to the target platform. This includes e.g. selecting the appropriate CPU, setting the JTAG clock to a suitable frequency, and selecting target-specific debugger options. Also options related to Linux debugging have to be enabled, e.g. the address space needs to be extended to support Linux tasks.

Finally, you need to connect the debugger to the target with SYStem.Up or SYStem.Mode Attach.

Load the Linux kernel symbols

The file “vmlinux” contains the Linux kernel's debug information. This file needs to be compiled with “debugging information enabled”. You can load the kernel symbols with:

With the /NOCODE option, you only load the kernel symbols into the debugger, but do not write any kernel binary code into your target.

Setup the debugger’s MMU translation

The debugger needs to have some information about the format of the Memory Management Unit (MMU) tables used by the kernel for address translation. For this you use the command MMU.FORMAT

The first argument of this command can be for example “LINUX”, “LINUXSWAP” or “LINUXSWAP3” , and describes the MMU table format. Because the Linux OS Awareness is constantly improved and extended, please check ”RTOS Debugger for Linux - Stop Mode” (rtos_linux_stop.pdf) for the format specifiers that

Data.LOAD.Elf vmlinux /NoCODE ; load only kernel debug symbols

MMU.FORMAT LINUXSWAP3 swapper_pg_dir 0xc0000000--0xefffffff 0x80000000


are currently available for your platform. The second argument is the name of the kernel symbol for the “kernel page table”. On Linux this is “swapper_pg_dir”. The third parameter is a mapping of virtual kernel addresses to physical kernel addresses.

Now you need to set the common address range with the command TRANSlation.COMMON. This is actually the common address range for all processes and includes the kernel range as well as the virtual machine range:

You can specify up to two ranges for the COMMON area using “||” in the TRANSlation.COMMON command, or multiple ranges with additional TRANSlation.COMMON.ADD

Finally you need to enable the MMU table walk with TRANSlation.TableWalk ON and enable the debugger address translation with the command TRANSlation.ON.

If the table walk is enabled, when the debugger needs to access a virtual address which has no mapping in the debugger's local address translation list, the debugger tries to access the kernel MMU tables to get the corresponding physical address.

Therefore, with table walk enabled, it is not necessary to “scan” the whole MMU (with M MU.SCAN) before the access.

Setup the Linux OS Awareness

The TRACE32 Linux OS Awareness is implemented in the file linux.t32. This is how to load the Linux OSAwareness and its menu:

If you get the error message “invalid combination” after issuing the MMU.FORMAT command, please check if you have MMUSPACES enabled.

TRANSlation.COMMON 0xC0000000--0xFFFFFFFF 0x80000000--0xB00FFFFF

TRANSlation.COMMON 0xC0000000--0xFFFFFFFFTRANSlation.COMMON.ADD 0x80000000--0xB00FFFFF

TRANSlation.TableWalk ONTRANSlation.ON

TASK.CONFIG ~~/demo/<arch>/kernel/linux/linux.t32 ; load the awarenessMENU.ReProgram ~~/demo/<arch>/kernel/linux/linux.men ; load Linux menu


Setup the symbol autoloader

You can specify a PRACTICE script that is called by TRACE32 whenever a process, kernel module or library is loaded the first time, to load the corresponding symbols. This script, “autoload.cmm” is provided on your Lauterbach DVD or installation directory in “\demo\<arch>\kernel\linux\“.

This is the command to setup the autoloader script:

Boot the system

Everything is set up now. If Android is not already running and if you are not interested in debugging the kernel boot, you can let Android run as long as it needs to boot completely (e.g. 60 seconds).

VM Awareness setup (steps and commands)

The following setup steps are necessary for VM-aware debugging:

Load the Dalvik VM symbols

You need to load the symbols of the Dalvik virtual machine (libdvm.so).

Android 2.x used a fixed address table to place common shared libraries in memory, but Android 4.x supports "Address Space Layout Randomization" (ASLR). This means, the load address of libraries (shared objects) is not fixed anymore, but changes with every boot.

sYmbol.AutoLoad.CHECKLINUX "do ~~/demo/<arch>/kernel/linux/autoload "

Note: Do not erase the blank space behind “autoload ”!

GoWAIT 60.sBreak


Therefore the easiest way to load the symbols - with the correct address information - is to use the "autoloader" script:

You can also load the symbols manually, but for this you need to know the address offset of libdvm.so:

Please note that the symbols are loaded with space id 0x0, so they are visible from all processes (space id 0 is the marker for a "common" memory area in Linux).

Scan the MMU page table of “zygote”

When TRANSlation.TableWalk is enabled, it is not necessary to scan the kernel and task page tables with MMU.SCAN.

Because the Dalvik VM Awareness frequently needs to access the page table of the process “zygote”, however, doing a page table walk for each access could slow down debugging. Therefore we recommend scanning the MMU page tables of the process “zygote” into the local translation table of the debugger:

Define symbols for the Dalvik VM Interpreter

Most of the time, a given Linux task that executes an instance of the Dalvik Virtual Machine to run an Android Application will be in a "waiting" state in a native call function (mostly "object wait").

To find out which Java code actually causes the wait, the Dalvik VM Awareness needs to be able to detect if and where the native task stack contains a stack frame for the VM interpreter loop. This stack frame will contain the relevant registers and variables that point to the Dalvik instruction pointer and to the Dalvik (Java) stack frame data.

To make this task - finding where on the task stack the Dalvik VM data is - you need to define a named range symbol for the Dalvik VM Interpreter function, and several local variables using fixed names.

The awareness uses these names to identify the stack frame with the VM interpreter, and to access the relevant Java instruction/method/frame pointer data.

; Enable the autoloader for processes:TASK.sYmbol.Option Autoload PROCESS; Enable the autoloader for the libraries of the process zygote:TASK.sYmbol.Option Autoload PROCLIB "zygote"; Check now:sYmbol.AutoLoad.CHECK; Force loading libdvm.so symbolssYmbol.AutoLoad.TOUCH "libdvm.so"

Data.LOAD.Elf libdvm.so 0x0:0x80200000 /NoCODE /NoClear

MMU.TaskPageTable.SCAN "zygote"


The first versions of the Dalvik VM Awareness (dalvik.t32) used the name “dalvik_interp” for the VM interpreter address range, and this worked well for Android 2.x.

But in Android 4.x, dalvik_mterp is already defined for an address range that is different from the whole Dalvik VM, therefore newer versions of the awareness use the name “t32_dalvik_vm” instead.

The machine-optimized Dalvik VM Interpreter loop (only this one is currently analyzed and supported) is made up from assembly language blocks, and the module address range they reside in can be accessed - e.g. for ARMv7 - accessing the module label name “\\libdvm\InterpAsm-armv7-a-neon”..

Load the Dalvik awareness

Now we can load the Dalvik VM Awareness extension module, and can add the Dalvik menu to TRACE32:

Configure JAVA extensions for Dalvik

TRACE32 has built-in support for various Virtual Machines types (e.g. J2ME_CDC, KAFFE, etc.). Because the Android APK file format is stable (thousands of rolled-out apps use this format) it was decided to implement support for this file type directly in TRACE32. Also the Dalvik Stack Frame system on ARM is very simple, therefore a "fallback" system for Java code stack walks was directly built into TRACE32 for it.

To use this support, however, we need to select the DALVIK mode with the Java.CONFIG command. We also need to tell TRACE32 about the VM Interpreter address range, and the Java instruction and frame pointers (which are stored in a local variable or register).

LOCAL &funcrange &funcbeg &funcend&funcbeg=address.offset(sYmbol.BEGIN("\\libdvm\InterpAsm-armv7-a-neon"))&funcend=address.offset(sYmbol.BEGIN("\\libdvm\InterpAsm-armv7-a-neon"))&funcrange="&funcbeg--&funcend"sYmbol.CREATE.Function t32_dalvik_vm &funcrangesYmbol.CREATE.LocalVar t32_dalvik_vm rPC &funcrange Register r4 void*sYmbol.CREATE.LocalVar t32_dalvik_vm rFP &funcrange Register r5 StackSaveArea*

; One local DVM symbol definition is different between Android 2.x and 4.x. ; For Android 2.x (FroYo) use:; sYmbol.CREATE.LocalVar t32_dalvik_vm rGLUE &funcrange Register r6 InterpState*; For Android 4.x (4.0.x Ice Cream Sandwich and 4.1.x JellyBean) use:sYmbol.CREATE.LocalVar t32_dalvik_vm rSELF &funcrange Register r6 Thread*

sYmbol.CREATE.LocalVar t32_dalvik_vm rINST &funcrange Register r7 void*sYmbol.CREATE.LocalVar t32_dalvik_vm rIBASE &funcrange Register r8 void*sYmbol.CREATE.Done

EXTention.LOAD dalvik.t32MENU.ReProgram dalvik.men


Pre-load Java class information from DeX files

Most standard Java applications use one *.class file for each class, also extra ones for "inner classes". Also there is a standardized mapping between a Java *.class file name and the corresponding Java package and class names. This makes it possible to do "on-demand"-loading of Java class data: translate the Java package name and class name to the name of the Java class file, and load it.

Android's Dalvik stores its Java class information in *.dex files (Dalvik EXecutables), which are optimized for minimal memory footprint. To save up to 50% space (compared to uncompressed Java class files), all Android applications only have one DeX file - classes.dex - which contains all classes that belong to this application.

With Dalvik Applications, however, the name of the file that contains all code and debugging information is always the same - classes.dex.

There is also no strict mapping between the APK (Android Package) file name and the Application name or the Java package name.

So we can not even "guess" the name of the APK file that contains the classes.dex file for a specific application or Java package.

Only by loading a classes.dex file and analyzing its contents, the debugger can derive the Java package and class name. This is the reason why the debugger needs to "pre-load" the DeX files that are relevant for your debug session.

This DeX file "pre-loading" is done with the Java.LOAD command e.g.:

The DALVIK mode of Java.LOAD supports several file types: dex files, apk files, jar files (for framework components from /system/framework), and odex (optimized dex) files (e.g. from the /data/dalvik-cache, or from the /system/app directory).

; Reset previous Java settings in the debuggerJava.RESet; select Dalvik mode for DeXfile loader and Java symbols processingJava.CONFIG DALVIK; Configure Java VM interpreter routine area, ip and fpJava.MAP.VM sYmbol.RANGE(t32_dalvik_vm)Java.MAP.IP Register R4 sYmbol.RANGE(t32_dalvik_vm)Java.MAP.FP Register R5 sYmbol.RANGE(t32_dalvik_vm)Java.ON

Java.LOAD data/dalvik-cache/system@[email protected]@classes.dex


Additional background information

On the device, the classes.dex file is “optimized” during application install (or - for a brand-new Android device - during the very first device boot), e.g. it is pre-linked with the device's framework class libraries, then the resulting file is stored in /data/dalvik-cache (see the preceding example). If - e.g. during an OTA (over-the-air) firmware update the Dalvik VM Interpreter or some framework classes are replaced with a newer version, this invalidates a signature stored in the "optimized" dex file in the /data/dalvik-cache directory, and it will be re-generated during the next boot, or latest before the next execution of the application.

Additionally, there is an Android build option to "pre-optimize" system applications ("built-in" apps from /system/app). After pre-optimization they are stored alongside a "stripped" APK or JAR file that only contains the remaining manifest and resources. These "pre-Optimized DEX files" have the extension *.odex, and avoid storing two files (for the normal binary plus the dalvik-cache file). If an OTA firmware update is performed and the Dalvik VM Interpreter is replaced with a newer version, however, all odex files need to be updated as well during the firmware update, so they match the Dalvik VM Interpreter (and framework files) again. Due to this fact newer Android distributions rarely use pre-optimized odex files.

Luckily - at least on ARM - there is no debug-relevant difference between DeX and ODeX files, and both can be processed alike.

Set Dalvik VM Interpreter internal debug status

Android has an internal variable to notify the VM that a native-code debugger is attached to the system. When this variable is set, some internal time-outs are ignored and some safeguards are disabled. You set this variable with:

Var gDvm.nativeDebuggerActive = TRUE


Example Android setup script

Here is a sample PRACTICE script to set up debugging for Android 4.x (Jelly Bean) running on the PandaBoard. The Linux kernel and the Android root file system reside on the SD card.

continued on next page.

RESet PRINT "initializing..." SYStem.CPU OMAP4430 SYStem.JtagClock CTCK 30MHz SYStem.Option DACR ON ; give Debugger global write permissions TrOnchip.Set DABORT OFF ; used by Linux for page miss! TrOnchip.Set PABORT OFF ; used by Linux for page miss! TrOnchip.Set UNDEF OFF ; my be used by Linux for FPU detection SYStem.Option MMUSPACES ON ; enable space ids to virtual addresses SYStem.Up ; Open a serial terminal window DO ~~/demo/etc/terminal/term.cmm COM1 115200.

SETUP.IMASKASM ON ; lock interrupts while single stepping

; Load the Linux kernel symbols into the debugger Data.LOAD.Elf vmlinux /GNU /NoCODE /STRIPPART 3.

PRINT "initializing debugger MMU..." MMU.FORMAT LINUXSWAP3 swapper_pg_dir 0xc0000000--0xefffffff 0x80000000 TRANSLATION.COMMON 0x80000000--0xB00FFFFF 0xC0000000--0xFFFFFFFF TRANSLATION.TableWalk ON TRANSlation.ON

; Initialize Linux Awareness PRINT "initializing multi task support..." TASK.CONFIG ~~/demo/arm/kernel/linux/linux ; loads Linux awareness MENU.ReProgram ~~/demo/arm/kernel/linux/linux ; loads Linux menu

sYmbol.Autoload.CHECKLINUX "do ~~/demo/arm/kernel/linux/autoload.cmm "

TASK.Option Threading TGroup ; better visibility for Dalvik threads TASK.Option NameMode ARG0COMM ; better visibility for Dalvik threads

GROUP.Create "lib" 0x40000000--0x4FFFFFFF /YELLOW GROUP.Create "android" 0x80000000--0xAFFFFFFF /BLUE GROUP.Create "kernel" 0xC0000000--0xFFFFFFFF /RED

Go WAIT 60.s ; Waiting for Android startup (60 seconds) Break


continued:

; Loading dalvik symbolsTASK.sYmbol.Option AutoLoad PROCESSTASK.sYmbol.Option AutoLoad PROCLIB "zygote"sYmbol.AutoLOAD.CHECKsYmbol.AutoLOAD.TOUCH "libdvm.so"

; Scan dalvik MMU tablesMMU.TaskPageTable.SCAN "zygote"

; Define synthetic symbols for the Dalvik VM interpreterLOCAL &funcrange &funcbeg &funcend&funcbeg=address.offset(sYmbol.BEGIN("\\libdvm\InterpAsm-armv7-a-neon"))&funcend=address.offset(sYmbol.END("\\libdvm\InterpAsm-armv7-a-neon"))&funcrange="&funcbeg--&funcend"sYmbol.CREATE.Function t32_dalvik_vm &funcrangesYmbol.CREATE.LocalVar t32_dalvik_vm rPC &funcrange Register r4 void*sYmbol.CREATE.LocalVar t32_dalvik_vm rFP &funcrange Register r5 StackSaveArea*; The following steps depend on your Android version: sYmbol.CREATE.LocalVar t32_dalvik_vm rSELF &funcrange Register r6 Thread*sYmbol.CREATE.LocalVar t32_dalvik_vm rINST &funcrange Register r7 void*sYmbol.CREATE.LocalVar t32_dalvik_vm rIBASE &funcrange Register r8 void*sYmbol.CREATE.Done

; Load Dalvik VM awarenessEXTension.LOAD dalvik.t32MENU.ReProgram dalvik.men

; Configure JAVA extensions for DalvikJava.RESetJava.CONFIG DALVIKJava.MAP.VM sYmbol.RANGE(t32_dalvik_vm)Java.MAP.IP Register R4 sYmbol.RANGE(t32_dalvik_vm)Java.MAP.FP Register R5 sYmbol.RANGE(t32_dalvik_vm)Java.ON

; Pre-load DeX classes by calling a separate scriptDO dex-preload.cmm

; Set internal DVM debug statusVar gDvm.nativeDebuggerActive = TRUE

; Display somethingWinPOS 0. 30%EXTension.VMList

WinPOS 0% 0%Var.Frame /TASK "android.process.media"WinPOS 50% 0%Data.List /TASK "android.process.media"Register.TASK "android.process.media"

ENDDO


Debugging Android

For more information about debugging the native Android components (Boot Loader, Linux Kernel, LinuxKernel Modules, Native Processes and Native Libraries), please refer to ”Training Linux Debugging”(training_rtos_linux.pdf).

VM Dalvik Features

The Dalvik VM Awareness currently provides this functionality:

• List DVM threads with their class descriptors and names.

• Display the DVM stack for a single DVM thread.

• List the (Java) Source code for a method/offset shown in the DVM stack view.

• Display the stack frame for a selected DVM thread

Please also refer to the document ”VM Debugger Dalvik” (vmdalvik.pdf).

List Virtual Machine Threads

You can display a list of the Dalvik Virtual Machine (DVM) threads with the command:

You can also open this window from the TRACE32 Dalvik menu:

View virtual machine thread stack

You can display the Dalvik VM stack for one specific DVM instance with the command EXtension.VMView e.g.

EXTension.VMList

EXTension.VMView 0xEED82400

Training Android Debugging 14 Debugging Android ©1989-2016 Lauterbach GmbH

You can also open the same window by double-clicking on the "magic" or "task name" in theEXtension.VMView window, or by a right-click and then selecting “Display detailed”.

A double click in the column “frmCurPC” of the EXTension.VMView window opens a Data.ListJavawindow. Initially this windows shows the Dalvik bytecode at the indicated position.

With a double click in the column “class descriptor”, you will load the necessary symbols from preloadeddata into TRACE32 symbol database. This then makes it possible to also display the Java source code forthe corresponding entry.


Display the stack frame for a selected VM thread

You can display the stack frame for any Linux thread with the command

When the Java/Dalvik environment is configured correctly, this Var.Frame window will also show the transitions between native and Java code. With Data.List /TASK <task_name> you can also display the code for the current stack level.

Using the buttons “Up” and “Down” in the Var.Frame window, you can navigate up and down in the stacknesting. The Data.List /TASK window will automatically switch between native code and Java depending onthe current stack level.

Var.Frame /TASK <task_name_or_magic>


Examples

Debug daemon from main

You can e.g. debug the volume daemon vold from its main function. For this, you need to stop your system before vold has been started. Then select in the “Linux” menu “”Process Debugging” -> “Debug Process on main ...” and enter “vold” as “process name”:

As soon as “vold” is started, the autoloader loads the process symbols, and the target halts at the main()function.


Debugging the frame buffer

You can display the current screen image from the frame buffer in TRACE32. The registered frame buffersare listed in the array registered_fb

Each entry is a pointer to an fb_info structure. You can e.g. display the structure pointed by the first entry in registered_fb with the command

Using the screen_base and the information from the var structure, you can display the frame buffer imageby the Data.IMAGE command:

In our example, the frame buffer only contains the text “A N D R O I D”. The reason for this is that on our PandaBoard test platform, Android 4.x does not use the normal frame buffer device (/dev/graphics/fb0), but an embedded graphics accelerator instead.

However, Android 4.x comes with a “screencap” application to make a capture of the screen. Debugging this application gives us access to a capture of the screen. For this, we first run screencap, with a breakpoint set near the end of the main function.

Var.View %m %s (struct fb_info)*registered_fb[0]


When the system stops, we can access the dimensions and image data of the screen capture via the local variables “base”, “w” and “h”, and use them to display the screen image:

Debugging JNI calls

In this example we will debug JNI calls for the Dalvik application “android.process.acore”.

First we set a "task specific breakpoint" for the libdvm function dvmCallJNIMethod:

Break.Set dvmCallJNIMethod /TASK "android.process.acore"


Then we configure the autoloader to load any required library symbols for this process:

When a JNI call is executed for this application, the debugger will now stop at dvmCallJNIMethod. Theparameter “method” tells us about the JNI function is about to be executed here:

After some single stepping, we will get to the native part of the JNI function:

The Frame window will now display the stack frame with the transition from Java to native code:

TASK.sYmbol.Option AutoLOAD PROCLIB "android.process.acore"sYmbol.AutoLOAD.CHECK


training android debugging · training android debugging 3 basic terms on android ©1989-2016...

Documents