Google, Siyah topluluklar için ırksal eşitliği ilerletmeye kararlıdır. Nasıl olduğunu gör.
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'ı yalnızca oluşturma kurallarını tanımlamak ve yürütmek için kullandı. Make derleme sistemi yaygın olarak destekleniyor ve kullanılıyor, ancak Android'in ölçeğinde yavaş, hata eğilimli, ölçeklenemez ve test edilmesi zorlaştı. Soong yapı sistemi , Android yapıları için gereken esnekliği sağlar.

Bu nedenle, platform geliştiricilerinin mümkün olan en kısa sürede Make ve Myong'u benimsemeleri bekleniyor. Destek almak için android oluşturma Google Grubuna sorular gönderin.

Soong nedir?

Soong oluşturma sistemi , Make'ın yerini almak için 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 derleme sistemi bileşenini kullanır.

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

Anahtar terimlerin tanımları için terimler sözlüğündeki derleme ile ilgili girdilere ve tüm ayrıntılar için Soong başvuru dosyalarına bakın.

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

Burada bir Soong yapılandırma (Blueprint veya .bp ) dosyasında aynı şeyi gerçekleştirerek Yapılandırmayı Soong ile karşılaştırın.

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

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 özgü Soong yapılandırma örnekleri için Basit Yapılandırma Yapılandırması'na bakın.

Android.bp dosya biçimi

Tasarım gereği, Android.bp dosyaları basittir. Koşullu veya kontrol akışı ifadeleri içermezler; tüm karmaşıklık Go ile yazılmış yapı mantığı ile ele alınır. Mümkün olduğunda, Android.bp dosyalarının sözdizimi ve anlambilimi Bazel BUILD dosyalarına benzer.

Modüller

Android.bp dosyasındaki bir modül , modül türü ve ardından name: "value", bir dizi özellik ile başlar name: "value", biçim:

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

Her modülün bir name özelliği olmalı ve ad alanlarındaki ve önceden oluşturulabilen önceden oluşturulmuş modüllerde name özellik değerleri dışında, değerin tüm Android.bp dosyalarında benzersiz olması gerekir.

srcs özelliği, modülü oluşturmak için kullanılan kaynak dosyalarını 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 genrule .

Geçerli modül tiplerinin ve özelliklerinin listesi için Soong Modüller Referansına bakın .

Türleri

Değişkenler ve özellikler, ilk atamaya dinamik olarak dinamik olarak ve değişkenler modül tipine göre statik olarak ayarlanmış şekilde güçlü bir şekilde yazılmıştır. Desteklenen türler:

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

Haritalar, iç içe haritalar da dahil olmak üzere herhangi bir türde değerler içerebilir. Listeler ve haritalar son değerden sonra virgül içerebilir.

Globs

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

Değişkenler

Bir Android.bp dosyası en ü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, bildirildikleri dosyanın geri kalanına ve alt Blueprint dosyalarına dahil edilir. Değişkenler tek bir istisna dışında değiştirilemez: += atamasıyla eklenebilirler, ancak yalnızca referans verilmeden önce eklenebilirler.

Yorumlar

Android.bp dosyaları C tarzı çok satırlı /* */ ve C ++ tarzı 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 özetlenebilir. Bir harita eklemek her iki haritadaki anahtarların birleşmesini sağlar ve her iki haritadaki anahtarların değerlerini ekler.

Şartlılar

Soong, Android.bp dosyalarındaki koşulları desteklemez. Bunun yerine, şartlar gerektirecek oluşturma kurallarındaki karmaşıklık, üst düzey dil özelliklerinin kullanılabileceği ve koşulların getirdiği örtülü bağımlılıkların izlenebildiğ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'e benzer bir kurallı biçimlendirici içerir. Geçerli dizindeki tüm Android.bp dosyalarını özyinelemeli olarak yeniden biçimlendirmek için şunu çalıştırın:

 bpfmt -w .
 

Standart biçim, dört boşluklu girintiler, çok öğeli bir listenin her öğesinden sonra yeni satırlar ve listelerde ve haritalarda bir virgül içerir.

Özel modüller

Bazı özel modül grupları benzersiz özelliklere sahiptir.

Varsayılan modüller

Birden çok modülde aynı özellikleri tekrarlamak için varsayılan bir 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, zaten aynı ada sahip bir cc_binary olduğunda 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'tan Soong'a tamamen dönüşünceye kadar, Make make ürün yapılandırması bir PRODUCT_SOONG_NAMESPACES değeri belirtmelidir. Değeri, Soong'un m komutu ile oluşturulacak Make'a dışa aktardığı ad boşluklarının bir listesi olmalıdır. Android'in Soong'a dönüşümü tamamlandıktan sonra, ad alanlarını etkinleştirme ayrıntıları değişebilir.

Soong, her bir modül ayrı bir ad alanı içinde bildirildiği müddetçe, farklı dizinlerdeki modüllerin aynı adı belirtmesini sağlar. Bir ad alanı şöyle bildirilebilir:

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

Bir ad alanının bir 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ü 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 örtülü kök ad alanında kabul edilir.

İşte bir örnek: Soong, N1 ad alanındaki M1 modülünün I1, I2, I3 ad alanlarını içe aktaran bağımlılık D'yi çözmeye çalışır.

  1. Daha sonra D, form //namespace:module tam 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 adında bir modül arar.
  4. Son olarak, Soong kök ad alanına bakar.