Sebelum Android 7.0 dirilis, Android menggunakan GNU Make secara eksklusif untuk mendeskripsikan dan menjalankan aturan build-nya. Sistem Make build didukung dan digunakan secara luas, namun pada skala Android menjadi lambat, rawan kesalahan, tidak dapat diskalakan, dan sulit untuk diuji. Sistem build Soong memberikan fleksibilitas yang diperlukan untuk build Android.
Oleh karena itu, pengembang platform diharapkan untuk beralih dari Make dan mengadopsi Soong sesegera mungkin. Kirim pertanyaan ke Google Grup pembuat android untuk menerima dukungan.
Apa itu Soon?
Sistem build Soong diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Make. Ini memanfaatkan alat kloning Kati GNU Make dan komponen sistem pembuatan Ninja untuk mempercepat pembuatan Android.
Lihat deskripsi Android Make Build System di Android Open Source Project (AOSP) untuk petunjuk umum dan Build System Changes untuk Android.mk Writers guna mempelajari modifikasi yang diperlukan untuk beradaptasi dari Make ke Soong.
Lihat entri terkait build di glosarium untuk definisi istilah-istilah utama dan file referensi Soong untuk detail selengkapnya.
Perbandingan Make dan Soon
Berikut ini perbandingan konfigurasi Make dengan Soong yang melakukan hal yang sama dalam file konfigurasi Soong (Cetak Biru atau .bp ).
Berikan contoh
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libxmlrpc++
LOCAL_MODULE_HOST_OS := linux
LOCAL_RTTI_FLAG := -frtti
LOCAL_CPPFLAGS := -Wall -Werror -fexceptions
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/src
LOCAL_SRC_FILES := $(call \
all-cpp-files-under,src)
include $(BUILD_SHARED_LIBRARY)
Contoh segera
cc_library_shared {
name: “libxmlrpc++”,
rtti: true,
cppflags: [
“-Wall”,
“-Werror”,
“-fexceptions”,
],
export_include_dirs: [“src”],
srcs: [“src/**/*.cpp”],
target: {
darwin: {
enabled: false,
},
},
}
Lihat Konfigurasi Build Sederhana untuk contoh konfigurasi Soong khusus pengujian.
Format file Android.bp
Secara desain, file Android.bp sederhana. Mereka tidak berisi pernyataan kondisional atau aliran kontrol; semua kompleksitas ditangani oleh logika build yang ditulis dalam Go. Jika memungkinkan, sintaksis dan semantik file Android.bp mirip dengan file Bazel BUILD .
Modul
Modul dalam file Android.bp dimulai dengan tipe modul diikuti dengan sekumpulan properti dalam name: "value", format:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Setiap modul harus memiliki properti name , dan nilainya harus unik di semua file Android.bp , kecuali untuk nilai properti name di namespace dan modul bawaan, yang mungkin berulang.
Properti srcs menentukan file sumber yang digunakan untuk membangun modul, sebagai daftar string. Anda dapat mereferensikan output modul lain yang menghasilkan file sumber, seperti genrule atau filegroup , dengan menggunakan sintaks referensi modul ":<module-name>" .
Untuk daftar jenis modul yang valid dan propertinya, lihat Referensi Modul Soong .
Jenis
Variabel dan properti diketik dengan kuat, dengan variabel secara dinamis berdasarkan pada penugasan pertama, dan properti diatur secara statis berdasarkan tipe modul. Jenis yang didukung adalah:
- Boolean (
trueataufalse) - Bilangan bulat (
int) - Senar (
"string") - Daftar string (
["string1", "string2"]) - Peta (
{key1: "value1", key2: ["value2"]}
Peta mungkin berisi nilai jenis apa pun, termasuk peta bertingkat. Daftar dan peta mungkin memiliki tanda koma setelah nilai terakhir.
Gumpalan
Properti yang mengambil daftar file, seperti srcs , juga dapat mengambil pola glob. Pola glob dapat berisi wildcard UNIX normal * , misalnya *.java . Pola glob juga dapat berisi satu karakter pengganti ** sebagai elemen jalur, yang cocok dengan nol atau lebih elemen jalur. Misalnya, java/**/*.java cocok dengan pola java/Main.java dan java/com/android/Main.java .
Variabel
File Android.bp mungkin berisi penetapan variabel tingkat atas:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Variabel dicakup ke seluruh file yang dideklarasikannya, serta file Blueprint turunan apa pun. Variabel tidak dapat diubah dengan satu pengecualian: variabel dapat ditambahkan dengan penugasan += , namun hanya sebelum variabel tersebut direferensikan.
Komentar
File Android.bp dapat berisi komentar /* */ multiline gaya C dan komentar // baris tunggal gaya C++.
Operator
String, daftar string, dan peta dapat ditambahkan menggunakan operator +. Bilangan bulat dapat dijumlahkan menggunakan operator + . Menambahkan peta menghasilkan gabungan kunci di kedua peta, menambahkan nilai kunci apa pun yang ada di kedua peta.
Persyaratan
Soong tidak mendukung persyaratan dalam file Android.bp . Sebaliknya, kompleksitas dalam aturan build yang memerlukan kondisional ditangani di Go, di mana fitur bahasa tingkat tinggi dapat digunakan, dan dependensi implisit yang diperkenalkan oleh kondisional dapat dilacak. Sebagian besar kondisional dikonversi menjadi properti peta, di mana salah satu nilai dalam peta dipilih dan ditambahkan ke properti tingkat atas.
Misalnya, untuk mendukung file khusus arsitektur:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
Pemformat
Soong menyertakan pemformat kanonik untuk file Blueprint, mirip dengan gofmt . Untuk memformat ulang semua file Android.bp di direktori saat ini secara rekursif, jalankan:
bpfmt -w .
Format kanonik mencakup indentasi empat spasi, baris baru setelah setiap elemen daftar multielemen, dan tanda koma di akhir daftar dan peta.
Modul khusus
Beberapa kelompok modul khusus mempunyai karakteristik yang unik.
Modul default
Modul default dapat digunakan untuk mengulangi properti yang sama di beberapa modul. Misalnya:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Modul bawaan
Beberapa jenis modul bawaan memungkinkan modul memiliki nama yang sama dengan modul berbasis sumber. Misalnya, mungkin ada cc_prebuilt_binary bernama foo ketika sudah ada cc_binary dengan nama yang sama. Hal ini memberikan fleksibilitas kepada pengembang untuk memilih versi mana yang akan disertakan dalam produk akhir mereka. Jika konfigurasi build berisi kedua versi, nilai tanda prefer dalam definisi modul bawaan menentukan versi mana yang memiliki prioritas. Perhatikan bahwa beberapa modul bawaan memiliki nama yang tidak diawali dengan prebuilt , seperti android_app_import .
Modul ruang nama
Hingga Android sepenuhnya berkonversi dari Make ke Soong, konfigurasi produk Make harus menentukan nilai PRODUCT_SOONG_NAMESPACES . Nilainya harus berupa daftar namespace yang dipisahkan spasi yang diekspor Soong ke Make untuk dibuat dengan perintah m . Setelah konversi Android ke Soong selesai, detail pengaktifan namespace dapat berubah.
Soong memberikan kemampuan bagi modul di direktori berbeda untuk menentukan nama yang sama, selama setiap modul dideklarasikan dalam namespace terpisah. Namespace dapat dideklarasikan seperti ini:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Perhatikan bahwa namespace tidak memiliki properti nama; jalurnya secara otomatis ditetapkan sebagai namanya.
Setiap modul Soong diberi namespace berdasarkan lokasinya di pohon. Setiap modul Soong dianggap berada dalam namespace yang ditentukan oleh soong_namespace yang ditemukan dalam file Android.bp di direktori saat ini atau direktori leluhur terdekat. Jika tidak ada modul soong_namespace yang ditemukan, modul tersebut dianggap berada dalam namespace root implisit.
Berikut ini contohnya: Soong mencoba menyelesaikan ketergantungan D yang dideklarasikan oleh modul M di namespace N yang mengimpor namespace I1, I2, I3…
- Kemudian jika D adalah nama formulir yang sepenuhnya memenuhi syarat
//namespace:module, hanya namespace tertentu yang dicari untuk nama modul yang ditentukan. - Jika tidak, Soong pertama-tama mencari modul bernama D yang dideklarasikan di namespace N.
- Jika modul tersebut tidak ada, Soong mencari modul bernama D pada namespace I1, I2, I3…
- Terakhir, Soong mencari di namespace root.