Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Sistem Bangun Soong

Sebelum rilis Android 7.0, Android menggunakan GNU Make secara eksklusif untuk mendeskripsikan dan menjalankan aturan build-nya. Sistem Make build didukung dan digunakan secara luas, tetapi pada skala Android menjadi lambat, rentan kesalahan, tidak dapat diskalakan, dan sulit untuk diuji. Sistem build Soong memberikan fleksibilitas yang diperlukan untuk build Android.

Untuk itu, developer platform diharapkan beralih dari Make dan mengadopsi Soong secepatnya. Kirim pertanyaan ke Google Grup yang membangun android untuk menerima dukungan.

Apa Soong?

Sistem build Soong diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Make. Ini memanfaatkan alat klon Kati GNU Make dan komponen sistem build Ninja untuk mempercepat build Android.

Lihat deskripsi Android Make Build System di Android Open Source Project (AOSP) untuk petunjuk umum dan Perubahan Sistem Build untuk Penulis Android.mk guna mempelajari tentang modifikasi yang diperlukan untuk beradaptasi dari Make ke Soong.

Lihat entri terkait build dalam glosarium untuk definisi istilah kunci dan file referensi Soong untuk detail lengkapnya.

Perbandingan Make dan Soong

Berikut adalah perbandingan konfigurasi Make dengan Soong yang melakukan hal yang sama dalam file konfigurasi Soong (Blueprint atau .bp ).

Beri 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 soong

cc_library_shared {
     name: “libxmlrpc++”,

     rtti: true,
     cppflags: [
           “-Wall”,
           “-Werror”,
           “-fexceptions”,
     ],
     export_include_dirs: [“src”],
     srcs: [“src/**/*.cpp”],

     target: {
           darwin: {
                enabled: false,
           },
     },
}

Lihat Konfigurasi Bangun Sederhana untuk contoh konfigurasi Soong khusus pengujian.

Format file Android.bp

Secara desain, file Android.bp sederhana. Mereka tidak berisi pernyataan conditional atau control flow; semua kompleksitas ditangani oleh logika build yang ditulis di Go. Jika memungkinkan, sintaks dan semantik file Android.bp mirip dengan file Bazel BUILD .

Modul

Modul dalam file Android.bp dimulai dengan jenis modul yang 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 membuat modul, sebagai daftar string. Anda dapat mereferensikan keluaran modul lain yang menghasilkan file sumber, seperti genrule atau filegroup , dengan menggunakan sintaks referensi modul ":<module-name>" .

Untuk daftar tipe modul yang valid dan propertinya, lihat Referensi Soong Modules .

Jenis

Variabel dan properti sangat diketik, dengan variabel secara dinamis didasarkan pada tugas pertama, dan properti disetel secara statis menurut jenis modul. Jenis yang didukung adalah:

  • Boolean ( true atau false )
  • Bilangan bulat ( int )
  • String ( "string" )
  • Daftar string ( ["string1", "string2"] )
  • Peta ( {key1: "value1", key2: ["value2"]} )

Peta mungkin 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 menggunakan pola glob. Pola globe dapat berisi karakter pengganti UNIX normal * , misalnya *.java . Pola globe 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 dibatasi ke sisa file yang dideklarasikannya, serta file Blueprint turunannya. Variabel tidak dapat diubah dengan satu pengecualian: variabel dapat ditambahkan dengan += assignment, tetapi hanya sebelum direferensikan.

Komentar

Android.bp file dapat berisi C-gaya multiline /* */ dan C ++ style single-line // komentar.

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 kondisional 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 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"],
        },
    },
}

Formatter

Soong menyertakan formatter kanonik untuk file Blueprint, mirip dengan gofmt . Untuk memformat ulang semua file Android.bp secara rekursif di direktori saat ini, jalankan:

bpfmt -w .

Format kanonis menyertakan indentasi empat spasi, baris baru setelah setiap elemen 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 mengulangi 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 prebuilt

Beberapa jenis modul prebuilt mengizinkan sebuah modul memiliki nama yang sama dengan rekan berbasis sumbernya. Misalnya, mungkin ada cc_prebuilt_binary bernama foo jika 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 menentukan versi mana yang memiliki prioritas. Perhatikan bahwa beberapa modul prebuilt memiliki nama yang tidak dimulai dengan prebuilt , seperti android_app_import .

Modul ruang nama

Hingga Android sepenuhnya mengonversi dari Make ke Soong, konfigurasi produk Make harus menentukan nilai PRODUCT_SOONG_NAMESPACES . Nilainya harus berupa daftar spasi yang dipisahkan dari namespace yang diekspor Soong ke Make untuk dibangun dengan perintah m . Setelah konversi Android ke Soong selesai, detail mengaktifkan namespace dapat berubah.

Soong menyediakan kemampuan untuk modul dalam direktori yang 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 ditemukan di file Android.bp di direktori saat ini atau direktori leluhur terdekat. Jika modul soong_namespace tidak ditemukan, modul tersebut dianggap berada dalam namespace root implisit.

Berikut ini contohnya: Soong mencoba menyelesaikan dependensi D yang dideklarasikan oleh modul M di namespace N yang mengimpor namespace I1, I2, I3…

  1. Kemudian jika D adalah nama yang sepenuhnya memenuhi syarat dari //namespace:module form //namespace:module hanya namespace yang ditentukan dicari untuk nama modul yang ditentukan.
  2. Jika tidak, Soong pertama-tama mencari modul bernama D yang dideklarasikan di namespace N.
  3. Jika modul itu tidak ada, Soong mencari modul bernama D di ruang nama I1, I2, I3…
  4. Terakhir, Soong mencari di namespace root.