Selezione degli strumenti
Il metodo che presento qui si basa sul codice sorgente Android di CyanogenMod.
Mentre AOSP di Google fornisce solo lo strumento per creare il boot.img
file, CyanogenMod aggiunge anche lo unpackbootimg
strumento che consente di decomprimerlo . Questo strumento non sembra progettato specificatamente per CyanogenMod in alcun modo, quindi la maggior parte delle probabilità è che funzioni anche con altre ROM.
Esistono, tuttavia, un numero relativamente elevato di alternative per decomprimere il boot.img
file che funzionano tutte più o meno allo stesso modo.
Fondamentalmente, tale strumento di decompressione estrarrà il contenuto del boot.img
file e visualizzerà una serie di parametri che dovrete passare allo mkbootimg
strumento di Google per creare un file la cui configurazione (principalmente parametri del kernel e indirizzi di memoria) corrisponderà a quella originale.
Ecco alcuni esempi, non li ho testati personalmente, quindi non posso consigliarne nessuno e li presento solo a scopo di riferimento:
Tutti questi strumenti (e altri che potresti trovare con qualsiasi motore di ricerca) dovrebbero funzionare allo stesso modo, ma alcuni potrebbero funzionare meglio di altri nella gestione di alcuni casi particolari che potresti incontrare con il tuo dispositivo. La maggior parte di essi, tuttavia, almeno nell'arena open source, non sembra essere mantenuta regolarmente, quindi la migliore scommessa secondo me per avere strumenti funzionanti, mantenuti e documentati è quella di andare con quelli di CyanogenMod.
Alcuni produttori producono ROM più o meno lontane dallo standard AOSP (indirizzi insoliti, intestazioni, formato file, ecc.). Se la procedura standard di seguito non funziona, forse uno di questi software alternativi potrebbe fare il trucco. Altrimenti, dovrai verificare la presenza di problemi specifici per il tuo dispositivo: alcuni sembrano aver bisogno di una procedura specifica o persino di strumenti specifici (conferisci questa domanda relativa ai dispositivi MediaTek, ad esempio).
Installazione degli strumenti
La compilazione del set di strumenti CyanogenMod per l' boot.img
imballaggio e il disimballaggio è abbastanza semplice.
- Se hai già installato l'albero completo del codice sorgente Android (puoi controllare la mia altra risposta per ottenere maggiori informazioni a riguardo), vai nella
system/core/mkbootimg/
directory (come promemoria, il codice sorgente AOSP di Google fornisce solo lo strumento per creare il boot.img
file, non fornire qualsiasi strumento di disimballaggio),
Se non hai e non hai bisogno di questo per nessun altro scopo, una soluzione più semplice e veloce è quella di clonare solo il repository android_system_core di CyanogenMod :
git clone https://github.com/CyanogenMod/android_system_core.git
cd android_system_core/mkbootimg/
Una volta nella directory giusta, compila e installa:
gcc -o ./mkbootimg -I ../include ../libmincrypt/*.c ./mkbootimg.c
gcc -o ./unpackbootimg -I ../include ../libmincrypt/*.c ./unpackbootimg.c
sudo cp ./mkbootimg ./unpackbootimg /usr/bin/
Nota che Google sta sostituendo la C mkbootimg
con una versione di Python , quindi nelle versioni future non sarà più necessaria alcuna compilazione per questo comando.
Sarà inoltre necessario installare strumenti Android sul computer per consentire la comunicazione con il telefono. Avrai bisogno di adb
(Android Debug Bridge, un'utilità di shell che consente di comunicare con il sottosistema di debug di Android), adbd
(il demone correlato) e fastboot
(un'utilità di shell che consente di comunicare con il sistema di bootloader del telefono).
La tua distribuzione Linux preferita può fornirli in pacchetti singoli o separati, ma di solito sono sempre chiamati "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
Recupera il boot.img
file
Estrarre il file boot.img dal file .zip della ROM o direttamente dal dispositivo:
- Dal file .zip della ROM di serie: alcune applicazioni come SuperSU possono modificare il file boot.img direttamente sul dispositivo, sostituendolo con quello di serie si rompono tali applicazioni.
- Direttamente dal dispositivo: alcune persone segnalano problemi di lettura che portano a danneggiati
boot.img
. IMO, questi problemi sono molto probabilmente legati all'uso di cavi USB o hub USB scadenti e possono essere semplicemente evitati utilizzando cavi di buona qualità che collegano direttamente il telefono al computer. È inoltre necessario eseguire ADB in modalità root (a seconda della ROM utilizzata, potrebbe essere banale o meno).
Il primo metodo è molto ovvio: estrarre il file .zip con qualsiasi software ZIP, il boot.img
file dovrebbe essere proprio lì alla radice dell'archivio.
Per il secondo metodo, dovrai prima determinare il percorso (purtroppo specifico del dispositivo) verso il dispositivo di archiviazione in cui boot.img
è possibile recuperare il contenuto. Conosco due metodi per questo:
ls /dev/block/platform/*/by-name/
(dove *
le coperture ancora un altro nome della cartella specifica del dispositivo, è probabile che sia l'unica directory sotto platform/
), il nome esatto di ricerca è anche dipendente dalla piattaforma, ma rende senso comune (alcuni esempi: boot
, LNX
(acronimo di "Linux")). I file in questa directory sono in realtà collegamenti simbolici e alcune persone si preoccupano di andare manualmente alla destinazione, ma consiglio di attenersi al percorso basato sul nome di livello superiore che, sebbene più lungo, rimane meno soggetto a errori. Quindi finirai con un percorso simile /dev/block/platform/sdhci-tegra.3/by-name/LNX
.
- Su alcuni dispositivi (più vecchi?), È possibile trovare il dispositivo giusto esaminando l'output di
cat /proc/mtd
. Se vedi il dispositivo mtd2
associato "boot"
all'etichetta, utilizzerai il percorso /dev/mtd2
.
Adesso:
- Dal menu sviluppatore del telefono:
- Abilita il debug sul telefono,
- Consenti accesso root ad ADB (questo passaggio si applica ai telefoni che eseguono CynogenMod, altri dispositivi potrebbero richiedere procedure potenzialmente più complesse),
- Collegalo al tuo computer (e da lì al guest VM se stai eseguendo strumenti Android da una macchina virtuale).
Se ciò non è già stato fatto, ti consiglio di avviare manualmente il server ADB sul lato del computer, questo ti permetterà di validare direttamente la chiave RSA sul lato del dispositivo senza influenzare il comportamento dei seguenti comandi ADB:
adb start-server
Quindi cambia ADB in modalità root:
adb root
Infine, dovresti essere in grado di estrarre direttamente il boot.img
file dal dispositivo utilizzando tale comando (il percorso e i nomi di origine e destinazione sono indicati come esempi, adattali alle tue esigenze e preferenze):
adb pull /dev/block/platform/sdhci-tegra.3/by-name/LNX ./boot.img
Il comando copierà l'intera partizione, sia quella utilizzata che quella libera, quindi non sorprenderti se il boot.img
file risultante sarà più grande del boot.img
file originale fornito con il file .zip della ROM di scorta, il contenuto stesso rimarrà simile.
Una volta terminato il trasferimento, scollegare il telefono e non dimenticare di disabilitare sia il debug sia l'accesso root dal menu dello sviluppatore.
Decomprimi il boot.img
file originale
Decomprimere il boot.img
file stesso utilizzando il comando compilato in precedenza:
unpackbootimg -i ./boot.img
Questo produrrà diverse informazioni essenziali per permetterti di ricostruire un nuovo boot.img
con la struttura corretta rispetto allo stock boot.img
. Tuttavia, non affrettarti sul tuo blocco note poiché CyanogenMod's upackbootimg
salva anche le stesse informazioni in diversi file che useremo in seguito.
Questo comando genera diversi file con suffissi particolari aggiunti al nome del file di input:
*-second
: Si tratta del bootloader di secondo livello, opzionale e raramente utilizzato sui telefoni degli utenti finali. Se questo file è vuoto (il caso più comune), il bootloader del telefono chiamerà direttamente il kernel Linux.
*-zImage
: Questo è il kernel Linux.
*-ramdisk.gz
oppure *-ramdisk.lz4
: il disco RAM utilizzato per popolare la directory principale del dispositivo. L'estensione varia in base all'algoritmo di compressione utilizzato.
*-dt
: L'albero dei dispositivi, popolato /dev
.
- Il resto sono piccoli file che contengono ciascuno dei valori visualizzati in
unpackbootimg
output. Questi valori definiscono il parametro della riga di comando da passare al kernel Linux e gli indirizzi in cui il bootloader dovrà caricare ciascun oggetto all'avvio.
Molto spesso, si decomprime il file boot.img
per essere in grado di modificare il contenuto della directory principale del telefono. Come visto sopra, questo contenuto è archiviato nel file *-ramdisk.gz
o *-ramdisk.lz4
e può essere estratto usando i comandi seguenti:
mkdir ./ramdisk
cd ./ramdisk/
gzip -dc ../boot.img-ramdisk.gz | cpio -imd
Per un disco RAM compresso LZ4, sostituire l'ultimo passaggio con lz4 -d ../boot.img-ramdisk.lz4 | cpio -imd
.
Ora sei libero di fare la modifica che desideri prima di procedere. Tuttavia, potrebbe valere la pena seguire una volta la procedura completa di decompressione - reimballaggio - avvio senza modificare nulla per garantire che gli strumenti funzionino come previsto. Altrimenti, in caso di problemi, non sarai certo se la causa sia la tua modifica o una certa incompatibilità (vedi le mie osservazioni all'inizio su alcuni produttori che richiedono procedure o strumenti non standard).
Ricostruisci per ottenere il nuovo new-boot.img
file
Il processo di creazione della ROM CyanogenMod si basa su uno strumento interno mkbootfs
, per produrre il boot.img
file (ciò accade in build / tools / releasetools / common.py ). Tuttavia, i passaggi per creare questo strumento mi sembrano inutilmente complessi, mentre l'utilizzo del sistema fornito cpio
sembra funzionare altrettanto bene. La differenza principale tra i due, secondo la mia comprensione dopo un (molto) rapido controllo nel mkbootfs
codice Souce, sembra che quest'ultimo applichi alcune misure di integrità non includendo i file punteggiati e la /root
directory nell'archivio risultante mentre la cpio
procedura basata di seguito inserirà ciecamente l'intero albero di directory selezionato nell'archivio.
Conclusione: compilazione inutilmente complessa con pochissimi vantaggi, quindi atteniamoci agli strumenti forniti dal sistema!
Inizia creando il nuovo disco RAM, dalla ramdisk
directory creata sopra, digita:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Oppure, se è necessario generare un archivio LZ4:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | lz4 > ../new-boot.img-ramdisk.lz4
L'obiettivo qui è quello di creare un nuovo file del disco RAM con proprietà il più vicino possibile a quello originale (ad esempio, l'impostazione del proprietario sembra spesso mancare nelle procedure condivise nei forum e nei blog, tuttavia questo era richiesto sul mio dispositivo).
Vai ora nella directory principale per generare il new-boot.img
file stesso.
cd ..
Come visto sopra, il unpackbootimg
comando di CyanogenMod genera un file corrispondente a ciascun parametro previsto da mkbootimg
. Pertanto, è sufficiente emettere un mkbootimg -h
per ottenere un elenco di tutti i parametri, quindi impostare ognuno di essi sul valore appropriato utilizzando il file corrispondente. Si noti che alcuni parametri prevedono un percorso di file mentre altri prevedono di ricevere il contenuto del file come valore. Vedi un esempio del comando risultante di seguito:
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
Qui non sono impostati solo due parametri:
--board
: Secondo la mia comprensione, questo è solo un campo informativo che consente di inserire un nome di modello nell'immagine risultante.
--id
: Questo non prevede alcun valore, stampa solo un identificatore univoco dopo che l'immagine è stata creata (combinando un timestamp e un checksum).
Flash il new-boot.img
file sul dispositivo
- Avvia il dispositivo in modalità avvio rapido (ovvero modalità bootloader, in genere tenendo premuti i pulsanti di accensione e volume).
- Collegare il cavo USB
Verificare che il dispositivo sia stato rilevato correttamente:
sudo fastboot devices
Prova ad avviare utilizzando la nuova ROM (senza ancora eseguirne il flashing, quindi in caso di problemi devi solo riavviare il telefono per ripristinarlo, sostituisci il ./new-boot.img
nome del file con il tuo):
sudo fastboot boot ./new-boot.img
Se il telefono funziona correttamente con la nuova immagine di avvio, torna in modalità di avvio rapido e flash in modo permanente:
sudo fastboot flash boot ./new-boot.img
sudo fastboot reboot
Conclusione
All'inizio questa procedura può sembrare scoraggiante, ma una volta che lo capirai, vedrai che in realtà non lo è.
L'aspetto "scoraggiante" deriva dal fatto che non esiste un unico "sistema Android": molti produttori e fornitori di ROM apportano modifiche che possono variare da una sottile differenza di percorso a un ambiente completamente non standard.
Quello che devi fare è determinare la postura del tuo dispositivo particolare, e quindi quali sono i pochi comandi appropriati nel tuo caso. Una volta ottenuti, puoi attenerti a loro e persino copiarli facilmente se ne hai bisogno spesso.
Sono entrato volontariamente in dettagli di livello relativamente basso a volte perché ti consentirà di risolvere i problemi più facilmente. Utilizzeresti un'utilità opaca "più semplice" per creare e eseguire il flashing del tuo nuovo boot.img
file e vedere che il tuo dispositivo non può iniziare con esso, sarebbe più difficile per te determinare quale passo è andato storto. Qui, ad ogni passaggio, sarai in grado di confrontare i dati che stai manipolando con i dati provenienti dal boot.img
file originale o i dati visti sul telefono, o provare ad esempio a ricostruire il boot.img
file con l'originale o il nuovo generato File del disco RAM per verificare se ciò fa alcuna differenza (ciò consente di individuare se il problema deriva dalla boot.img
procedura di generazione del file del disco RAM o).