Mientras miraba mi sistema de archivos de Android, descubrí que sí, de hecho, tenía un /etc/init.d/
directorio. Después de mirar por allí, encontré /etc/init.d/20userinit
las siguientes líneas:
if [ -e /data/local/userinit.sh ];
then
log -p -i -t userinit "Executing /data/local/userinit.sh";
busybux chmod +x /data/local/userinit.sh;
logwrapper /system/bin/sh /data/local/userinit.sh;
setprop cm.userinit.active 1;
fi;
Siendo esto, por supuesto, exactamente lo que necesitaba, escribí el siguiente script en mi computadora y luego lo introduje en mi dispositivo:
#!/system/bin/sh
dropbear -s -g
(empujado al dispositivo a través scp userinit.sh phone:/data/local/userinit.sh
, ten en cuenta:])
Reinició el dispositivo, luego se ejecutó ps | grep "[d]ropbear"
y, efectivamente, se está ejecutando. ¡Frescura!
/data/init.sh
se ejecuta en el arranque, si tienes root puedes editarlo como quieras. Ten cuidado ;)Editar: Aparentemente, es posible que también necesite calzar el guión editado en la imagen de arranque. Información sobre cómo hacerlo aquí: http://forum.xda-developers.com/showthread.php?t=443994
fuente
find / -name "init.sh"
aparece algo. ¿Hay otros scripts que se ejecutan en el arranque?/etc/init.rc
que inicie el shell. Debería llamar a init.sh, pero si no lo hace, puede hacer que llame a su propio script./data
pero no/data/init/.sh
o/etc/init.rc
. Grep no encuentra ninguna instancia interesante de la cadenainit
en/etc
(incluso recursiva).Mira al
/etc/
directorio. Por lo general, se coloca en una/system/
partición que puede montar como RW:Algunos pasos anteriores pueden reemplazarse con:
y luego volver a montar RO:
Ahora su tarea de encontrar el archivo ejecutable o el
*rc
archivo que modifica para lograr su objetivo:Google acerca de cada candidato para saber cómo se utilizó este archivo.
Un buen candidato para incluir scripts personalizados son líneas de:
Como cada dispositivo es único, es posible que deba adivinar los criterios de búsqueda ...
Por ejemplo, encontré el
/etc/mkshrc
que usaba Korn shell. Actualizo este archivo para extenderPATH
env var y ahora cada vez que lo hagoadb shell
¡tengo enlaces simbólicos de Busybox en mi RUTA!Vea también de manera difícil (si no tiene suerte con la búsqueda del archivo mágico ): https://stackoverflow.com/questions/9768103/make-persistent-changes-to-init-rc
fuente
/system
estásystem.img
, y/etc
es un enlace simbólico en/system
.Probé todos estos métodos y ninguno de ellos funcionó para mí. Sin embargo, lo que funcionó se basó en la respuesta de lord-ralf-adolf aquí ¿Cómo ejecutar un script en el arranque en CM12.1?
básicamente, encuentre el archivo
/system/etc/install-recovery.sh
y agregue la siguiente línea al principio/data/init.sh &
entonces
¡Hecho! Ahora puede poner lo que quiera
/data/init.sh
y se ejecutará al inicio. Si el archivo/system/etc/install-recovery.sh
no está en su sistema, esta respuesta no funcionará para usted. No te molestes en crearlo.fuente
/system/etc/install-recovery.sh
no estaba presente, pero todavía se ejecuta en el arranque si está presente, por lo que vale la pena verificarlo.Las cosas eran simples antes de Android 5 cuando SELinux no lo era
enforcing
. Puede poner su código en cualquier script o reemplazar un binario con script que se ejecutó con privilegios de root en el arranque. Otro método fue definir uninit
servicio personalizado específicamente para ejecutar scripts de ejecución por lotes desde algún directorio.Sobre la base de estos enfoques desarrolladores ROM personalizada introducido diferentes pseudo
init.d
fenómeno como/etc/init.d/
,/etc/install-recovery.sh
,/etc/init.qcom.post_boot.sh
,/system/bin/debuggerd
,/data/init.sh
,/data/local/userinit.sh
,/data/local/init.d/
etc.Sin embargo, un proceso que se ejecuta con UID
0
pero en un contexto restringido de SELinux es bastante inútil. Un servicio iniciado eninit.rc
los archivos deu:r:init:s0
contexto ni siquiera puede ejecutar un script de shell desde/system/bin/
, por lo que las necesidades de políticas de SELinux a ser parcheado para inyectar una irrestricta contexto por ejemplo magisk defineu:r:magisk:s0
. Después de eso, es posible ejecutar un script directamente comoinit
servicio o desde uninit.d
directorio similar.Para obtener más información, consulte ¿Cómo ejecutar un ejecutable en el arranque y mantenerlo ejecutándose?
fuente
Manera simple (trabajando):
Prepare sus comandos posteriores al inicio en un script, digamos / system / xbin / post-boot (establezca la permanente exec)
Agregue la ruta de script personalizada anterior al final de /system/etc/init.qcom.post_boot.sh
P.ej:
echo / system / xbin / post-boot >> /system/etc/init.qcom.post_boot.sh
¡Hecho!
(Si no puede encontrar el qcom post_boot (dispositivos Qualcomm), busque los scripts post_boot)
fuente
Si tiene magisk instalado, puede colocar el .sh para:
o para
No se olvide de hacerlo ejecutable:
chmod +x your-script.sh
.Más información: https://github.com/topjohnwu/Magisk/blob/master/docs/guides.md#boot-scripts
fuente