Selección de herramientas

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

Si bien AOSP de Google solo proporciona la herramienta para crear el boot.imgarchivo, CyanogenMod también agrega la unpackbootimgherramienta que le permite descomprimirlo . Esta herramienta no parece diseñada específicamente para CyanogenMod de ninguna manera, por lo que lo más probable es que también funcione para otras ROM.

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

Básicamente, dicha herramienta de desempaquetado extraerá el contenido del boot.imgarchivo y mostrará un conjunto de parámetros que deberá pasar a la mkbootimgherramienta de Google para crear un archivo cuya configuración (principalmente parámetros del kernel y direcciones de memoria) coincidirá con la original.

Aquí hay algunos ejemplos, no los probé personalmente, por lo que no puedo recomendar ninguno y los presento solo como referencia:

• Algunos son de código abierto o basados ​​en secuencias de comandos:

  • Aparentemente, Android Kitchen estaba destinado a ser una especie de navaja suiza para los desarrolladores de Android. El autor original oficialmente dejó de mantener el proyecto, algunos otros usuarios lo bifurcaron como javilonas o cmotc .
  • Szym apunta a la facilidad al agregar envolturas de scripts de shell a su conjunto de herramientas para hacer que el proceso completo de desempaquetado y reempaquetado sea más sencillo.
  • osm0sis propone una bifurcación de las herramientas de CyanogenMod "bifurcada y actualizada" según la propia descripción del proyecto. De hecho, parece que este proyecto aún se mantiene, lo cual no es muy común en esta área, sin embargo, la ventaja real sobre las herramientas originales de CyanogenMod sigue sin estar clara para mí.

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

  • Kuismaunmkbootimg aparece con bastante frecuencia en los foros de ayuda y parece hacer un buen trabajo para ayudar a manejar casos extraños, generando una recomendación en inglés "legible por humanos" cuando se requiere alguna modificación en mkbootimgel código fuente y mostrando la línea de comando exacta para usar para reconstruir la imagen.
  • Xiaolumkbootimg_tools también parece mencionarse con bastante frecuencia y permite descomprimir y volver a empaquetar boot.imgy el archivo del árbol del dispositivo dt.img. No se deje engañar por el hecho de que está alojado en GitHub: es un binario propietario de código cerrado y solo los binarios compilados están disponibles en su repositorio (en realidad, incluso me pregunto cuál es el interés exacto de usar un repositorio de código fuente para almacenar manchas binarias, pero diferentes personas, diferentes mentes...).
  • CNexus en el foro XDA proporciona un archivo con una selección de herramientas.
  • Esta respuesta en Unix.SE recomienda algunas herramientas del proyecto Android Serial Port, ahora aparentemente desaparecido. Sin embargo, los nombres de los archivos me llevan a pensar que deberían ser versiones antiguas precompiladas de las herramientas de CyanogenMod (el proyecto está cerrado, no hay documentación ni soporte).

Todas estas herramientas (y otras que puede encontrar con cualquier motor de búsqueda) deberían funcionar de la misma manera, pero algunas pueden funcionar mejor que otras para manejar algún caso límite particular que pueda enfrentar con su propio dispositivo. Sin embargo, la mayoría de ellos, al menos en el ámbito del código abierto, no parecen recibir un mantenimiento regular, por lo que, en mi opinión, la mejor apuesta para tener herramientas que funcionen, mantenidas y documentadas es optar por las de CyanogenMod.

Algunos fabricantes producen ROM que están más o menos alejadas del estándar AOSP (direcciones inusuales, encabezados, formato de archivo, etc.). Si el procedimiento estándar a continuación no funciona, tal vez uno de estos programas alternativos pueda funcionar. De lo contrario, deberá buscar problemas específicos de su dispositivo: algunos parecen necesitar un procedimiento específico o incluso herramientas específicas (consulte esta pregunta relacionada con los dispositivos MediaTek, por ejemplo).

Instalación de herramientas

Compilar el conjunto de herramientas de CyanogenMod para boot.imgempaquetar y desempaquetar es bastante sencillo.

• Si ya instaló el árbol completo del código fuente de Android (puede consultar mi otra respuesta para obtener más información al respecto), vaya al system/core/mkbootimg/directorio (como recordatorio, el código fuente AOSP de Google solo proporciona la herramienta para crear el boot.imgarchivo, no proporcionar cualquier herramienta de desembalaje),

• Si no lo ha hecho y no necesita esto para ningún otro propósito, una solución más fácil y rápida es clonar solo el repositorio android_system_core de CyanogenMod:

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

