Sistem build Soong

Sebelum rilis Android 7.0, Android menggunakan Produsen GNU secara eksklusif untuk mendeskripsikan dan menjalankan aturan build-nya. Sistem build Make banyak didukung dan digunakan, tetapi pada skala Android menjadi lambat dan rentan terhadap error, tidak skalabel, dan sulit diuji. Tujuan Sistem build Soong menyediakan fleksibilitas yang diperlukan untuk build Android.

Karena alasan ini, developer platform diharapkan beralih dari Make dan mengadopsi Soong sesegera mungkin. Kirim pertanyaan ke android-building Google Grup untuk menerima dukungan.

Apa itu Soong?

Sistem build Soong diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Make. Solusi ini memanfaatkan Kati GNU Alat pembuatan clone dan sistem build Ninja untuk mempercepat proses build Android.

Lihat Sistem Build Android Make deskripsi dalam Proyek Open Source Android (AOSP) untuk informasi petunjuk dan Membuat Perubahan Sistem untuk Penulis Android.mk belajar tentang modifikasi yang diperlukan untuk beradaptasi dari Make ke Soong.

Lihat entri terkait build di glosarium untuk definisi istilah kunci dan File referensi segera untuk mengetahui detail selengkapnya.

Perbandingan Make dan Soong

Berikut adalah perbandingan konfigurasi Make dengan Soong yang mencapai 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,
           },
     },
}

Untuk contoh konfigurasi Soong khusus pengujian, lihat Konfigurasi Build Sederhana.

Untuk penjelasan tentang bidang dalam file Android.bp, lihat Format file Android.bp.

Modul khusus

Beberapa grup modul khusus memiliki karakteristik unik.

Modul default

Modul default dapat digunakan untuk mengulangi properti yang sama di beberapa modul. Contoh:

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 berbasis sumber. Misalnya, bisa ada cc_prebuilt_binary bernama foo padahal sudah ada cc_binary dengan nama yang sama. Hal ini memberikan developer memiliki fleksibilitas untuk memilih versi yang akan disertakan dalam Google. Jika konfigurasi build berisi kedua versi, flag 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 namespace

Hingga Android sepenuhnya dikonversi dari Make ke Soong, konfigurasi produk Make harus menentukan nilai PRODUCT_SOONG_NAMESPACES. Ini nilai harus berupa daftar namespace yang dipisahkan spasi yang diekspor Soong ke Make dibuat oleh perintah m. Setelah konversi Android ke Soong selesai, detail pengaktifan namespace dapat berubah.

Soong memberikan kemampuan bagi modul di berbagai direktori untuk menentukan nama yang sama, asalkan setiap modul dideklarasikan dalam namespace terpisah. J dapat dideklarasikan sebagai berikut:

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 hierarki. Setiap modul Soong dianggap berada dalam namespace yang ditentukan oleh soong_namespace ditemukan di file Android.bp pada direktori saat ini atau direktori ancestor terdekat. Jika modul soong_namespace tersebut tidak ditemukan, dianggap berada dalam namespace root implisit.

Berikut ini contohnya: Soong berupaya 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 formulir //namespace:module, hanya namespace yang ditentukan akan ditelusuri untuk mencari nama modul yang ditentukan.
2. Jika tidak, Soong akan terlebih dahulu mencari modul bernama D yang dideklarasikan di namespace Virginia
3. Jika modul itu tidak ada, Soong akan mencari modul bernama D di namespace I1, I2, I3...
4. Terakhir, Soong mencari di namespace root.