Android 7.0 sürümünden önce Android, oluşturma kurallarını açıklamak ve yürütmek için özel olarak GNU Make'ı kullandı. Make build sistemi geniş çapta desteklenmekte ve kullanılmaktadır, ancak Android'in ölçeğinde yavaş, hataya açık, ölçeklenemez ve test edilmesi zor hale gelmiştir. Soong derleme sistemi, Android derlemeleri için gereken esnekliği sağlar.
Bu nedenle platform geliştiricilerin bir an önce Make'den geçiş yapması ve Soong'u benimsemesi bekleniyor. Destek almak için android geliştiren Google Grubuna soru gönderin.
Soong nedir?
Soong yapı sistemi, Make'in yerini almak üzere Android 7.0'da (Nougat) tanıtıldı. Android derlemelerini hızlandırmak için Kati GNU Make klonlama aracından ve Ninja derleme sistemi bileşeninden yararlanır.
Genel talimatlar için Android Açık Kaynak Projesi'ndeki (AOSP) Android Make Build System açıklamasına bakın ve Make to Soong'a uyum sağlamak için gereken değişiklikler hakkında bilgi edinmek için Android.mk Yazarları için Sistem Değişiklikleri Yapın .
Temel 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 bir Soong yapılandırma (Blueprint veya .bp ) dosyasında aynısını gerçekleştirmesiyle Yapılandırma Yap'ın karşılaştırması yer almaktadır.
Örnek olun
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)
Yakında örnek
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 dosya biçimi
Tasarım gereği, Android.bp dosyaları basittir. Koşullu ifadeler veya kontrol akışı ifadeleri içermezler; tüm karmaşıklık, Go'da yazılmış yapı mantığı tarafından yönetilir. Mümkün olduğunda, Android.bp dosyalarının sözdizimi ve semantiği Bazel BUILD dosyalarına benzer.
Modüller
Android.bp dosyasındaki bir modül, bir modül türüyle başlar ve ardından name: "value", format:
cc_binary {
name: "gzip",
srcs: ["src/test/minigzip.c"],
shared_libs: ["libz"],
stl: "none",
}
Her modülün bir name özelliği olmalıdır ve değer, ad alanlarındaki ve önceden oluşturulmuş modüllerdeki yinelenebilen name özelliği değerleri dışında tüm Android.bp dosyalarında benzersiz olmalıdır.
srcs özelliği, modülü oluşturmak için kullanılan kaynak dosyaları bir dize listesi olarak belirtir. ":<module-name>" modül referans sözdizimini kullanarak, genrule veya filegroup gibi kaynak dosyalar üreten diğer modüllerin çıktılarına başvurabilirsiniz.
Geçerli modül türlerinin ve özelliklerinin bir listesi için Soong Modülleri Referansına bakın.
Türler
Değişkenler ve özellikler, ilk atamaya göre dinamik olarak değişkenler ve modül tipine göre statik olarak ayarlanan özellikler ile güçlü bir şekilde yazılır. Desteklenen türler şunlardır:
- Boolean (
trueveyafalse) - tamsayılar (
int) - Dizeler (
"string") - Dize listeleri (
["string1", "string2"]) - Haritalar (
{key1: "value1", key2: ["value2"]})
Haritalar, iç içe haritalar da dahil olmak üzere her türden değer içerebilir. Listelerde ve haritalarda son değerden sonra virgül olabilir.
Küreler
srcs gibi bir dosya listesi alan özellikler de glob kalıpları alabilir. Glob kalıpları normal UNIX joker karakterini * içerebilir, örneğin *.java . Glob kalıpları ayrıca yol öğesi olarak sıfır veya daha fazla yol öğesiyle eşleşen tek bir ** joker karakter içerebilir. Örneğin, java/**/*.java hem java/Main.java hem de java/com/android/Main.java kalıplarıyla eşleşir.
Değişkenler
Bir Android.bp dosyası, üst düzey değişken atamaları içerebilir:
gzip_srcs = ["src/test/minigzip.c"],
cc_binary {
name: "gzip",
srcs: gzip_srcs,
shared_libs: ["libz"],
stl: "none",
}
Değişkenler, herhangi bir alt Blueprint dosyasının yanı sıra içinde bildirildikleri dosyanın geri kalanına göre kapsamlandırılır. Değişkenler değişmezdir, bir istisna dışında: += atamasıyla eklenebilirler, ancak yalnızca başvurulmadan önce.
Yorumlar
Android.bp dosyaları, C stili çok satırlı /* */ ve C++ stili tek satırlı // yorumlar içerebilir.
Operatörler
Dizeler, dizi listeleri ve haritalar + operatörü kullanılarak eklenebilir. Tamsayılar + operatörü kullanılarak toplanabilir. Bir haritanın eklenmesi, her iki haritada bulunan anahtarların değerlerinin eklenmesiyle her iki haritadaki anahtarların birleşimini oluşturur.
Şartlılar
Soong, Android.bp dosyalarındaki koşullu ifadeleri desteklemez. Bunun yerine, koşullu ifadeler gerektirecek yapı kurallarındaki karmaşıklık, üst düzey dil özelliklerinin kullanılabileceği ve koşullu koşullar tarafından sunulan örtük bağımlılıkların izlenebileceği Go'da ele alınır. Çoğu koşul, haritadaki değerlerden birinin seçildiği ve üst düzey özelliklere eklendiği bir harita özelliğine dönüştürülür.
Örneğin, mimariye özgü dosyaları desteklemek için:
cc_library {
...
srcs: ["generic.cpp"],
arch: {
arm: {
srcs: ["arm.cpp"],
},
x86: {
srcs: ["x86.cpp"],
},
},
}
biçimlendirici
Soong, Blueprint dosyaları için gofmt'ye benzer bir kurallı biçimlendirici içerir. Geçerli dizindeki tüm Android.bp dosyalarını yinelemeli olarak yeniden biçimlendirmek için şunu çalıştırın:
bpfmt -w .
Kanonik biçim, dört boşluklu girintiler, çok öğeli bir listenin her öğesinden sonra yeni satırlar ve listelerde ve haritalarda sondaki bir virgül içerir.
Özel modüller
Bazı özel modül grupları benzersiz özelliklere sahiptir.
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ı ada sahip olmasına izin verir. Örneğin, aynı ada sahip bir cc_binary varken foo adlı bir cc_prebuilt_binary olabilir. Bu, geliştiricilere nihai ürünlerine hangi sürümü dahil edeceklerini seçme esnekliği sağlar. Bir derleme 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 adlarla başlamadığını unutmayın.
Ad alanı modülleri
Android, Make'den Soong'a tamamen dönüşene kadar, Make ürün yapılandırması bir PRODUCT_SOONG_NAMESPACES değeri belirtmelidir. Değeri, Soong'un m komutu tarafından oluşturulmak üzere Make'e dışa 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ı etkinleştirmenin ayrıntıları değişebilir.
Soong, her modül ayrı bir ad alanı içinde bildirildiği sürece, farklı dizinlerdeki modüller için 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 bir ad özelliğine sahip olmadığına dikkat edin; yolu, adı olarak otomatik 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 dizinde veya en yakın ata dizininde bir Android.bp dosyasında bulunan soong_namespace tarafından tanımlanan ad alanında olduğu kabul edilir. Böyle bir soong_namespace modülü bulunamazsa, modülün örtük 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ışır…
- Daha sonra D
//namespace:moduleformunun tam nitelenmiş bir adıysa, belirtilen modül adı için yalnızca belirtilen ad alanı aranır. - Aksi takdirde, Soong önce N ad alanında bildirilen D adlı bir modülü arar.
- Bu modül yoksa Soong, I1, I2, I3… ad alanlarında D adlı bir modül arar.
- Son olarak Soong, kök ad alanına bakar.