Guida alla realizzazione di Custom Roms (I parte)

Tutte le recensioni delle console e le guide frutto del lavoro della community
Post Reply
paulvern
Cavaliere OC.it
Cavaliere OC.it
Posts: 268
Joined: 21 Sep 2011, 11:50

Guida alla realizzazione di Custom Roms (I parte)

Post by paulvern »

Visto che il nuovo numero della rivista langue un po', d'accordo con l'admin, ho deciso di pubblicare qui la prima parte della mia guida sulla realizzazione delle Custom Roms per Android. Spero di vedere presto nuove roms! Qui pubblico la guida facendo un copia e incolla. Per una lettura più agevole, la si può scaricare anche qui: https://docs.google.com/document/d/1RGD ... EMpCw/edit

Iniziamo con questa puntata un mini corso sulla realizzazione di custom rom per Android. In questa prima puntata parleremo di:

- Cosa è una custom rom?
- Perchè realizzare una custom rom?
- Cosa si può fare con una custom rom?
- Cosa serve per realizzare una custom rom?
- Modificare le app inserite di default
- Modificare build.prop
- Signare la custom rom
- Testare la custom rom

Rispondiamo innanzitutto alla prima domanda: cos'è una custom rom?
Tutti i telefoni cellulari e tutti i dispositivi elettronici di ultima generazione (tablet, console, navigatori) sono dotati di un sistema operativo che viene caricato ogni volta che il dispositivo è acceso dall'utenet. Il sistema operativo può essere proprietario (cioè sviluppato direttamente dal venditore) o sviluppato da terzi o open. Tra i sistemi operativi proprietari probabilmente uno dei più famosi è Symbian sviluppato dalla Nokia. Tra i sistemi sviluppati da terzi ma utilizzati da molti costruttori possiamo ricordare Windows Ce, Windows Mobile (sviluppati da Microsoft) e Android (sviluppato da Google). Tra i sistemi open ricordiamo sicuramente le varie implementazioni di Linux.
Poiché sarebbe abbastanza scomodo e poco sicuro (oltre che costoso) dotare un telefono cellulare (o un navigatore) di un hard disk sul quale è memorizzato il sistema operativo, di norma i produttori usano memorie flash (ROM riscrivibili dal sistema stesso, ma non volatili) nel quale l'intero sistema operativo è precaricato di fabbrica. I dati contenuti in tale rom (dati che possono essere anche parecchio corposi) costituiscono la rom originale del sistema operativo. Ogni modifica a tale rom e il successivo processo di reflashing (con il quale si riscrive la memoria flash del dispositivo) determinano la realizzazione di una custom rom.
Quindi in pratica la realizzazione di una custom rom prevede la possibilità di disporre di una rom originale, la competenza per modificarla e la conoscenza delle modalità per flasharla sul dispositivo da modificare.

Ma a questo punto sorge spontanea la seconda domanda: perchè realizzare una custom rom?
La domanda può sembrare banale ma è anche vero che nella maggior parte dei casi non occorre realizzare una custom rom per aggiungere funzionalità al proprio dispositivo. Spesso ci piacerebbe cambiare semplicemente le icone che visualizziamo sul dispositivo, o inserire nuove suonerie o rimuovere degli applicativi che non ci interessano e che ci danno fastidio.
Tutte queste operazioni in genere non richiedono una modifica significativa della rom e sono piuttosto semplici anche senza correre il rischio di modificare la ROM originale. Perchè, dobbiamo ricordarlo, ogni modifica della rom originale porta inevitabilmente a una modifica significativa del nostro apparecchio elettronico che ne fa subito invalidare la garanzia. Pertanto prima di imbarcarsi nella realizzazione di una custom rom per l'ultimo telefono da 600 euro e trovarselo poi bloccato per un qualche errore commesso, è meglio sapere bene cosa fare e come rimediare eventuali danni. In questa guida vedremo nel dettaglio come realizzare custom rom per le ultime console da gioco della JXD per due motivi molto semplici: le console in questione costano poco e rovinarle è molto difficile.
Oltre a questi due innegabili vantaggi c'è quello non da poco che il sistema operativo su cui si basano è Android (che pur essendo proprietà di Google è molto simile a Linux e facilmente modificabile) e sono veramente scarsamente ottimizzate da parte della casa madre.

