{"id":1362,"date":"2014-06-16T20:16:14","date_gmt":"2014-06-16T18:16:14","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=1362"},"modified":"2014-06-16T20:16:14","modified_gmt":"2014-06-16T18:16:14","slug":"reemplazando-android","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=1362","title":{"rendered":"Reemplazando Android"},"content":{"rendered":"

(La segunda parte de este art\u00edculo est\u00e1 en https:\/\/blog.rastersoft.com\/?p=1386<\/a>)<\/p>\n

Hace unas semanas me compr\u00e9 un cacharro de tipo AndroidTV (este en concreto<\/a>). Sin embargo ya ten\u00eda claro que no quer\u00eda tener Android, sino un linux como $DEITY manda. Por eso busqu\u00e9 uno con el mismo chip que mi tablet<\/a>. Por desgracia esta vez no consegu\u00ed que arrancase desde una tarjeta externa (parece que han cambiado algo en el cargador). Pero como a cabezota no me gana nadie, decid\u00ed buscar alguna alternativa.<\/p>\n

Por supuesto no quer\u00eda eliminar el Android que ya trae, m\u00e1s que nada por si me lo cargo y acabo con un bonito pisapapeles. Por eso decid\u00ed intentar una ruta intermedia: una vez arrancado el sistema, lanzar\u00eda un programa que matar\u00eda todos los procesos de Android y lanzar\u00eda una Debian almacenada en un disco externo, desde un entorno chroot, con su entorno gr\u00e1fico y todo. De esta manera, si no enchufo el disco el sistema arrancar\u00eda Android normalmente, y si lo enchufo, arrancar\u00eda Linux.<\/p>\n

Obviamente la cosa no es tan sencilla. Para empezar, los diversos procesos de Android se vuelven a lanzar autom\u00e1ticamente si mueren, por lo que no podemos utilizar un simple kill pid<\/em>. Afortunadamente existen los comandos start<\/em> y stop<\/em> que lanzan y detienen todo el entorno gr\u00e1fico. Para probarlos utilic\u00e9 adb<\/em><\/a>, disponible en el entorno de desarrollo de Android. Para ello primero lanc\u00e9 el servidor con<\/p>\n

\n
sudo .\/adb start server<\/pre>\n<\/div>\n
Y luego cada vez que necesitaba una consola en el dispositivo, lo conectaba con el cable USB y lanzaba:<\/p>\n
\n
.\/adb shell<\/pre>\n<\/div>\n
Y efectivamente, si ejecutaba stop<\/em> el entorno de Android desaparec\u00eda, quedando la pantalla congelada. Ejecutando start<\/em> volv\u00eda a arrancar todo. Afortunadamente, aunque mi dispositivo no est\u00e1 completamente rooteado<\/em>, si es lo suficientemente libre<\/em> como para que, por defecto, entre como root<\/em> desde esta shell, adem\u00e1s de incluir un busybox<\/em> con chroot<\/em>. Con esto ya tengo resuelto el primer gran problema. Es cierto que todav\u00eda quedan varios servicios en marcha, como el gestor de red, pero es un problema secundario que ya resolveremos luego.<\/p>\n
OJO: el servicio adb<\/em> en el dispositivo Android tarda un poco en ser lanzado. Si acab\u00e1is de arrancarlo, sed pacientes. Por otro lado, a veces la lista de dispositivos USB con Android no est\u00e1 actualizada en Linux, as\u00ed que es posible que haya que tocar un poco en udev<\/em> para que reconozca el nuestro.<\/p>\n
Autoarranque<\/h3>\n
Si s\u00f3lo quisiese lanzar manualmente el nuevo entorno ya tendr\u00eda el problema resuelto; pero yo quiero un dispositivo que arranque Debian incluso si no estoy (por ejemplo si se va la luz y luego vuelve), por lo que no queda m\u00e1s remedio que meter las narices en el proceso de arranque de Android.<\/p>\n
Alguno puede pensar que ir a tan bajo nivel es exagerado, pero hay un motivo: la primera idea que se me ocurri\u00f3 fue buscar alg\u00fan programa nativo de Android que en el arranque lance autom\u00e1ticamente un script<\/em> que yo le pase. Encontr\u00e9 varios, pero fue entonces cuando descubr\u00ed que mi cacharro no est\u00e1 rooteado<\/em> del todo, por lo que ese script<\/em> no pod\u00eda lanzar un chroot<\/em> ni nada por el estilo. As\u00ed pues, no queda m\u00e1s remedio que meter las narices m\u00e1s abajo.<\/p>\n
Como en cualquier sistema Linux, una vez arrancado el n\u00facleo se ejecuta el proceso init<\/em>. Pero aqu\u00ed acaban los paralelismos, porque en Android este proceso es muy diferente del SysV Init<\/em>: aqu\u00ed hay un conjunto de ficheros .rc<\/em> con una serie de indicaciones de qu\u00e9 procesos hay que lanzar, en qu\u00e9 orden, con qu\u00e9 permisos, de qu\u00e9 dependen, y, sobre todo, si es necesario volver a lanzarlos si mueren. Estos ficheros .rc<\/em> se encuentran en el ra\u00edz del sistema de ficheros, y ese es primer problema serio con el que nos encontramos: en general, el sistema ra\u00edz es de tipo rootfs<\/em>. Este sistema de ficheros es un tipo de ramfs,<\/em> que se inicializa durante el arranque con unos valores predeterminados, y adem\u00e1s est\u00e1 montado como s\u00f3lo lectura. Aunque en principio podemos hacer mount -o remount,rw \/<\/em> para permitir escritura, cualquier cambio que hagamos desaparecer\u00e1 al reiniciar. La \u00fanica manera de modificar el sistema de archivos es recompilarlo y grabar la partici\u00f3n entera, y eso es algo que no quiero hacer por el riesgo de cascar el sistema. Sin embargo, en \/system<\/em> tenemos una partici\u00f3n que s\u00ed es modificable, porque es de tipo ext4<\/em>, as\u00ed que intentaremos meter nuestro autoarranque ah\u00ed. En caso de que, por defecto, dicha partici\u00f3n est\u00e9 montada como s\u00f3lo lectura, podemos volverla de lectura\/escritura con:<\/p>\n
\n
mount -o remount,rw \/system<\/pre>\n<\/div>\n
y devolverla a s\u00f3lo lectura con<\/p>\n
\n
mount -o remount,ro \/system<\/pre>\n<\/div>\n
El formato de los ficheros .rc<\/em> es relativamente sencillo<\/a>: si una l\u00ednea comienza por on XXXXX<\/em><\/strong>, las l\u00edneas siguientes definen los comandos a realizar cuando ocurra el evento XXXXX<\/em>. Pero si empieza por service XXXXX<\/em><\/strong>, entonces las siguientes l\u00edneas definen a dicho servicio XXXXX<\/em>, que se debe lanzar al inicio. Un ejemplo de servicio ser\u00eda este:<\/p>\n
\n
service console \/system\/bin\/sh\n    class core\n    console\n    disabled\n    user shell\n    group log<\/pre>\n<\/div>\n
Estas l\u00edneas definen el servicio console<\/em>, que se lanza ejecutando el binario \/system\/bin\/sh<\/em>. Adem\u00e1s, debe lanzarse como usuario shell<\/em> y grupo log<\/em>. Si estos dos par\u00e1metros no se incluyen se lanza como root<\/em>.<\/p>\n
Una l\u00ednea especial, que nos interesa especialmente, es oneshot<\/em>. Cuando un servicio la incluye significa que debe lanzarse una \u00fanica vez durante el arranque, y si se muere no debe lanzarse de nuevo. En cambio, aquellos servicios que no incluyen oneshot<\/em> se vuelven a lanzar si mueren. El motivo de explicar esto es que lo que vamos a hacer es buscar un servicio de tipo oneshot<\/em>, y reemplazar su binario por un script<\/em> que primero llame al binario original, y luego haga lo que a nosotros nos interese. En mi caso tuve m\u00e1s suerte, y encontr\u00e9 este servicio:<\/p>\n
\n
service flash_recovery \/system\/etc\/install-recovery.sh\n    class main\n    oneshot<\/pre>\n<\/div>\n
Por el nombre, tiene pinta de ser lo que se lanza cuando se borran las preferencias y se quiere dejar el sistema como reci\u00e9n comprado. Si vamos a \/system\/etc<\/em>, vemos que no existe el fichero install-recovery.sh<\/em>, supongo que porque s\u00f3lo se crear\u00e1 cuando se quieran borrar los datos; pero eso significa que nosotros podemos meter en su lugar un ejecutable o un script<\/em> y \u00e9ste se ejecutar\u00e1 como root<\/em> cada vez que arranque el sistema. Y adem\u00e1s, al estar en \/system<\/em> podemos editarlo a nuestro antojo \u00a1Justo lo que est\u00e1bamos buscando!<\/p>\n
Lanzamiento condicional<\/h3>\n
Ahora que ya tenemos donde meter nuestro c\u00f3digo, la primera idea que se nos viene a la cabeza es montar un sistema Debian<\/em> en, por ejemplo, \/system\/debian<\/em>, escribir un script<\/em> que monte una copia de\u00a0proc, sys <\/em>y\u00a0<\/em>dev<\/em>, y meterlo directamente en \/system\/etc\/install-recovery.sh<\/em>. Esto tiene varios problemas:<\/p>\n