Invece di (od oltre a) includere APK da fonti esterne in un repository, è possibile compilarli direttamente dal codice sorgente.
Usando questo metodo, è possibile verificare che l’applicazione si compili correttamente, corrisponda al codice sorgente, e contenga solo software libero. Sfortunatamente, nel mondo Android, sembra essere molto frequente che un’applicazione fornita come APK si presenti come “software libero” quando in realtà alcune delle condizioni seguenti (se non tutte) sono vere:
- Il codice sorgente (per una versione specifica, o persino tutte le versioni!) non è disponibile o è incompleto.
- Il codice sorgente non è in grado di produrre il file binario effettivamente fornito.
- Il “codice sorgente” contiene file binari di orgine sconosciuta, o con licenze propietarie.
Per questa ragione, le applicazioni compilate dal codice sorgente sono il metodo preferito per il repository principale di F-Droid, anche se occasionalmente, per ragioni tecniche o storiche, si fanno delle eccezioni a questa politica.
Quando si costruiscono applicazioni dalla sorgente, va notato che le si firmerà (tutti i file APK devono essere firmati per essere installabili su Android) con la propria chiave. Quando un’applicazione è già installata su un dispositivo, non è possibile aggiornarla a una nuova versione firmata con una chiave diversa senza prima disinstallare l’originale. Ciò può rappresentare un inconveniente per gli utenti, in quanto il processo di disinstallazione perde i dati associati alla precedente installazione.
Il processo di gestione di un repository per applicazioni built-from-source è molto simile a quello descritto nel capitolo del Simple Binary Repository, tranne che ora è necessario:
- Includere le voci Build nei file di metadati.
- Eseguire
fdroid build
per costruire qualsiasi applicazione che non sia già stata costruita. - Eseguire
fdroid publish
per finalizzare l’imballaggio e firmare gli APK che sono stati costruiti.
Cartella dei dati dell’app, denominata fdroiddata
Per fare qualsiasi cosa, è necessaria almeno una directory di dati del
repository. È da questa directory che si esegue il comando fdroid
per
eseguire tutte le attività di gestione del repository. È possibile crearne
una nuova, oppure prendere una copia dei dati utilizzati dal repository
principale di F-Droid:
git clone https://gitlab.com/fdroid/fdroiddata.git
Indipendentemente dall’uso previsto degli strumenti, sarà sempre necessario
impostare alcuni dettagli di configurazione di base. Questo viene fatto
creando un file chiamato config.yml nella directory dei dati. Si dovrebbe
fare questo copiando il file di esempio (./examples/config.yml
) dal
progetto fdroidserver nella directory dei dati e poi modificandolo secondo
le istruzioni al suo interno.
Una volta configurato in questo modo, si accede a tutte le funzionalità
degli strumenti eseguendo il comando fdroid
. Eseguirlo da solo per
ottenere una lista dei sottocomandi disponibili.
È possibile seguire qualsiasi comando con ---aiuto
per ottenere una lista
di opzioni aggiuntive disponibili per quel comando.
fdroid update --help
Maggiori informazioni su fdroid build
Quando viene eseguito senza parametri, fdroid build
costruirà tutte le
versioni di applicazioni che non si hanno già nella directory repo
(o più
precisamente, la directory unsigned
). Ci sono varie altre cose che si
possono fare. Come per tutti gli strumenti, l’opzione --help
è vostra
amica, ma segue qualche esempio commentato e la discussione delle modalità
di utilizzo più comuni:
Per costruire una singola versione di una singola applicazione, è possibile eseguire quanto segue:
fdroid build org.fdroid.fdroid:16
Questo tenta di costruire il codice della versione 16 (che è la versione 0.25) del client F-Droid. Molti degli strumenti riconoscono gli argomenti come pacchetti, permettendo di limitare la loro attività ad un insieme limitato di pacchetti.
Se la compilazione di cui sopra ha avuto successo, due file saranno stati
inseriti nella directory unsigned
:
org.fdroid.fdroid_16.apk
org.fdroid.fdroid_16_src.tar.gz
Il primo è l’APK (non firmato). Potreste firmarlo con una chiave di debug e spingerlo direttamente sul vostro dispositivo o su un emulatore per i test. Il secondo è un tarball sorgente contenente esattamente la sorgente che è stata usata per generare il binario.
Se si intendeva pubblicare questi file, è possibile eseguire:
fdroid publish
The source tarball would move to the repo
directory (which is the
directory you would push to your web server). A signed and zipaligned
version of the APK would also appear there, and both files would be removed
from the unsigned
directory.
Se si sta costruendo solo a scopo di test, e non si intende spingere i
risultati in un repository, almeno per ora, l’opzione --test
può essere
usata per indirizzare l’output alla directory tmp
invece di unsigned
. Un
effetto simile potrebbe essere ottenuto semplicemente cancellando i file di
output da unsigned
dopo la compilazione, ma con il rischio di dimenticarsi
di farlo!
In modo simile (e solo in combinazione con --test
, è possibile utilizzare
--force
per forzare la costruzione di un’applicazione Disabled, dove
normalmente verrebbe completamente ignorata. Allo stesso modo una versione
che si è trovata a contenere ELF o librerie note Non-Libere può essere
forzata a costruire. Vedi anche - scanignore e scandelete nella sezione
Builds.
Se la build non ha avuto successo, si può scoprire il perché guardando l’output nella directory logs/. Se questo non è illuminante, provate a costruire l’app nel modo normale, passo dopo passo: progetto di aggiornamento di androide, ndk-build, debug lento.
Si noti che i repository di codice sorgente spesso contengono librerie pre-costruite. Se l’applicazione viene presa in considerazione per il repository principale di F-Droid, è importante che tutti questi pre-costruiti siano costruiti o tramite i metadati o da una terza parte rispettabile.
Esecuzione di fdroid build
nel sorgente della vostra app
Un’altra opzione per l’utilizzo di fdroid build
è quella di utilizzare un
file di metadati incluso nel sorgente stesso dell’applicazione, piuttosto
che in una cartella metadata/ con molte altre applicazioni. Il file di
metadati .fdroid.yml dovrebbe essere nella root del repo sorgente.
Una volta che si dispone di tale configurazione, è possibile costruire la versione più recente dell’applicazione utilizzando l’intero stack di F-Droid eseguendo:
fdroid build
Se si desidera compilare ogni singola versione, specificare --all
.
Installazione diretta
You can also build and install directly to a connected device or emulator
using the fdroid install
command. If you do this without passing packages
as arguments then all the latest built and signed version available of each
package will be installed . In most cases, this will not be what you want to
do, so execution will stop straight away. However, you can override this if
you’re sure that’s what you want, by using --all
. Note that currently, no
sanity checks are performed with this mode, so if the files in the signed
output directory were modified, you won’t be notified.