Cosa si può fare con una custom rom?
Dipende. Su un telefono in genere non si riesce ad avere un'esperienza radicalmente diversa. Normalmente ci si concentra sulla rimozione di applicativi inutili e la personalizzazione degli sfondi e dei loghi. Su console come quelle di JXD si possono ottenere vantaggi molto significativi come l'overclock da 600 MHz a 1 GHz e oltre. Alcune rom per sistemi non open prevedono la possibilità di lanciare applicativi che altrimenti non funzionano (è il caso per esempio di alcuni telefoni Samsung o Nokia e della possibilità di lanciare midlet Java non firmati). Una delle modifiche più semplici e comuni su Android è la modifica del nome con cui il dispositivo è riconosciuto dal Google Market. Il Market filtra i risultati basandosi sulla supposta compatibilità di una app con un dispositivo o meno. Cambiando il nome del nostro dispositivo potremmo aggirare questo blocco e quanto meno testare la app in questione (l'eliminazione del blocco non elimina anche l'incompatibilità che spesso è reale). In generale i sistemi open sono molto più customizzabili di quelli proprietari per la disponibilità di documentazione maggiore e perché disponibili su un vastissimo numero di dispositivi.

Cosa serve per realizzare una custom rom?
Tempo, pazienza e una certa dose di predisposizione per il rischio oltre che a una serie molto limitata di strumenti software che ci possono aiutare nel processo. Il rischio è evidente. Se producete una rom che ha qualche problema nel migliore dei casi il vostro dispositivo non partirà più e dovrete riflashare la rom originale. Nel peggiore dei casi l'avrete brickato, cioè reso del tutto inservibile. E' fondamentale sapere se il proprio dispositivo è facilmente brickabile o non lo è. Il rischio di brickare un telefono da 600 euro per inserire una app nuova è troppo elevato per essere praticabile. Meglio affidarsi in questi casi a custom rom già testate o leggere bene nei forum sparsi per il web quale è la procedura (se esiste) per debrickare il telefono nel caso non parta più. In generale si bricka un dispositivo se la rom sovrascrive (in modo errato) il programma che viene eseguito all'avvio per caricare il sistema operativo vero e proprio. Le console della JXD sono praticamente non brickabili perché non è possibile allo stato attuale sovrascrivere il programma che permette di riflashare la ROM originale in caso di errore pertanto è estremamente comodo fare test su queste. Il tempo e la pazienza sono altre due doti fondamentali. Se pensate che la vostra prima custom rom funzioni senza problema siete molto illusi o molto fortunati. Bisogna fare poche modifiche all'inizio e tanti tentavi sempre. Con il tempo si capisce quali sono i punti più critici e gli errori spariscono o si riducono.
Da questo punto in poi ci occuperemo della customizzazione delle ROM della JXD (il processo è abbastanza simile per tutte le ROM Android).
Sul fronte software in un primo momento ci serve ben poco: un programma di compressione/decompressione (per esempio l'ottimo e gratuito 7zip (http://www.7-zip.org/), o ancora meglio il file manager Total Commander (http://www.ghisler.com/) che ci permette di lavorare direttamente dentro agli archivi) e un programma Java per firmare la nostra ROM. La firma è importante perché la rom viene verificata durante il caricamento sulla console. Senza firma il processo di reflashing non procede (il programma più semplice per la firma è signer.jar (potete scaricarlo da quì: http://bit.ly/LUEAh0).
Vediamo nel dettaglio da cosa è costituita la rom di una JXD, per esempio quella della JXD S601.
Quando eseguite l’update dovete copiare sulla scheda SD una serie di files:
- update.zip (la rom vera e propria zippata)
- uimage (è la parte del sistema operativo che si occupa del boot. Si può modificare ma lo vedremo in una prossima puntata)
- uimage_recovery (è la parte del sistema operativo che si occupa del boot se qualcosa è andato storto. Meglio non modificarla mai così saremo sempre in grado di riavere una console funzionante se la rom modificata non funziona
- factory_update_param.aml (è uno script che ‘spiega’ alla console cosa fare durante l’update; visto che le operazioni sono davvero poche lasciamolo stare)

Concentriamoci a questo punto su update.zip, la parte più importante e modificabile dell’intera ROM. L’archivio contiene tutti i files che andremo a flashare nella nuova ROM e che costituiranno di fatto il nuovo sistema operativo. Dimentichiamo fin da subito di poter usare parti di rom non studiate per il dispositivo che dobbiamo aggiornare. Non possiamo flashare una rom di Android 4.0 presa da un cellulare Samsung su una JXD S601. Le modifiche sono troppo sostanziali per funzionare e in generale richiedono l’intervento dello sviluppatore originale. Pertanto possiamo modificare tutto quello che vogliamo ma rimarremo sempre all’interno della stessa versione di Android (nel caso della S601 per ora è la versione 2.3, anche se è possibile che in futuro sia aggiornata dalla JXD alla 4.0).

Supponiamo che sappiate come zippare e dezippare un file zip. Dezippiamo update.zip in una cartella qualsiasi che useremo per lavorare alla nostra custom rom.
La struttura di update.zip è la seguente:
- data (la cartella contiene in genere una sola sottocartella /app - Quì sono copiate tutte le app non di sistema che possiamo comunque rimuovere una volta avviata la console). Potete inserire in questa cartella la maggior parte delle app aggiuntive che vi interessano.
Il mio consiglio per trovare le app più utili è quello di provarle sulla propria console PRIMA di modificare la rom. Quando avete un pacchetto di app completo collegate la console via USB al PC e utilizzate un programma tipo Android Commander (http://androidcommander.com/) per copiare dalla console al PC le app che vi servono che poi andrete a posizionare nella cartella app della vostra custom rom. Un metodo molto più elegante per fare la stessa cosa molto rapidamente è quello di scaricare direttamente sul PC le app dal google market. Per farlo dovete usare Chrome e una sua estensione che trovate quì assieme al tutorial su come farla funzionare:
(http://www.androidworld.it/2012/02/25/e ... -pc-74708/)

- META-INF (questa cartella contiene uno script importantissimo annidato in META-INF/com/google/android/updater-script - Lo script si occupa delle operazioni di copiatura dei files dalle varie cartelle di update.zip direttamente nella memoria flash della console. Assegna i symlink a tutte i file di sistema (in pratica ‘spiega’ al sistema operativo che non è necessario specificare il percorso dei file di sistema) e si preoccupa di assegnare i privilegi di amministratore alle cartelle di sistema (in questo modo la console risulta rootata di default, cioè l’utente può modificare i file di sistema). La gestione dello script è abbastanza delicata e pertanto ci occuperemo di updater-script nella seconda puntata. Per ora conviene utilizzare direttamente uno degli script modificati dello custom rom esistenti così da ritrovarsi una rom rootata di base (per gli smanettoni le righe che rootano la rom sono le seguenti (per il processo completo è necessario aggiungere anche la riga ro.secure=0 in build.prop e copiare superuser.apk nella cartella system/app... vedremo anche queste fasi)
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
set_perm(0, 3003, 02750, "/system/bin/netcfg");
set_perm(0, 3004, 02755, "/system/bin/ping");
set_perm(0, 2000, 06750, "/system/bin/run-as");
set_perm_recursive(1002, 1002, 0755, 0440, "/system/etc/bluetooth");
set_perm(0, 0, 0755, "/system/etc/bluetooth");
set_perm(1000, 1000, 0640, "/system/etc/bluetooth/auto_pairing.conf");
set_perm(3002, 3002, 0444, "/system/etc/bluetooth/blacklist.conf");
set_perm(1002, 1002, 0440, "/system/etc/dbus.conf");
set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");
set_perm(0, 2000, 0550, "/system/etc/init.goldfish.sh");
set_perm(0, 0, 0544, "/system/etc/install-recovery.sh");
set_perm_recursive(0, 0, 0755, 0555, "/system/etc/ppp");
set_perm_recursive(0, 0, 0755, 0755, "/system/xbin");
set_perm(0, 0, 06755, "/system/xbin/librank");
set_perm(0, 0, 06755, "/system/xbin/procmem");
set_perm(0, 0, 06755, "/system/xbin/procrank");
set_perm(0, 0, 06755, "/system/xbin/su");
set_perm(0, 0, 06755, "/system/bin/su");
set_perm(0, 0, 06755, "/system/xbin/tcpdump");

- recovery (contiene solo lo script utilizzato in caso di crash totale del sistema. Dall’esperienza in genere è un po’ come la procedura di ripristino di windows che non funziona quasi mai. Se la console non riparte meglio riflasharla)

- system (contiene tutte le cartelle di sistema) a sua volta suddiviso in:
- app (contiene tutte le app di sistema comprese quelle installate dalla ditta che non vi servono. E’ la cartella fondamentale su cui agire per modificare l’installazione di base. Le app installate quì non si disinstallano se non con applicativi particolari una volta flashata la rom. Il consiglio è di ridurre al minimo le app installate in questa cartella ed eventualmente aggiungerne altre nella cartella data che vedavamo in precedenza. Non è il caso di eliminare app che non si conoscono perché molte sono app di sistema. Interessante invece la possibilità di sostituire o aggiungere una app che si occupa della gestione della console, un launcher: di base la JXD installa il gamehub.apk che può tranquillamente essere sostituito con l’ottimo adw-launcher o con l’altrettanto buono ma parecchio ingombrante go.launcher. Anche il browser.apk può essere sostituito con un altro browser migliore. Vedrete che molte app sono costituite da un file .apk e da un file .odex. Il file odex contiene parti del codice della app e ne permette una esecuzione più rapida. Potete riconoscere tutte le app di sistema per la presenza del file .odex e decidere con l’esperienza se eliminarle. Se eliminate una app eliminate anche il corrispondente file .odex. E’ possibile deodexare l’intero sistema. Sia io (paulvern) che Skelton abbiamo un sistema deodexato nelle nostre custom rom. Un sistema deodexato è più lento nel primo boot ma è possibile modificare anche il contenuto delle app di sistema. Il deodexing è una procedura abbastanza complessa che esula da questa guida). Ricordate che in questa cartella va inserito superuser.apk per avere il rooting della console.
- bin (contiene tutti gli eseguibili di Android compilati per il processore che state utilizzando. Il consiglio è di non modificare nulla quì dentro. Se proprio volete aggiungere o modificare qualcosa sappiate che tutti gli eseguibili sono invocabili da shell anche dal PC collegato alla console. Vi basta utilizzare adb.exe che è disponibile nella distribuzione di google framework. Se volete aggiungere degli eseguibili nella cartella bin (penso per esempio al compilatore di BENNUGD dovete farlo inserendo esclusivamente eseguibili compilati per il vostro processore, nel caso della JXD S601 ARM Cortex A8)
- etc (contiene i codec audio e video e le configurazioni di diversi applicativi di sistema più una serie di cose che gestiscono il bluetooth e il gps che nella JXD S601 non ci sono. Il consiglio è lasciare tutto come è. Se volete potete eliminare tutti i riferimenti al gps e al bluetooth senza problemi. Interessante il file wpa-supplicant.conf dove viene registrata la configurazione del wifi. Se volete che la console si connetta automaticamente dopo il reflashing alla vostra rete domestica potete copiare il wpa-supplicant.conf che si trova in etc/wifi dalla console configurata alla vostra custom rom. Decisamente da non distribuire per evitare che tutti conoscano la password del vostro router)
- fonts (contiene i fonts di sistema e altri fonts che possono essere utilizzati. Se volete modificare il font di sistema vi basta sostituire droidsans.ttf. I font sono gli stessi che utilizzate anche su Windows o in Linux)
- framework (contiene le applicazioni fondamentali del sistema operativo. Meglio non eliminare nulla. Anche quì di base tutte gli applicativi sono odexati tranne framework-res.apk. Scaricate la mia rom o quella di Skelton per avere tutto il framework deodexato. Se volete modificare i messaggi di sistema dovete lavorare su framework-res.apk (lo vedremo in una prossima puntata)
- lib (contiene le librerie di sistema; come nella cartella bin tutto è compilato per ARM Cortex A8. Non rimuovete nulla se volete essere sicuri che tutto giri come dovrebbe. Eventualmente aggiungete altre librerie per applicativi che lo richiedano)
- media (interessante cartella che contiene i file audio di sistema nella sottocartella /audio che al limite si possono anche eliminare se volete una console che non emetta suoni quando fate qualcosa - i suoni delle app sono contenuti nelle app stesse e non saranno modificati - e il file bootanimation.zip che contiene l’animazione di boot. Se dezippate anche questo file vedrete che contiene una o più cartelle part numerate come part0, part1 e così via e un file di testo desc.txt. Le cartelle contengono immagini png della sequenza di boot, ogni immagine è un frame della sequenza di boot e sono tutti numerati di seguito. I file possono essere chiamati come vi pare ma devono essere in formato png a 24 bit. Anche il loro formato non è fondamentale. La console può ridimensionare le immagini in fase di boot. Il file desc.txt spiega alla console come caricare i frame, per esempio:
480 272 10
p 3 0 part0

480 e 272 rappresentano la risoluzione dello schermo della JXD S601 e spiegano alla console che volete che le immagini di boot siano presentate in questo formato. Il consiglio è avere una sequenza di immagini già ridimensionate ma se così non fosse la console lo fa da sola. Il numero 10 indica il numero di frame che volete visualizzare per secondo (in questo caso 10). Evitate animazioni elaboratissime, richiedono tempo per il caricamento.
La riga p 3 0 part0 indica che volete iniziare una nuova sequenza di animazione (il comando p), che volete eseguirla 3 volte (il numero 3) e che volete aspettare 0 secondi prima di eseguire la parte successiva (che non necessariamente avrete). part0 indica la cartella da cui pescare l’animazione.
Ricordate che le immagini devono essere dei PNG non interlacciati e non trasparenti a 24 bit (in teoria potete usare anche JPG ma la qualità è peggiore a bassa risoluzione). Il file è uno zip un po’ strano in cui tutti i files sono memorizzati con l’opzione store e non sono pertanto compressi. Usate l’opzione store quando modificate qualcosa. Non c’è bisogno di signare lo zip.

-resource (quì ho sempre visto unicamente le immagini da visualizzare quando la console si sta ricaricando. Se volete potete modificarle. Sono file BMP standard)

- usr (questa cartella contiene una serie di impostazioni utente sulla tastiera. Il file più interessante è in keylayout ed è qwerty.kl. Si tratta delle assegnazioni dei tasti della console alle varie funzioni. Ogni tasto ha un suo specifico scancode (che è un numero), ogni funzione ha una stringa che si descrive abbastanza bene da sola. Ogni tasto poi ha una funzione Wake se spingendolo si risveglia la console e la funzione del tasto va passata alla console o wake_dropped se si risveglia la console ma non si vuole passare la funzione del tasto alla console. Potete copiare il qwerty.kl da una delle custom rom esistenti che assegnano a tutti i tasti una funziona specifica e poi modificarlo)
- xbin (altri file di sistema, è importante che la cartella e soprattuto il comando su abbiano le permission settate a 0755 perché la console sia completamente rootata. L’operazione è eseguita dall’updater-script)

-build.prop (non è una cartella ma un file di testo modificabile. Contiene alcune impostazioni di sistema abbastanza importanti. Vediamone alcune:
Tutte le proprietà sono di tipo ro o rw, cioè read only o read write. Il sistema può modificare quelle di tipo read write (per esempio lo stato del wifi), ma non quelle di tipo ro (per esempio il nome della ROM).

Le prime righe contengono informazioni del tutto personalizzabili
ro.build.id contiene il nome interno della ROM
ro.build.display.id contiene il nome che viene mostrato vedendo le proprietà del sistema
ro.build.version.incremental è il numero di versione
ro.build.version.sdk il numero della sdk con cui è stata sviluppata la ROM (credo che in realtà sia importante solo se testate la rom sull'emulatore android)
ro.build.version.codename il nome in codice? (non so quando venga visualizzato)
ro.build.version.release il numero di versione della releaase
ro.build.date la data di rilascio (va scritta in inglese con il giorno mese numerogiorno ora:minuti:secondi fascia fusio orario anno)
ro.build.date.utc stessa cosa scritta in coordinated universal time (che è un po' complesso... per qualche informazione vedi http://www.dxing.com/utcgmt.htm#utc altrimenti puoi lasciare anche come è)
ro.build.type io ho visto sempre user, sospetto che ci possano essere altri tipi di build
ro.build.user il nome dell'autore
ro.build.host il sistema operativo su cui funziona (Android nel nostro caso)


E veniamo ora alla parte importante del build.pro, la parte che definisce come si chiamerà il nostro dispositivo e come sarà riconosciuto dal sistema (e dal market).

ro.build.tags la funzione di questa linea mi è un po' oscura. E' sempre impostata come test-keys
ro.product.model quì mettiamo il modello del dispositivo. Per fare riconoscere al market il nostro dispositivo come un Sony Ericsson Experia (che dispone dei tastini per giocare e quindi è quello che dà la migliore compatibilità per esempio con una JXD S601) inseriremo le informazioni copiate dal build.pro del Sony (importante modificare questi campi e anche description e fingerprint). Alcuni giochi, per esempio i vari Dungeon Defenders, non sembrano supportati come si deve dall'Experia e non si lanciano. In quel caso basta sostituire le caratteristiche con quelle dell'LG indicato nel primo build.pro e tutto funziona!
ro.product.brand
ro.product.name
ro.product.device
ro.product.board
Inutile testare questi quattro campi, copiateli da un build.pro di qualcosa che volete simulare e inserite i nomi corretti.
ro.product.cpu.abi quì si sceglie la tipologia di processore, non utilizzare build.pro di modelli con processori a tecnologia diversa, niente mips al posto di arm o viceversa
ro.product.cpu.abi2 stessa cosa
ro.product.manufacturer quì va inserito il nome della ditta che ha fatto il dispositivo.
ro.product.locale.language la siglia del linguaggio installato di default. Consiglio è prima verificare cosa è supportato dalla ROM. Non importa se poi nella ROM non è possibile cambiare il linguaggio al proprio. Questa riga serve a specificare al market in che linguaggio scaricare un applicativo (almeno credo, non ho conferme in merito).
ro.product.locale.region stessa cosa di cui sopra?
ro.wifi.channels il numero di canali wifi attivi (per l'europa è 14, in altre nazioni può essere meno, lasciare 14 permette uno spettro maggiore di possibilità di connessione
ro.build.product di nuovo il modello per prodotto da copiare da un altro build.pro
ro.build.description la descrizione della build
ro.build.fingerprint é il fingerprint di sistema. Può essere più o meno qualsiasi stringa.
Affronteremo altre parti del build.prop nelle prossime puntate.
Per ora riteniamoci soddisfatti e proviamo a reimpacchettare tutta la nostra ROM.
Innanzitutto zippiamo di nuovo tutto (tutte le cartelle contenenti tutte le app aggiuntive e le modifiche) con 7zip e creiamo un file che necessariamente si dovrà chiamare update.zip. Una volta creato update.zip passiamo al passo successivo.

Signare (firmare) la custom rom
Questo è un passo fondamentale se volete che il sistema riconosca update.zip come una rom valida per l’aggiornamento. Uno script molto semplice da utilizzare è signer.jar (che trovete quì: http://bit.ly/LUEAh0). Per utilizzarlo decomprimete tutto l’archivio SignApkv2.zip nella stessa cartella dove avete messo update.zip e lanciate signerscript.bat. Attendete un tempo variabile a seconda della dimensione della vostra rom (anche 5 minuti) e poi vi ritroverete nella stessa cartella un file chiamato update_signed.zip. Copiatelo sulla SD della vostra console e rinominatelo in update.zip.
A questo punto è il momento di...

Testare la custom rom
Spegnete la JXD e riavviatela tenendo premuto contemporaneamente il tasto di avvio e il tasto menu. Il sistema inizierà il processo di update e flasherà la vostra nuova rom sulla console. Attendete il tempo necessario al flashing del sistema e poi la console si riavvierà da sola. Se tutto è andato come doveva avrete la vostra console funzionante con la vostra prima custom rom. Se la console non si dovesse riavviare niente paura: copiate sulla SD la rom originale sempre nel formato update.zip e rilanciate la procedura appena descritta. Per quanto flashare una rom su un dispositivo Android sia un processo abbastanza sicuro (per le console JXD è praticamente a prova di errore, visto che potete sempre riavviare la console e ripristinare la rom precedente) è importante che vi sinceriate che il vostro dispositivo disponga di una procedura di ripristino se qualcosa va storto e che voi sappiate utilizzarla. Il mio consiglio è quello di provare prima di tutto a flashare la rom originale e vedere se riuscite a seguire il processo senza problemi. A quel punto avrete a disposizione almeno un metodo per ripristinare il corretto funzionamento del vostro dispositivo. Se dopo le vostre modifiche qualcosa non funziona o, peggio, il vostro dispositivo non parte proprio più... beh non riteneteci responsabili dell’accaduto. Costruire una custom rom è un processo delicato e in tutti i casi flashare una rom diversa dall’originale sul vostro dispositivo invalida la garanzia originale. Fate attenzione!

Nella prossima puntata vedremo come rootare la rom, come modificare il boot della rom e i bootscreens e come personalizzare le app inserendo le vostre stringhe di testo.
Buon lavoro e buon divertimento!
alterego1
Posts: 1
Joined: 6 Sep 2012, 14:33

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by alterego1 »

bravissimo, ho cercato molto in rete ma fin'ora la tua è la guida più completa in italiano che abbia mai visto sull' argomento..
attendo con ansia il seguito ;)
P.S. hai un account su XDA ?
paulvern
Cavaliere OC.it
Cavaliere OC.it
Posts: 268
Joined: 21 Sep 2011, 11:50

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by paulvern »

Grazie! Sì su Xda mi chiamo allo stesso modo
User avatar
kayuz
Cavaliere OC.it
Cavaliere OC.it
Posts: 627
Joined: 4 May 2011, 15:27
Console open: Caanoo fidelis!! sempre co'te! :D
Location: Terni

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by kayuz »

mostruoso! :D sei bravissimo, voglio anche io concentrarmi sul fare una rom per la vecchia ydp-g18 la prima :)
complimenti per l'articolo, ti voglio beccare anche su Xda :)
User avatar
Zip
Site Admin
Posts: 3101
Joined: 3 May 2011, 21:03
Console open: Attuali Caanoo , Wiz, dingoo a320 (possedute Wiz, s7100B, s5110, s7300B, OpenPandora)
Location: Sicilia
Contact:

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by Zip »

anche io ci sono su xda eh!
paulvern
Cavaliere OC.it
Cavaliere OC.it
Posts: 268
Joined: 21 Sep 2011, 11:50

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by paulvern »

Su XDA c'è tanta di quella roba che in genere leggo i lavori degli altri. Credo di avere postato un paio di domande o due e essermi scordato cosa avevo chiesto :-)
User avatar
kayuz
Cavaliere OC.it
Cavaliere OC.it
Posts: 627
Joined: 4 May 2011, 15:27
Console open: Caanoo fidelis!! sempre co'te! :D
Location: Terni

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by kayuz »

xda è infinito, ci si sperde :D zip tu che username hai?
User avatar
scrawl71
Posts: 5
Joined: 6 Aug 2012, 13:06
Console open: jxds7100b,caanoo,dingooa320,wiz
Location: Milano

Re: Guida alla realizzazione di Custom Roms (I parte)

Post by scrawl71 »

Slurp..... guida moooolto interessante...credo che mi cimentero' anch'io nella realizzazione di roms Android !!


Grazie , grazie ..grazie... :)
Post Reply