[MAXI-GUIDA] Come iniziare a compilare e buildare Android

Visualizzazione stampabile

29-01-14, 20:54
KlaasMad

[MAXI-GUIDA] Come iniziare a compilare e buildare Android
DISCLAIMER: io non sono un developer, sto imparando in questi mesi questo complessissimo ed estremamente vasto mondo che abbraccia diverse branche della tecnologia e dell'informatica. Ho, però, deciso di condividere con voi quello che ho imparato in questi mesi di apprendimento, integrando con gli appunti che ho da parte.
Spero ne possiate fare un buon uso e soprattutto, spero che riusciate nella titanica avventura di diventare degli aspiranti developers!

Articolazione della guida

Mi riservo questo OP per iniziarvi al modo di pensare di un aspirante developer, per poi andare sviscerando i vari argomenti nei post successivi.

Alcuni tips generici

1. Il mondo del development è vasto e complesso, i fallimenti sono sempre dietro l'angolo ed imprecherete alla vostra macchina molto molto spesso per una compilazione andata a male. Non perdetevi d'animo, è normale ed anzi, io personalmente mi stranizzerei se la compilazione andasse bene al primo tentativo.

2. Il vostro sistema verrà messo a dura prova, la compilazione può durare 20 minuti, come può durare 6 ore e tutto dipende dal vostro hardware. CPU più potenti, SSD al posto di HDD, più RAM libera sicuramente velocizzeranno il processo di building. Overcloccare la CPU migliora la velocità, ma dotatevi di un sistema di cooling in quel caso.

3. Il download dei sorgenti è parecchio impegnativo, ma non per voi, ma per il vostro provider della linea. In media i sorgenti di una singola ROM pesano dai 9 ai 16GB (avete letto bene) e, nonostante sulle guide online troverete scritto che ci vogliono 4 ore, io, con la mia 8Mb/s offerta da Alice, ci metto dalle 8 ore ai 2 giorni. Un device tree va da 1GB a 1.5GB, i sorgenti di un kernel più meno simile, quindi mettetevi l'anima in pace ed aspettate e nel frattempo leggete leggete leggete.

Dove andremo a lavorare

Dato che questa vuole essere una maxi guida per tutti quanti per iniziarvi al building, partirò da molto lontano, ossia dalla preparazione del pc, vostro fedele alleato.
Android è basato su Linux e su Linux dovrete compilare, quindi mettetevi il cuore in pace e lasciate da parte Windows, prendete confidenza con il padre di Android!

Alcuni tips anche qui:

1. Ci sono un'infinità di distribuzioni (flavour, varianti), Ubuntu, Debian, Arch, Red Hat, SuSe, Fedora, Gentoo e chi più ne ha, più ne metta (credo che siamo sulle 3000 distro), ma il mio consiglio personale è di usarne una semplice (se siete dei principanti) e soprattutto leggera, visto che le preziose risorse del vostro PC serviranno per la compilazione e non per reggere inutili artefatti grafici. Non vi dico di compilare con Debian server stable senza interfaccia grafica (che sarebbe l'ideale), ma almeno adoperate un DE leggero, XFCE, LXDE o Openbox. Ovviamente l'architettura deve essere per forza di cose a 64bit, io adopero Linux Mint 16 XFCE, ve lo consiglio ardentemente, specialmente se siete nuovi del mondo Linux.

2. Usate Google. No davvero, usatelo! Incontrerete tantissime difficoltà specialmente se provenite da Windows, tutto è diverso, più semplice, ma diverso e quindi inizialmente complesso. Ma non preoccupatevi, per qualsiasi domanda che vi verrà in mente, ci sono almeno 15 risposte su altrettanti siti differenti per ogni lingua conosciuta. Googlate! E se proprio non riuscite a trovare, chiedete qui (se correlato al settaggio dell'ambiente di sviluppo) o nella sezione GNU/Linux se strettamente correlato al mondo Linux.

3. Prendete confidenza col terminale! È lo strumento più potente di Linux ed è quello che rende Linux grande! Sarebbe il corrispettivo del prompt dei comandi di Windows, ma con diverse chicche in più. Imparate quanti più comandi possibile, googlateli, scopritelo, mettetelo alla prova.

Editor di testo

Gedit (o qualunque voi preferite) è un vostro fedele alleato: vi servirà per modificare i vari makefile, gli xml e i diversi script durante il processo di compilazione e modifica. Scoprirete le diverse configurazioni di colori per indicare diversi tag.

Articolazione della guida
- Terminologia di base
- Preparazione del ambiente
- Manifest e download dei sorgenti
- Buildiamo!
- Custom toolchain
- Cherry-picking da gerrit
- Cherry-picking da github
- Aggiungere apk prebuildate o usando il local_manifest.xml
- Effettuare un porting di una ROM - Parte 1/2
- Effettuare un porting di una ROM - Parte 2/2
- Come buildare il proprio kernel - Parte 1/2
- Come buildare il proprio kernel - Parte 2/2
- Il comando git e github - Work in progress
- Come uploadare i propri sorgenti su Github - Work in progress
- In arrivo
- In arrivo
- In arrivo
Prepariamoci!
29-01-14, 20:56
KlaasMad

Terminologia di base

In qualsiasi guida, anche quelle che sono solito scrivere io, troverete un warning che vi dice che non vi sarà spiegata la terminologia di base di Linux, perché si suppone che per compiere un passo tanto grande ed impegnativo quale il processo di building, voi sappiate già queste cose.
Non è questo il caso comunque. Questa guida vi viene in soccorso proprio in questo. Vediamo alcuni termini prettamente Linuxiani.

Root

- ormai se siete dei modders, siete avvezzi con questo termine che può avere due significati: il root può essere di una cartella, ossia la cartella principale (in Linux indicata col simbolo /) o il particolare utente con i privilegi di amministratore (discorso che si traduce, nel mondo di Android, con la parola SuperSU o SuperUser).

Terminale

- lo strumento che fa la differenza. È una finestra dove immettere dei comandi in maniera testuale, in modo da interagire con la macchina. Su Ubuntu lo si apre con la combinazione di tasti ctrl+alt+t.

sudo

- comando, invocato dal terminale, per guadagnare l'accesso come root. Segue una richiesta di immissione password (che avrete scelto voi durante l'installazione di Linux).

DE, Desktop Enviroment

- tutto quello che vediamo nello schermo. Un sistema operativo può essere gestito testualmente, ma per venire incontro all'utente, si da un'interfaccia grafica a tutto. Il DE è appunto l'ambiente grafico di un sistema operativo, composto da barre laterali, dock etc etc.

Nautilus, Thunar, Dolphin

