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