Traté de Root manualmente mi teléfono a través de empujar un binario adecuado su a /system/bin y /system/xbin. Yo era capaz de empujar a través de adb en la recuperación, que es un Root (idk por qué). Una vez dentro de mi teléfono, chmodded 755 tanto de ellos y escribió su --install y su --daemon& . Después de eso, intenté setenforce 0 .
Todo parecía funcionar, pero cuando reinicié, no estaba rooteado. Así que volví al recovery, usé la opción "re-Root" y funcionó. ¿A qué se debe esto?
Según el código fuente disponible en GitHub, la recuperación realiza un montón de operaciones aparte de simplemente lanzar el demonio en segundo plano, copiar el su binario a /sistema/xbin y cambiar sus permisos. Como se puede entender examinando este install-su script Lo que hace el recovery, es realizar inicialmente una operación de limpieza de las aplicaciones del Root manager que puedan estar ya instaladas.
A continuación, la operación de copia de los archivos correspondientes, es decir, el su (que se llama cada vez que se solicitan privilegios de Root), el 99SuperSUDaemon (cuya ejecución depende de init.d ), un sistema personalizado de install-recovery.sh (para forzar la ejecución del demonio en Jelly Bean) y SuperSU.apk (el gestor de root).
Tras esta fase, el script utiliza las funciones previamente definidas set_perm (que combina chmod y chown, y sirve para definir la propiedad y los permisos) y ch_con (que marca los archivos como de sistema). Esto último es probablemente la causa del mal funcionamiento de tu procedimiento manual: no cambiaste el contexto de los archivos que empujaste, por lo que no fueron reconocidos como archivos del sistema.
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.
