2012-06-29 10 views
6

Estamos probando nuestra aplicación para Android en dispositivos del mundo real y notamos que algunos de ellos se reinician ocasionalmente después de 2 o 3 horas de funcionamiento de la aplicación. La aplicación consta de un servicio con 3 hilos (con GPS y red) y dos actividades, una de las cuales consume muchos recursos (muestra el mapa)Reinicia el dispositivo Android de vez en cuando

Logcat no ayudó, ya que no vimos ningún mensaje importante antes del el dispositivo se reinicia. A veces, el dispositivo incluso no se inicia, solo la extracción de la batería ayuda a volver a encenderlo.

Los dispositivos se basan en diferentes hardware, producidos en diferentes países (principalmente PRC, jeje) y utilizan diferentes versiones de Android.

¿Cuáles son los problemas más comunes que podrían provocar el reinicio del dispositivo y cómo se puede depurar?

+0

10 meses después, ¿descubrió lo que estaba causando después de todo? – jcage

+0

Parece que algunos dispositivos se sobrecalientan cuando usan el GPS durante más de una hora más o menos. – saabeilin

Respuesta

0

Es muy probable que sea un problema de sobrecalentamiento cuando el receptor GPS está encendido. Al apagar el GPS y obtener la ubicación de la red de la célula, la aplicación funciona sin problemas durante horas.

Gracias a todos por las respuestas y las ideas!

0

Según la información que ha proporcionado, parece que probablemente gotee un Thread. Puede usar DDMS para analizar thread usage durante el curso de ejecución de su aplicación. Otra posibilidad es que simplemente se está quedando sin memoria ... también puede usar DDMS para ayudarlo con esto.

+0

Gracias. Pero, ¿por qué el servicio y/o la actividad no mueren ni reciben GC? – saabeilin

+0

Los servicios son procesos a largo plazo que existen incluso después de que la aplicación deja de ejecutarse ... por lo que debe anular el registro cuando sea necesario. Las actividades no tienen GC porque el sistema Android subyacente destruirá las actividades cuando el dispositivo tenga pocos recursos. –

+1

Si, como usted notó, "... simplemente se está quedando sin memoria", las Actividades * serán * destruidas, destruidas y liberadas, pero no sucede. Los servicios tampoco se eliminan (aunque se pueden eliminar) y, por cierto, el servicio y las actividades comparten el mismo objeto de Aplicación. Así que no estoy seguro de que sea un problema de memoria baja (sin embargo, ¿podría ser un error en la versión OEM andrid?) – saabeilin

1

tuve un problema similar (también GPS y la red) He forgoten para ajustar el temporizador de actualización de red a la producción (15 minutos) para que el dispositivo se actualiza cada 15 segundos cualquier forma el dispositivo caliente soner o posterior (HTC Desire)
tratar de minimizar el uso de la CPU (perfiles) o garantizar un mecanismo de enfriamiento adecuado

+0

Sí hacemos redwrking muy pesados ​​en depuración/prueba, además el receptor GPS consume mucha energía y se calienta mucho. Pero los dispositivos de reinicio son un poco más fríos que los estables. Mi Nuvifone con 2.1, Xperia con 2.x cyanogen, Iconia con 4.0 y varios dispositivos chineese noname con 2.1, 2.2, 2.3.xy 4.x funcionan muy bien, aunque se ponen extremadamente calientes (mi Nuvifone está listo para hacer un poco de café) . De todos modos, el uso de la CPU es normal, el acceso más rápido al GPS se calienta. – saabeilin

+0

el dispositivo puede ser más frío desde el exterior pero más caliente en el interior, también si entiendo correctamente que un dispositivo de un vendedor diferente puede tener una temperatura crítica diferente, pruebe el funcionamiento y minimice la comunicación de red. Funcionará – sherif

3

No tenemos dos tipos de reinicio en Android: fallo del servidor

  1. sistema. En ese caso, no se reinicia pero se reinicia el Zygote. Las razones más comunes:

    • Watchdog mataron a un proceso de system_server causa de estancamiento en los servicios que se está ejecutando.
    • Se produjo una excepción fatal en uno de los servicios del sistema. Sin embargo, la razón real a veces puede ser un problema de hardware. Por ejemplo, en algunos casos, después del restablecimiento de fábrica, las particiones ext2 no se formatean de la siguiente manera. Conduce a errores y la partición /data/ se monta como de solo lectura, lo que produce un montón de errores.
    • En casos excepcionales, se puede agotar el tiempo de espera del watchdog debido a la gran cantidad de memoria y al uso de la CPU.

    Ambos son bastante raros y se pueden reproducir principalmente en situaciones de prueba de monos, no en casos reales. Puede ver un ejemplo de salida de logcat al matar el proceso service_manager con adb shell.

  2. Kernel panic. En ese caso, el dispositivo realmente se reinicia. Como el pánico del kernel ocurre en la capa más allá de Android, no producirá ninguna salida de logcat. En cambio, escribirá un seguimiento de pila en la consola. Puede leerlo desde /dev/kmsg o desde el shell de ADB: adb shell dmesg.

    Desafortunadamente es difícil de leer, ya que en la mayoría de los dispositivos, la salida de la consola está deshabilitada y el búfer kmsg se borrará en cada reinicio.

P.S. También el reinicio puede ser causado por problemas de hardware. En ese caso, es poco probable que encuentre rastros, pero esperamos que esto se reproduzca solo en dispositivos particulares.

+0

Gracias Andrey . Creo que si la raíz del problema está en Zygote, entonces deberíamos ver algunos mensajes de registro. Tan pronto como no recuerdo ninguno, podría ser un KP. De todos modos, intentaremos eliminar service_manager y ver la diferencia en los registros. – saabeilin

Cuestiones relacionadas