A couple of days ago we shown you
how to get a memory dump of your Android application and open it in Eclipse MAT. That procedure was valid for versions up to 1.1, but it has slightly changed for the new version 1.5 (a.k.a. cupcake).
- First step doesn’t change, we have to make sure /data/misc is writable:
adb shell
#su
#chmod 777 /data/misc
- Take note of your application process number using the Eclipse DDMS perspective or with the command ‘ps’ within the emulator/phone shell.
- Send a SIGUSR1 signal to the process with the command:
kill -10 <pid number>
In 1.5, a new API has been introduced to generate a dump programmatically, the static method dumpHprofData(String fileName) of the Debug class. Example:
Debug.dumpHprofData("myAppDump.hprof");
- In 1.5 only one dump file will be generated (with the pattern heap-dump-tm<timestamp>-pid<myPid>.hprof), so you no longer need to concatenate it with anything.
- You still need to pull it from the emulator/phone to your computer and “deandroidize” it with the hprof-conv tool. The good news is this tool is now bundled with the SDK and you don’t need to download or compile it anymore.
adb pull /data/misc/heap-dump-tm<timestamp>-pid<myPid>.hprof .
hprof-conv heap-dump-tm<timestamp>-pid<myPid>.hprof myDump.hprof
- Now you can open it with your preferred memory analysis tool (ours is MAT!).
Note: This procedure is valid for SDK versions up to 1.1. For instructions about how to do it in Android 1.5 take a look at our new post: Analyze an Android 1.5 memory dump.
In this post we will show you how to get a memory dump of your running Android application, convert it to a standard format supported by the conventional tools and open it with Eclipse MAT (Memory Analyzer Tool) to detect memory leaks.
The memory dump is going to be generated on the
/data/misc directory so the first step is modifying its permissions to make sure it is writable.
adb shell
#su
#chmod 777 /data/misc |
Note: You can do this on the emulator or if you are working with an Android Developer Phone, but you cannot do it if you are working with a T-Mobile G1 (unless you are root, but that's for another post). The ‘su’ command is only needed if you are working with an ADP1 because the adb daemon runs as a regular user.
Next, we should run our application and take note of its process number. It can be found using the DDMS view in Eclipse
or if you are a command line guy you can use:
to list the currently running processes.
We will use this number to send a SIGUSR1 signal to the process. Currently the Dalvik VM will generate a memory dump in response to two signals, SIGQUIT and SIGUSR1. If you send it a SIGQUIT it will dump the stacks from all running threads; if you send it a SIGUSR1 it will dump the heap profiling data. The most usual way to send the signal to the process is with the kill command:
but you can also send it programmatically from inside the application with this code:
android.os.Process.sendSignal(android.os.Process.myPid(), android.os.Process.SIGNAL_USR1);
On a "regular" JVM you could generate a dump in the very moment the first OOM occurs (starting it with the
-XX:+HeapDumpOnOutOfMemoryError option), which is very useful, but that feature is not available in Dalvik yet (however, it is on the “to do list” of the Android team).
If everything works OK, you should see something like this on the log:
04-28 13:53:32.418: INFO/dalvikvm(22609): threadid=7: reacting to signal 10
04-28 13:53:32.418: INFO/dalvikvm(22609): SIGUSR1 forcing GC and HPROF dump
04-28 13:53:32.418: INFO/dalvikvm(22609): hprof: dumping VM heap to "/data/misc/heap-dump-tm1240926812-pid22609.hprof".
04-28 13:53:35.682: INFO/dalvikvm(22609): hprof: dumping heap strings to "/data/misc/heap-dump-tm1240926812-pid22609.hprof-head".
Now we can pull the generated files to the computer:
adb pull /data/misc/heap-dump-tm1240926812-pid22609.hprof-head .
adb pull /data/misc/heap-dump-tm1240926812-pid22609.hprof . |
And we have to join them in a single file. If you are in a Windows system you could use the ‘
type’ command:
C:\...>type heap-dump-tm1240926812-pid22609.hprof-head > android-dump.hprof
C:\...>type heap-dump-tm1240926812-pid22609.hprof >> android-dump.hprof |
or ‘
cat’ in a Linux system.
The generated dump contains specific information related with the Dalvik VM that are not part of the standard hprof format so the standard tools won’t be able to open it. Luckily, the Android team has released a tool to trim the Dalvik specific records and convert the dump to a standard format. You can find the source code
here. Also, if you are using windows you can download a compiled version from
here (compiling it for other systems shouldn’t be difficult, ask us if you have any problem).
C:\...>hprof-conv android-dump.hprof standard-dump.hprof |
Finally you can open it with your preferred analysis tool (JHat, JProfiler, MAT, etc.). In this post and followings we will be using
MAT.
That’s all for now! We will publish more information soon about how to use MAT to detect and solve memory leaks in your application.
The list of the 10 finalist projects in the BBVA OpenTalent contest has been announced today and BioWallet is one of them!
This is the list of the selected projects:
Congratulations to the other finalists and good luck to everybody, there are really good ideas amongst all the projects and we are sure many of them will succeed.
Now a new stage opens where the Fundings Committee of the bank will analyze the team behind each finalist project and their ability to execute the idea and make it a reality. The BioWallet team has been invited to present the project and themselves during a meeting next week. Winner will be announced after that so keep following this blog and twitter and we hope we can give you good news soon!
We really want to thank all the people that have supported us with their comments and votes. This wouldn't have been possible without you.
