Formato file Android.bp

Per progettazione, i file Android.bp sono semplici. Non contengono istruzioni condizionali o di controllo del flusso; tutta la complessità è gestita dalla logica di build scritta in Go.

Moduli

Un modulo in un file Android.bp inizia con un tipo di modulo seguito da un insieme di proprietà in formato name: "value",:

cc_binary {
    name: "gzip",
    srcs: ["src/test/minigzip.c"],
    shared_libs: ["libz"],
    stl: "none",
}

Ogni modulo deve avere una proprietà name e il valore deve essere univoco in tutti i file Android.bp, ad eccezione dei valori della proprietà name negli spazi dei nomi e nei moduli predefiniti, che possono ripetersi.

La proprietà srcs specifica i file di origine utilizzati per creare il modulo come elenco di stringhe. Puoi fare riferimento all'output di altri moduli che producono file di origine, come genrule o filegroup, utilizzando la sintassi di riferimento del modulo ":<module-name>".

Per un elenco dei tipi di moduli validi e delle relative proprietà, consulta il riferimento ai moduli Soong.

Tipi

Le variabili e le proprietà sono fortemente tipizzate, con variabili basate dinamicamente sul primo assegnamento e proprietà impostate staticamente dal tipo di modulo. I tipi supportati sono:

  • Valori booleani (true o false)
  • Numeri interi (int)
  • Stringhe ("string")
  • Elenchi di stringhe (["string1", "string2"])
  • Maps ({key1: "value1", key2: ["value2"]})

Le mappe possono contenere valori di qualsiasi tipo, incluse le mappe nidificate. Gli elenchi e le mappe potrebbero avere virgole finali dopo l'ultimo valore.

Globs

Le proprietà che accettano un elenco di file, come srcs, possono accettare anche pattern glob. I pattern glob possono contenere il carattere jolly UNIX normale *, ad esempio *.java. I pattern glob possono contenere anche un singolo carattere jolly ** come elemento del percorso, che corrisponde a zero o più elementi del percorso. Ad esempio, java/**/*.java corrisponde sia al pattern java/Main.java sia al pattern java/com/android/Main.java.

Variabili

Un file Android.bp può contenere assegnazioni di variabili di primo livello:

gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
    name: "gzip",
    srcs: gzip_srcs,
    shared_libs: ["libz"],
    stl: "none",
}

Le variabili sono limitate al resto del file in cui sono dichiarate, nonché a tutti i file di bozza secondari. Le variabili sono immutabili, con una sola eccezione: possono essere aggiunte con un'assegnazione +=, ma solo prima che siano state referenziate.

Commenti

I file Android.bp possono contenere commenti /* */ multiriga in stile C e commenti // su una sola riga in stile C++.

Operatori

Stringhe, elenchi di stringhe e mappe possono essere aggiunti utilizzando l'operatore +. I numeri interi possono essere sommati utilizzando l'operatore +. L'aggiunta di una mappa produce l'unione delle chiavi in entrambe le mappe, aggiungendo i valori di tutte le chiavi presenti in entrambe le mappe.

Moduli predefiniti

Gli sviluppatori possono utilizzare un modulo predefinito per ripetere le stesse proprietà in più moduli. Ad esempio:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

Moduli predefiniti

Alcuni tipi di moduli predefiniti consentono a un modulo di avere lo stesso nome delle controparti basate sull'origine. Ad esempio, può esistere un cc_prebuilt_binary denominato foo quando esiste già un cc_binary con lo stesso nome. In questo modo, gli sviluppatori possono scegliere quale versione includere nel prodotto finale. Se una configurazione di compilazione contiene entrambe le versioni, il valore del flag prefer nella definizione del modulo precompilato determina quale versione ha la priorità. Tieni presente che alcuni moduli predefiniti hanno nomi che non iniziano con prebuilt, ad esempio android_app_import.

Moduli dello spazio dei nomi

Finché Android non esegue la conversione completa da Make a Soong, la configurazione del prodotto Make deve specificare un valore PRODUCT_SOONG_NAMESPACES. Il suo valore deve essere un elenco di spazi dei nomi separati da spazi che Soong esporta in Make per essere compilati dal comando m. Una volta completata la conversione di Android a Soong, i dettagli dell'attivazione degli spazi dei nomi potrebbero cambiare.

Soong consente ai moduli in directory diverse di specificare lo stesso nome, purché ogni modulo sia dichiarato all'interno di uno spazio dei nomi separato. Gli sviluppatori possono dichiarare uno spazio dei nomi:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

Tieni presente che uno spazio dei nomi non ha una proprietà name; il suo percorso viene assegnato automaticamente come nome.

A ogni modulo Soong viene assegnato uno spazio dei nomi in base alla sua posizione nell'albero. Ogni modulo Soong è considerato nello spazio dei nomi definito da soong_namespace trovato in un file Android.bp nella directory corrente o nella directory principale più vicina. Se non viene trovato alcun modulo soong_namespace, il modulo viene considerato nello spazio dei nomi radice implicito.

Ecco un esempio: Soong tenta di risolvere la dipendenza D dichiarata dal modulo M nello spazio dei nomi N che importa gli spazi dei nomi I1, I2, I3…

  1. Se D è un nome completo nel formato //namespace:module, viene cercato solo lo spazio dei nomi specificato per il nome del modulo specificato.
  2. In caso contrario, Soong cerca prima un modulo denominato D dichiarato nello spazio dei nomi N.
  3. Se questo modulo non esiste, Soong cerca un modulo denominato D negli spazi dei nomi I1, I2, I3…
  4. Soong cerca nello spazio dei nomi radice.

Condizionali

Soong non supporta le condizioni nei file Android.bp. Invece, la complessità delle regole di compilazione che richiederebbero condizioni viene gestita in Go, dove è possibile utilizzare funzionalità di linguaggio di alto livello e le dipendenze implicite introdotte dalle condizioni possono essere monitorate. La maggior parte delle condizioni viene convertita in una proprietà della mappa, in cui uno dei valori della mappa viene selezionato e aggiunto alle proprietà di primo livello.

Ad esempio, per supportare file specifici dell'architettura:

cc_library {
    ...
    srcs: ["generic.cpp"],
    arch: {
        arm: {
            srcs: ["arm.cpp"],
        },
        x86: {
            srcs: ["x86.cpp"],
        },
    },
}

Formattatore

Soong include un formattatore canonico per i file Blueprint, simile a gofmt. Per riformattare in modo ricorsivo tutti i file Android.bp nella directory corrente, esegui:

bpfmt -w .

Il formato canonico include rientri di quattro spazi, nuove righe dopo ogni elemento di un elenco con più elementi e una virgola finale in elenchi e mappe.