Traté de rootear mi teléfono manualmente empujando un su binario adecuado a /system/bin y /system/xbin. Pude empujarlos a través de adb en la recuperación, que es una raíz (no sé por qué). Una vez dentro de mi teléfono, cambié 755 a ambos y escribí su --instally su --daemon&. Después de eso, traté de setenforce 0.
Todo parecía funcionar, pero cuando reinicié, no estaba rooteado. Así que volví a la recuperación, usé la opción "re-rootear" y funcionó. ¿Por qué es esto?
De acuerdo con el código fuente disponible en GitHub, la recuperación realiza una gran cantidad de operaciones además de simplemente iniciar el demonio en segundo plano, copiar el binario su a /system/xbin y cambiar sus permisos. Como se puede entender al examinar este script install-su , lo que hace la recuperación es realizar inicialmente una operación de limpieza para las aplicaciones del administrador raíz que ya se hayan instalado.
Después de eso, la operación de copiar los archivos relevantes, a saber, el binario su (que se llama cada vez que solicita privilegios de root), el 99SuperSUDaemon (cuya ejecución depende de init.d ), un install-recovery.sh personalizado (para forzar el daemon para ser ejecutado en Jelly Bean) y SuperSU.apk (el administrador raíz).
Después de 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 del sistema). Esta última es probablemente la causa del mal funcionamiento de su procedimiento manual: no cambió el contexto de los archivos que envió, por lo que no se reconocieron como archivos del sistema.