Training Android Debugging

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

Training Android Debugging Version 06-Nov-2015 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

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

Setting up a script for Android debugging This chapter covers the typical steps to configure TRACE32 for convenient Android Debugging. The demonstration 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: LOG.OPEN <file> LOG.CLOSE Create and open a file for the commands to be logged. The default extension for LOG-files is (.log) Close the 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. STOre <file> SYStem ClipSTOre SYStem Create a PRACTICE batch file to restore the SYStem settings Copy the commands to restore the SYStem settings into the clipboard 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. HISTory.type Display the command history Training Android Debugging 4 Setting up a script for Android debugging

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: Data.LOAD.Elf vmlinux /NoCODE ; load only kernel debug symbols 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 MMU.FORMAT LINUXSWAP3 swapper_pg_dir 0xc0000000--0xefffffff 0x80000000 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 Training Android Debugging 5 Setting up a script for Android debugging

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. If you get the error message invalid combination after issuing the MMU.FORMAT command, please check if you have MMUSPACES enabled. 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: TRANSlation.COMMON 0xC0000000--0xFFFFFFFF 0x80000000--0xB00FFFFF 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 TRANSlation.COMMON 0xC0000000--0xFFFFFFFF TRANSlation.COMMON.ADD 0x80000000--0xB00FFFFF Finally you need to enable the MMU table walk with TRANSlation.TableWalk ON and enable the debugger address translation with the command TRANSlation.ON. TRANSlation.TableWalk ON 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 OS Awareness and its menu: TASK.CONFIG ~~/demo/<arch>/kernel/linux/linux.t32 ; load the awareness MENU.ReProgram ~~/demo/<arch>/kernel/linux/linux.men ; load Linux menu Training Android Debugging 6 Setting up a script for Android debugging

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: symbol.autoload.checklinux "do ~~/demo/<arch>/kernel/linux/autoload " Note: Do not erase the blank space behind autoload! 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). Go WAIT 60.s Break 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. Training Android Debugging 7 Setting up a script for Android debugging

Therefore the easiest way to load the symbols - with the correct address information - is to use the "autoloader" script: ; 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 symbols symbol.autoload.touch "libdvm.so" You can also load the symbols manually, but for this you need to know the address offset of libdvm.so: Data.LOAD.Elf libdvm.so 0x0:0x80200000 /NoCODE /NoClear 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: MMU.TaskPageTable.SCAN "zygote" 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. Training Android Debugging 8 Setting up a script for Android debugging

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.. 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 &funcrange symbol.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 Load the Dalvik awareness Now we can load the Dalvik VM Awareness extension module, and can add the Dalvik menu to TRACE32: EXTention.LOAD dalvik.t32 MENU.ReProgram dalvik.men 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). Training Android Debugging 9 Setting up a script for Android debugging

; Reset previous Java settings in the debugger Java.RESet ; select Dalvik mode for DeXfile loader and Java symbols processing Java.CONFIG DALVIK ; Configure Java VM interpreter routine area, ip and fp Java.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 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.: Java.LOAD data/dalvik-cache/system@app@launcher2.apk@classes.dex 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). Training Android Debugging 10 Setting up a script for Android debugging

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 (overthe-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 Training Android Debugging 11 Setting up a script for Android debugging

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. RESet PRINT "initializing..." SYStem.CPU OMAP4430 SYStem.JtagClock CTCK 30MHz SYStem.Option DACR ON TrOnchip.Set DABORT OFF TrOnchip.Set PABORT OFF TrOnchip.Set UNDEF OFF SYStem.Option MMUSPACES ON SYStem.Up ; give Debugger global write permissions ; used by Linux for page miss! ; used by Linux for page miss! ; my be used by Linux for FPU detection ; enable space ids to virtual addresses ; 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 MENU.ReProgram ~~/demo/arm/kernel/linux/linux ; loads Linux awareness ; 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 on next page. Training Android Debugging 12 Setting up a script for Android debugging

continued: ; Loading dalvik symbols TASK.sYmbol.Option AutoLoad PROCESS TASK.sYmbol.Option AutoLoad PROCLIB "zygote" symbol.autoload.check symbol.autoload.touch "libdvm.so" ; Scan dalvik MMU tables MMU.TaskPageTable.SCAN "zygote" ; Define synthetic symbols for the Dalvik VM interpreter LOCAL &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 &funcrange symbol.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 awareness EXTension.LOAD dalvik.t32 MENU.ReProgram dalvik.men ; Configure JAVA extensions for Dalvik Java.RESet Java.CONFIG DALVIK Java.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 script DO dex-preload.cmm ; Set internal DVM debug status Var gdvm.nativedebuggeractive = TRUE ; Display something WinPOS 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 Training Android Debugging 13 Setting up a script for Android debugging

Debugging Android For more information about debugging the native Android components (Boot Loader, Linux Kernel, Linux Kernel 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: EXTension.VMList 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.VMView 0xEED82400 Training Android Debugging 14 Debugging Android

You can also open the same window by double-clicking on the "magic" or "task name" in the EXtension.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.ListJava window. 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 preloaded data into TRACE32 symbol database. This then makes it possible to also display the Java source code for the corresponding entry. Training Android Debugging 15 Debugging Android

Display the stack frame for a selected VM thread You can display the stack frame for any Linux thread with the command Var.Frame /TASK <task_name_or_magic> 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 stack nesting. The Data.List /TASK window will automatically switch between native code and Java depending on the current stack level. Training Android Debugging 16 Debugging Android

Training Android Debugging 17 Debugging Android

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. Training Android Debugging 18 Debugging Android

Debugging the frame buffer You can display the current screen image from the frame buffer in TRACE32. The registered frame buffers are 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 Var.View %m %s (struct fb_info)*registered_fb[0] Using the screen_base and the information from the var structure, you can display the frame buffer image by 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. Training Android Debugging 19 Debugging Android

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" Training Android Debugging 20 Debugging Android

Then we configure the autoloader to load any required library symbols for this process: TASK.sYmbol.Option AutoLOAD PROCLIB "android.process.acore" symbol.autoload.check When a JNI call is executed for this application, the debugger will now stop at dvmcalljnimethod. The parameter 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: Training Android Debugging 21 Debugging Android