Google is committed to advancing racial equity for Black communities. See how.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

Soong Yapı Sistemi

Android 7.0 sürümünden önce, Android, GNU Make'i yalnızca kendi oluşturma kurallarını tanımlamak ve yürütmek için kullanıyordu. Make build sistemi yaygın bir şekilde desteklenmekte ve kullanılmaktadır, ancak Android ölçeğinde yavaş, hataya açık, ölçeklenemez ve test edilmesi zor hale gelmiştir. Soong yapı sistemi , Android yapıları için gereken esnekliği sağlar.

Bu nedenle, platform geliştiricilerinin Make'den geçmesi ve Soong'u mümkün olan en kısa sürede benimsemesi bekleniyor. Destek almak için android geliştiren Google Grubu'na sorular gönderin.

Soong nedir?

Soong yapı sistemi , Make'in yerine Android 7.0'da (Nougat) tanıtıldı. Android sürümlerini hızlandırmak için Kati GNU Make clone aracını ve Ninja oluşturma sistemi bileşenini kullanır.

Genel talimatlar için Android Açık Kaynak Projesi'ndeki (AOSP) Android Make Build System açıklamasına ve Make'den Soong'a uyarlamak için gereken değişiklikleri öğrenmek için Android.mk Yazarları için Sistem Değişikliklerini Derlemeye 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 and Soong karşılaştırması

İşte aynı şeyi bir Soong yapılandırma (Blueprint veya .bp ) dosyasında gerçekleştiren Yap yapılandırmasının Soong ile karşılaştırması.

Ö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)

Güzel örnek

cc_library_shared {
     name: “libxmlrpc++”,

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

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

Teste özgü Soong yapılandırma örnekleri için Basit Yapı Yapılandırmasına bakın.

Android.bp dosya biçimi

Tasarım Android.bp dosyaları basittir. Koşullar veya kontrol akışı ifadeleri içermezler; tüm karmaşıklık, Go'da yazılan yapı mantığı tarafından ele alınır. Mümkün olduğunda, Android.bp dosyalarının sözdizimi ve anlam bilgisi 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", formatta bir dizi özellik izler:

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

Her modül olmalıdır name özelliği ve değer tüm arasında benzersiz olmalıdır Android.bp haricinde dosyalar name tekrarlayabilir ad ve önceden oluşturulmuş modüllerde gayrimenkul değerleri.

srcs özelliği, modülü oluşturmak için kullanılan kaynak dosyalarını dizelerin listesi olarak belirtir. Modül başvuru sözdizimini ":<module-name>" kullanarak, genrule veya filegroup gibi kaynak dosyaları üreten diğer modüllerin çıktılarına genrule .

Geçerli modül türlerinin ve özelliklerinin bir listesi için Soong Modules Reference belgesine bakın.

Türler

Değişkenler ve özellikler, ilk atamaya göre dinamik olarak değişkenler ve modül türüne göre statik olarak ayarlanmış özellikler ile güçlü bir şekilde türlenmiştir. Desteklenen türler şunlardır:

  • Boole'lar ( true veya false )
  • Tamsayılar ( int )
  • Dizeler ( "string" )
  • ["string1", "string2"] listeleri ( ["string1", "string2"] )
  • Haritalar ( {key1: "value1", key2: ["value2"]} )

Haritalar, iç içe geçmiş haritalar dahil her türden değer içerebilir. Listelerin ve haritaların sonunda son değerden sonra virgül olabilir.

Küre

srcs gibi bir dosya listesi alan özellikler de glob desenleri alabilir. Glob kalıpları normal UNIX joker karakterini * içerebilir, örneğin *.java . Glob desenleri, sıfır veya daha fazla yol öğesiyle eşleşen bir yol öğesi olarak tek bir ** joker karakter de içerebilir. Örneğin, java/**/*.java hem java/Main.java hem de java/com/android/Main.java kalıplarıyla java/com/android/Main.java .

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, içinde bildirildikleri dosyanın geri kalanının yanı sıra tüm alt Blueprint dosyalarının kapsamına alınır. Değişkenler, bir istisna dışında değişmezdirler: Bir += atamasıyla, ancak yalnızca başvurulmadan önce eklenebilirler.

Yorumlar

Android.bp dosyaları C-stili çok satırlı /* */ ve C ++ stili tek satırlı // yorumlar içerebilir.

Operatörler

Dizeler, dize listeleri ve haritalar + operatörü kullanılarak eklenebilir. Tam sayılar + operatörü kullanılarak toplanabilir. Bir harita eklemek, her iki haritada da bulunan anahtarların değerlerini ekleyerek her iki haritada da anahtarların birleşimini üretir.

Şartlılar

Soong, Android.bp dosyalarındaki koşullu Android.bp desteklemez. Bunun yerine, koşul ifadeleri gerektiren derleme kurallarındaki karmaşıklık, yüksek seviyeli dil özelliklerinin kullanılabildiği ve koşul ifadeleri tarafından getirilen örtük bağımlılıkların izlendiği Go'da ele alınır. Çoğu koşul, haritadaki değerlerden birinin seçildiği ve en ü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, gofmt'ye benzer şekilde Blueprint dosyaları için kanonik bir formatlayıcı 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 format, dört boşluklu girintiler, bir çoklu ekran listesinin her öğesinden sonra yeni satırlar ve listelerde ve haritalarda takip eden bir virgül içerir.

Özel modüller

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

Varsayılan modüller

Aynı özellikleri birden çok 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ı muadilleriyle aynı ada sahip olmasına izin verir. Örneğin, aynı ada sahip bir cc_binary varsa 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 işareti 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 adları olduğunu unutmayın.

Ad alanı modülleri

Android, Make'den Soong'a tam olarak dönüşene 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ığı, boşlukla ayrılmış ad alanları 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ü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 ad özelliğine sahip olmadığını unutmayın; yolu otomatik olarak adı olarak atanır.

Her Soong modülüne ağaçtaki konumuna bağlı olarak bir ad alanı atanır. Her Soong modülü tarafından tanımlanan ad olarak kabul edilir soong_namespace bir bulundu Android.bp geçerli dizinde ya da en yakın atası dizinindeki dosyasında. 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 ...

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