Por design, os arquivos Android.bp
são simples. Eles não contêm condicionais ou instruções de fluxo de controle; toda a complexidade é tratada pela lógica de construção escrita em Go. Quando possível, a sintaxe e a semântica dos arquivos Android.bp
são semelhantes aos arquivos Bazel BUILD .
Módulos
Um módulo em um arquivo Android.bp
começa com um tipo de módulo seguido por um conjunto de propriedades em name: "value",
formato:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Cada módulo deve ter uma propriedade name
, e o valor deve ser exclusivo em todos os arquivos Android.bp
, exceto para os valores da propriedade name
em namespaces e módulos pré-construídos, que podem se repetir.
A propriedade srcs
especifica os arquivos de origem usados para construir o módulo, como uma lista de strings. Você pode referenciar a saída de outros módulos que produzem arquivos de origem, como genrule
ou filegroup
, usando a sintaxe de referência de módulo ":<module-name>"
.
Para obter uma lista de tipos de módulos válidos e suas propriedades, consulte a Referência de Módulos Soong .
Tipos
Variáveis e propriedades são fortemente tipadas, com variáveis baseadas dinamicamente na primeira atribuição e propriedades definidas estaticamente pelo tipo de módulo. Os tipos suportados são:
- Booleanos (
true
oufalse
) - Inteiros (
int
) - Sequências (
"string"
) - Listas de strings (
["string1", "string2"]
) - Mapas (
{key1: "value1", key2: ["value2"]}
)
Os mapas podem conter valores de qualquer tipo, incluindo mapas aninhados. Listas e mapas podem ter vírgulas finais após o último valor.
Globos
Propriedades que usam uma lista de arquivos, como srcs
, também podem usar padrões glob. Os padrões Glob podem conter o curinga normal do UNIX *
, por exemplo *.java
. Os padrões glob também podem conter um único curinga **
como elemento de caminho, que corresponde a zero ou mais elementos de caminho. Por exemplo, java/**/*.java
corresponde aos padrões java/Main.java
e java/com/android/Main.java
.
Variáveis
Um arquivo Android.bp
pode conter atribuições de variáveis de nível superior:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
As variáveis têm como escopo o restante do arquivo em que são declaradas, bem como quaisquer arquivos filhos do Blueprint. Variáveis são imutáveis com uma exceção: elas podem ser anexadas com uma atribuição +=
, mas somente antes de serem referenciadas.
Comentários
Os arquivos Android.bp
podem conter comentários //
de linha única /* */
de várias linhas no estilo C e // de linha única no estilo C++.
Operadores
Strings, listas de strings e mapas podem ser anexados usando o operador +. Os números inteiros podem ser somados usando o operador +
. Acrescentar um mapa produz a união de chaves em ambos os mapas, anexando os valores de quaisquer chaves presentes em ambos os mapas.
Condicionais
Soong não oferece suporte a condicionais em arquivos Android.bp
. Em vez disso, a complexidade nas regras de construção que exigiriam condicionais é tratada em Go, onde recursos de linguagem de alto nível podem ser usados e dependências implícitas introduzidas por condicionais podem ser rastreadas. A maioria das condicionais são convertidas em uma propriedade de mapa, onde um dos valores do mapa é selecionado e anexado às propriedades de nível superior.
Por exemplo, para oferecer suporte a arquivos específicos de arquitetura:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Formatador
Soong inclui um formatador canônico para arquivos Blueprint, semelhante ao gofmt . Para reformatar recursivamente todos os arquivos Android.bp
no diretório atual, execute:
bpfmt -w .
O formato canônico inclui recuos de quatro espaços, novas linhas após cada elemento de uma lista de vários elementos e uma vírgula final em listas e mapas.