[GUIDA ]Lollipop 5.1.1, Recovery, Bootloader, Never Brick, ecc...
Premessa
Uffa, ma che titolo ha questo thread?
E' ormai parecchio tempo che non posto quasi più online per problemi di tempo e lavoro, ma quando hai in mano un telefono come questo come si fa a resistere?
...è davvero uno spettacolo di tecnologia a un prezzo incredibilmente basso...
...ed è personalizzabilissimo!
...inoltre con poche semplicissime attenzioni (vedi dopo) è praticamente IMBRICCABILE! :)
Custom Recovery
ovvero a "meno uno" dall'imbriccabilità del telefono :)
Di recovery ce ne sono davvero tante ma, di solito, mi piace compilarmela da solo...
Questa volta ho preso la TWRP e l'ho compilata dai sorgenti OmniROM seguendo queste istruzioni! :)
il risultato è una recovery TWRP 2.8.10 touch perfettamente funzionante :), che ho installato da bootloader unlocked:
codice:
mfastboot flash recovery recovery.img
Una volta avviata, fatto il backup del sistema corrente su scheda SD e copiato su PC, sono in una botte di ferro!
Qualunque cosa farò poi (escluse ovviamente le cosiddette c....77...te) potrò sempre ricominciare da qui, col telefono perfettamente funzionante!
Firmware Stock 4.4.4, bootloader e flash sicuro al 100%
Quali sono, allora, e come posso evitare errori irrecuperabili?
Dopo avere scaricato il firmware ufficiale 4.4.4 (esattamente quello che ho trovato installato nel telefono) da qui, guardo come è fatto.
ATTENZIONE: Ho scaricato ESATTAMENTE il firmware che ho nel telefono (in impostazioni -> info telefono leggo proprio KXC21.5-40), non uno quasi simile...
codice:
doc@saucy:~$ unzip RETEUALL_XT1021_4.4.4_KXC21.5-40_cid7_CFC.xml.zip
Archive: RETEUALL_XT1021_4.4.4_KXC21.5-40_cid7_CFC.xml.zip
inflating: motoboot.img
inflating: recovery.img
inflating: fsg.mbn
inflating: gpt.bin
inflating: boot.img
inflating: system.img_sparsechunk.0
inflating: system.img_sparsechunk.1
inflating: system.img_sparsechunk.2
inflating: logo.bin
inflating: NON-HLOS.bin
inflating: flashfile.xml
inflating: servicefile.xml
doc@saucy:~$
Se voglio ripristinare lo Stock firmware...
...è davvero necessario riflashare sempre tutto ogni volta?
Leggo su internet di gente disperata perchè non riesce più a fare il downgrade del bootloader o non flasha più i file motoboot.img e gpt.bin e ottiene sempre errori e tutto è perduto...
Leggo anche domande su quale bootloader serve per Lollipop e quale bootloader, invece, per Kitkat... e via discorrendo...
Avendo, per fortuna, buona conoscenza di Linux, Android, Compilazione, custom ROM, kernel ecc..., tutte le volte che installo una ROM non ufficiale, vedo che cambiano solo queste due partizioni:
...stessa cosa ogni volta che faccio un restore da Recovery...
...è evidente, quindi, che, se limito la mia attività pseudo distruttiva a Custom ROM, Modding e robe simili... potrò sempre recuperare i danni fatti, qualunque essi siano...
...e senza mai bisogno di toccare motoboot.img e/o gpt.bin...
N.B. Se un aggiornamento ufficiale me li cambia... terrò semplicemente quelli...
Nel caso però che io voglia provare un custom Lollipop, partendo da un bootloader KitKat, non ci saranno affatto problemi e non sarà necessario aggiornare ufficialmente nulla prima di farlo :):
infatti il Kernel di Kitkat e il Kernel di Lollilop hanno lo stesso punto di inizio in memoria: non entro nei dettagli della cosa, ma, accendendo il telefonino, dopo che il bootloader (motoboot + gpt.bin) ha fatto la sua parte, si limita a caricare in memoria il contenuto della partizione boot.img per farlo partire da un punto prestabilito... ma cosa c'è lì dentro non è un problema suo... è evidente che Lollipop o KitKat o JellyBean allora andranno - di fatto - bene uguale: partono tutti dallo stesso identico punto.
Ogni custom ROM, in definitiva, ha un boot.img e un system.img propri... e tutto il resto non conta veramente... ...basta che la ROM sia del telefono giusto però...
Gpt.bin
Tecnicamente questa non è una partizione come le altre, ma una "tavola di partizioni" di tipo nuovo (GUID Partition Table), trovata negli ultimi PC con tecnologia UEFI e simili e anche nel Moto E...
Cosa contiene?
se in linux uso il comando gdisk, ottengo:
codice:
doc@saucy:~$ gdisk -l gpt.bin
GPT fdisk (gdisk) version 0.8.8
[...]
Number Start (sector) End (sector) Size Code Name
1 256 131327 64.0 MiB 0700 modem
2 131328 132351 512.0 KiB FFFF sbl1
[...]
17 155648 158719 1.5 MiB FFFF modemst1
18 158720 161791 1.5 MiB FFFF modemst2
[...]
30 207616 208639 512.0 KiB FFFF misc
31 208640 229039 10.0 MiB FFFF boot
32 229040 249599 10.0 MiB FFFF recovery
33 249600 1179647 454.1 MiB 0700 cache
34 1179648 3014655 896.0 MiB 0700 system
35 3014656 3031039 8.0 MiB FFFF kpan
36 3031040 3031039 0 bytes 0700 userdata
doc@saucy:~$
...36 partizioni dentro al telefono in fondo sono un bel pò di partizioni...quando a me ne bastano tre (boot, recovery, system) per divertirmi...
Occasionalmente una Stock ROM potrà riscrivere questa tabella (gpt.bin) magari per dare un pò più spazio a system o data e viceversa e, in generale, ridimensionare le partizioni interne del telefono... come fosse una specie di Hard Disk insomma...
...se, però, io sto attento a scrivere in system qualunque cosa più piccola di 896Mb e in boot qualunque cosa più piccola di 10Mb...
...allora posso metterci quello che voglio che, nel peggiore dei casi, semplicemente non funzionerà ma non briccherà mai nulla...
Riassumendo: non ho nessun vero motivo per flashare motoboot.img e gpt.bin, se non per autoaggiornamenti OTA del firmware originale... chi me lo fa fare, allora, di cambiarli (rischiando bricks) se non ce n'è veramente bisogno?
Lollipop 5.1.1 a razzo
Forte di quanto appena detto, ho compilato dai sorgenti l'ultima versione di Cyanogenmod: la 12.1, cioè Lollilop 5.1.1...
...e l'ho installata da Recovery TWRP 2.8.10 senza toccare motoboot.img e gpt.bin del Kitkat originale...
Questo è il risultato:
N.B. La prima compilazione di Lollipop mi ha, in realtà, un pò deluso:
...molto lento il primo boot (quasi 8 minuti)...
...prestazioni piuttosto scadenti...
...bordo rosso occasionalmente lampeggiante...
Ho aggiunto allora una modifica a BoardConfig.mk per migliorarne le prestazioni:
codice:
WITH_DEXPREOPT := true
DONT_DEXPREOPT_PREBUILTS := true
...e una a system.prop per risolvere il problema del Red Border:
codice:
persist.sys.strictmode.visual=0
persist.sys.strictmode.disable=1
...ho ricompilato, e...
...hei, wow...
DAVVERO IMPRESSIONANTE!
...lo zip installabile da Recovery si trova qui.
...e come al solito i passaggi obbligatori per installare una Custom ROM da recovery sono sempre gli stessi:
- Factory reset,
- Install zip file,
- wipe cache and dalvik,
- reboot!
Google apps
Infine, non voglio certo farmi mancare nulla, quindi da qui ho preso una versione stringatissima (zero) delle Google Apps, installate anche loro da recovery.
Gli anglosassoni direbbero:
working like a charm!
N.B. Ho finito; nel mio Google Drive c'è proprio tutto quello di cui ho appena discusso.
Marshmallow e Xposed Framework...
Marshmallow 6.0.1
e Xposed Modding...
perchè no?
Cosa provo oggi? ...giusto per mettere a dura prova ancora una volta l'imbriccabilità di questo smartphone...
1
Prima di tutto entro in recovery e faccio un backup del sistema installato...
2
Poi - visto che sto per sostituirlo completamente - faccio un Factory reset sempre da recovery...
3
...e ci installo sopra Marshmallow 6.0.1 scaricato a partire da qui:
è una versione decisamente base senza fronzoli e nessuna app extra...
...come piacciono a me insomma...
!Un missile supersonico! :cool:
4
La uso un po', giusto per verificare che tutto fuzioni a dovere...
e tutto funziona a dovere!
5
Poi ci installo SuperSU scaricato da qui:
6
...le OpenGapps versione pico (le più piccole in assoluto!) prese da qui:
7
Installo tutto da recovery, factory reset (anche se probabilmente non serve...) e:
WOW! che spettacolo di firmware!!!
8
...e giusto perchè alla fine rimane davvero un bel po' di spazio libero nell'area di sistema ci aggiungo anche circa 300Mb di applicazioni che uso più o meno quotidianamente... :cool:
...sempre da recovery chiaramente...
9
Non contento, nonostante io sia sempre a favore di ROM Custom - possibimente compilate direttamente da me stesso - questa volta scarico il famosissimo Modding Xposed framework da qui:
...versione V82 SDK23 unitamente all'app Xposed Installer...
10
Lo installo da recovery e reboot...
...cross fingers...
Il firmware impiega alcuni minuti a riottimizzare tutte le app poi parte normalmente...
11
Non ho mai usato prima d'ora questo modding quindi adesso proseguo un po' a braccio e ne installo - giusto per testarlo - un modulo a caso:
e personalizzo un pò, ad esempio, la barra di stato e applicazioni extra nella schermata di sblocco:
5,1 motivi per cui oggi continuo ad usare Lollipop :)
Ho provato Marshmallow per un po', sia la Cyanogenmod 13.0 che la AOSP 6.0 sviluppata un po' dalla community Code Aurora Forum e da Shubhmg e la trovo una ROM davvero impressionante in quanto a migliorie - diciamo così - sotto il cofano e prestazioni generali, ma è ancora rilasciata in modalità Nightly, cioè è un firmware facilmente instabile, con bug non ancora risolti o appena introdotti da nuove features sperimentali, ecc... e quindi si può tranquillamente definire poco affidabile per l'uso quotidiano...
...è anche il motivo per cui ogni notte (nightly) ne viene compilata una versione più aggiornata... più aggiornata rispetto a quella appena compilata il giorno precedente...
Ora il Marshmallow che ho provato in questi giorni gira già splendidamente e con davvero pochi problemi evidenti o meno...
...e con nuove funzioni davvero fantastiche, come ad esempio l'Adoptable Storage... che con molta nostalgia, tra l'altro, mi ricorda un hack che ho usato cinque anni fa per il Samsung Galaxy Next e di cui ne ho parlato proprio su questo forum... :cool:
...tuttavia per l'uso quotidiano preferisco ancora non correre rischi...
...e inoltre è davvero incredibile quanta roba si riesce ad aggiungere a Lollipop nell'area di sistema...
Visto che parlo di uso quotidiano, questa volta preparo la Cyanogenmod 12.1 (Lollipop 5.1.1) aggiornata al 23 aprile ma compilata in maniera un po' più conservativa del solito:
...settando il buildtype a user invece che userdebug
Cos'è il buildtype? ecco un estratto delle istruzioni preso dal sito ufficiale AOSP
codice:
[...]
The BUILDTYPE is one of the following:
- user limited access; suited for production
- userdebug like "user" but with root access and debuggability; preferred for debugging
- eng development configuration with additional debugging tools
For more information ...
In definitiva compilo un firmware senza root (tanto installerò successivamente SuperSU :)) ma, soprattutto, senza parecchie informazioni di debug dentro le app e senza log di debug che, anche se poco poco, rallentano il sistema... :cool:
In fondo non userò questo firmware per sviluppare o per debug, e quindi cercherò di avere un sistema che occupa il minor spazio possibile sul telefono...
In questo caso aggiungo allora alle opzioni di compilazione questo flag:
codice:
PRODUCT_LOCALES := it_IT en_US
che mi elimina tutte le localizzazioni tranne l'Italiana (la mia lingua) e l'Inglese americano (obbligatorio per il corretto funzionamento di alcune parti del sistema).
Così facendo ottengo un sistema che occupa davvero poco spazio...
Successivamente all'installazione del firmware da recovery, elimino anche le seguenti applicazioni extra (ne uso altre simili prese dal market):
codice:
Browser,
Calculator,
CMFilemanager,
CMWallpapers e LiveWallpapers,
Camera2,
Email e Exchange2
installo le Open Gapps pico, giusto per avere accesso al Play store, SuperSU per i diritti di root e, infine, ci aggiungo tutte queste applicazioni (le uso spessissimo :)):
codice:
Android Firewall Link2SD Shazam
Colornote Maps Sql Editor
Dropbox My Wind Tapatalk
Drweb Open Camera Titanium Backup
Firefox Orario Treni Touch Down
Google Drive Paypal Translate
Hexeditor Postepay Whatsapp
Il meteo Rassegna Stampa Youtube
Jota plus Editor Real Calc
K9 Mail Root Explorer
easy play :cool:
Giusto una nota su come installo una singola app nell'area di sistema di Lollipop, risparmiando il maggior spazio possibile (Argomento purtroppo molto tecnico)...
Passando da KitKat a Lollipop Android ha smesso di mettere tutte le app insieme nella cartellina
e le librerie per farle funzionare, se presenti, nella cartellina
mescolandole tutte insieme... :(
...e ha cominciato a dividerle in singole cartelline, inserendoci sia l'app che le librerie... ad esempio l'app Whatsapp risulta memorizzata così:
codice:
/system/app/Whatsapp
├── lib
│ └── arm
│ ├── libcurve25519.so
│ ├── libresample.so
│ ├── libvlc.so
│ └── libwhatsapp.so
└── Whatsapp.apk
Questo schema rende, di fatto, molto facile installare qualunque app nell'area di sistema... è sufficente estrarre dal file .apk (è tecnicamente solo un file .zip) le librerie e ricostruire in /system/app lo schema sopra evidenziato avendo cura di dare alle directory i permessi di scrittura ed esecuzione standard:
codice:
root@condor_umts:/system/app # ll | grep Whatsapp
drwxr-xr-x root root 2016-04-23 18:06 Whatsapp
e ai file i permessi di lettura standard:
codice:
root@condor_umts:/system/app # ll Whatsapp/ | grep Whatsapp
-rw-r--r-- root root 23556008 2008-08-01 14:00 Whatsapp.apk
e assegnare ad entrambi l'utente root:root...
Tutto qui?
In Marshmallow per adesso sì...
In Lollipop, invece, riesco ancora a fare qualcosa :cool:...
Vediamo cosa succede se installo, per esempio Skype for Business sul telefonino:
l'app (il file .apk) pesa un sacco di Megabytes... da pc vedo:
codice:
doc@bilbo $ ls -hl Skypeforbusiness.apk
-rw-r--r--. 1 doc doc 31M 25 apr 15.07 Skypeforbusiness.apk
l'app pesa ben 31Mb... :(
e, una volta installata dal Play Store pesa ancora di più:
codice:
root@condor_umts:/ # du -h -s /data/app/com.microsoft.office.lync15-1
64M com.microsoft.office.lync15-1
PIU' DEL DOPPIO!
se la metto così in /system funziona ma mi sono giocato 64 Mb di spazio... :(
Vediamo allora cosa contiene l'area dati dell'applicazione:
codice:
com.microsoft.office.lync15-1
├── base.apk
└── lib
└── arm
├── libacomo.so
├── libBreakpadLibrary.so
└── libCpuFeatures.so
giusto il file .apk e tre librerie...
...librerie estratte proprio dal file .apk...
hmm...
Quote:
Apro una parentesi su come funzionano i
controlli di integrità delle app in Android:
perchè, giustamente, se modifico in maniera fraudolenta un'app... Android se ne accorge e mi dice che ho fatto il furbo...e, sempre giustamente, l'applicazione smette di funzionare...
...
root o
non root che dirsi voglia...
Adesso controllo allora l'integrità di questa app:
codice:
doc@bilbo $ jarsigner -verify Skypeforbusiness.apk
jar verified.
[...]
poi provo
semplicemente a rimuovere dal file
.zip le librerie (non le modifico ma le elimino soltanto):
codice:
doc@bilbo $ zip -d Skypeforbusiness.apk "lib/*"
deleting: lib/armeabi/libacomo.so
deleting: lib/armeabi/libBreakpadLibrary.so
deleting: lib/armeabi/libCpuFeatures.so
e rieseguo il controllo di integrità:
codice:
doc@bilbo $ jarsigner -verify Skypeforbusiness.apk
jar verified.
[...]
Wow, eliminare contenuti dall'apk non ne invalida l'integrità :)
in effetti l'app controllerà comunque l'integrità delle librerie estratte durante l'installazione ad ogni esecuzione successiva... ma quelle librerie sono già nel sistema o in userdata...e Android controlla quelle (da usare) piuttosto che quelle contenute nel file apk...
...quindi potrei limitarmi a sovrascrivere - ma solo dopo l'installazione - il file
.apk contenente le librerie con quello da cui le ho tolte...
Cosa cambia?
codice:
doc@bilbo $ ls -h -l Skypeforbusiness.apk
-rw-r--r--. 1 doc doc 19M 25 apr 15.40 Skypeforbusiness.apk
...beh... in questo caso l'app pesa 15Mb in meno... :cool:
...ed è sempre valida... non l'no modificata affatto nei suoi contenuti...
Se adesso faccio questi passaggi creando una cartellina in /system, mettendoci l'apk ridotto (shrinked), le librerie e settando i permessi giusti dei files...
...al reboot successivo ecco l'app perfettamente funzionante nel launcher... e scritta nell'area di sistema :)
Ripetendo, infine, questi passaggi per tutte, o quasi, le app che metto in /system, ecco scoperto come faccio a mettercene così tante...
:cool: