Recentemente, baixei esta ROM para o Allview P5 (Allview P5 é o equivalente ao Gionee GN700W / FLY IQ441 / QMobile Noir A8). Chama-se ROM Primonex e é feito para a versão Gionee do telefone.

• Primeiramente, tentei instalá-lo como está, mas ele ficou preso na tela de inicialização.
• Após algumas pesquisas, descobri que poderia haver um problema com o boot.imgarquivo e não sei como extraí-lo ou editá-lo ...

Alguém pode me dizer como fazer isso?

Seleção de ferramentas

O método que apresento aqui se baseia no código-fonte Android do CyanogenMod.

Enquanto o AOSP do Google fornece apenas a ferramenta para criar o boot.imgarquivo, o CyanogenMod também adiciona a unpackbootimgferramenta, permitindo descompactá- lo. Essa ferramenta não parece projetada especificamente para o CyanogenMod de forma alguma; portanto, a maioria das chances é de que funcione para outras ROMs também.

Há, no entanto, um número relativamente grande de alternativas para descompactar o boot.imgarquivo, que funcionam mais ou menos da mesma forma.

Basicamente, essa ferramenta de descompactação extrairá o conteúdo do boot.imgarquivo e exibirá um conjunto de parâmetros que você precisará passar para a mkbootimgferramenta do Google para criar um arquivo cuja configuração (principalmente parâmetros do kernel e endereços de memória) corresponda ao original.

Aqui estão alguns exemplos: eu não os testei pessoalmente, portanto não posso recomendar nenhum e os apresento apenas para fins de referência:

• Alguns são baseados em código aberto ou em script:

  • Aparentemente, o Android Kitchen era para ser algum tipo de canivete suíço para desenvolvedores do Android. O autor original parou oficialmente de manter o projeto, alguns outros usuários o bifurcaram como javilonas ou cmotc .
  • O szym visa a facilidade adicionando wrappers de script de shell ao seu conjunto de ferramentas para tornar o processo completo de descompactação e reembalagem mais simples.
  • osm0sis propõe um garfo das ferramentas do CyanogenMod "bifurcadas e atualizadas" de acordo com a descrição do próprio projeto. Este projeto parece de fato ainda mantido, o que não é muito comum nessa área, no entanto, a vantagem real sobre as ferramentas originais do CyanogenMod permanece incerta para mim.

• Alguns são binários proprietários de código fechado gratuito:

  • O Kuismaunmkbootimg aparece com bastante frequência nos fóruns de ajuda e parece fazer um bom trabalho ajudando a lidar com casos estranhos, emitindo recomendação em inglês "legível por humanos" quando são necessárias algumas modificações no mkbootimgcódigo-fonte e exibindo a linha de comando exata a ser usada para reconstruir a imagem.
  • O Xiaolumkbootimg_tools também parece mencionado com bastante frequência e permite descompactar e reembalar boot.imge o arquivo da árvore do dispositivo dt.img. Não se deixe enganar pelo fato de ele estar hospedado no GitHub: é um binário proprietário de código fechado e apenas binários compilados estão disponíveis em seu repositório (na verdade, eu estou me perguntando sobre o interesse exato de usar um repositório de código-fonte para armazenar bolhas binárias, mas pessoas diferentes, mentes diferentes ...).
  • O CNexus no fórum XDA fornece um arquivo com uma seleção de ferramentas.
  • Esta resposta no Unix.SE recomenda algumas ferramentas do projeto aparentemente agora extinto da porta serial do Android. Os nomes dos arquivos, no entanto, me levam a pensar que essas devem ser versões pré-construídas antigas das ferramentas do CyanogenMod (o projeto está sendo fechado, não há documentação nem suporte).

Todas essas ferramentas (e outras que você pode encontrar em qualquer mecanismo de pesquisa) devem funcionar da mesma maneira, mas algumas podem funcionar melhor do que outras no tratamento de casos específicos que você pode enfrentar com seu próprio dispositivo. No entanto, a maioria deles, pelo menos na área de código aberto, não parece mantida regularmente, então a melhor aposta em minha opinião para ter ferramentas de trabalho, manutenção e documentação é ir com as do CyanogenMod.

