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 solo proporciona la herramienta para construir el boot.imgarchivo, CyanogenMod también agrega la unpackbootimgherramienta que le permite desempaquetarlo . 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 una cantidad relativamente grande de alternativas para descomprimir el boot.imgarchivo que funcionan más o menos igual.
Básicamente, dicha herramienta de desempaque 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 núcleo y direcciones de memoria) coincida con la original.
Aquí hay algunos ejemplos, no los probé personalmente, así que no puedo recomendar ninguno y los presento solo con fines de referencia:
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 en el manejo de algún caso 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 mantenerse regularmente, por lo que, en mi opinión, la mejor apuesta para tener herramientas de trabajo, mantenidas y documentadas es ir con las de CyanogenMod.
Algunos fabricantes producen ROM que están más o menos lejos 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 software alternativos pueda ser el truco. De lo contrario, tendrá que verificar si hay problemas específicos de su dispositivo: algunos parecen necesitar un procedimiento específico o incluso herramientas específicas (confiera esta pregunta relacionada con los dispositivos MediaTek, por ejemplo).
Instalación de herramientas
Compilar el conjunto de herramientas CyanogenMod para boot.imgempacar y desempacar es bastante sencillo.
- Si ya ha instalado el árbol completo de código fuente de Android (se puede comprobar mi otra respuesta para obtener más información sobre esto), ir en
system/core/mkbootimg/el directorio (como recordatorio, el código fuente AOSP de Google sólo proporcionan la herramienta para construir el boot.imgarchivo, lo hacen sin proporcionar cualquier herramienta de desembalaje),
Si no lo ha necesitado y no lo necesita 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, compile e instale:
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 el C mkbootimgcon una versión de Python , por lo que en futuras versiones ya no será necesaria la compilación para este comando.
También deberá instalar 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 le permite comunicarse con el subsistema de depuración de Android), adbd(el demonio relacionado) y fastboot(una utilidad de shell que le permite comunicarse con el sistema del gestor de arranque de su teléfono).
Su distribución de Linux favorita puede proporcionarlos en paquetes individuales o separados, pero generalmente siempre se denominan "herramientas de Android":
- Debian / Ubuntu:
sudo apt-get install android-tools-{adb,adbd,fastboot}
- Fedora / CentOS:
sudo yum install android-tools
- openSUSE:
sudo zypper install android-tools
Obtener el boot.imgarchivo
Extraiga boot.img del archivo .zip de ROM o directamente del dispositivo:
- Desde el archivo .zip de ROM de stock: algunas aplicaciones como SuperSU pueden modificar boot.img directamente en el dispositivo, reemplazándolo con el stock de stock que rompería dichas aplicaciones.
- Directamente desde el dispositivo: algunas personas informan que el problema de lectura está dañado
boot.img. En mi opinión, lo más probable es que estos problemas estén relacionados con el uso de cables USB o hub USB deficientes y simplemente se pueden evitar mediante el uso de cables de buena calidad que conecten 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í, en la raíz del archivo.
Para el segundo método, primero tendrá que 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 *cubiertas todavía otro nombre de la carpeta específica del dispositivo, lo más probable es que es el único directorio de abajo platform/), el nombre exacto de búsqueda 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. Entonces terminarás con un camino como /dev/block/platform/sdhci-tegra.3/by-name/LNX.- En algunos dispositivos (¿antiguos?), Se puede encontrar el dispositivo correcto investigando la salida de
cat /proc/mtd. Si ve el dispositivo mtd2asociado a la "boot"etiqueta, utilizará la ruta /dev/mtd2.
Ahora:
- Desde el menú de desarrollador del teléfono:
- Habilite la depuración en su teléfono,
- Permitir acceso de root a ADB (este paso se aplica a teléfonos que ejecutan CynogenMod, otros dispositivos pueden requerir algún procedimiento potencialmente más complejo),
- Conéctelo a su computadora (y desde allí al invitado de VM si está ejecutando herramientas de Android desde 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, debe poder extraer directamente el boot.imgarchivo del dispositivo utilizando dicho comando (la ruta de origen y destino y los nombres se dan como ejemplos, adaptarlos 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 libre como el usado, 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 ROM .zip de stock, el contenido en sí sigue siendo similar.
Una vez que finalice la transferencia, desconecte el teléfono y no olvide deshabilitar tanto la depuración como el acceso a la raíz desde el menú del desarrollador.
Descomprima el boot.imgarchivo original
Descomprima el boot.imgarchivo usando el comando compilado previamente:
unpackbootimg -i ./boot.img
Esto generará información esencial que le permitirá reconstruir una nueva 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 gestor de arranque de la segunda etapa, opcional y rara vez se usa en teléfonos de 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 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, que se completa /dev.- El resto son pequeños archivos que almacenan uno de los valores que se muestran en la
unpackbootimgsalida. Estos valores definen el parámetro de línea de comando para pasar al kernel de Linux y las direcciones donde el gestor de arranque tendrá que cargar cada objeto en el momento del arranque.
En la mayoría de los casos, uno desempaqueta 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 con 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, reempaquetado y arranque una vez sin cambiar nada para garantizar 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 construcción de ROM de CyanogenMod se basa en una herramienta interna mkbootfspara producir el boot.imgarchivo (esto ocurre en build / tools / releasetools / common.py ). Sin embargo, los pasos para construir esta herramienta me parecen inútilmente complejos, mientras que usar el sistema provisto cpioparece funcionar igual de bien. La principal diferencia entre los dos, según tengo entendido después de una (muy) revisión rápida en el mkbootfscó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 pondrá a ciegas todo el árbol de directorios seleccionado en el archivo.
Conclusión: compilación innecesariamente compleja con muy pocas ventajas, ¡así que pegémonos de las herramientas proporcionadas 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 unpackbootimgcomando de CyanogenMod 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 -hpara obtener una lista de todos los parámetros, luego establecer cada uno de ellos en el valor apropiado 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
Solo dos parámetros no están establecidos 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, solo imprime un identificador único después de que la imagen ha sido construida (combinando una marca de tiempo y una suma de verificación).
Destella el new-boot.imgarchivo en el dispositivo
- Inicie el dispositivo en modo fastboot (también conocido como modo bootloader, generalmente manteniendo presionados los botones de encendido y subir volumen).
- Conecta el cable USB.
Compruebe que el dispositivo se detecte correctamente:
sudo fastboot devices
Intente arrancar usando la nueva ROM (sin flashearla todavía, por lo que en caso de problemas solo tiene que reiniciar el teléfono para volver a ponerlo en marcha, 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 inicio, vuelva al modo de inicio rápido y actualícelo 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 obtenga, verá que en realidad no lo es.
El aspecto "desalentador" proviene del hecho de que no hay 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 atenerse a ellos e incluso escribirlos fácilmente si los necesita con frecuencia.
Voluntariamente entré en detalles de nivel relativamente bajo a veces porque te hará solucionar tus problemas más fácilmente. Si usa 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 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 intente, por ejemplo, reconstruir el boot.imgarchivo con el original o el recién generado Archivo de disco RAM para verificar si eso hace alguna diferencia (esto le permite determinar si el problema proviene del boot.imgprocedimiento de generación de archivos de disco RAM).
