Soong yapı sistemi

Android 7.0 sürümünden önce Android, oluşturma kurallarını tanımlamak ve yürütmek için yalnızca GNU Make'i kullanıyordu. Make build sistemi geniş çapta destekleniyor ve kullanılıyor, ancak Android ölçeğinde yavaşladı, hataya açık, ölçeklenemez ve test edilmesi zor hale geldi. Soong derleme sistemi, Android derlemeleri için gereken esnekliği sağlar.

Bu nedenle platform geliştiricilerinin bir an önce Make'den geçip Soong'u benimsemeleri bekleniyor. Destek almak için android geliştiren Google Grubuna sorularınızı gönderin.

Soong nedir?

Soong yapı sistemi, Make'in yerini almak üzere Android 7.0'da (Nougat) tanıtıldı. Android yapılarını hızlandırmak için Kati GNU Make klon aracını ve Ninja yapı sistemi bileşenini kullanır.

Genel talimatlar için Android Açık Kaynak Projesi'ndeki (AOSP) Android Make Build System açıklamasına bakın ve Make'den Soong'a uyarlamak için gereken değişiklikler hakkında bilgi edinmek için Android.mk Yazarları için Sistem Değişiklikleri Oluşturun'a bakın .

Anahtar terimlerin tanımları için sözlükteki yapıyla ilgili girişlere ve tüm ayrıntılar için Soong referans dosyalarına bakın.

Make ve Soong karşılaştırması

Burada Soong'un aynısını Soong yapılandırma (Blueprint veya .bp ) dosyasında gerçekleştirmesiyle Make yapılandırmasının karşılaştırması verilmiştir.

Örnek yap

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)

Soong örneği

cc_library_shared {
     name: "libxmlrpc++",

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

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

Teste özel Soong yapılandırma örnekleri için bkz. Basit Yapı Yapılandırması .

Android.bp dosyasındaki alanların açıklaması için Android.bp dosya biçimine bakın.

Özel modüller

Bazı özel modül gruplarının benzersiz özellikleri vardır.

Varsayılan modüller

Aynı özellikleri birden fazla modülde tekrarlamak için bir varsayılan modül kullanılabilir. Örneğin:

cc_defaults {
    name: "gzip_defaults",
    shared_libs: ["libz"],
    stl: "none",
}

cc_binary {
    name: "gzip",
    defaults: ["gzip_defaults"],
    srcs: ["src/test/minigzip.c"],
}

Önceden oluşturulmuş modüller

Bazı önceden oluşturulmuş modül türleri, bir modülün kaynak tabanlı benzerleriyle aynı adı taşımasına izin verir. Örneğin, aynı adda bir cc_binary zaten varken, foo adında bir cc_prebuilt_binary olabilir. Bu, geliştiricilere nihai ürünlerine hangi sürümü dahil edeceklerini seçme esnekliği sağlar. Bir yapı yapılandırması her iki sürümü de içeriyorsa, önceden oluşturulmuş modül tanımındaki prefer bayrağı değeri hangi sürümün önceliğe sahip olduğunu belirler. Bazı önceden oluşturulmuş modüllerin android_app_import gibi prebuilt ile başlamayan adlara sahip olduğunu unutmayın.

Ad alanı modülleri

Android, Make'den Soong'a tamamen dönüştürülene kadar Make ürün yapılandırmasının bir PRODUCT_SOONG_NAMESPACES değeri belirtmesi gerekir. Değeri, Soong'un m komutu tarafından oluşturulmak üzere Make'e aktardığı ad alanlarının boşlukla ayrılmış bir listesi olmalıdır. Android'in Soong'a dönüşümü tamamlandıktan sonra ad alanlarının etkinleştirilmesine ilişkin ayrıntılar değişebilir.

Soong, her modül ayrı bir ad alanı içinde bildirildiği sürece, farklı dizinlerdeki modüllere aynı adı belirtme yeteneği sağlar. Bir ad alanı şu şekilde bildirilebilir:

soong_namespace {
    imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}

Bir ad alanının name özelliğine sahip olmadığını unutmayın; yolu otomatik olarak adı olarak atanır.

Her Soong modülüne ağaçtaki konumuna göre bir ad alanı atanır. Her Soong modülünün, geçerli dizindeki veya en yakın ata dizinindeki bir Android.bp dosyasında bulunan soong_namespace tarafından tanımlanan ad alanında olduğu kabul edilir. Eğer böyle bir soong_namespace modülü bulunamazsa, modülün örtülü kök ad alanında olduğu kabul edilir.

İşte bir örnek: Soong, I1, I2, I3… ad alanlarını içe aktaran N ad alanında M modülü tarafından bildirilen D bağımlılığını çözmeye çalışıyor.

  1. Daha sonra D //namespace:module formunun tam nitelikli adıysa, belirtilen modül adı için yalnızca belirtilen ad alanı aranır.
  2. Aksi takdirde, Soong ilk önce N ad alanında bildirilen D adlı bir modülü arar.
  3. Bu modül mevcut değilse Soong, I1, I2, I3… ad alanlarında D adında bir modül arar.
  4. Son olarak Soong kök ad alanına bakar.