He escrito un su.d script para realizar periódicamente (cada 4 horas) una copia de seguridad de los datos de una app utilizando un bucle sleep comando:
#!/system/bin/sh
(
# Wait for boot to complete
until [ "$(getprop sys.boot_completed)" ]
do
sleep 300
done
while true
do
(
new_dir="/storage/emulated/0/temp/AppData/$(date '+%Y%m%d-%H%M')"
mkdir -p $new_dir
cp /data/data/com.example.app/files/*.json $new_dir
echo "$(date '+%F %T') | app data backup OK!" >> /storage/emulated/0/su.d.log
) &
sleep 14400 # 4 hours
done
) &En la práctica, el script hace una copia de seguridad de los datos sólo después del arranque, no cada 4 horas.
Sin embargo, si entro en un shell remoto a través de adb y dejarlo solo, entonces los datos sí se respaldan cada 4 horas.
¿Cómo puedo forzar la copia de seguridad periódica sin estar permanentemente conectado a un PC? (¿Y por qué no funciona como se espera?)
EDITS
-
El comentario de @Irfan Latif me dio la idea de probar un intérprete diferente (busybox ash -
#!/system/xbin/sh), pero el resultado fue el mismo. Probaré la sugerencia de @mirabilos de daemonizar (sh -T- -c '...') siguiente. -
Probado la sugerencia de @mirabilos de daemonise con el mismo resultado: respalda los datos sólo después del arranque.
-
Probado
nohup:nohup /system/bin/sh -T- -c '...' >/dev/null 2>&1 &El mismo resultado.
2 votos
No recuerdo exactamente pero ya lo había resuelto una vez. Creo que el problema era con
/system/bin/sh(korn shell). Se comporta de forma inesperada cuando no está conectado a un terminal y bifurca un shell en segundo plano. Para la línea de comandos, puedes optar por busyboxcronpara programar las tareas. Para la interfaz de usuario, utiliza una aplicación como Tasker.1 votos
Puedes optar por el demonio cron simplemente creando un
crontabsarchivo. Esto parece una solución más apropiada para las tareas repetidas en lugar de utilizarshellen el fondo. Todo lo que necesitas para ejecutar en el arranque es:busybox crond -c /path/to/crontabs. Si quieres seguir con lo de la cáscara, usaset -xyexec &>para tomar registros de su.d script con marcas de tiempo para encontrar cuándo y por qué falla la ejecución del shell.0 votos
Hombre Se pueden utilizar alternativas, ver aquí: < unix.stackexchange.com/questions/482725/ >