Recientemente descargué esta ROM para mi Allview P5 (Allview P5 es el equivalente de Gionee GN700W / FLY IQ441 / QMobile Noir A8). Se llama Primonex ROM y está hecho para la versión Gionee del teléfono.

• En primer lugar, intenté instalarlo tal como está, pero se atascó en la pantalla de inicio.
• Después de algunas investigaciones descubrí que podría ser un problema con el boot.imgarchivo y no sé cómo extraerlo o editarlo ...

¿Alguien puede decirme cómo hacerlo?

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:

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

  • Aparentemente, Android Kitchen estaba destinado a ser una especie de navaja suiza para 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 agregando envoltorios de script de shell a su conjunto de herramientas para que el proceso completo de desempaque y reempaque sea más sencillo.
  • osm0sis propone una bifurcación de las herramientas de CyanogenMod "bifurcadas y actualizadas" según la propia descripción del proyecto. 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 no me resulta clara.

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

  • Kuismaunmkbootimg aparece con bastante frecuencia en foros de ayuda y parece hacer un buen trabajo ayudando a manejar casos extraños, generando recomendaciones en inglés "legibles para humanos" cuando se requieren algunas modificaciones en el mkbootimgcódigo fuente y mostrando la línea de comandos exacta para usar para reconstruir la imagen.
  • mkbootimg_toolsParece que Xiaolu también se menciona con bastante frecuencia y permite desempaquetar y reempaquetar boot.imgel archivo de á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 sobre 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 de puerto serie de Android ahora aparentemente desaparecido. Sin embargo, los nombres de los archivos me llevan a pensar que deberían ser versiones antiguas preconstruidas 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 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).

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