2 votos

¿Android detiene/pausa la ejecución de mi script en segundo plano?

La versión corta:

¿Por qué mi script bash (que se ejecuta en segundo plano, iniciado a través de SSHD) no se ejecuta cada ~30 segundos cuando debería hacerlo? (NOTA: SSHD y el script se ejecutan como root !)


Tengo un script que empiezo a utilizar nohup bash script.sh & para que se ejecute en segundo plano.

El script debe comprobar si una aplicación específica está conectada utilizando netstat y si no, se reconecta automáticamente utilizando am start y input keyevent . (Aunque esto resulta ser irrelevante).

Me he dado cuenta de que aunque el script debería comprobar cada 30 segundos (aproximadamente, por supuesto), a veces tarda minutos en comprobarlo. Realmente no pude averiguar por qué y parecía completamente al azar (tenga en cuenta que la pantalla del teléfono está apagado la mayor parte del tiempo y todo se ejecuta en el fondo.), así que hice un testcript que es lo que la pregunta debe centrarse en la simplicidad:

#!/bin/sh
while : ; do
    echo "$(date +'%Y-%m-%d %H:%M:%S')"
    sleep 30
done

Eso es. Comenzó a través de nohup bash script.sh & usando SSHD. El script no hace nada más que imprimir la fecha actual y gracias a nohup la escribe en un archivo. Dejé esto funcionando por un tiempo y luego escribí otro script para comprobar los resultados e imprimir la cantidad de segundos siempre que esté por encima de 30. Resultado:

134
127
115
127
88
113
116
99
110
116
54
44
70
75
62
82
94
68
429
62
81
126
144
39
467
71
62

Esto es de la salida de un script que se ejecutó durante sólo 4:20 horas, por lo que un buen número de veces donde la ejecución debe haber sido retrasado, el sueño era más de 30 segundos, o lo que está pasando....

¿Puede alguien explicar esto? ¿Y hay alguna solución para esto?

Sospecho que esto puede tener algo que ver con la memoria o la gestión de energía que pausa el script, pero realmente no debería suceder y me gustaría que mi script se ejecutara en segundo plano y durmiera exactamente 30 segundos y no se pausara o retrasara. En este testrun, el más alto fue 467 segundos, pero el más alto que he visto con el script principal hasta ahora fue un poco más de 20 minutos . Esto es raro, pero 5-10 minutos de retraso ocurre algunas veces al día.

5voto

Jack Wade Puntos 231

Android apaga algunas de las CPUs y/o no deja que las aplicaciones las usen cuando es dormitando . Se logra a través del núcleo de Linux Grupos de control . Uno de los cgroups es cpuset que controla qué CPU se asigna a qué procesos. Android crea múltiples descendientes cgroups en cpuset Por ejemplo background , foreground , system-background , top-apps etc.

Las aplicaciones suelen estar en background categoría que puede utilizar el menor número de CPUs, normalmente una o dos. Servicios nativos básicos como vold , zygote (y system_server ), los servicios de telefonía y las aplicaciones que ejecutan un servicio en primer plano (por ejemplo, las notificaciones) o las que están exentas de la optimización de la batería o tienen privilegios como allow-in-power-save se ponen en foreground que puede utilizar las CPUs incluso cuando el dispositivo está en modo de reposo.

Por lo tanto, es necesario añadir la secuencia de comandos a foreground cgroup para mantenerlo vivo. Desde dentro del guión:

~# echo -n $$ >/dev/cpuset/foreground/tasks

Siendo aún más agresivo, puedes mantener un bloqueo de vigilia para que el dispositivo no se suspenda:

~# echo -n my_script >/sys/power/wake_lock

No olvides liberarlo ( echo -n my_script >/sys/power/wake_unlock ) después de detener la secuencia de comandos.

Ten en cuenta que ambas medidas pueden afectar negativamente al rendimiento de la batería, sobre todo esta última. Android's advertencia :

La creación y el mantenimiento de los bloqueos de vigilia pueden tener un impacto dramático en la vida de la batería del dispositivo anfitrión

0 votos

Wow, mi pobre interino era siempre enviar keyevent de entrada cada 10 segundos. ¿es la misma lista utilizada para la batería más segura en la configuración?

2 votos

@alecxs es parcialmente sí. También hay otros factores. La gestión de energía de Android es complicada. Después de la contribución de los OEM también se vuelve incierta y frustrante. He estado pensando en explicar este tema en detalle pero creo que se volvería demasiado detallado. Y no estoy al tanto de muchas cosas específicas de los OEM.

0 votos

Estaba pensando en desactivar la "optimización de la batería" en los ajustes también, pero no estaba seguro de si tendría que hacerlo para shell o SimpleSSHD y sentí que eso tendría un efecto en algo más que mi guión, así que potencialmente reduciría la vida de la batería también mucho. La primera solución de tu respuesta parece funcionar perfectamente sin un solo paso de >31s hasta ahora. Tendré que ver esto un poco más, pero hasta ahora el uso de la batería parece ser más o menos el mismo (probablemente diferente para los scripts más complejos / hambrientos de batería, por supuesto).

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X