Sebelum rilis Android 7.0, Android menggunakan GNU Make secara eksklusif untuk menjelaskan dan menjalankan aturan pembuatannya. Sistem Make build didukung dan digunakan secara luas, tetapi pada skala Android menjadi lambat, rawan kesalahan, tidak dapat diskalakan, dan sulit untuk diuji. Sistem pembangunan Soong memberikan fleksibilitas yang diperlukan untuk pembangunan Android.
Untuk alasan ini, pengembang platform diharapkan untuk beralih dari Make dan mengadopsi Soong sesegera mungkin. Kirim pertanyaan ke Google Group pembuat android untuk menerima dukungan.
Apa itu Soong?
Sistem pembangunan Soong diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Make. Ini memanfaatkan alat klon Kati GNU Make dan komponen sistem pembangunan Ninja untuk mempercepat pembangunan Android.
Lihat deskripsi Android Make Build System di Android Open Source Project (AOSP) untuk petunjuk umum dan Build System Changes for Android.mk Writers untuk mempelajari tentang modifikasi yang diperlukan untuk beradaptasi dari Make to Soong.
Lihat entri terkait build di glosarium untuk definisi istilah kunci dan file referensi Soong untuk detail lengkapnya.
Membuat dan segera perbandingan
Berikut adalah perbandingan Make configuration dengan Soong yang melakukan hal yang sama dalam file konfigurasi Soong (Blueprint atau .bp ).
Buat 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 Pembuatan Sederhana untuk contoh konfigurasi Soong khusus pengujian.
Format file Android.bp
Secara desain, file Android.bp sederhana. Mereka tidak berisi kondisional atau pernyataan aliran kontrol; semua kerumitan ditangani oleh logika build yang ditulis dalam Go. Jika memungkinkan, sintaks 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 ruang nama 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 penugasan pertama, dan properti disetel secara statis oleh tipe modul. Jenis yang didukung adalah:
- Boolean (
trueataufalse) - Bilangan bulat (
int) - String (
"string") - Daftar string (
["string1", "string2"]) - Peta (
{key1: "value1", key2: ["value2"]})
Peta dapat berisi nilai jenis apa pun, termasuk peta bersarang. 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 yang 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 dicakupkan ke sisa file tempat mereka dideklarasikan, serta file Blueprint anak apa pun. Variabel tidak dapat diubah dengan satu pengecualian: mereka dapat ditambahkan dengan tugas += , tetapi hanya sebelum mereka direferensikan.
Komentar
File Android.bp dapat berisi komentar gaya C multiline /* */ dan gaya C++ single-line // .
Operator
String, daftar string, dan peta dapat ditambahkan menggunakan operator +. Bilangan bulat dapat dijumlahkan menggunakan operator + . Menambahkan peta menghasilkan penyatuan kunci di kedua peta, menambahkan nilai kunci apa pun yang ada di kedua peta.
bersyarat
Soong tidak mendukung persyaratan dalam file Android.bp . Sebaliknya, kompleksitas dalam aturan pembangunan yang memerlukan persyaratan ditangani di Go, di mana fitur bahasa tingkat tinggi dapat digunakan, dan dependensi implisit yang diperkenalkan oleh persyaratan dapat dilacak. Sebagian besar kondisional dikonversi ke properti peta, di mana salah satu nilai di 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 formatter kanonik untuk file Blueprint, mirip dengan gofmt . Untuk memformat ulang semua file Android.bp di direktori saat ini, jalankan:
bpfmt -w .
Format kanonik mencakup indentasi empat spasi, baris baru setelah setiap elemen dari daftar multielemen, dan tanda koma di daftar dan peta.
Modul khusus
Beberapa kelompok modul khusus memiliki karakteristik yang unik.
Modul default
Modul default dapat digunakan untuk mengulang properti yang sama di beberapa modul. Sebagai contoh:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Modul yang sudah dibuat sebelumnya
Beberapa jenis modul bawaan memungkinkan sebuah modul memiliki nama yang sama dengan rekan-rekan berbasis sumbernya. Misalnya, mungkin ada cc_prebuilt_binary bernama foo ketika sudah ada cc_binary dengan nama yang sama. Ini memberi pengembang fleksibilitas untuk memilih versi mana yang akan disertakan dalam produk akhir mereka. Jika konfigurasi build berisi kedua versi, nilai flag prefer dalam definisi modul bawaan akan menentukan versi mana yang memiliki prioritas. Perhatikan bahwa beberapa modul bawaan memiliki nama yang tidak dimulai dengan prebuilt , seperti android_app_import .
Modul namespace
Hingga Android sepenuhnya mengonversi dari Make to Soong, konfigurasi produk Make harus menentukan nilai PRODUCT_SOONG_NAMESPACES . Nilainya harus berupa daftar ruang nama yang dipisahkan oleh spasi yang Soong ekspor ke Make untuk dibuat dengan perintah m . Setelah konversi Android ke Soong selesai, detail pengaktifan ruang nama dapat berubah.
Soong menyediakan kemampuan bagi modul di direktori yang berbeda untuk menentukan nama yang sama, selama setiap modul dideklarasikan dalam namespace yang 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 di namespace yang ditentukan oleh soong_namespace yang ditemukan di file Android.bp di direktori saat ini atau direktori ancestor terdekat. Jika tidak ada modul soong_namespace yang ditemukan, modul dianggap berada di root namespace 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 yang sepenuhnya memenuhi syarat dari formulir
//namespace:module, hanya namespace yang ditentukan yang akan dicari untuk nama modul yang ditentukan. - Jika tidak, Soong pertama-tama mencari modul bernama D yang dideklarasikan di namespace N.
- Jika modul itu tidak ada, Soong mencari modul bernama D di ruang nama I1, I2, I3…
- Terakhir, Soong mencari di root namespace.