Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Sistem Bangun Soong

Sebelum rilis Android 7.0, Android digunakan GNU Membuat eksklusif untuk menggambarkan dan melaksanakan aturan membangun nya. Sistem Make build didukung dan digunakan secara luas, tetapi pada skala Android menjadi lambat, rawan kesalahan, tidak dapat diskalakan, dan sulit untuk diuji. The Soong membangun sistem menyediakan fleksibilitas yang dibutuhkan untuk Android membangun.

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

Apa itu Soong?

The Soong membangun sistem diperkenalkan di Android 7.0 (Nougat) untuk menggantikan Membuat. Ini memanfaatkan Kati GNU alat Membuat clone dan Ninja membangun sistem komponen untuk mempercepat membangun dari Android.

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

Lihat entri yang berhubungan dengan pembangunan di glossary untuk definisi dari istilah kunci dan file referensi Soong untuk rincian lengkap.

Membuat dan segera membandingkan

Berikut ini adalah perbandingan dari konfigurasi Membuat dengan Soong mencapai yang sama dalam konfigurasi Soong (Blueprint atau .bp ) file.

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 Build sederhana untuk contoh konfigurasi uji spesifik Soong.

Format file Android.bp

Dengan desain, Android.bp file sederhana. Mereka tidak berisi kondisional atau pernyataan aliran kontrol; semua kompleksitas ditangani oleh logika build yang ditulis dalam Go. Bila mungkin, sintaks dan semantik dari Android.bp file mirip dengan file BUILD Bazel .

Modul

Sebuah modul dalam Android.bp berkas dimulai dengan jenis modul diikuti oleh satu set properti di name: "value", Format:

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

Setiap modul harus memiliki name properti, dan nilai harus unik di seluruh Android.bp file, kecuali untuk name nilai properti di ruang nama dan modul prebuilt, yang mungkin mengulang.

The srcs menspesifikasikan properti file sumber yang digunakan untuk membangun modul, sebagai daftar string. Anda dapat referensi 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 sifat mereka, melihat Soong Modul Referensi .

Jenis

Variabel dan properti diketik dengan kuat, dengan variabel secara dinamis berdasarkan penugasan pertama, dan properti ditetapkan secara statis oleh tipe modul. Jenis yang didukung adalah:

  • Booleans ( true atau false )
  • Bilangan bulat ( int )
  • String ( "string" )
  • Daftar string ( ["string1", "string2"] )
  • Maps ( {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 gumpal. Pola Glob dapat berisi normal UNIX wildcard * , misalnya *.java . Pola Glob juga dapat berisi satu ** wildcard sebagai elemen jalan, yang cocok dengan nol atau lebih elemen jalan. Misalnya, java/**/*.java cocok baik java/Main.java dan java/com/android/Main.java pola.

Variabel

Sebuah Android.bp File mungkin berisi tugas 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 yang berubah dengan satu pengecualian: mereka dapat ditambahkan ke dengan += tugas, tetapi hanya sebelum mereka telah dirujuk.

Komentar

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

Operator

String, daftar string, dan peta dapat ditambahkan menggunakan operator +. Bilangan bulat dapat disimpulkan menggunakan + operator. Menambahkan peta menghasilkan penyatuan kunci di kedua peta, menambahkan nilai kunci apa pun yang ada di kedua peta.

bersyarat

Soong tidak mendukung conditional di Android.bp file. 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"],
        },
    },
}

Pemformat

Soong termasuk formatter kanonik untuk file Blueprint, mirip dengan gofmt . Untuk rekursif memformat semua Android.bp file dalam 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 tipe modul bawaan memungkinkan sebuah modul memiliki nama yang sama dengan rekan-rekan berbasis sumbernya. Sebagai contoh, bisa 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 namespace

Sampai Android mengkonversi sepenuhnya dari Make to Soong, konfigurasi produk Membuat harus menentukan PRODUCT_SOONG_NAMESPACES nilai. Nilainya harus daftar dipisahkan dengan spasi dari ruang nama yang ekspor Soong Membuat yang akan dibangun oleh m perintah. 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 dalam namespace didefinisikan oleh soong_namespace ditemukan di sebuah Android.bp file dalam direktori saat ini atau direktori nenek moyang terdekat. Jika tidak ada seperti soong_namespace modul ditemukan, modul dianggap di root namespace implisit.

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

  1. Kemudian jika D adalah nama yang memenuhi syarat dari bentuk //namespace:module , hanya namespace ditentukan mencari 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 root namespace.