Google berkomitmen untuk memajukan ekuitas ras untuk komunitas kulit hitam. Lihat bagaimana.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Sistem Membangun Soong

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

Untuk alasan ini, pengembang platform diharapkan untuk beralih dari Make dan mengadopsi Soong sesegera mungkin. Kirim pertanyaan ke Google Group building android untuk menerima dukungan.

Apa itu Soong?

Sistem Soong build diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Make. Ini memanfaatkan Kati GNU Make clone tool dan komponen sistem pembuatan Ninja untuk mempercepat pembangunan Android.

Lihat deskripsi Android Make Build System di Android Open Source Project (AOSP) untuk instruksi umum dan Build System Changes untuk Android.mk Penulis untuk mempelajari tentang modifikasi yang diperlukan untuk beradaptasi dari Make to Soong.

Lihat entri terkait-bangunan di glosarium untuk definisi istilah kunci dan file referensi Soong untuk detail lengkap.

Membuat dan membandingkan Soong

Berikut ini adalah perbandingan membuat konfigurasi dengan Soong 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 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 spesifik-uji.

Format file Android.bp

Secara desain, file Android.bp sederhana. Mereka tidak mengandung conditional atau pernyataan aliran kontrol; semua kompleksitas ditangani oleh build logic 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 jenis modul diikuti oleh serangkaian 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 dalam ruang nama dan modul prebuilt, yang dapat diulang.

Properti srcs menentukan file sumber yang digunakan untuk membangun modul, sebagai daftar string. Anda dapat mereferensikan output dari 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 jenis modul. Jenis yang didukung adalah:

  • Boolean ( true atau false )
  • Integer ( 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 gumpal dapat berisi wildcard UNIX * normal, misalnya *.java . Pola gumpal juga dapat berisi satu wildcard ** sebagai elemen path, yang cocok dengan nol atau lebih elemen path. Sebagai contoh, java/**/*.java cocok dengan pola java/Main.java dan java/com/android/Main.java .

Variabel

File Android.bp dapat berisi tugas variabel tingkat atas:

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

Variabel dicakup hingga sisa file yang dideklarasikan, serta file Cetak Biru anak. Variabel tidak berubah dengan satu pengecualian: mereka dapat ditambahkan dengan += tugas, tetapi hanya sebelum direferensikan.

Komentar

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

Operator

String, daftar string, dan peta dapat ditambahkan menggunakan operator +. Integer dapat disimpulkan menggunakan operator + . Menambahkan peta menghasilkan gabungan kunci di kedua peta, menambahkan nilai kunci apa saja yang ada di kedua peta.

Persyaratan

Soong tidak mendukung persyaratan dalam file Android.bp . Alih-alih, kompleksitas dalam membangun aturan yang membutuhkan persyaratan 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 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"],
        },
    },
}
 

Formatter

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

 bpfmt -w .
 

Format kanonik mencakup indentasi empat spasi, baris baru setelah setiap elemen daftar multielemen, dan koma tertinggal dalam daftar dan peta.

Modul khusus

Beberapa grup modul khusus memiliki karakteristik unik.

Modul standar

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 memungkinkan modul memiliki nama yang sama dengan rekan-rekan berbasis sumbernya. Sebagai contoh, 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 membangun mengandung kedua versi, yang prefer nilai bendera dalam modul prebuilt definisi perintah yang versi memiliki prioritas. Perhatikan bahwa beberapa modul prebuilt memiliki nama yang tidak dimulai dengan prebuilt , seperti android_app_import .

Modul ruang nama

Sampai Android sepenuhnya mengonversi dari Make ke Soong, konfigurasi Make product harus menentukan nilai PRODUCT_SOONG_NAMESPACES . Nilainya harus berupa daftar ruang nama yang dipisahkan oleh ruang yang diekspor Soong ke Make untuk dibangun oleh perintah m . Setelah konversi Android ke Soong selesai, detail ruang nama yang diaktifkan bisa berubah.

Soong menyediakan kemampuan untuk modul dalam direktori yang berbeda untuk menentukan nama yang sama, selama setiap modul dideklarasikan dalam ruang nama 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 ruang nama berdasarkan lokasinya di pohon. Setiap modul Soong dianggap berada di namespace yang ditentukan oleh soong_namespace 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 di root namespace implisit.

Berikut ini sebuah contoh: Soong mencoba menyelesaikan dependensi D yang dideklarasikan oleh modul M di namespace N yang mengimpor namespaces I1, I2, I3 ...

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