Selección de herramientas

El método que presento aquí se basa en el código fuente de Android de CyanogenMod.

Mientras que el AOSP de Google sólo proporciona la herramienta para construir el boot.img CyanogenMod también añade el archivo unpackbootimg herramienta que le permite desempacar lo. Esta herramienta no parece diseñada específicamente para CyanogenMod de ninguna manera, así que lo más probable es que funcione para otras ROMs también.

Sin embargo, hay un número relativamente grande de alternativas para desempacar el boot.img que funcionan más o menos igual.

Básicamente, dicha herramienta de desempaquetado extraerá el contenido del boot.img y muestra un conjunto de parámetros que tendrá que pasar al archivo de Google mkbootimg para construir un archivo cuya configuración (principalmente parámetros del kernel y direcciones de memoria) coincida con la original.

Aquí hay algunos ejemplos, no los he probado personalmente por lo que no puedo recomendar ninguno y los presento sólo como referencia:

• Algunos son de código abierto o basados en script:

  • La cocina de Android estaba destinado a ser una especie de navaja suiza para los desarrolladores de Android. El autor original dejó oficialmente de mantener el proyecto, algunos otros usuarios lo bifurcaron como javilonas o cmotc .
  • szym apunta a la facilidad añadiendo envolturas de shell script a su conjunto de herramientas para hacer que el proceso completo de desempaquetado y reempaquetado sea más sencillo.
  • osm0sis propone un fork de las herramientas de CyanogenMod "bifurcado y actualizado" según la propia descripción del proyecto. Este proyecto parece de hecho todavía se mantiene que no es muy común en esta área, sin embargo, la ventaja real sobre las herramientas originales de CyanogenMod sigue siendo poco clara para mí.

• Algunos son binarios propietarios de código cerrado gratuitos:

  • Kuisma's unmkbootimg aparece muy a menudo en los foros de ayuda y parece hacer un buen trabajo para ayudar a manejar los casos extraños, la salida de la recomendación de Inglés "legible para los humanos" cuando se requieren algunas modificaciones en mkbootimg código fuente y mostrando la línea de comandos exacta que debe utilizarse para reconstruir la imagen.
  • Xiaolu's mkbootimg_tools parece que también se menciona con bastante frecuencia y permite desempaquetar y volver a empaquetar boot.img y el archivo del árbol de dispositivos dt.img . No te dejes engañar por el hecho de que esté alojado en GitHub: es es un binario propietario de código cerrado y sólo los binarios compilados están disponibles en su repositorio (de hecho, incluso me pregunto sobre el interés exacto de utilizar un repositorio de código fuente para almacenar blobs binarios, pero diferentes personas, diferentes mentes...).
  • CNexus en el foro de XDA ofrece un archivo con una selección de herramientas.
  • Esta respuesta en Unix.SE recomienda algunas herramientas del ahora aparentemente desaparecido proyecto Android Serial Port. Los nombres de los archivos, sin embargo, me llevan a pensar que deben ser antiguas versiones preconstruidas de las herramientas de CyanogenMod (al estar cerrado el proyecto, no hay ni documentación ni soporte).

Todas estas herramientas (y otras que puedes encontrar en cualquier motor de búsqueda) deberían funcionar de la misma manera, pero algunas pueden funcionar mejor que otras a la hora de manejar algún caso particular al que puedas enfrentarte con tu propio dispositivo. La mayoría de ellas, sin embargo, al menos en el ámbito del código abierto, no parecen ser mantenidas regularmente, por lo que la mejor apuesta en mi opinión para tener herramientas que funcionen, sean mantenidas y estén documentadas es ir con las de CyanogenMod.

Algunos fabricantes producen ROMs que están más o menos lejos del estándar AOSP (direcciones, cabeceras, formato de archivo inusuales, etc.). Si el procedimiento estándar a continuación no funciona, tal vez uno de estos programas alternativos puede hacer el truco. De lo contrario, tendrá que comprobar los problemas específicos de su dispositivo: algunos parecen necesitar un procedimiento específico o incluso herramientas específicas (confer esta pregunta relacionados con los dispositivos MediaTek, por ejemplo).

Instalación de herramientas

