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

[KlaasMad]

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!

[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.

[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:

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:

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:

sudo apt-get install ubuntu-restricted-extras

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

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:

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

Ora copiate ed incollate il seguente testo nel vostro editor:

# 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:

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:

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:

sudo apt-get install schedtool pngcrush

Installiamo Java:

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

Dopo di che digitate:

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:

mkdir ~/bin

Aggiungete la cartella ~/bin nel path dando:

PATH=~/bin:$PATH

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

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

Dategli i permessi:

chmod a+x ~/bin/repo

Repo è ora installato! Non ci resta che preparare il nostro percorso di download dei sorgenti!

[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:

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):

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:

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:

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:



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:



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



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



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

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:

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.

[KlaasMad]

Preparazione del building

Otteniamo i prebuilts

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

cd sorgenti/cyanogenmod/vendor/cm

./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

 gedit .bashrc

3. Aggiungete le seguenti linee di 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:

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:

cd sorgenti/cyanogenmod

Attivate lo script per il build:

. 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:

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:

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

Nel caso del Nexus 7 2012 WiFi:

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

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

Dopo di che digitate:

./extract-files.sh

Vedrete i file proprietari trasportati sul pc.

Adesso digitate:

croot

Tornerete nella cartella ~/sorgenti/cyanogenmod automaticamente.

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

repo sync

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

. 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!

[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

cd prebuilts/gcc/linux-x86/arm/

Attenzione: la cartella giusta è prebuilts, non prebuilt.



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:

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:

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

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

Al termine del download eseguite

bunzip2 *.tar.bz2

e

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:



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).



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.



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.



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:

/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.

[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:



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:



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).

cd ~/sorgenti/cyanogenmod/frameworks/base

ora incollate il codice che avete copiato poco fa:

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.



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

git status

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

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

e poi ridate il comando

git status

per verificare se tutto è andato bene.



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:

git add -A

e

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.



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:



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!

[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:



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

Clickate su Fork



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



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:



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:



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

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à:

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

Analizziamo il 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).

git@github.com:klaasmad/android_frameworks_base.git

È il path dell'url github, via SSH.

&&

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

git cherry pick

È il comando di cherry pick in sé.

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:

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

git status

analizzate quali sono i file incriminati e poi manualmente o tramite l'aggiunta vista prima, li correggete.

[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:



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:

<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:

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

Questo è quello che avremo:



Analizziamo meglio:
Innanzitutto potete notare la stringa in blu

<!-- SlimFileManager -->

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

cd ~/sorgenti/cyanogenmod

e diamo

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

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:



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:



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:

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

Dovreste avere davanti qualcosa del genere



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:



Finito! Eh sì, è abbastanza semplice farlo perché si salta la parte relativa alla compilazione (essendo già compilata!).

[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



cliccateci sopra ed avrete questo davanti



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"



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:

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:



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):

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:

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

e

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:

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:

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ì:



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

<?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

  <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:



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:

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