Alguns fabricantes produzem ROMs mais ou menos distantes do padrão AOSP (endereços incomuns, cabeçalhos, formato de arquivo etc.). Se o procedimento padrão abaixo não funcionar, talvez um desses softwares alternativos possa executar o truque. Caso contrário, você precisará verificar se há problemas específicos para o seu dispositivo: alguns parecem precisar de um procedimento específico ou mesmo de ferramentas específicas (confira essa pergunta relacionada aos dispositivos MediaTek, por exemplo).

Instalação de ferramentas

Compilar o conjunto de ferramentas CyanogenMod para boot.imgempacotar e descompactar é bastante simples.

• Se você já instalou a árvore completa do código-fonte do Android (você pode verificar minha outra resposta para obter mais informações sobre isso), entre no system/core/mkbootimg/diretório (como lembrete, o código-fonte AOSP do Google fornece apenas a ferramenta para criar o boot.imgarquivo, eles não fornecer qualquer ferramenta de desembalagem),

• Se você não precisa e não precisa disso para nenhum outro propósito, uma solução mais fácil e rápida é clonar apenas o repositório android_system_core do CyanogenMod :

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

Uma vez no diretório certo, 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/

Observe que o Google está substituindo o C mkbootimgpor uma versão Python , portanto, em versões futuras, nenhuma compilação poderá mais ser necessária para esse comando.

Você também precisará instalar as ferramentas do Android no seu computador para permitir que ele se comunique com o seu telefone. Você precisará adb(Android Debug Bridge, um utilitário de shell que permite se comunicar com o subsistema de depuração do Android), adbd(o daemon relacionado) e fastboot(um utilitário de shell que permite se comunicar com o sistema do carregador de inicialização do seu telefone).

Sua distribuição Linux favorita pode fornecê-los em pacotes únicos ou separados, mas geralmente eles são sempre chamados de "ferramentas 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

Buscar o boot.imgarquivo

Extraia o boot.img do arquivo .zip da ROM ou diretamente do dispositivo:

• No arquivo .zip da ROM de estoque: alguns aplicativos, como o SuperSU, podem modificar o boot.img diretamente no dispositivo, substituindo-o pelo estoque que quebra esses aplicativos.
• Diretamente do dispositivo: algumas pessoas relatam problemas de leitura que levam a corrompidos boot.img. Na IMO, esses problemas provavelmente estão relacionados ao uso de cabos USB ou hub USB ruins e podem ser simplesmente evitados usando cabos de boa qualidade que conectam diretamente o telefone ao computador. Você também precisa executar o ADB no modo raiz (dependendo da ROM usada, isso pode ser trivial ou não).

O primeiro método é muito óbvio: extraia o arquivo .zip com qualquer software ZIP, o boot.imgarquivo deve estar na raiz do arquivo.

Para o segundo método, primeiro você precisará determinar o caminho (infelizmente específico do dispositivo) para o dispositivo de armazenamento onde boot.imgo conteúdo pode ser recuperado. Eu conheço dois métodos para isso:

• ls /dev/block/platform/*/by-name/(onde *coberturas ainda outro nome da pasta específica do dispositivo, as chances são de que é o único diretório abaixo platform/), o nome exato para pesquisa também é dependente de plataforma, mas faz sentido usual (alguns exemplos: boot, LNX(sigla para "Linux")). Os arquivos neste diretório são na verdade links simbólicos e algumas pessoas se preocupam em ir manualmente para o destino, mas eu recomendo continuar com o caminho baseado em nomes de nível superior que, embora mais longo, continue menos propenso a erros. Então você vai acabar com um caminho como /dev/block/platform/sdhci-tegra.3/by-name/LNX.
• Em alguns dispositivos (mais antigos?), O dispositivo certo pode ser encontrado investigando a saída de cat /proc/mtd. Se você vir o dispositivo mtd2associado ao "boot"rótulo, usará o caminho /dev/mtd2.

Agora:

• No menu do desenvolvedor do telefone:
  • Ative a depuração no seu telefone,
  • Permitir acesso root ao ADB (esta etapa se aplica a telefones executando o CynogenMod, outros dispositivos podem exigir procedimentos potencialmente mais complexos),
• Conecte-o ao seu computador (e de lá ao convidado da VM, se você estiver executando ferramentas Android de dentro de uma máquina virtual).

Se isso ainda não tiver sido feito, recomendo iniciar manualmente o servidor ADB no lado do computador; isso permitirá que você valide diretamente a chave RSA no lado do dispositivo sem afetar o comportamento dos seguintes comandos do ADB:

adb start-server

Em seguida, alterne o ADB no modo raiz:

adb root

Por fim, você deve conseguir extrair o boot.imgarquivo diretamente do dispositivo usando esse comando (o caminho e os nomes de origem e destino são dados como exemplos, adaptá-los às suas necessidades e preferências):

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

O comando copiará toda a partição, o espaço usado e o espaço livre; portanto, não se surpreenda que o boot.imgarquivo resultante seja maior que o boot.imgarquivo original que acompanha o arquivo .zip da ROM de estoque, o conteúdo em si permanece semelhante.

Quando a transferência for concluída, desconecte o telefone e não se esqueça de desativar a depuração e o acesso root no menu do desenvolvedor.

Descompacte o boot.imgarquivo original

Descompacte o boot.imgarquivo em si, usando o comando compilado anteriormente:

unpackbootimg -i ./boot.img

Isso produzirá várias informações essenciais para permitir que você reconstrua um novo boot.imgcom a estrutura correta em relação ao estoque boot.img. No entanto, não se apresse em seu bloco de notas, pois o CyanogenMod upackbootimgtambém salva as mesmas informações em vários arquivos que usaremos posteriormente.

Este comando gera vários arquivos com sufixos específicos adicionados ao nome do arquivo de entrada:

• *-second: É o carregador de inicialização de segundo estágio, opcional e raramente usado em telefones de usuários finais. Se esse arquivo estiver vazio (o caso mais comum), o carregador de inicialização do telefone chamará diretamente o kernel do Linux.
• *-zImage: Este é o kernel do Linux.
• *-ramdisk.gzou *-ramdisk.lz4: o disco RAM usado para preencher o diretório raiz do dispositivo. A extensão difere dependendo do algoritmo de compactação usado.
• *-dt: A árvore do dispositivo, preenchendo /dev.
• O restante são arquivos pequenos, cada um armazenando um dos valores exibidos na unpackbootimgsaída. Esses valores definem o parâmetro da linha de comandos a ser transmitido ao kernel do Linux e os endereços onde o carregador de inicialização precisará carregar cada objeto no momento da inicialização.

Na maioria das vezes, descompacta o arquivo boot.imgpara poder editar o conteúdo do diretório raiz do telefone. Como visto acima, esse conteúdo é armazenado no arquivo *-ramdisk.gzou *-ramdisk.lz4e pode ser extraído usando os comandos abaixo:

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

Para um disco RAM compactado LZ4, substitua a última etapa por lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd.

Agora você está livre para fazer a modificação que deseja antes de continuar. No entanto, pode valer a pena seguir o procedimento completo de desempacotamento - reembalar - inicialização uma vez sem alterar nada para garantir que suas ferramentas estejam funcionando como esperado. Caso contrário, no caso de um problema, você não terá certeza se a causa é sua modificação ou alguma incompatibilidade (consulte minhas observações no início sobre alguns fabricantes que exigem procedimentos ou ferramentas não-padrão).

Reconstruir para obter o novo new-boot.imgarquivo

O processo de criação da ROM do CyanogenMod depende de uma ferramenta interna mkbootfs, para produzir o boot.imgarquivo (isso acontece em build / tools / releasetools / common.py ). No entanto, as etapas para criar essa ferramenta me parecem inutilmente complexas, enquanto o uso do sistema fornecido cpioparece funcionar tão bem. A principal diferença entre os dois, de acordo com meu entendimento após uma verificação (muito) rápida no mkbootfscódigo de fonte, parece ser que o último aplica algumas medidas de sanidade ao não incluir arquivos pontilhados e o /rootdiretório no arquivo resultante enquanto o cpioprocedimento abaixo é baseado colocará cegamente toda a árvore de diretórios selecionada no arquivo.

Conclusão: desnecessariamente complexo para compilar com muito poucas vantagens, então vamos nos ater às ferramentas fornecidas pelo sistema!

Comece criando o novo disco RAM, no ramdiskdiretório criado acima, digite:

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

Ou, se você precisar gerar um arquivo LZ4:

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

O objetivo aqui é criar um novo arquivo de disco RAM com propriedades o mais próximo possível do original (por exemplo, definir o proprietário geralmente parece estar ausente nos procedimentos compartilhados em fóruns e blogs, mas isso foi necessário no meu dispositivo).

Vá agora no diretório pai para gerar o new-boot.imgpróprio arquivo.

cd ..

Como visto acima, o unpackbootimgcomando do CyanogenMod gera um arquivo que corresponde a cada parâmetro esperado por mkbootimg. Portanto, tudo o que você precisa fazer é emitir a mkbootimg -hpara obter uma lista de todos os parâmetros e definir cada um deles com o valor apropriado usando o arquivo correspondente. Observe que alguns parâmetros esperam um caminho de arquivo, enquanto outros esperam receber o conteúdo do arquivo como valor. Veja um exemplo do comando resultante abaixo:

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

Apenas dois parâmetros não são definidos aqui:

• --board: Segundo meu entendimento, este é apenas um campo informativo que permite inserir um nome de modelo na imagem resultante.
• --id: Este não espera nenhum valor, apenas imprime um identificador exclusivo após a construção da imagem (combinando um carimbo de data e hora e uma soma de verificação).

Atualize o new-boot.imgarquivo no dispositivo

• Inicie o dispositivo no modo de inicialização rápida (também conhecido como modo do carregador de inicialização, geralmente pressionando os botões liga / desliga e aumentar volume).
• Conecte o cabo USB.

• Verifique se o dispositivo foi detectado corretamente:

  sudo fastboot devices
  

• Tente inicializar usando a nova ROM (sem piscar ainda, por isso, em caso de problema, basta reiniciar o telefone para recuperá-lo nas trilhas, substitua o ./new-boot.imgnome do arquivo pelo seu):

  sudo fastboot boot ./new-boot.img
  

• Se o telefone funcionar com êxito com a nova imagem de inicialização, volte ao modo de inicialização rápida e faça o flash permanente:

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

Conclusão

Este procedimento pode parecer assustador no começo, mas quando você o obtiver, verá que na verdade não é.

O aspecto "assustador" vem do fato de não haver um único "sistema Android": muitos fabricantes e provedores de ROM fazem alterações que podem variar de uma diferença sutil de caminho a um ambiente completamente fora do padrão.

O que você precisa fazer é determinar a postura do seu dispositivo específico e, em seguida, quais são os poucos comandos que são apropriados no seu caso. Depois de obtê-los, você pode cumpri-los e até mesmo escrevê-los com facilidade, se precisar deles com frequência.

Voluntariamente, entrei em detalhes de nível relativamente baixo algumas vezes, porque isso ajudará você a solucionar seus problemas com mais facilidade. Você usaria algum utilitário opaco "mais fácil" para criar e atualizar seu novo boot.imgarquivo e ver que seu dispositivo não pode iniciar com ele? Seria mais difícil determinar qual etapa deu errado. Aqui, em cada etapa, você poderá comparar os dados que está manipulando com os dados provenientes do boot.imgarquivo original ou com os dados vistos no telefone ou tentar, por exemplo, reconstruir o boot.imgarquivo com o original ou o recém-gerado Arquivo de disco RAM para verificar se isso faz alguma diferença (isso permite identificar se o problema é proveniente do boot.imgprocedimento de geração de arquivo em disco ou da RAM).

Use a cozinha Android. Existe uma opção para descompactar / reembalar boot.img lá, em Advanced options.