Compilación del conjunto de herramientas de CyanogenMod para boot.img empacar y desempacar es bastante sencillo.

• Si ya tiene instalado el árbol de código fuente completo de Android (puede consultar mi otra respuesta para obtener más información al respecto), entra en system/core/mkbootimg/ (como recordatorio, el código fuente de AOSP de Google sólo proporciona la herramienta para construir el boot.img archivo, lo hacen no proporcionar cualquier herramienta de desempaquetado),

• Si no lo has hecho y no necesitas esto para ningún otro propósito, una solución más fácil y rápida es sólo clonar la versión de CyanogenMod android_system_core depósito:

    git clone https://github.com/CyanogenMod/android_system_core.git
    cd android_system_core/mkbootimg/

Una vez en el directorio correcto, compilar e instalar:

gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/

Tenga en cuenta que Google está sustituyendo el C mkbootimg con una versión de Python por lo que, en futuras versiones, es posible que ya no sea necesaria la compilación para este comando.

También tendrás que instalar las herramientas de Android en tu ordenador para que pueda comunicarse con tu teléfono. Necesitará adb (Android Debug Bridge, una utilidad de shell que permite comunicarse con el subsistema de depuración de Android), adbd (el demonio relacionado) y fastboot (una utilidad de shell que permite comunicarse con el sistema del cargador de arranque de tu teléfono).

Tu distribución de Linux favorita puede proporcionarlos en un paquete único o separado, pero normalmente siempre se llaman "Android-tools":

• Debian / Ubuntu: sudo apt-get install android-tools-{adb,adbd,fastboot}
• Fedora / CentOS: sudo yum install android-tools
• openSUSE: sudo zypper install android-tools

Busca el boot.img archivo

Extraiga el boot.img desde el archivo ROM.zip o directamente desde el dispositivo:

• Desde el archivo .zip de la ROM stock: algunas aplicaciones como SuperSU pueden modificar el boot.img directamente en el dispositivo, sustituirlo por el stock rompería dichas aplicaciones.
• Directamente desde el dispositivo: algunas personas informan de un problema de lectura que conduce a la corrupción boot.img . En mi opinión, lo más probable es que estos problemas estén relacionados con el uso de cables o concentradores USB de mala calidad y pueden evitarse simplemente utilizando cables de buena calidad que conecten directamente el teléfono al ordenador. También se necesita la capacidad de ejecutar ADB en modo Root (dependiendo de la ROM utilizada, esto puede ser trivial o no).

El primer método es muy obvio: extraer el archivo .zip con cualquier software ZIP, el boot.img debería estar en root del archivo.

Para el segundo método, primero tendrá que determinar la ruta (tristemente específica del dispositivo) al dispositivo de almacenamiento donde boot.img se puede recuperar el contenido de la misma. Conozco dos métodos para esto:

• ls /dev/block/platform/*/by-name/ (donde * cubre otro nombre de carpeta específico del dispositivo, lo más probable es que sea el único directorio debajo de platform/ ), el nombre exacto a buscar también depende de la plataforma pero tiene el sentido habitual (algunos ejemplos: boot , LNX (acrónimo de "Linux")). Los archivos en este directorio son en realidad enlaces simbólicos y algunas personas se molestan en ir manualmente al objetivo, pero yo recomiendo quedarse con la ruta basada en el nombre de nivel superior que, aunque es más larga, sigue siendo menos propensa a errores. Así que usted terminará con una ruta como /dev/block/platform/sdhci-tegra.3/by-name/LNX .
• En algunos dispositivos (¿antiguos?), se podía encontrar el dispositivo correcto investigando la salida de cat /proc/mtd . Si ves el dispositivo mtd2 asociado a la "boot" entonces se utilizará la ruta /dev/mtd2 .

Ahora:

• Desde el menú de desarrollador del teléfono:
  • Activa la depuración en tu teléfono,
  • Permitir el acceso Root a ADB (este paso se aplica a los teléfonos que ejecutan CynogenMod, otros dispositivos pueden requerir algún procedimiento potencialmente más complejo),
• Conéctalo a tu ordenador (y desde allí al invitado de la VM si estás ejecutando las herramientas de Android desde una máquina virtual).

Si aún no se ha hecho, recomiendo iniciar manualmente el servidor ADB en el lado del ordenador, esto le permitirá validar directamente la clave RSA en el lado del dispositivo sin afectar el comportamiento de los siguientes comandos ADB:

adb start-server

A continuación, cambie el ADB en modo Root:

adb root

Por último, debería poder extraer directamente el boot.img del dispositivo utilizando dicho comando (la ruta y los nombres de origen y destino se dan como ejemplos, adáptelos a sus necesidades y preferencias):

adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img

El comando copiará toda la partición, tanto el espacio usado como el libre, así que no te sorprendas de que el boot.img será mayor que el original boot.img que viene con el archivo .zip de la ROM original, el contenido en sí sigue siendo similar.

Una vez terminada la transferencia, desconecta el teléfono y no olvides desactivar tanto la depuración como el acceso Root desde el menú de desarrollador.

Desembale el original boot.img archivo

Desembale el boot.img utilizando el comando compilado anteriormente:

unpackbootimg -i ./boot.img

Esto producirá varias informaciones esenciales para permitirle reconstruir un nuevo boot.img con la estructura correcta con respecto a las acciones boot.img . Sin embargo, no se apresure en su bloc de notas, ya que CyanogenMod upackbootimg también guarda la misma información en varios archivos que utilizaremos más adelante.

Este comando genera varios archivos con sufijos particulares añadidos al nombre del archivo de entrada:

• *-second : Este es el gestor de arranque de segunda etapa, opcional y raramente utilizado en los teléfonos de los usuarios finales. Si este archivo está vacío (el caso más común), el gestor de arranque del teléfono llamará directamente al kernel de Linux.
• *-zImage : Este es el núcleo de Linux.
• *-ramdisk.gz o *-ramdisk.lz4 : el disco RAM utilizado para poblar el directorio root del dispositivo. La extensión difiere en función del algoritmo de compresión utilizado.
• *-dt : El árbol de dispositivos, rellenando /dev .
• El resto son pequeños archivos que almacenan cada uno de los valores mostrados en unpackbootimg de salida. Estos valores definen el parámetro de la línea de comandos a pasar al kernel de Linux y las direcciones donde el gestor de arranque tendrá que cargar cada objeto en el momento del arranque.

La mayoría de las veces, uno desempaca el boot.img para poder editar el contenido del directorio root del teléfono. Como se ha visto anteriormente, este contenido se almacena en el directorio *-ramdisk.gz o *-ramdisk.lz4 y se puede extraer con los siguientes comandos:

mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd

Para un disco RAM comprimido LZ4, sustituya el último paso por lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd .

Ahora es libre de hacer la modificación que desee antes de continuar. Sin embargo, podría valer la pena seguir el procedimiento completo de desempaquetar - reembalar - arrancar una vez sin cambiar nada para asegurarse de que sus herramientas funcionan como se espera. De lo contrario, en caso de un problema, no estarás seguro de si la causa es tu modificación o alguna incompatibilidad (ver mis comentarios al principio sobre algunos fabricantes que requieren procedimientos o herramientas no estándar).

Reconstruir para obtener el nuevo new-boot.img archivo

El proceso de construcción de la ROM de CyanogenMod se basa en una herramienta interna, mkbootfs para producir el boot.img (esto ocurre en build/tools/releasetools/common.py ). Sin embargo, los pasos para construir esta herramienta me parecen inútilmente complejos, mientras que el uso de la herramienta proporcionada por el sistema cpio parece funcionar igual de bien. La principal diferencia entre los dos, según mi entendimiento después de una (muy) rápida comprobación en mkbootfs código fuente, parece ser que este último aplica algunas medidas de sanidad al no incluir archivos con puntos y el /root en el archivo resultante, mientras que el directorio cpio -basado en el procedimiento que se describe a continuación, simplemente pondrá a ciegas todo el árbol de directorios seleccionado en el archivo.

Conclusión: es innecesariamente complejo de compilar y tiene muy pocas ventajas, así que sigamos con las herramientas proporcionadas por el sistema.

Comience por crear el nuevo disco RAM, desde el ramdisk directorio creado anteriormente, escriba:

find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz

O, si necesita generar un archivo LZ4:

find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4

El objetivo aquí es crear un nuevo archivo de disco RAM con propiedades lo más parecidas al original (por ejemplo, la configuración del propietario parece faltar a menudo en los procedimientos compartidos en foros y blogs, sin embargo esto era necesario en mi dispositivo).

Ve ahora en el directorio principal para generar el new-boot.img archivo en sí mismo.

cd ..

Como se ha visto anteriormente, el sistema de CyanogenMod unpackbootimg genera un archivo que coincide con cada parámetro esperado por mkbootimg . Por lo tanto, todo lo que tiene que hacer es emitir un mkbootimg -h para obtener un listado de todos los parámetros y, a continuación, establecer cada uno de ellos con el valor adecuado utilizando el archivo correspondiente. Tenga en cuenta que algunos parámetros esperan una ruta de archivo mientras que otros esperan recibir el contenido del archivo como valor. Vea un ejemplo del comando resultante a continuación:

mkbootimg                                           \
--kernel ./boot.img-zImage                          \
--ramdisk ./new-boot.img-ramdisk.gz                 \
--second ./boot.img-second                          \
--cmdline "$(cat ./boot.img-cmdline)"               \
--base "$(cat ./boot.img-base)"                     \
--pagesize "$(cat ./boot.img-pagesize)"             \
--dt ./boot.img-dt                                  \
--ramdisk_offset "$(cat ./boot.img-ramdisk_offset)" \
--second_offset "$(cat ./boot.img-second_offset)"   \
--tags_offset "$(cat ./boot.img-tags_offset)"       \
--output ./new-boot.img

Sólo hay dos parámetros que no se ajustan aquí:

• --board : Según tengo entendido, se trata de un campo informativo que permite insertar un nombre de modelo en la imagen resultante.
• --id : Este no espera ningún valor, sólo imprime un identificador único después de la construcción de la imagen (combinando una marca de tiempo y una suma de comprobación).

Flash de la new-boot.img archivo en el dispositivo

• Inicia el dispositivo en modo fastboot (también conocido como modo bootloader, normalmente manteniendo pulsados los botones de encendido y subir volumen).

• Conecta el cable USB.

• Compruebe que el dispositivo se detecta correctamente:

    sudo fastboot devices

• Intenta arrancar usando la nueva ROM (sin flashearla todavía, así que en caso de problema sólo tienes que reiniciar el teléfono para que vuelva a funcionar, sustituye el ./new-boot.img nombre de archivo con el suyo propio):

    sudo fastboot boot ./new-boot.img

• Si el teléfono funciona satisfactoriamente con la nueva imagen de arranque, entonces vuelve al modo fastboot y flashéalo permanentemente:

    sudo fastboot flash boot ./new-boot.img
    sudo fastboot reboot

Conclusión:

Este procedimiento puede parecer desalentador al principio, pero una vez que lo consigas, verás que en realidad no lo es.

El aspecto "desalentador" viene del hecho de que no hay un único "sistema Android": muchos fabricantes y proveedores de ROMs hacen cambios que pueden ir desde una sutil diferencia de camino hasta un entorno completamente no estándar.

Lo que tienes que hacer es determinar la postura de tu dispositivo en particular, y luego cuáles son los pocos comandos que son apropiados en tu caso. Una vez que los consigas, puedes ceñirte a ellos e incluso script fácilmente si los necesitas a menudo.

A veces he entrado voluntariamente en detalles de nivel relativamente bajo porque eso hará que se puedan solucionar los problemas más fácilmente. ¿Utilizarías alguna utilidad opaca "más fácil" para construir y flashear tu nuevo boot.img y ve que su dispositivo no puede arrancar con él, le resultará más difícil determinar qué paso ha ido mal. Aquí, en cada paso, podrá comparar los datos que está manipulando con los datos procedentes del original boot.img archivo o los datos que se ven en el teléfono, o intentar, por ejemplo, reconstruir el boot.img con el archivo original o con el nuevo archivo de disco RAM generado para comprobar si hay alguna diferencia (esto le permite determinar si el problema proviene del boot.img o el procedimiento de generación de archivos del disco RAM).

Utilice el Cocina Android. Hay una opción para desempaquetar/reempaquetar boot.img allí, en Advanced options .