- sono tutti dei gestori file (o file manager, un po' come quelli android) coi quali ci interfacciamo graficamente ai file ed alle cartelle. Sono, rispettivamente, di Ubuntu (o comunque del DE Unity), del DE XFCE e del DE Dolphin.

gksu

- comando che apre come root un'applicazione.

repo

- può essere inteso come abbreviazione di repository, ma anche come un programma (scritto in python) che sincronizza i tuoi sorgenti con quelli online.

git

- un sistema per tenere online il codice sorgente.

Branch

- versione di un codice sorgente, solitamente correlato alla versione di android

cm-10.2, jb-mr2, kitkat-4.4

- sono un sistema di denominazione dei branch, rispettivamente di CyanogenMod, AOKP e Slim.

Gerrit

- un sistema di revisione del codice online che usa gli standard git.

Commit

- una patch, o comunque una modifica, non ancora implementata

Build

- può indicare il processo di buildare, ossia costruire, ma anche una milestone di una ROM (build 1.2, build 5.0 etc)

Cherry-pick

- integrare nel codice sorgente dei commit.

Clone

- l'azione di clonare dei repository sulla tua macchina.

Manifest

- un documento che contiene un elenco dei progetti (project) appartenenti alla ROM da scaricare.
29-01-14, 21:04
KlaasMad

Download ed installazione di una distro linux

Nella guida spiegherò l'installazione di Linux Mint 16 XFCE, ma lo stesso procedimento lo si può applicare anche ad altre distro (Debian, Fedora, Arch, Gentoo, ma se state usando queste, non avete neanche motivo di leggere la guida).

- scaricate la .iso di Linux Mint dal sito ufficiale LinuxMint.com, ma scaricate la versione a 64 bit! La maggior parte dei processi di build, compresi quelli del kernel, vi richiederanno questa architettura. E comunque, se vi aspettate di terminare la compilazione in un lasso di tempo decente (meno di 6 ore), vi conviene avere almeno una macchina dual core con architettura 64 bit.

- scaricate unetbootin dalla loro pagina di sourceforge unetbootin.sourceforge.net. Questo programma vi servirà a creare la pen drive avviabile. Volendo, potete masterizzare l'iso su DVD, per cui, se avete intenzione di utilizzare questo metodo, potete saltare questo punto.

- una volta scaricato unetbootin, installatelo e, se la vostra distro si è scaricata, collegate la pen drive vuota (formattata in FAT32) e avviate unetbootin. Selezionate l'iso scaricata ed il dispositivo di montaggio dell'ISO (vedi immagini sotto spoiler) ed avviate (le immagini sono prese dalla mia guida per installare android x86 su pc, cambiano i file, ma il processo è identico.

Spoiler:

http://i.imgur.com/oknkf9I.png http://i.imgur.com/8SUyV3T.png http://i.imgur.com/NCtFSio.png http://i.imgur.com/5oowwLO.png

Una volta che la pen drive è pronta (ci vorranno 2-5 minuti a seconda della potenza del vostro pc), riavviate e selezionate dal menu di boot la vostra pen drive. Si avvierà una finestra blu che vi chiederà se volete provare o installare Mint. Selezionate l'installazione, che vi porterà ad una procedura guidata estremamente semplice. Arrivati ad un certo punto, vi chiederà se volete installare Mint da solo sul pc, o se volete affiancarlo a Windows/Mac OS, qui sta a voi decidere, l'importante è che riserviate ad Mint almeno 150gb (vedremo dopo perché).
Procedete con l'installazione assegnando come file system ext4 (è già disponibile il nuovo btfrs, ma non è ancora stabile). Decidete anche il vostro nome utente e la vostra password (consiglio di usare una parola abbastanza corta poiché dovrete inserire spesso la password nel terminale).

Nel giro di una ventina di minuti o poco più (sempre a seconda del vostro pc) avrete Mint installato sulla vostra macchina.

Appena entrati su Mint, corriamo subito ad aggiornare i pacchetti esistenti aprendo il terminale ed immettendo i seguenti comandi:

codice:

sudo apt-get update sudo apt-get dist-upgrade

Giusto il tempo di scaricare gli aggiornamenti (in genere mai più di 300mb), di installarli ed il sistema è pronto. Per sicurezza riavviate.

Installazione pacchetti essenziali

In questo momento avete un sistema operativo basilare, aggiornato e funzionale, ma non ancora pronto ad ospitare il processo di building. Ci servono alcuni pacchetti e li installiamo sempre da terminale. Potete copipastare i comandi che vi do, onde evitare errori.

Installiamo i codec e le librerie multimediali:

codice:

sudo apt-get install ubuntu-restricted-extras

codice:

sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update

codice:

sudo apt-get install libdvdcss2

Installazione dei pacchetti necessari

Prima di installare alcuni pacchetti fondamentali, creiamo le regole di accesso alle porte usb per i device.
Da terminale date il comando per aprire come root gedit, un potente editor di testo e creare un file nel percorso /etc/udev/rules.d:

codice:

sudo gedit /etc/udev/rules.d/51-android.rules

Ora copiate ed incollate il seguente testo nel vostro editor:

codice:

# adb protocol on passion (Nexus One) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e12", MODE="0666", OWNER="klaasmad" # fastboot protocol on passion (Nexus One) SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0fff", MODE="0666", OWNER="klaasmad" # adb protocol on crespo/crespo4g (Nexus S) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e22", MODE="0666", OWNER="klaasmad" # fastboot protocol on crespo/crespo4g (Nexus S) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e20", MODE="0666", OWNER="klaasmad" # adb protocol on stingray/wingray (Xoom) SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="70a9", MODE="0666", OWNER="klaasmad" # fastboot protocol on stingray/wingray (Xoom) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="708c", MODE="0666", OWNER="klaasmad" # adb protocol on maguro/toro (Galaxy Nexus) SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", ATTR{idProduct}=="6860", MODE="0666", OWNER="klaasmad" # fastboot protocol on maguro/toro (Galaxy Nexus) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0666", OWNER="klaasmad" # adb protocol on panda (PandaBoard) SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d101", MODE="0666", OWNER="klaasmad" # fastboot protocol on panda (PandaBoard) SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d022", MODE="0666", OWNER="klaasmad" # usbboot protocol on panda (PandaBoard) SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d00f", MODE="0666", OWNER="klaasmad" # usbboot protocol on panda (PandaBoard ES) SUBSYSTEM=="usb", ATTR{idVendor}=="0451", ATTR{idProduct}=="d010", MODE="0666", OWNER="klaasmad" # adb protocol on grouper (Nexus 7) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e42", MODE="0666", OWNER="klaasmad" # fastboot protocol on grouper (Nexus 7) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e40", MODE="0666", OWNER="klaasmad" # mtp protocol on the grouper (Nexus 7) SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e41", MODE="0666", OWNER="klaasmad" ## Google #SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee2", MODE="0666", OWNER="klaasmad" ## LG Nexus 4 SUBSYSTEM=="usb", ATTR{idVendor}=="1004", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="0bb4", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="0502", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="12d1", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="1004", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="22b8", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="0fce", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="0489", MODE="0666", OWNER="klaasmad" SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", SYMLINK+="android_adb", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", MODE="0666", GROUP="plugdev" # Google Nexus 7 MTP mode : automatic mount when plugged (all android versions) ENV{ID_MODEL}=="Nexus_4", ENV{ID_MODEL_ID}=="4ee2", ACTION=="add", RUN+="/usr/bin/sudo -b -u yourlogin /usr/local/sbin/go-mtpfs -allow-other=true /media/Nexus4" ENV{ID_MODEL}=="Nexus_4", ENV{ID_MODEL_ID}=="4ee2", ACTION=="add", RUN+="/usr/bin/sudo -b -u yourlogin /usr/local/sbin/go-mtpfs -allow-other=true /media/Nexus4" ENV{ID_MODEL}=="Nexus_7", ENV{ID_MODEL_ID}=="4e41", ACTION=="add", RUN+="/usr/bin/sudo -b -u yourlogin /usr/local/sbin/go-mtpfs -allow-other=true /media/Nexus7" ENV{ID_MODEL}=="Nexus_7", ENV{ID_MODEL_ID}=="4e42", ACTION=="add", RUN+="/usr/bin/sudo -b -u yourlogin /usr/local/sbin/go-mtpfs -allow-other=true /media/Nexus7" # Google Nexus 7 MTP mode : automatic unmount when unplugged (all android versions) ENV{ID_MODEL}=="Nexus_4", ENV{ID_MODEL_ID}=="4ee2", ACTION=="remove", RUN+="/bin/umount /media/Nexus4" ENV{ID_MODEL}=="Nexus_4", ENV{ID_MODEL_ID}=="4ee2", ACTION=="remove", RUN+="/bin/umount /media/Nexus4" ENV{ID_MODEL}=="Nexus_7", ENV{ID_MODEL_ID}=="4e41", ACTION=="remove", RUN+="/bin/umount /media/Nexus7" ENV{ID_MODEL}=="Nexus_7", ENV{ID_MODEL_ID}=="4e42", ACTION=="remove", RUN+="/bin/umount /media/Nexus7"

Cliccate sulla lente di ingrandimento e la matita nella barra degli strumenti e sostituite la parola "klaasmad" (mio nome utente) con il vostro nome utente. Salvate il file ed uscite.

Installate i pacchetti chiave per settare l'ambiente:

codice:

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386

Dopo che ha terminato l'installazione, date:

codice:

sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so

Dopo di ché, continuate dando da terminale:

codice:

sudo apt-get install schedtool pngcrush

Installiamo Java:

codice:

sudo add-apt-repository ppa:webupd8team/java sudo apt-get update sudo apt-get install oracle-java6-installer

Dopo di che digitate:

codice:

sudo update-alternatives --config java

E selezionate la versione Java 6 di Oracle/Sun.

Alcune modifiche essenziali

Scarichiamo i binari del programma repo, diamogli i permessi necessari ed inseriamolo nel path di esecuzione.

Aprite un nuovo terminale e date:

codice:

mkdir ~/bin

Aggiungete la cartella ~/bin nel path dando:

codice:

PATH=~/bin:$PATH

Scaricate ora i binari di repo ed inseriteli nella cartella bin dando:

codice:

curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo

Dategli i permessi:

codice:

chmod a+x ~/bin/repo

Repo è ora installato! Non ci resta che preparare il nostro percorso di download dei sorgenti!
29-01-14, 21:59
KlaasMad

Percorso dei sorgenti

Per comodità, sono solito scaricare 5-6 sorgenti diversi per ogni ROM, non tanto perché buildo ogni ROM che mi torna in mano, ma quanto perché confronto spesso i sorgenti di questa ROM con quelli di un'altra (e servirà anche a voi, fidatevi!). Allora è opportuno creare un buon set di cartelle dove operare.
Questa è la mia struttura, voi siete liberi di piazzarle dove volete, è solo per darvi una linea guida:

Da terminale (ma potete farlo anche da GUI) date:

codice:

mkdir ~/sorgenti && cd ~/sorgenti

Con questo comando creeremo la cartella sorgenti e ci entreremo. Notate il nome minuscolo. Da un esponente ragionevolmente malato di OCD, è un bel pugno nello stomaco, ma vi servirà quando dovrete digitare velocemente da terminale ed il tempo per premere lo shift, sarà un'eternità.

Quando dovrete scaricare dei sorgenti, vi verrà chiesto di creare una cartella in base al nome della ROM:

- cm per CyanogenMod (anche se di solito la struttura che usano è ~/android/system)
- aokp per le AOKP
- slim per le SlimROM

etc etc. Ero solito averle tutte nella home, con conseguente disordine. Così è tutto molto più ordinato e strutturato.

Ora, per onor di cronaca non ufficiale, vi consiglierei di scaricare i sorgenti della CyanogenMod, sia perché ha la struttura di compilazione e build più semplice, sia perché è la ROM alla quale TUTTE QUANTE LE ALTRE ROM fanno riferimento, visto che praticamente i device tree, ossia la struttura di codice degli specifici smartphones, appartiene al team CM.

Download dei sorgenti CyanogenMod

Vediamo, anche come esempio di massima, come scaricare i sorgenti CyanogenMod (senza riferimento a particolari devices).
Innanzitutto recatevi alla pagina github del team che potete trovare su github.com/CyanogenMod.

Cercate il loro platform_manifest, di solito rinominato così nei sorgenti comuni, ma CyanogenMod ha una denominazione particolare, si chiama infatti android.

Lì potrete trovare i comandi per scaricare i sorgenti, in questo caso, essendo la vostra prima volta, ve li scrivo io (devono essere eseguiti da terminale):

codice:

cd sorgenti mkdir cyanogenmod cd cyanogenmod

Questi comandi ci serviranno a creare la cartella ~/sorgenti/cyanogenmod dove andremo a piazzare i sorgenti. Digitiamo da terminale:

codice:

repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0

Fermiamoci un attimo a guardarli, possiamo riconoscere 3 parti fondamentali, vediamo cosa significano:

- [repo init -u] possiamo riconoscere repo, il programma in python che abbiamo scaricato e che abbiamo settato nel path ~/bin/repo
- [git://github.com/CyanogenMod/android.git] è l'indirizzo del manifest di CyanogenMod seguito da .git, il formato che viene compreso dal tool repo
- [-b cm-11.0] è invece il branch (la b iniziale sta per branch), ossia il ramo che vogliamo scaricare che è, per l'appunto, cm-11.0 (android 4.4).

In questo modo scaricheremo alcuni file basilari per il download vero e proprio. Per verificare cosa abbiamo scaricato, riduciamo ad icona il terminale ed apriamo il file manager e andiamo fisicamente nella cartella ~/sorgenti/cyanogenmod. Non vedremo nulla, perché la cartella che è stata creata è nascosta. Per vederla basterà eseguire la combinazione di tasti ctrl + h. Spunterà una cartella chiamata .repo (il punto davanti la prima parola nasconde la cartella in Linux). Entrateci e cliccate su manifests. Ci sarà un documento chiamato default.xml apritelo (tasto destro del mouse, apri con gedit) e spulciatelo. Quelli sono gli indirizzi dei vostri sorgenti. Non toccate nulla e non salvate quando chiudete il documento.

Snellimento del codice

16GB sono tanti, ma possiamo comunque snellirli perché al loro interno c'è del codice appartenente ad architetture che non ci competono. Ad esempio ci sono i tool relativi alla compilazione su Mac e se buildiamo su Linux, possiamo tranquillamente eliminarli!
Diamo un'occhiata sullo specifico:

codice:

klaasmad@K53TA ~/sorgenti/prova $ repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0 Get https://gerrit.googlesource.com/git-repo remote: Counting objects: 108, done remote: Finding sources: 100% (108/108) remote: Total 2692 (delta 1477), reused 2692 (delta 1477) Ricezione degli oggetti: 100% (2692/2692), 2.08 MiB | 781.00 KiB/s, done. Risoluzione dei delta: 100% (1477/1477), done. Da https://gerrit.googlesource.com/git-repo * [nuovo branch] maint -> origin/maint ... ... Get git://github.com/CyanogenMod/android.git remote: Counting objects: 2800, done. remote: Compressing objects: 100% (1794/1794), done. remote: Total 2800 (delta 849), reused 2800 (delta 849) Ricezione degli oggetti: 100% (2800/2800), 900.89 KiB | 14.00 KiB/s, done. Risoluzione dei delta: 100% (849/849), done. Da git://github.com/CyanogenMod/android * [nuovo branch] cm-10.1 -> origin/cm-10.1 ... ... Your identity is: KlaasMad <klaas.madison2389@gmail.com> If you want to change this, please re-run 'repo init' with --config-name repo has been initialized in /home/klaasmad/sorgenti/prova klaasmad@K53TA ~/sorgenti/prova $ repo sync Fetching project CyanogenMod/android_abi_cpp Fetching project CyanogenMod/androidFetching project CyanogenMod/android_art Fetching project CyanogenMod/android_bionic remote: Reusing existing pack: 36, done. remote: Total 36 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (36/36), done. Da git://github.com/CyanogenMod/android_abi_cpp * [nuovo branch] cm-11.0 -> github/cm-11.0 Da git://github.com/CyanogenMod/android_abi_cpp * [nuova tag] cm-10.1-M1 -> cm-10.1-M1 ... Fetching projects: 0% (1/443) Fetching project CyanogenMod/android_bootable_diskinstaller remote: Counting objects: 611, done.

Ci sono 611 progetti da scaricare, ma non tutti sono necessari!
Andiamo ad analizzare il file ~/sorgenti/cyanogenmod/.repo/manifests/default.xml

Scrollatelo e vedrete una cosa del genere:

http://i.imgur.com/lZncM3A.png

1. il remote, ossia l'indirizzo remoto dal quale si andrà a scaricare quando andremo a dare il tag <remote="nomeremoto">

2. il progetto base, ossia l'indirizzo all'interno del remoto google, che andremo a scaricare direttamente dal codice android.

3. il progetto comune, ossia l'indirizzo all'interno del remoto custom che scaricheremo. Il tag contiene anche il percorso dove andrà posto automaticamente e il branch da scaricare (ossia la versione).

Scrollando i vari progetti possiamo trovare questo:

http://i.imgur.com/IjjYrzU.png

Sono tutti i tool relativi alla compilazione su Mac, se siete su ambiente Linux, potete rimuoverli tranquillamente. Come? Modificando il default.xml? NO!
Il default.xml è direttamente collegato al github della ROM e modificandolo, potete potenzialmente modificare anche il github della ROM danneggiandola!
Il miglior metodo per modificare il default.xml è creare una cartella local_manifests nella cartella .repo e al suo interno, creare il file local_manifest.xml

http://i.imgur.com/cpeWXrt.png

Al suo interno potete rimuovere i vari progetti col tag <remove-project ... />

http://i.imgur.com/hYg7Li7.png

A cosa serve il local_manifest.xml?

Semplice! Attraverso questo file potete:
- rimuovere progetti indesiderati (tools per la compilazione su Mac, device tree di smartphone/tablet che non vi interessano etc)
- aggiungere device tree di telefoni/tablet non supportati ufficialmente
- aggiungere progetti alternativi (app, toolchain, progetti vari)

Capite quanto questo sia importante!

Dopo aver alleggerito il vostro default.xml tramite il local_manifest.xml tornate al vostro terminale ridotto ad icona e diamo, come ultimo comando

codice:

repo sync

Il comando repo ormai lo conoscete. Sync sta per synchronize, sincronizzazione. Difatti il terminale comincerà un download frenetico dei vostro sorgenti che possono variare dagli 8gb ai 16gb.
È possibile impostare un'opzione per velocizzare il download usando l'opzione -jX (j sta per jobs e la X sta per un valore numerico, tanto più alto, quanto più veloce).
Esempio:

codice:

repo sync -j32

È lecito pensare che valori più alti indurranno un download più veloce. Sarebbe anche così se non fosse che le connessioni italiane sono scadenti, per cui scaricare 8~16gb significherà, per la maggior parte di voi, comunque aspettare almeno 5-6 ore, almeno!
Comunque, di suo, è impostato per scaricare con 4 jobs (lo potete vedere nel default.xml che abbiamo aperto poco sopra), per cui il numero di jobs è implicito nel comando che date.
29-01-14, 22:34
KlaasMad

Preparazione del building

Otteniamo i prebuilts

Ci sono dei file già buildati che dovrete ottenere e lo farete digitando da terminale:

codice:

cd sorgenti/cyanogenmod/vendor/cm

codice:

./get-prebuilts

Vedrete del codice partire a terminale, è il download dei file prebuildati.

Utilizziamo CCACHE

CCACHE è una cache del compilatore per C e C++ che aiuta i processi di building nel velocizzare il tutto. Ovviamente, immagazzinando cache, occuperà spazio sul vostro pc e di solito si aggira dai 25GB ai 100GB.
Vediamo come utilizzarla:

1. Aprite un terminale

2. Digitate

codice:

gedit .bashrc

3. Aggiungete le seguenti linee di codice:

codice:

export USE_CCACHE=1 export CCACHE_DIR=/home/klaasmad/sorgenti/cyanogenmod/prebuilts/misc/linux-x86/ccache

Ovviamente sostituite klaasmad al vostro nome utente.

4. Ora, sempre da terminale digitate:

codice:

cd sorgenti/cyanogenmod prebuilts/misc/linux-x86/ccache/ccache -M 50G

In questo modo setterete i 50GB di cache nella cartella /home/nomeutente/sorgenti/cyanogenmod/prebuilt/misc/linux-x86/ccache/ccache.

Si builda!

Aprite un terminale e recatevi nella root dei vostri sorgenti:

codice:

cd sorgenti/cyanogenmod

Attivate lo script per il build:

codice:

. build/envsetup.sh

Nota: c'è uno spazio tra il punto e la parola build.
Nota 2: andate a vedere questo script, sarà ostico, ma piano piano lo capirete. Ovviamente il percorso è ~/sorgenti/cyanogenmod/build/envsetup.sh

A terminale vedrete del codice che va, è lo script che parte.

Preparazione del vostro device

Se il vostro device è ufficialmente supportato dalla CyanogenMod è sufficiente digitare subito dopo l'esecuzione dello script precedente:

codice:

breakfast codenamedevice

Sostituento a "codenamedevice" il nome in codice del vostro dispositivo, i9100 nel caso del SII international, hammerhead nel caso del Nexus 5, grouper nel caso del Nexus 7 2012 WiFi e così via.
In questo modo si scaricheranno i file relativi al device tree in questione. Ci vorrà un po' di tempo, verranno scaricati 1.5GB circa.

File proprietari

Adesso è tempo di ottenere i file proprietari del vostro device. Assumiamo di buildare per Nexus 7 2012 WiFi (ma lo stesso concetto è applicabile a qualsiasi altro device).
Collegate il vostro device (con accesso adb attivato) al pc e da terminale recatevi su:

codice:

cd ~/sorgenti/cyanogenmod/device/nomeprodotto/codename

Nel caso del Nexus 7 2012 WiFi:

codice:

cd ~/sorgenti/cyanogenmod/device/asus/grouper

Ovviamente potete sostituire le varie stringhe con quelle del vostro device.

Dopo di che digitate:

codice:

./extract-files.sh

Vedrete i file proprietari trasportati sul pc.

Adesso digitate:

codice:

croot

Tornerete nella cartella ~/sorgenti/cyanogenmod automaticamente.

codice:

make clobber && make -jX bacon

Con questo comando pulirete la cartella di uscita della vostra build (make clobber) e (&&) inizierete il processo di build vero e proprio (make) ad una determinata quantità di processi per momento t (-jX), creando uno zip flashabile (bacon).

Come detto all'inizio, il tempo sarà variabile dai 20 minuti alle 6 ore a seconda della vostra build machine. Sedetevi comodi e tornate a leggere qualcosa per imparare nel frattempo che viene creato il vostro zip flashabile!

Quali sono i vantaggi di buildare da sé la propria ROM?

Beh, il primo, non indifferente, è che potete avere lo zip prima degli altri, decidere voi quando avere le nightly aggiornate all'ultima versione e testarle da voi. Vi basterà aggiornare i sorgenti con il noto comando

codice:

repo sync

e ripetere l'esecuzione dei comandi da terminale a partire dal richiamo dello script

codice:

. build/envsetup.sh

e a finire al comando di make vero e proprio.

Inoltre, guadagnando un po' di esperienza, potrete personalizzare la vostra ROM aggiungendo delle features (cherry-pick) o rimuovendo quelle che non vi piacciono.
Insomma, potrete essere voi i padri del sistema operativo che state facendo andare sul vostro device!
30-01-14, 17:33
KlaasMad

Usare un custom toolchain

Cos'è un Toolchain?

Nel software, un toolchain è un set di tool di programmazione che sono usati per creare un prodotto (tipicamente un altro programma per computer o un sistema di programmi. I tools possono essere usati in una catena, così che l'output di ciascun tool diventi l'input per il seguente, ma il termine è usato ampiamente in riferimento a qualunque set di tool di sviluppo collegato.
Una toolchain di sviluppo di un semplice software consiste in un compilatore ed un collegatore per trasformare il codice sorgente in un programma eseguibile, librerie per fornire un'interfaccia al sistema operativo ed un debugger. Un prodotto complesso come un videogame necessita di tools per preparare gli effetti sonori, la musica, la textures, i modelli 3D e le animazioni, ed inoltre altri tools per combinare queste risorse al prodotto finito.
Fonte: Wikipedia.

Cos'è Linaro?

Linaro è un posto dove gli ingegneri da tutto il mondo che lavorano per le compagnie tecnologiche definiscono il futuro di ARM su Linux. La compagnia è un'organizzazione ingegneristica no-profit con oltre 120 ingegneri che lavorano al consolidamento e all'ottimizzazione del software open source per le architetture ARM, inclusi i toolchain GCC, il kernel Linux, la gestione energetica ARM e l'interfaccia grafica e multimediale.
Fonte: linaro.org

Cos'è SaberMod?

SaberMod è una ROM AOSP-based con alcune caratteristiche extra aggiunte e tanto materiale da da CyanogenMod. SaberMod è cominciata da AOSP quando Android 4.2.1 è stato lanciato. Originariamente era il semplice AOSP con alcune caratteristiche che sono state portate da CyanogenMod con ottimizzazioni Linaro. Successivamente sono state implementate cherry pick da rasbeanjelly.
Il creatore della ROM ha customizzato il GCC di Google per ottimizzare le performance e la stabilità, chiamandolo, per l'appunto, SaberMod.
Fonte: XDA

In soldoni cosa si ricava dall'utilizzare un custom toolchain? Migliori performance in quanto il codice ne risulta più snello, una durata migliore della batteria ed in generale la ROM funziona meglio in funzione dall'efficacia del toolchain stesso.
Alcuni esempi che fanno da prova a questa tesi sono le ROM stesse, tra le quali (nella sezione per i9100, lo smartphone in mio possesso):

- https://www.androidiani.com/forum/mo...nofficial.html (rom originale la SlimKAT)

- https://www.androidiani.com/forum/mo...al-builds.html (rom originale la SlimBean)

- https://www.androidiani.com/forum/mo...rom-v-5-a.html (rom originale la CyanogenMod)

- https://www.androidiani.com/forum/mo...ly-builds.html (rom originale la CyanogenMod)

Linaro Toolchain

Recatevi nella root del vostro codice sorgente usando il terminale (assumiamo la solita ~/sorgenti/cyanogenmod/).
Sempre da terminale digitate

codice:

cd prebuilts/gcc/linux-x86/arm/

Attenzione: la cartella giusta è prebuilts, non prebuilt.

http://i.imgur.com/mKLWxok.png

Nota bene: lo screen dice android/system perché appartiene ad una guida che feci tempo prima rispetto a questa.

Adesso dovrete scaricare il toolchain Linaro vero e proprio, per cui eseguite sul terminale

Versione testata da me e perfettamente funzionante:

codice:

wget http://releases.linaro.org/12.11/components/android/toolchain/4.7/android-toolchain-eabi-linaro-4.7-2012.11-1-2012-11-16_21-55-58-linux-x86.tar.bz2

Ultima versione testata da me ed anch'essa funzionante alla perfezione:

codice:

wget http://releases.linaro.org/13.10/components/android/toolchain/4.7/android-toolchain-eabi-4.7-2013.10-x86.tar.bz2

http://i.imgur.com/viNwnwi.png

Nota: scegliete una sola dei due toolchain, mica entrambi!

Al termine del download eseguite

codice:

bunzip2 *.tar.bz2

e

codice:

tar -xvf *.tar

Adesso aprite il vostro file manager (Nautilus se siete su Ubuntu con su Unity, Thunar se utilizzate XFCE come DE, etc) e recatevi fisicamente nella cartella root del vostro codice sorgente, dopo di che aprite la cartella build:

http://i.imgur.com/zZOUfRF.png

Col vostro editor di testo preferito (io uso gedit, ma potete usare leafpad o altro, ma non libreoffice) aprite il file envsetup.sh e scrollate fino alla stringa evidenziata nell'immagine (potete aiutarvi con lo strumento di ricerca parole attivabile con la combinazione ctrl+f). Modificate la stringa che trovate come lo vedete nell'immagine (inserendo il percorso del toolchain Linaro).

http://i.imgur.com/GiZZo2B.png

Salvate il documento e chiudete.

SaberMod Toolchain

Il procedimento è simile a quello adoperato per Linaro, cambiano alcune cose.

Recatevi alla pagina del progetto SaberMod dal github di Sparsko e sulla destra, cliccate su Download zip.

http://i.imgur.com/uWr30en.png

Estraete la cartella dallo zip e rinominatela in "sabermod-toolchain-eabi". Piazzatela nella cartella ~/sorgenti/cyanogenmod/prebuilts/gcc/linux-x86/arm, dopo di che aprite il file ~/sorgenti/cyanogenmod/build/envsetup.sh modificandolo alla solita riga con il nome sabermod-toolchain-eabi.

http://i.imgur.com/GiZZo2B.png

Finito!

Nota: è probabile che durante la compilazione vi dia degli errori, un esempio è questo che ho avuto mentre cercavo di creare una custom ROM 4.4.2 per il Samsung Galaxy Ace:

codice:

/home/klaasmad/sorgenti/galaxy-ace/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/arm-eabi-gcc: No such file or directory make[4]: *** [scripts/mod/empty.o] Errore 1 make[3]: *** [scripts/mod] Errore 2 make[2]: *** [scripts] Errore 2 make[1]: *** [sub-make] Errore 2 make[1]: uscita dalla directory "/home/klaasmad/sorgenti/galaxy-ace/kernel/samsung/msm7x27"

In questo caso, il toolchain non è compatibile ed è necessario editare alcuni file per far sì che esso "combaci" con il vostro device. Non mi è possibile descrivere tutti i casi volta per volta, 1 perché non ne ho l'esperienza e la conoscenza, 2 perché esistono centinaia di device, è umanamente impossibile conoscere tutti i makefile ed i file di configurazione di migliaia di dispositivi.
Potete comunque chiedere assistenza qui o nel thread di SOS dedicato.
30-01-14, 17:52
KlaasMad

Cherry-picking da gerrit

Il cherry picking, letteralmente, raccolta di ciliege, è la parte più interessante e sicuramente più importante per chi sviluppa e mantiene una ROM. Al di là del significato letterale, "cherrypickare" significa ottenere un particolare commit (modifica del codice) non ancora unito (merged) al codice sorgente padre (che è su github o piattaforme simili), oppure appartenente ad un altro codice sorgente di un'altra ROM.
Su questa logica si fonde la notissima piattaforma sviluppata da Google, chiamata Gerrit che consente all'utente di inviare patch o commit al manteiner di una ROM, che decide in seguito se unirlo al codice sorgente.
Ma tali commit non vengono applicati immediatamente al codice sorgente, restano in un periodo di prova, beta, durante il quale sono visibili a tutti e i vari developer possono giudicarlo (con un sistemi di voti) dopo averlo testato. È qui che il concetto di cherry picking viene applicato. I commit (le ciliege) sono open (ovviamente) e possono essere pickate (raccolte) per essere unite alla copia del codice sorgente che avete in locale sul vostro pc.

Poniamo, come esempio, che vogliamo applicare questo commit dal gerrit delle SlimROMs:

http://i.imgur.com/tZquxxI.png

1. indicato al numero 1 potete vedere su quale progetto andrà ad influire il commit che, come abbiamo visto in precedenza, sostituendo ai _ le slash, diventa anche il percorso, che sarà quindi (applicato alla nostra struttura dei sorgenti ~/sorgenti/cyanogenmod/frameworks/base).

2. indica che tipo di commit stiamo guardando, in questo caso quello relativo a far comparire nella status bar la velocità di download ed upload. Notate anche (1/2) che ci dice che questa è solo la prima parte del commit, spulciando nel gerrit delle SlimROMs dovrebbe esserci anche la seconda parte che porta lo stesso nome, ma con dicitura (2/2).

3. indica il branch al quale andremo ad applicare il commit, quindi, in questo caso, kk4.4, quindi KitKat.

Scrolliamo verso il basso e passiamo ad analizzare altri aspetti:

http://i.imgur.com/ebGMZlw.png

Clicchiamo su Patch set1 e si aprirà quello che vedete in immagine.

1. quelli cerchiati sono i file che il commit andrà a modificare, se cliccate su essi, avrete il confronto del file tra prima e dopo che il commit è stato applicato!

2. sono le patch da applicare, una per una, per applicare l'intero commit. Questo commit consta di 6 patch set.

3. notate la dicitura "cherry-pick", cliccando verrà fuori il codice che inizia per git fetch che vedete in basso.

Avete visto i vari file da modificare, penserete, dovrò modificare manualmente i file uno per uno? Ovviamente no! È qui che sta il colpo di genio del comando git (che vedremo nello specifico più avanti), dando un solo comando da terminale, applicherà tutte le patch set, modificando automaticamente i vari file! Come?

4. notate il piccolo pulsate. Dopo aver clickato su cherry-pick, clickate sul pulsantino e vi copierà automaticamente il codice.

Aprite il vostro terminale e recatevi (se non lo avete già fatto) nella cartella frameworks/base (come indicato nella prima nota della precedente immagine).

codice:

cd ~/sorgenti/cyanogenmod/frameworks/base

ora incollate il codice che avete copiato poco fa:

codice:

git fetch https://gerrit.slimroms.net/SlimRoms/frameworks_base refs/changes/69/769/1 && git cherry-pick FETCH_HEAD

Vedrete scorrere il terminale, sta applicando il vostro commit!

Visto che questo commit si basa su 6 patch set, dovrete farlo per ogni patch set, ma è semplicissimo, visto che è soltanto un'operazione di copia ed incolla.

Nota bene: è probabile che il commit non venga applicato perché esiste un conflitto tra la vostra copia di codice sorgente che avete in locale ed il commit stesso.

http://i.imgur.com/W61fC7L.png

In questo caso dovrete capire quale file va in conflitto digitando dalla cartella dove avete applicato il codice:

codice:

git status

http://i.imgur.com/VkpYCiU.png

Come vedete dei 6 file (non patch set!) del patch set 1, non è riuscito a modificare il file packages/SystemUI/res/values/colors.xml perché esiste un conflitto. Come modificarlo?
Aggiungetelo preso paro paro dal commit eseguendo il comando

codice:

git add packages/SystemUI/res/values/colors.xml

e poi ridate il comando

codice:

git status

per verificare se tutto è andato bene.

http://i.imgur.com/Jxb9INf.png

Perfetto! Tutto unito al codice sorgente in locale, avete eseguito il vostro primo cherry pick!
Ma non è finita, se volete che il cherry-pick sia un "pick attivo" dovrete dire ai vostri sorgenti che c'è stato questo inserimento, per cui, sempre da dove siete dovrete digitare da terminale:

codice:

git add -A

e

codice:

git commit -a

Vi si aprirà un editor di testo a terminale chiamano nano che è abbastanza ostico da comprendere per chi arriva su Linux per la prima volta, ma è solo l'inizio.

http://i.imgur.com/WA0S4FJ.png

Notate all'estrema sinistra della finestra del terminale, c'è una serie di # che corrono per lungo dall'alto verso il basso. Universalmente (o quasi), quando una riga inizia con # significa che quella riga è una riga di "commento". Cosa significa? Nel linguaggio di programmazione python e PHP, è possibile scrivere delle righe di testo nel linguaggio comune (inglese, italiano etc) che non verranno lette dal compilatore (poiché le riconoscerebbe come errore sintattico del linguaggio che egli comprende), e servono per dare degli spunti, degli aiuti, dei promemoria o anche dei consigli al developer (o a sé stessi, tanti lo fanno). Per fare in modo che non vengano lette dal compilatore si antepone il simbolo #. Questo stratagemma rende possibile anche estromettere del codice che non si vuole far leggere al compilatore anteponendo, sempre, il simbolo #.
Questo concetto è stato esportato anche nella lettura dei vari file dove si intende estromettere parte del testo ed è questo il nostro caso: verso i 3/4 del vostro terminale notate i file che abbiamo appena modificato, preceduti dal simbolo #. Eliminando quel simbolo, direte che i file vanno applicati e modificati! Quindi, dal vostro terminale scendete col cursore (usando la tastiera) in corrispondenza delle 6 righe (una per volta) e cancellate il simbolo. Avrete la finestra identica all'immagine qui sopra (io vi mostro già le linee de-commentate, ossia senza il simbolo #).

Adesso non vi resta che salvare (ricordate che, anche se avete davanti il terminale, è un editor di testo in questo momento) usando la combinazione di tasti CTRL+O, dare invio e poi uscire dall'editor con la combinazione di tasti CTRL+X.

Questo è quello che dovreste trovarvi davanti in questo momento:

http://i.imgur.com/5GnicuS.png

Avete terminato l'applicazione del commit. Ricordatevi, comunque che per ogni patch set, dovrete applicare lo stesso procedimento. Git è automatico, sì, ma fino ad un certo punto!
31-01-14, 11:14
KlaasMad

Cherry-pickare da Github

Immaginiamo di voler cherrypickare da un github perché sappiamo che c'è una feature di una ROM che ci piace un sacco. Conoscendo di che tipo di feature si tratta, rechiamoci nel relativo github della ROM e nel progetto dove sappiamo essere il commit. Supponiamo di voler cherrypickare dal framework_base della OmniROM, nota ROM creata dall'elite di XDA.
Rechiamoci nella pagina del progetto ed avremo questo davanti:

http://i.imgur.com/Q5zrW4T.png

Nota bene: vi servirà un account github per fare ciò, clicca qui per sapere come configurarlo. [link in arrivo].

Clickate su Fork

http://i.imgur.com/Q9kRiUh.png

Attendete che forki il progetto (ossia che lo cloni sul vostro account, ci vorrà qualche secondo), dopo di che clickate dove è cerchiato:

http://i.imgur.com/YcsX1Lz.png

ebbene sì, in questo progetto ci sono più di 10.000 commits, non è semplicissimo trovare quello che vogliamo.

Supponiamo di voler cherry pickare la personalizzazione della navbar:

http://i.imgur.com/O2dHvxY.png

Nota bene: anche qui il commit si compone di due parti.

Clickiamoci sopra e si aprirà il commit. Qui si ha una struttura leggermente diversa da quella su gerrit: inizialmente avremo una lunga descrizione del commit, con i relativi conflitti da risolvere (ma sappiamo già farlo), il numero del commit e i file modificati che evidenziano, in verde, le aggiunte ed in rosso, le rimozioni di codice.
Ma focalizziamoci su un punto in particolare:

http://i.imgur.com/Fcxckr3.png

Quello è il numero identificativo del commit e ci servirà per integrarlo nel nostro codice! Come? Semplice, anche qui è tutto automatizzato:
Recatevi nel percorso che dovete modificare: il nome del progetto è android_frameworks_base quindi (rimuovendo la voce android_, tipica delle cyanogenmod e delle omnirom) sostituiamo i _ con gli slash e troveremo che il progetto è in frameworks/base

codice:

cd ~/sorgenti/cyanogenmod/frameworks/base

Il comando di cherry-pick è un po' diverso da quello per gerrit e dovrete scriverlo voi a mano. Per lo specifico commit che stiamo analizzando sarà:

codice:

git remote add klaasmad -f git@github.com:klaasmad/android_frameworks_base.git && git cherry pick 19442d7c6aa6b67a5474da0ed50b2ce799d1180d

Analizziamo il codice:

codice:

git remote add klaasmad -f

Aggiungerà il remoto (ricordate i manifest.xml?) chiamato klaasmad (il nome è opinabile, potete chiamarlo come volete, l'importante è il path dell'url).

codice:

git@github.com:klaasmad/android_frameworks_base.git

È il path dell'url github, via SSH.

codice:

&&

È la "e" congiunzione del terminale, significa di fare un comando "e" un altro comando.

codice:

git cherry pick

È il comando di cherry pick in sé.

codice:

19442d7c6aa6b67a5474da0ed50b2ce799d1180d

È l'ID del commit, quello cerchiato in rosso dell'immagine di sopra.

Dopo che avete scaricato il commit, applicate lo stesso procedimento di sopra per salvare la configurazione. Avete appena cherrypickato da github! Complimenti!

Perché all'inizio dello scaricamento del commit abbiamo forkato il progetto? Semplice, per tenere un track online di quello che stiamo facendo e, non avendo i permessi di scrittura (meno male) sui github delle ROM che non sono nostre, quello che possiamo fare è copiare il loro github (forkandolo) sul nostro account e lì pasticciare, cambiare, modificare, migliorare (perché no?) a nostro piacimento.

Dopo che avete completato il download del commit, "pushatelo", ossia spingetelo, nella vostra copia in remoto del progetto forkato in precedenza tramite il comando:

codice:

git push git@github.com:klaasmad/android_frameworks_base.git

Probabile che vi dia qualche errore di conflitto, i passi sono gli stessi: tramite il comando

codice:

git status

analizzate quali sono i file incriminati e poi manualmente o tramite l'aggiunta vista prima, li correggete.
31-01-14, 11:43
KlaasMad

Aggiungere progetti al local_manifest.xml

Abbiamo visto come cherry-pickare da un repository online (github) o da uno strumento di code review (gerrit) per una particolare feature e metterla nella nostra copia in local dei sorgenti. Ma se ci interessasse un'app per intero? Se avete seguito questa guida fino a qui, avete una copia dei repository del github di CyanogenMod. Mettiamo caso di volere integrata nella nostra ROM come app di sistema il File manager delle SlimROMs perché quello CM non è di nostro gradimento.
Per prima cosa è necessario verificare che l'app abbia i sorgenti aperti, basta googlare il nome dell'app seguita da github e come primo risultato troviamo la sua pagina. Fantastico, mettiamoci all'opera!

Come procediamo? Ricordate il manifest.xml? Scordatevelo. Come detto in precedenza, editare il manifest.xml (o default.xml) significa andare potenzialmente a modificare i sorgenti della ROM che state usando come base, andando ad influire sul lavoro di altri! E questo non lo vogliamo!

NB. i developers non sono idioti, ovviamente i codici sorgenti sono blindati a chi è dentro il gruppo di revisione del codice sorgente stesso, per cui, anche se editate il default.xml non modificherete i sorgenti della ROM. In compenso però, il comando di repo sync non funzionerà perché il default.xml in locale non corrisponde a quello in remoto.

Quindi, come abbiamo visto prima per aggiungere il device tree della ROM e per alleggerire i sorgenti da ciò che non ci serve, eseguiamo lo stesso procedimento modificando il file ~/sorgenti/cyanogenmod/.repo/local_manifests/local_manifest.xml

Al momento la nostra situazione è questa:

http://i.imgur.com/GwAbvmH.png

Per aggiungere lo Slim File Manager dovremo procedere attraverso i tag che sono utilizzati nel default.xml, praticamente tratteremo il local_manifest.xml come se fosse un'estensione del default.xml!
Per cui usiamo i tag:

codice:

<project path="" name="" remote="" revision="" />

Vediamo come. Aggiungiamo il testo proprio sotto le stringhe che abbiamo addizionato per rimuovere gli strumenti relativi a darwin (kernel del Mac) nella seguente maniera:

codice:

<project path="packages/apps/SlimFileManager" name="SlimRoms/packages_apps_SlimFileManager" remote="github" revision="kk4.4" />

Questo è quello che avremo:

http://i.imgur.com/OsP9f9p.png

Analizziamo meglio:
Innanzitutto potete notare la stringa in blu

codice:



Non vi ho parlato di questa stringa o almeno, l'ho fatto indirettamente. Ricordate quando abbiamo cherrypickato ed abbiamo decommentato rimuovendo i #? Stesso concetto qui, tutto ciò che è racchiuso tra  è un commento e non letto dal sistema. Ho fatto uso di questo strumento per indicare (a me stesso) che la prima parte di codice è relativo alla rimozione della roba (stuff) di Darwin, mentre la seconda porzione di codice è l'aggiunta dell'app SlimFileManager. Semplice no?

Allora, tornando a noi, salviamo e chiudiamo il local_manifest.xml, apriamo il terminale e dirigiamoci nella cartella dei nostri file sorgenti

codice:

cd ~/sorgenti/cyanogenmod

e diamo

codice:

repo sync

In questo modo sincronizzeremo tutto il contenuto nel default.xml e nel local_manifest.xml compresa la nostra app!

Non abbiamo ancora integrato l'app in sé e per sé nel codice, ne abbiamo solo scaricato i sorgenti.
Adesso dobbiamo andare a modificare un altro file con un'estensione che ancora non abbiamo visto, un makefile. Illustro due metodi che lo fanno in maniera identica, un metodo è per chi vuole usare l'interfaccia grafica, l'altro è tramite l'uso del terminale. Consiglio il secondo metodo per prendere maggiore confidenza col terminale stesso.

1° metodo

Aprite il vostro file manager, Thunar se avete installato la distro che vi ho consigliato io (Linux Mint 16 XFCE) e recatevi nella cartella sorgenti/cyanogenmod/build/target/product e cliccate col tasto destro del mouse sul file core.mk selezionando "apri con editor di testo".

2° medoto (consigliato)

Dal terminale date il comando

codice:

gedit ~/sorgenti/cyanogenmod/build/target/product/core.mk

Il risultato è identico, semplicemente facendolo da terminale prendete confidenza con questo strumento e lo fate anche in maniera più veloce.

Quick tip: durante la digitazione da terminale, se siete a metà di una parola e premete il tasto TAB sulla tastiera, il terminale vi completerà la parola da sé.

Comunque, avete aperto il file e vi si dovrebbe presentare questo:

http://i.imgur.com/X8O1Us6.png

Aggiungente, in ordine alfabetico, il nome dell'app per come l'avete indicata nel project path (packages/apps/SlimFileManager, prendiamo, ovviamente solo SlimFileManager) e un backslash che dice al sistema che dopo quella riga ce n'è un'altra (notate che l'ultima app indicata, VpnDialogs, non ha il backslash perché è l'ultima app da includere).

Il risultato è questo:

http://i.imgur.com/MkwNgom.png

Salvate e chiudete.
Congratulazioni, al prossimo processo di building, avrete integrato la vostra app!

Aggiungere apk precompilati

Purtroppo non tutte le app sono open-source e quindi non è possibile aggiungerle ai nostri sorgenti via local_manifest.xml, ma fortunatamente esiste un'alternativa. Possiamo implemetarle semplicemente in formato apk!
Prima di iniziare a spiegare come fare, è opportuno precisare che è assolutamente vietato inserire nelle proprie ROM (se pubbliche) degli apk a pagamento, anche se siete stati voi stessi a comprarle. Il perché è presto spiegato: fornirete copie di software a pagamento in maniera gratuita che è universalmente riconosciuto essere warez. Distribuire warez comporta il ban perentorio dal forum, uomo avvisato...

Vediamo come fare allora, ad implementare app gratuite nella propria ROM.

Per prima cosa, procuriamoci l'applicazione in sé. Potete scaricarla dal Play Store e con un root explorer, andarla a prelevare da /data/app, dopo di che salvatela sul pc.
Aprite fisicamente col vostro file manager la vostra cartella dei sorgenti ed andate in vendor/cm/prebuilt/common/app e copiate qui il vostro apk.

Quick tip: rinominate l'applicazione (sicuramente ancora chiamata com.nomeapp.nomedev) in nomeapp.apk (es. FileManager.apk), vi risparmierà sicuramente qualche typo.

Dopo di che, da terminale, andate nella cartella vendor/cm/config ed editate il file common.mk:

codice:

cd ~/sorgenti/cyanogenmod/vendor/cm/config && gedit common.mk

Dovreste avere davanti qualcosa del genere

http://i.imgur.com/lxICEkI.png

Ora, come abbiamo fatto per l'aggiunta dell'app col metodo precedente, facciamo ora in questo file, aggiungendo il solo nome dell'app, senza l'estensione .apk, seguito da uno spazio ed un backslash (solo se non è l'ultima app).
Avrete qualcosa del genere davanti:

http://i.imgur.com/bvQJu4Y.png

Finito! Eh sì, è abbastanza semplice farlo perché si salta la parte relativa alla compilazione (essendo già compilata!).
03-02-14, 11:55
KlaasMad

Effettuare il porting di una ROM usando il codice sorgente
Parte 1/2

Introduzione e spiegazione di qualche concetto base

Portare (trasposizione volgare del termine inglese "porting") una ROM significa aggiungere il supporto di un device, in via non ufficiale, alla ROM della quale si intendono sfruttare i sorgenti. In soldoni, volete una ROM non supportata? Farne il porting la renderà disponibile per il vostro device!
Questa operazione, a seconda della ROM che volete portare, può essere estremamente semplice, ma anche estremamente complicata e del tutto irrealizzabile per chi non ha le competenze in C. C++ ed anche java.
Mettiamo caso che abbiamo in nostro possesso un Samsung Galaxy SIV e vogliamo ottenere il supporto della notissima Carbon ROM, come procedere?

Partiamo col presupposto che l'operazione sarà tanto più facile quanto più ROM sono già state sviluppate per quel device, in particolare la CyanogenMod, che solitamente è il punto di inizio di un'infinità di queste, Carbon ROM in primis.

Reperimento device tree

Per capire al meglio le operazioni che stiamo andando a compiere è opportuno avere qualche concetto in testa.
Possiamo sommariamente (e non ufficialmente) suddividere i nostri sorgenti in 4 frazioni:

- la struttura della ROM, costituita da librerie, file .java, file .xml, makefile, toolchain etc etc, costituisce circa l'80% dei sorgenti ed è la ROM in sé e per sé.
- il device tree, ossia i sorgenti ed i file precompilati relativi all'hardware del device, contenuto nella cartella device/nomebrand/codename, costituisce il 10% dei sorgenti.
- il kernel del device, ossia i sorgenti del kernel contenuti nella cartella kernel/nomebrand/codename, costituisce il 7-8% dei sorgenti totali.
- il vendor tree, ossia i file proprietari dei quali non esistono i sorgenti, ma solo i file già compilati e sono nella cartella vendor/nomebrand/codename, costituiscono il 2-3% dei sorgenti totali.

NB. non esiste una suddivisione ufficiale ed ovviamente questa è abbozzata sommariamente per esemplificare il concetto del porting al massimo. Non prendetela come definizione vera!

Il porting, concettualmente, significa aggiungere le ultime 3 voci, ossia quelle strettamente collegate al dispositivo, alla prima, che è la ROM! Quindi ci mancano questi 3 aspetti dei sorgenti, vediamo come procurarceli.
Il modo migliore, come detto, è recarsi nel github della CyanogenMod e spulciare tutti i sorgenti alla ricerca del codename del nostro device. Nel caso specifico della Samsung Galaxy SIV, il codename è jfltevzw.

Quick tip: come fare a trovarlo velocemente senza spulciare? Conoscendo il codename del device, è sufficiente recarsi alla home del github della CM, aggiungere uno slash all'URL e aggiungere android_device_samsung_jfltevzw (nota bene: i sorgenti CM-based antepongono sempre la voce android_ al nome in sé del sorgente).

Quindi abbiamo trovato il repository giusto, che, nel nostro caso è questo!

Scrollate i vari file e troverete il file cm.dependencies

http://i.imgur.com/6lpyQhs.png

cliccateci sopra ed avrete questo davanti

http://i.imgur.com/CKsYBXi.png

Alla riga "repository", avrete dei percorsi tutti anteceduti da android_: queste sono le dipendenze del vostro device!

In diverse tab del vostro browser, incollate ognuna di queste dipendenze alla home del github della CyanogenMod e, su ognuna di queste pagine, cliccate su "Fork"

http://i.imgur.com/vpQbpLn.png

in modo da trasferirle sul vostro account github.

Tempo di syncare!

Proprio come abbiamo editato il local_manifest.xml per aggiungere nuove app o per rimuovere i progetti a noi inutili nei sorgenti CyanogenMod, andiamo a scaricare la configurazione base della ROM Carbon e ad aggiungere il device tree (ossia la somma dei repository trovati nel file cm.dependencies) nel nostro manifesto.

Da terminale digitate:

codice:

cd sorgenti mkdir carbon cd carbon

Ci servono le istruzioni per scaricare lo scheletro dei nostri sorgenti, rechiamoci nel github della Carbon ROM (googlatelo se non sapete come si chiama il github che vi interessa) che possiamo trovare qui.
Come detto in precedenza, i sorgenti basati sulla ROM CyanogenMod, assumono la forma github.com/<nomesorgente>/android_<nomerepository>, ma a noi non serve un repo in particolare, bensì il comando per scaricare tutto che, sempre nella CM-based, è dentro la cartella android_ stessa (ovviamente senza _), per cui rechiamoci su github.com/carbondev/android e noteremo i comandi necessari.

Quick tip: mentre sulle CM-based troviamo le istruzioni nella cartella android, le altre ROM seguono un altro schema e solitamente troviamo le istruzioni per il download in github.com/<nomerom>/platform_manifest o semplicemente github.com/<nomerom>/manifest

Scrollate fin quando non troverete il comando repo init (visto che il processo di installazione del tool repo e della creazione delle directory per i sorgenti li abbiamo già espletati), che una volta trovato, avrà questa sembianza:

http://i.imgur.com/yT44R1c.png

Notate come abbia cerchiato soltanto una parte del codice, analizziamolo per un attimo tutto quanto al meglio per capire perché (risulterò prolisso, ma è necessario per far capire tutti quanti):

codice:

repo init -u https://github.com/CarbonDev/android.git -b kk && repo sync -f

Abbiamo già incontrato i simboli && e, se ricordiamo meglio, sono la congiunzione tra due comandi in un unico solo, che quindi consta di:

codice:

repo init -u https://github.com/CarbonDev/android.git -b kk

e

codice:

repo sync -f

Il primo comando inizializza la struttura dei sorgenti secondo il branch kk (che è quello che ci serve a noi), mentre il secondo fa partire direttamente il sync. Visto che stiamo supponendo di aggiungere il supporto per un device che non è incorporato nel loro github, prima di cominciare a scaricare col comando repo sync, dobbiamo snellire il codice da eventuali device a noi inutili ed aggiungere il supporto al device di nostro interesse! E perché aspettare che scarichi tutto, cancellare quel che non ci serve e poi riaggiungere ciò che ci serve? Facciamo tutto subito e via!
Quindi, lasciamo perdere il comando di repo sync e focalizziamoci sul primo. Da terminale diamo:

codice:

cd sorgenti/carbon repo init -u https://github.com/CarbonDev/android.git -b kk

Nel giro di qualche secondo avremo scaricato lo scheletro dei nostri sorgenti che saranno nella cartella sorgenti/carbon/.repo (il puntino prima di repo sta ad indicare che la cartella è nascosta, secondo lo standard linux). Dobbiamo editare ed aggiungere i nostri progetti che abbiamo forkato precedentemente, quindi da terminale:

codice:

cd .repo mkdir local_manifests cd local_manifests gedit local_manifest.xml

Col primo comando entriamo nella cartella nascosta .repo, col secondo creiamo la cartella local_manifests, col terzo ci entriamo dentro e con l'ultimo creiamo il file local_manifest.xml (possiamo fare anche tutto col file manager, ma serve per prendere confidenza col terminale).

Nell'editor di testo, aggiungiamo lo standard di formattazione per gli xml in modo che il documento sia così:

http://i.imgur.com/mUFJxe9.png

Vi copincollo qui la formattazione per agevolarvi l'operazione e per prevenire typo:

codice:

<?xml version="1.0" encoding="UTF-8"?> <manifest> </manifest>

NB. invece di chiamarlo local_manifest.xml, io l'ho chiamato roomservices.xml, è la stessa cosa.

Ora, attraverso gli stessi tag che trovate nel default.xml (~/sorgenti/carbon/.repo/manifests/default.xml), aggiungiamo il device tree

codice:

<project name="NomeUtente/android_device_samsung_qcom-common" path="device/samsung/qcom-common" remote="github" revision="kk" /> <project name="NomeUtente/android_device_samsung_msm8960-common" path="device/samsung/msm8960-common" remote="github" revision="kk" /> <project name="NomeUtente/android_device_samsung_jf-common" path="device/samsung/jf-common" remote="github" revision="kk" /> <project name="NomeUtente/android_kernel_samsung_jf" path="kernel/samsung/jf" remote="github" revision="kk" /> <project name="NomeUtente/android_hardware_samsung" path="hardware/samsung" remote="github" revision="kk" />

Ecco cosa avremo davanti una volta completato:

http://i.imgur.com/cqLCIOx.png

NB. a NomeUtente dovrete sostituire il vostro nome utente su github, così come dovrete sostituire il nome del remote e della revision in base a come sono stati impostati, rispettivamente, nel default.xml e nel github. Non sto a sottolinearvi che i repository presi in considerazione valgono solo e soltanto per Samsung Galaxy IV.

Salvate e chiudete che è ora di syncare! Da terminale:

codice:

cd ~/sorgenti/carbon repo sync -f

NB. in questo caso ho aggiunto l'opzione -f solo perché, come possiamo vedere da github.com/carbondev/android.git ci viene consigliato di farlo per alcuni problemi col motore della piattaforma git di Google che blocca i sync più veloci di 4 jobs (quando effettuiamo un repo sync, viene implicitamente specificata anche l'opzione -j4). L'opzione -f fa in modo che vengano syncati senza problemi (e serve anche per correggere eventuali errori di sync o sync interrotti dall'utente/remoto).

Al termine del sync avrete tutti i sorgenti che vi serviranno.

CONTINUA AL POST SUCCESSIVO
03-02-14, 16:56
KlaasMad

Effettuare il porting di una ROM usando il codice sorgente
Parte 2/2

Abbiamo tutti i sorgenti necessari, ma non è finita qui. Difatti è qui che arriva la parte complicata che varia da ROM a ROM e da device a device. Non essendo possibile trattare tutte le ROM in circolazione e non essendo possibile trattare tutti i device in circolazione, accennerò il procedimento essenziale, poi, purtroppo, cambia da caso a caso e la frammentazione è molta.
Nel caso delle CM-based, dovremo ottenere i file proprietari che andranno a piazzarsi in vendor/nomebrand/codename e lo faremo nello stesso modo in cui lo abbiamo fatto per la CyanogenMod. Colleghiamo il device al pc (nel nostro caso il Samsung Galaxy SIV) e da terminale diamo:

codice:

cd sorgenti/carbon/device/samsung/jfltevzw ./extract-files.sh

In questo modo andremo ad eseguire lo script extract-files.sh contenuto nella cartella sorgenti/carbon/device/samsung/jfltevzw. Questo andrà a creare la struttura di file proprietari in sorgenti/carbon/vendor/samsung/jfltevzw.

Adesso abbiamo i file prebuildati.

Quick tip: è possibile ottenerli anche in un altro modo: difatti possiamo recarci nel github di una ROM già sviluppata per il nostro device e forkare il vendor tree del nostro device ed aggiungerlo al local_manifest.xml (proprio come abbiamo fatto per gli altri sorgenti) secondo il path corretto (vendor/nomebrand/codename). Non è detto che funzioni, non tutti rilasciano i file proprietari nei loro sorgenti (ed è qui che ci ricolleghiamo al discorso di porting molto semplice o molto difficile).

Ora, rechiamoci nuovamente nel github della ROM che vogliamo portare, nel nostro caso la Carbon e andiamo a guardare il vendor della ROM reperibile in vendor_nomerom (essendo una CM-based sarà android_vendor_nomerom), quindi github.com/carbondev/android_vendor_carbon. Clicchiamo su commits

http://i.imgur.com/hqodRSz.png

e scrolliamoli tutti finché non troviamo un commit relativo all'aggiunta di un nuovo device

http://i.imgur.com/CfzvxpW.png

Clicchiamoci e guardiamo la struttura del commit.
Siamo stati fortunati: in questo caso per aggiungere un nuovo device, sarà necessario soltanto aggiungere una sola riga di codice al file ~/sorgenti/carbon/vendor/carbon/vendorsetup.sh

http://i.imgur.com/dpmqClL.png

NB. Ovviamente al codename del LG G2 dovremo sostituire il codename del nostro device.

http://i.imgur.com/yXxujsE.png

NB. è assolutamente necessario seguire l'ortografia degli altri setup, altrimenti non builderete.

Adesso è la volta di modificare i file dentro il device tree in modo da farli combaciare col vendor tree.
Andate fisicamente col gestore file nella cartella ~/sorgenti/carbon/device/samsung/jfltevzw e spulciatevi tutti i file con estensione .mk alla volta di trovare ogni referenza alla CyanogenMod (o cm), per sostituirla con la parola "carbon" (senza virgolette ovviamente). Notate anche il file cm.mk, che è da sostituire con carbon.mk. È un'operazione lunga e tediosa e spesso porterà a diversi errori, ma purtroppo, nel caso non esista il vendor tree già bello confezionato nel github di qualche ROM, è l'unica opzione plausibilmente efficace.

È tempo di modificare anche un file all'interno dei sorgenti del kernel. Rechiamoci fisicamente col filemanager in ~/sorgenti/carbon/kernel/nomebrand/nomekernel/arch/arm/configs.
Ci saranno una serie (ma anche uno solo) di file, cerchiamo quello con la referenza al nostro device (nel caso di multipli file) e modifichiamo il nome del file secondo quanto indicato nel file ~/sorgenti/carbon/device/nomebrand/codename/BoardConfig.mk alla stringa

codice:

TARGET_KERNEL_CONFIG :=

Una volta terminata quest'operazione, da terminale rechiamoci nella root dei sorgenti:

codice:

cd ~/sorgenti/carbon . build/envsetup.sh lunch

Se siamo stati attenti, dovrebbe essere spuntata la voce del nostro device nel terminale, come da immagine:

http://i.imgur.com/UZRu8qV.png

Siamo pronti a buildare (si spera)!

codice:

make carbon -j7

NB. questa volta il comando di build è cambiato perché le istruzioni presenti in github.com/carbondev/android.git ce lo hanno imposto.

http://i.imgur.com/HggYt6D.png

Se siamo fortunati, il processo di build andrà avanti e si completerà da solo, altrimenti si renderà necessaria la modifica di qualche file (saprete quale in base all'errore che il terminale vi restituisce).
Se avete degli errori dei quali non riuscite a venirne a capo, chiedete assistenza in questo thread https://www.androidiani.com/forum/in...ammazione.html.
07-02-14, 21:09
KlaasMad

Come buildare il proprio kernel
Parte 1/2

Ipotesi: abbiamo già la nostra bella ROM preferita che non vogliamo modificare (o non ne ha necessità, perché no?), ma sentiamo il bisogno di modificare il kernel per migliori performance/battery life. Perché non crearci il nostro bel kernel personalizzato per poter inserire al suo interno tutte le features che vogliamo? In fondo Android poggia su una variante del kernel Linux con l'obbligo di essere open source, quindi possiamo tranquillamente metterci mano!
Vediamo come procedere.

Prefazione

Iniziamo col dire, sottolineando, che un kernel per un particolare dispositivo non va assolutamente e nella maniera più assoluta, installato/flashato su un altro dispositivo, neanche della stessa marca o vagamente simile (tipo tra i9100 e i9105), pena il brick del vostro telefono. Questo è l'errore più banale e più pericoloso da fare, quindi non mettetevi in testa di flashare un kernel di un dispositivo solo perché è simile o perché vi piace la sua struttura!

Come effetto collaterale di questa "regola" di android, c'è quello che questa guida non è e non potrà mai essere universale per ogni device. La guida qui di seguito non è intesa per qualsiasi dispositivo, ma sono linee guida generali (pensate voi di creare una guida per ogni device in circolazione, da uscirne pazzi!). Se avete problemi, potete sempre chiedere nel thread SOS di questa sezione.

La guida segue la traduzione di un'altra guida che feci a suo tempo per il mio device (i9100), riadattata per ogni device, quindi perdonatemi se non segue il trend esplicativo delle altre guide in questo thread.

Step 1. Ambiente

Abbiamo già completato questi passi, però rieseguite il codice sul terminale, magari qualche pacchetto può essere stato tralasciato nella prima fase.

A. Dovrete buildare su Linux (e questo già lo sappiamo fare).[/I]

B. Pacchetti richiesti: git-core, gnupg, flex, bison, gperf, libsdl-dev, libesd0-dev, libwxgtk2.8-dev, build-essential, zip, curl, libncurses5-dev, zlib1g-dev, lib32z1, lib32ncurses5, lib32bz2-1.0, lib32z1-dev, lib32ncurses5-dev, gcc-multilib, g++-multilib, e Adb.
Quindi per installare le dipendenze richieste, da terminale digitiamo:

codice:

sudo apt-get install git-core gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.8-dev build-essential zip curl libncurses5-dev zlib1g-dev lib32z1 lib32ncurses5 lib32bz2-1.0 lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib

e per installare adb, potete installarlo via terminale:

codice:

sudo apt-get install android-tools-adb

NB. il forum storpia il codice ed inserisce una "k" ed una chiocciola "@" di troppo, per cui sarebbe android, trattino, tools, trattino e alla fine adb.

o potete trovarlo nella cartella dove avete estratto SDK, a sua volta dentro la cartella platform-tools.

Installate anche git:

codice:

sudo apt-get install git

C. Aprite un terminale (ctrl+alt+t su Ubuntu)

D. Digitate "mkdir android" (crea la cartella android) (non inserite le virgolette)

E. Digitate "cd android" (entra dentro la cartella android)

G. Digitate "mkdir kernel" (crea la cartella kernel)

F. Chiudete il terminale.

Step 2. Vostri sorgenti

A. Aprite il terminale

B. Digitate "cd android/kernel" (entra dentro la cartella kernel situata dentro la cartella android)

C. Digitate "git clone git://github.com/DooMLoRD/android_prebuilt_toolchains.git toolchains" (recupera attraverso il comando git clone, il toolchains e lo piazza dentro la cartalla toolchains)

D. Adesso arriva la parte difficile, vi serve alcuni tipi di sorgenti per il vostro kernel. Controllate i due seguenti siti per il vostro dispositivo. Una volta che li avete scaricati, devono essere estratti o clonati dentro una cartella nella tua directory del kernel

Welcome to HTCdev
Samsung Open Source Release Center
Developer World
OpenSource Code Distribution

Cos'è un toolchain? Date un'occhiata qui. Questi toolchains sono instabili e non totalmente supportati ancora. Queste sono le versioni che uso e se volete usare una versione stabile (4.5.3 as of 07/06/12) trovate il link su google.

Step 3. Modifiche

Questa è la parte che incuriosisce la gente, loro vorrebbero sapere come fare modifiche al kernel e renderlo speciale. Comincia tutto questo che viene dalla root directory (~/android/kernel) del sorgente del kernel.

Mod 1. Applicare una patch

A. Scarica la patch che vuoi applicare, in questo caso questa dovrebbe funzionare.

B. Salvate il file come "kernelPatch" nella vostra directory del kernel

C. Aprite un terminale

D. Spostate dentro la root del vostro kernel la directory del kernel che volete patchare

E. Digitate "patch -p1 < ../kernelPatch"

Spiegazione:
A. Semplice, ci serve una patch. La patch in se stessa è semplice e differisce dall'originale albero (tree) del codice del kernel.
Posterà un veloce tutoria su come creare una patch nel terzo post. La patch sopra contiene diversi governor da aggiungere al vostro kernel.

B. Si spiega da sé.
C. Si spiega da sé.
D. Si spiega da sé.
E. In pratica lanciamo il comando della patch sulla nostra sorgente usando la patch che abbiamo scaricato prima. La porzione della patch è il binario, l'opzione "-p1" ci consente di controllare il numero di successivi slash (/) da rimuovere dal percorso del file (vi servirà di guardare quest'opzione più che usare una strana struttura di directory o di applicare le patch da un posto a casaccio) L'operatore "<" dirige il contenuto del nostro file "../kernelPatch" nel comando.

Mod 2. Aggoiungere un singolo governor

A. Aprite "drivers/cpufreq/Kconfig"

B. Aggiungete le seguenti stringe in uno spazio appropriato tra gli altri governorAdd the following lines in appropriate spot amongst the other govenor's

codice:

config CPU_FREQ_DEFAULT_GOV_SMARTASS bool "smartass" select CPU_FREQ_GOV_SMARTASS select CPU_FREQ_GOV_PERFORMANCE help Use the CPUFreq governor 'smartass' as default.

codice:

config CPU_FREQ_GOV_SMARTASS tristate "'smartass' cpufreq governor" depends on CPU_FREQ help smartass' - a "smart" optimized governor! If in doubt, say N.

C. Aprite "drivers/cpufreq/Makefile"
D. Aggiungete le seguenti stringhe in uno spazio appropriato.

codice:

obj-$(CONFIG_CPU_FREQ_GOV_SMARTASS) += cpufreq_smartass.o

E. Create a file chiamato "drivers/cpufreq/cpufreq_smartass.c" (l'ha spiegato un po' a cazzo di cane, il file è cpufreq_smartass.c dentro la direcotry drivers/cpufreq).

F. Inserite il sequente codice in quel file
[C] Smartass Kernel Govenor - Pastebin.com

G. Aprite "include/linux/cpufreq.h"

H. Sotto la sezione "Cpufreq Default" aggiugnete

codice:

#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_SMARTASS) extern struct cpufreq_governor cpufreq_gov_smartass; #define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_smartass)

Ok, c'è un governor aggiunto, fate gli stessi identici step per qualunque altro governor che vogliate aggiungere.

Spiegazione:

A. Aprite un file che avete già. Il Kconfig file ci lega dentro il nostro comando "make menuconfig" più tardi, facendo sì che la nostra mod sia un'opzione selezionabile.

B. Aggiungete il codice appropriato per il nostro governor per avere il nostro file .config. Il primo trancio ci permette di settare il nostro governor come default per il nostro kernel, l'altro ci permette di rimuoverlo o aggiungerlo alla build come vogliamo.

E-F. La creazione del governor stesso, non saltate questo passo. Suggerisco di leggere attrraverso questo codice per capire come funziona, è qualcosa di strepitoso.

G-H. Apre un file e aggiunge il codice necessario per legare il nostro modulo al resto del sorgente. Senza questo non saremo capaci di compilare il dovuto resto del sorgente senza conoscere se il modulo esiste.

Step 4. Ottenere un file config

Opzione A. Prendere un config file da un kernel.

A. Agganciare un device che sta usando un kernel simile al tuo e usarlo come base.

B. Aprite un terminale.

C. Andate nella vostra directory root del kernel.

D. Digitate "adb pull /proc/config.gz"

E. Digitate "gunzip config.gz"

F. Digitate "mv config arch/arm/configs/<your_config_name>_defconfig"

Spiegazione:

A. Questo vi permetterà di prendere un file di configurazione da un kernel che sapete funzionare. È molto più facile iniziare così. Come nota, non tutti i kernel supportano quest'opzione, così devi provarne diversi prima di avere il file funzionante. Se non funziona, guarda l'opzione B.

B. Ormai siete bravi a farlo.

C. Naviga verso la parte più alta della directory del tuo kernel.

D. Usa adb per prendere una copia del file config per i tuoi sorgenti.

E. Unzippa il file di configurazione.

F. Sposta il file di configurazione che hai preso verso la directory di configo così possiamo usarlo come referenza più tardi.

Opzione B. Usare il config del produttore.

Sfortunatamente, come detto sopra, non tutti i kernel supportano il metodo "/proc/config.gz". Puoi trovare un file di configurazione tipicamente nel percorso di configurazione del produttore "arch/arm/configs". Credo che quello per il mio HTC Flyer è chiamato "flyer_hc_defconfig", così dovrebbe essere (almeno simile) per te Inoltre leggi i readme per farti un'idea di come modificarli. Io farei una copia di esso chiamata "<your_config_name>_defconfig" e usarla come mia base.

CONTINUA AL POST SUCCESSIVO
07-02-14, 21:15
KlaasMad

Come buildare il proprio kernel
Parte 2/2

Step 5. Building

È tempo di partire col vero atto del building.

Part A. Step prebuild.

A. Apri un terminale e vai nella root del tuo kernel

B. Digitate "export ARCH=arm"

C. Digitate "export CROSS_COMPILE=~/android/kernel/toolchains/arm-eabi-linaro-4.6.2/bin/arm-eabi-"

Part B. La prima build.

A. Digitate "make <your_config_name>_defconfig"

B. Digitate "make menuconfig" e fate i cambiamenti richiesti per usare qualsiasi modulo avete aggiunto.

C. Digitate "make -j<maximum number of jobs>" (I jobs sono le operazioni per volta che la macchina esegue. Solitamente si fa [numero di core del pc] x2, ma tanti tengono la tesi di [numero di core del pc]+1. Io personalmente quando buildo faccio make -j8 ossia 4 core x2.)

Part C. Re-Builds

A. Digitate "make clean"

B. Digitate "make oldconfig"

C. Digitate "make -j<maximum number of jobs>"

Part D. Building i moduli

Avete due opzioni:

A. Digitate "make modules"

B. Digitate "make path/to/your/module.ko"

Spiegazione:

Parte A. (Questi step sono richiesti ogni volta che chiudi il terminale e lo riapri)

A. Ok, non lo spiego più.

B. Questo comando setta il tuo obbiettivo dell'architettura (arm, x86, powerpc etc)

C. Definisce il percorso per il toolchain che stiamo per usare per compilare il kernel. Puoi cambiarlo indicando il percorso di qualunque toolchain hai scaricato o ti senti di usare. Il modo in cui è configurato è per usare il toolchain Linaro usato sopra.

Parte B. (Questi devono essere eseguire la prima volta che buildi il kernel)

A. Carica il tuo file di configurazione da prima.

B. Apri un meno per configurare il kernel. Userà il file di config caricato nel precedenti step come basi.

C. L'inizio del build. Tipicamente permetto un job per core, così sulla mia macchina quad core metto "make -j4". Aumentare il numero non renderà la build più velocemente, il tuo processore deve essere in grado di supportare i jobs che gli stai assegnando.

Parte C. (usate i comandi quando build qualsiasi volta che non sia la prima)

A. Questo comando soddisfa ogni vecchio binario o modulo che avete compilato prima e iniziamolo daccapo. Mi piace eseguirlo ogni build, a meno che i miei cambiamenti piccoli e localizzati.

B. Un meraviglioso comando: analizza quello che ha cambiato e ti conduce verso le nuove opzioni.

C. Vedi la spiegazione per la parte C sopra.

Parte D.(usa questi per buildare i moduli del kernel

A. Quest ribuilderà tutti i moduli.

B. Rebuilderà solo il modulo che ti serve. Utilissimo quando dovrai rebuildare il modulo wifi.

Step 6. Ed ora?

Ok, abbiamo cominciato a buildare ed aspettiamo che finisca. Quali sono i possibili risultati?

Risultato A. La build riesce

Grande! Hai buildato il tuo primo kernel dai sorgenti! Ci sono un paio di cose che ti serviranno per usare questo kernel nel tuo device: qualsiasi modulo ".ko" (kernel object) e i binary zImage. Se presti attentione all'output del compilatore, vedrai la locazione di questi oggetti. Comunque i seguenti comandi ti renderanno la vita un pelo più semplice:

A. Aprite un terminal

B. Andate nella root directory del kernel

C. Digitate "mkdir ../<tuo_kernel>_output"

D. Digitate "cp arch/arm/boot/zImage ../<tuo_kernel>_output/zImage"

E. Digitate "find . -name "*.ko" -exec cp {} ../<your_kernel>_output \;"

Spiegazione:

A-C. Si spiegano da sé

D. Spostate i binari del nostro kernel nella cartella di output

E. Questo tocco di magia trova tutti i moduli .ko e li copia nel file di output.

Vi servirà inoltre di assemblare l'immagine del kernel contenente gli iniramfs per il vostro device, assieme ai binari del kernel. Quello comunque è oltre lo scopo di questa guida. Per iniziare, provate a cercare le sequenti frasi.

codice:

building android kernel image xda build kernel image xda unpack boot.img

Risultato B. La build fallisce

Oh, è fallita. Beh, sai cosa, succederà un sacco di volte. Googla e sperimenta diverse soluzioni. I seguenti consigli cercheranno di aiutarti nel debug.

Esegui una build pulita.

A. Backuppa il tuo file di config (digitate "cp .config ../backupConfig")
B. Ri-eseguite il processo di build usando il vostro defconfig dall'inizio.

Limitate l'output

A. Un altro buon consiglio è quello di eseguire "make -j1" per capire dove sta l'errore, così il testo di output nel terminale sarà più lento e potrete scovarlo.

Potete comunque postare nel thread di SOS development per provare a risolvere insieme agli altri utenti.
Il bello è comunque provare e riprovare! Non vi aspettate nella maniera più assoluta di riuscire al primo colpo, ricordate quello che ho scritto all'inizio di questa maxiguida, gli errori del terminale saranno i vostri compagni più fedeli, saranno sempre lì, per aiutarvi a crescere, fateli vostri amici!
07-02-14, 21:19
KlaasMad

Post riservato per eventuali aggiunte riguardo al building del kernel.
07-02-14, 23:14
KlaasMad

Il comando Git e la sua integrazione con Github

Prefazione

Immaginate di dover scrivere un breve programma in java che vi restituisca a video il vostro nome. Peserà a mala pena 15KB e vi occuperà lo spazio di un file in estensione .java in una cartellina remota (uhm termine inappropriato per questa parte della guida, diciamo sperduta) del vostro pc. Spostarla da un pc ad un altro vi costerà in termini di tempo, più nel prendere fisicamente la pen drive che nello spostamento in sé. Ora, immaginate di avere il file su una cartella locale in file sharing (tipo una cartella su DropBox) e che sullo stesso ci lavoraste su in due persone da due pc diversi: data la minutezza del file e la semplicità di esso, non avreste problemi a coordinarvi per sapere cosa modificare e quando modificare, in modo da non accalcarvi in due sullo stesso punto del progetto e non sovrascrivere eventuali cambiamenti fatti da una o dall'altra parte.
Ma ciò è possibile su un piccolo file da 15KB. Ecco, ora immaginate di lavorare su una build di una ROM android, quindi con dei sorgenti da 12GB con una miriade di file che constano in una miriade di righe di codice e siete un team che sta modificando il framework dei settings. Ad un certo momento, in 4 persone (i membri del vostro team) decidete di salvare e non sapevate di lavorare sullo stesso file. I cambiamenti fatti verranno sovrascritti dall'ultimo che salva il file, facendo perdere il lavoro fatto dagli altri fino a quel momento, che può constare di qualche riga di codice, ma che può constare anche di diverse centinaia di righe!
Avreste perso un corposo lavoro e, soprattutto la sanità mentale del membro al quale avete cancellato il lavoro!

A cosa serve questo preambolo? No, non è un delirio, è il concetto di fondo sul quale si basa Github ed il comando sul quale è basato Github stesso, ossia Git!

Due righe di riferimento storico su Git è necessario spenderle, visto che è stato creato dal padre del kernel Linux stesso, Linus Torvalds a creare questo utilissimo comando. Git è un sistema di controllo di versione, direttamente usabile da riga di comando (ossia usando il vostro terminale) e permette di tenere degli "snapshots" del vostro lavoro, in modo da tornare tranquillamente indietro (nel caso quel che avete fatto è solo un abominio di programmazione o, per dire, se capite che non sia utile ciò a cui avete lavorato). Inoltre, citando l'esempio fatto prima sul piccolo programma in java condiviso, è possibile lavorare in due (o più) sullo stesso file su locale e, una volta uploadato, git tiene in conto entrambe (o più) le versioni del file e fa decidere all'utente se e quando unirli (merge) e se e quando scartarli (discard).
Prima di addentrarci nel mondo dei comandi git, è necessario introdurre un concetto fondamentale, il concetto di commit: il commit è, appunto, lo snapshot o, per dirla in maniera videoludica, il checkpoint dove arrivate e salvate, per poi tornate indietro in caso di errore/perdita di dati/sovrapposizione di scrittura. In pratica è quel che rende git il grandioso strumento che è!

Parimenti, introduciamo github. Sebbene ne abbiamo ampiamente parlato nei precedenti step della guida, adesso ne approfondiamo la conoscenza perché sarà un altro dei nostri grandi alleati nella conquista delle capacità di buildare una ROM.
Github è un social network (avete letto bene) dove è possibile uploadare il proprio codice sorgente (in pienissimo spirito open source), mostrarlo al pubblico, seguire e farsi seguire da altri developer. È controllato da git per l'integrazione del codice e quindi, riprendendo l'esempio del team che lavora su una ROM, posto che 4 persone lavorano sullo stesso file sulla copia locale dei sorgenti (scaricata mediante il comando repo sync, ricordate?), è possibile salvare uno snapshot attraverso il comando git commit, uploadare i file e tenere 4 copie del file stesso che poi si deciderà se fargli eseguire il merge o cancellare/modificare qualcosa.
Premettiamo un concetto che può sembrare banale, ma che in realtà non lo è per chi non è avvezzo di programmazione e simili. Github è un grandioso strumento perché contiene il codice sorgente di programmi/sistemi operativi/kernel ed in generale tutto software. Cosa significa? Avere il codice sorgente non significa avere il software già bello "assemblato" (perdonate il termine), ma solo i "pezzi" ed è da costruire. Noi possiamo assemblare il software, ma possiamo anche cambiarlo, modificarlo, ridurlo, aumentarlo, possiamo farci tutto quello che vogliamo. Discorso contrario se avessimo solo e soltanto il software già bello che costruito. In questo caso non potremo farci nulla, solo eseguirlo, senza poter vedere com'è fatto dentro, senza sapere il funzionamento. Esistono dei tool per decompilare ma non sono sempre estremamente precisi e comunque, funzionano (quando funzionano) su software semplici.

Quindi, cosa fa Github? Vi mette a disposizione i pezzi del vostro puzzle (i sorgenti, come quelli che abbiamo scaricato come prova per la rom), ma sta a voi metterli insieme!
Iscriversi non è molto diverso da come fareste per qualsiasi social network, Facebook, Google+ o Twitter che sia, ma richiede qualche passo aggiuntivo mediante il vostro beneamato strumento, chiamato terminale.

Iscrizione a Github

Recatevi nella home di github ed avrete questa schermata davanti

http://i.imgur.com/LCTqrYs.png

Non sto a spiegarvi come compilare i campi ovviamente.
Successivamente, aprite il vostro fidato terminale ed installiamo git (lo abbiamo già fatto seguendo la prima parte di questa maxiguida, ma per chi si imbattesse qui ed è solo interessato a github, ecco):

codice:

sudo apt-get install git

Configuriamo git con l'email usata per registrarci:

codice:

git config --global user.name "Vostro nome" git config --global user.email "vostraemail@vostraemail.com"

Creiamo una keygen che ci servirà da firma digitale:

codice:

ssh-keygen -t rsa -C "vostraemail@vostraemail.com"

Vi chiederà di inserire una passphrase, questa dovrete deciderla voi e cercate di tenerla in mente (o comunque segnatevela da qualche parte).

Il responso del terminale sarà qualcosa del genere:

codice:

# Your identification has been saved in /c/Users/you/.ssh/id_rsa. # Your public key has been saved in /c/Users/you/.ssh/id_rsa.pub. # The key fingerprint is: # 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db vostraemail@youremail.com

Adesso da terminale digitate:

codice:

cd ~/.ssh && gedit id_rsa.pub

Questo comando vi porterà nella cartella nascosta .ssh e aprirà con gedit il file id_rsa.pub. Lasciatelo aperto e recatevi su https://github.com/settings/ssh, cliccate su Add SSH key:

http://i.imgur.com/7CsqvMM.png

Tornate sul vostro gedit e copiate il contenuto del file, incollandolo nella casella in basso:

http://i.imgur.com/of0yudG.png

Da terminale controllache che funzioni tutto digitando:

codice:

ssh -T git@ssh.github.com

Vi richiederà la vostra passphrase secondo la chiave id_rsa.pub che avete inserito prima. Se non riuscite ad accedere via ssh, da terminale digitate:

codice:

gedit ~/.ssh/config

Ed inserite il seguente testo nel file che vi si aprirà

codice:

Host github.com Hostname ssh.github.com Port 443

Salvate ed uscite.
Da terminale testate se riuscite ad accedere digitando:

codice:

ssh -T -p 443 git@ssh.github.com

Dovreste visualizzare qualcosa del genere:

codice:

# Hi vostronome! You've successfully authenticated, but GitHub does not # provide shell access.

Avete configurato Github!

Work in progress...

http://www.waitmag.com/wp-content/up...012/10/mug.jpg