Una vez en el directorio correcto, compila e instala:

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á reemplazando la C mkbootimgcon una versión de Python , por lo que en futuras versiones es posible que ya no se necesite compilar este comando.

También deberá instalar las herramientas de Android en su computadora para permitir que se comunique con su 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 de cargador de arranque de su teléfono).

Su distribución de Linux favorita puede proporcionarlos en paquetes individuales o separados, pero por lo general siempre se los llama "herramientas de Android":

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

Obtener el boot.imgarchivo

Extraiga boot.img del archivo ROM .zip o directamente del dispositivo:

• Desde el archivo .zip de la ROM de stock: algunas aplicaciones como SuperSU pueden modificar el archivo boot.img directamente en el dispositivo; reemplazarlo con el de stock rompería dichas aplicaciones.
• Directamente desde el dispositivo: algunas personas informan problemas de lectura que conducen a archivos boot.img. En mi opinión, es muy probable que estos problemas estén relacionados con el uso de cables USB o un concentrador USB deficientes y se pueden evitar simplemente mediante el uso de cables de buena calidad que conectan directamente el teléfono a la computadora. También necesita la capacidad de ejecutar ADB en modo raíz (dependiendo de la ROM utilizada, esto puede ser trivial o no).

El primer método es muy obvio: extraiga el archivo .zip con cualquier software ZIP, el boot.imgarchivo debe estar allí mismo, en la raíz del archivo.

Para el segundo método, primero deberá determinar la ruta (lamentablemente específica del dispositivo) al dispositivo de almacenamiento donde boot.imgse puede recuperar el contenido. 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 a continuación platform/), el nombre exacto para buscar también depende de la plataforma, pero tiene 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 destino, pero recomiendo seguir con la ruta basada en el nombre de nivel superior que, aunque es más larga, sigue siendo menos propensa a errores. Así que terminarás 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 ve el dispositivo mtd2asociado a la "boot"etiqueta, entonces utilizará la ruta /dev/mtd2.

Ahora:

• Desde el menú de desarrollador del teléfono:
  • Habilite la depuración en su teléfono,
  • Permita el acceso de root a ADB (este paso se aplica a los teléfonos que ejecutan CynogenMod, otros dispositivos pueden requerir un procedimiento potencialmente más complejo),
• Conéctelo a su computadora (y de allí al invitado de VM si está ejecutando herramientas de Android desde dentro de una máquina virtual).

Si esto aún no se ha hecho, recomiendo iniciar manualmente el servidor ADB en el lado de la computadora, 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

Luego cambie ADB en modo raíz:

adb root

Finalmente, debería poder extraer directamente el boot.imgarchivo del dispositivo usando 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 se sorprenda de que el boot.imgarchivo resultante sea más grande que el boot.imgarchivo original que viene con el archivo .zip de la ROM estándar, el contenido en sí sigue siendo similar.

Una vez finalizada la transferencia, desconecta el teléfono y no olvides deshabilitar tanto la depuración como el acceso de root desde el menú del desarrollador.

Descomprimir el boot.imgarchivo original

Descomprima el boot.imgarchivo usando el comando compilado previamente:

unpackbootimg -i ./boot.img

Esto generará información esencial para permitirle reconstruir uno nuevo boot.imgcon la estructura correcta con respecto al stock boot.img. Sin embargo, no se apresure en su bloc de notas ya que CyanogenMod upackbootimgtambién guarda la misma información en varios archivos que usaremos más adelante.

Este comando genera varios archivos con sufijos particulares agregados al nombre del archivo de entrada:

• *-second: Este es el cargador de arranque de segunda etapa, opcional y rara vez se usa en los teléfonos de los usuarios finales. Si este archivo está vacío (el caso más común), entonces el gestor de arranque del teléfono llamará directamente al kernel de Linux.
• *-zImage: Este es el kernel de Linux.
• *-ramdisk.gzo *-ramdisk.lz4: el disco RAM utilizado para llenar el directorio raíz del dispositivo. La extensión difiere según el algoritmo de compresión utilizado.
• *-dt: El árbol de dispositivos, llenando /dev.
• El resto son archivos pequeños, cada uno de los cuales almacena uno de los valores que se muestran en unpackbootimgla salida. Estos valores definen el parámetro de la línea de comandos para pasar al kernel de Linux y las direcciones en las que el gestor de arranque tendrá que cargar cada objeto en el momento del arranque.

La mayoría de las veces, uno descomprime el boot.imgpara poder editar el contenido del directorio raíz del teléfono. Como se vio anteriormente, este contenido se almacena en el archivo *-ramdisk.gzo *-ramdisk.lz4y se puede extraer usando los siguientes comandos:

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

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

Ahora puede hacer la modificación que desee antes de continuar. Sin embargo, podría valer la pena seguir el procedimiento completo de desempaquetado, reempacado e inicio una vez sin cambiar nada para asegurarse de que sus herramientas funcionen como se espera. De lo contrario, en caso de un problema, no estará seguro de si la causa es su modificación o alguna incompatibilidad (vea mis comentarios al principio sobre algunos fabricantes que requieren procedimientos o herramientas no estándar).

Reconstruir para obtener el nuevo new-boot.imgarchivo

El proceso de creación de ROM de CyanogenMod se basa en una herramienta interna, mkbootfs, para producir el boot.imgarchivo (esto sucede en build/tools/releasetools/common.py ). Sin embargo, los pasos para construir esta herramienta me parecen inútilmente complejos, mientras que usar el sistema proporcionado cpioparece funcionar igual de bien. La principal diferencia entre los dos, según tengo entendido después de una verificación (muy) rápida en mkbootfsel código fuente, parece ser que este último aplica algunas medidas de cordura al no incluir archivos punteados y el /rootdirectorio en el archivo resultante mientras que el cpioprocedimiento basado a continuación simplemente colocará ciegamente todo el árbol de directorios seleccionado en el archivo.

Conclusión: innecesariamente complejo de compilar con muy pocas ventajas, ¡así que sigamos con las herramientas provistas por el sistema!

Comience creando el nuevo disco RAM, desde el ramdiskdirectorio 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 cercanas posible al original (por ejemplo, la configuración del propietario a menudo parece faltar en los procedimientos compartidos en foros y blogs, sin embargo, esto era necesario en mi dispositivo).

Vaya ahora al directorio principal para generar el new-boot.imgarchivo en sí.

cd ..

Como se vio anteriormente, el comando de CyanogenMod unpackbootimggenera un archivo que coincide con cada parámetro esperado por mkbootimg. Por lo tanto, todo lo que tiene que hacer es emitir un mkbootimg -hpara obtener una lista de todos los parámetros, luego establecer cada uno de ellos en el valor apropiado usando 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

Solo dos parámetros no se establecen aquí:

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

Flashea el new-boot.imgarchivo en el dispositivo

• Inicie el dispositivo en modo de arranque rápido (también conocido como modo de cargador de arranque, generalmente manteniendo presionados los botones de encendido y subir volumen).

• Conecte el cable USB.

• Compruebe que el dispositivo se detecta correctamente:

    sudo fastboot devices
  

• Intente iniciar con la nueva ROM (sin actualizarla todavía, por lo que, en caso de problemas, solo tiene que reiniciar el teléfono para que vuelva a funcionar, reemplace el ./new-boot.imgnombre del archivo con el suyo):

    sudo fastboot boot ./new-boot.img
  

• Si el teléfono funciona correctamente con la nueva imagen de arranque, vuelva al modo de arranque rápido y actualícelo de forma permanente:

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

Conclusión

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

El aspecto "desalentador" proviene del hecho de que no existe un solo "sistema Android": muchos fabricantes y proveedores de ROM realizan cambios que pueden variar desde una sutil diferencia de ruta hasta un entorno completamente no estándar.

Lo que tiene que hacer es determinar la postura de su dispositivo en particular y luego cuáles son los pocos comandos que son apropiados en su caso. Una vez que los obtenga, puede apegarse a ellos e incluso escribirlos fácilmente si los necesita con frecuencia.

A veces entré voluntariamente en detalles de nivel relativamente bajo porque le permitirá solucionar sus problemas más fácilmente. ¿Usaría alguna utilidad opaca "más fácil" para compilar y actualizar su nuevo boot.imgarchivo y ver que su dispositivo no puede comenzar con él? Sería más difícil para usted determinar qué paso salió mal. Aquí, en cada paso, podrá comparar los datos que está manipulando con los datos que provienen del boot.imgarchivo original o los datos que se ven en el teléfono, o intentar, por ejemplo, reconstruir el boot.imgarchivo con el original o con el recién generado. Archivo de disco RAM para verificar si eso hace alguna diferencia (esto le permite identificar si el problema proviene del boot.imgprocedimiento de generación de archivos de disco RAM).

Usa la cocina de Android. Hay una opción para desempaquetar/reempaquetar boot.img allí, en Advanced options.