System kompilacji Soong

Przed wersją 7.0 system Android używał GNU Make wyłącznie w celu opisania i wykonania jej reguł kompilacji. System tworzenia kompilacji były powszechnie obsługiwane i używane, ale na skalę Androida były wolne i podatne na błędy. nieskalowalne i trudne do przetestowania. System kompilacji Soong zapewnia elastyczność niezbędną do tworzenia aplikacji na Androida.

Z tego powodu oczekuje się od deweloperów platform Nagraj jak najwcześniej. Wyślij pytania do tworzenie Androida Grup dyskusyjnych Google, aby uzyskać pomoc.

Co to jest Soong?

System kompilacji Soong został wprowadzony w Androidzie 7.0 (Nougat) jako zamiennik Make. Wykorzystuje Kati GNU Narzędzie do tworzenia klonów i system kompilacji Ninja w celu przyspieszenia kompilacji Androida.

Zobacz Android Marka Build System w Android Open Source Project (AOSP) dla ogólnego opisu instrukcje, oraz Tworzenie zmian systemowych dla programistów Android.mk w celu uzyskania informacji o modyfikacjach wymaganych do przejścia z trybu tworzenia na utwór.

Przejrzyj wpisy związane z kompilacją w glosariusz z definicjami kluczowych pojęć Szczegółowe informacje znajdziesz w plikach referencyjnych do utworów.

Porównanie tworzenia i piosenek

Oto porównanie konfiguracji Make z Soong, która osiąga ten sam efekt w pliku konfiguracji Soong (pliku Blueprint lub .bp).

Przykład

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)

Przykład Soong

cc_library_shared {
     name: "libxmlrpc++",

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

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

Przykłady konfiguracji Soong do testów znajdziesz w artykule Prosta konfiguracja kompilacji.

Objaśnienie pól w pliku Android.bp znajdziesz tutaj: Format pliku Android.bp.

Moduły specjalne

Niektóre grupy modułów specjalnych mają unikalne właściwości.

Moduły domyślne

Moduł domyślnych pozwala powtarzać te same właściwości w wielu modułach. Na przykład:

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

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

Gotowe moduły

Niektóre wstępnie utworzone typy modułów umożliwiają nadanie modułowi tej samej nazwy co jego odpowiednikom opartym na źródłach. Na przykład cc_prebuilt_binary o nazwie foo, jeśli istnieje już element cc_binary o tej samej nazwie. Dzięki temu pozwala deweloperom decydować, którą wersję umieścić usługi. Jeśli konfiguracja kompilacji zawiera obie wersje, flaga prefer w definicji gotowego modułu określa, która wersja ma priorytet. Zwróć uwagę, że niektóre gotowe moduły mają nazwy, które nie zaczynają się od prebuilt, na przykład android_app_import.

Moduły przestrzeni nazw

Dopóki Android nie przejdzie pełnej konwersji z Marki na Song, konfiguracja produktu musi określać wartość PRODUCT_SOONG_NAMESPACES. To powinna być rozdzielaną spacjami listą przestrzeni nazw, które Soong eksportuje do ma zostać stworzona za pomocą polecenia m. Po zakończeniu konwersji Androida na Soong szczegóły włączania przestrzeni nazw mogą ulec zmianie.

Soong umożliwia modułom w różnych katalogach określanie tej samej nazwy, o ile każdy z nich jest zadeklarowany w osobnej przestrzeni nazw. Przestrzeń nazw można zadeklarować w ten sposób:

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

Pamiętaj, że przestrzeń nazw nie ma właściwości name. Jej nazwą jest automatycznie przypisana ścieżka.

Każdy moduł Soong ma przypisaną przestrzeń nazw na podstawie swojej lokalizacji w drzewie. Każdy moduł Soong mieści się w przestrzeni nazw zdefiniowanej przez Plik soong_namespace został znaleziony w pliku Android.bp w bieżącym katalogu lub w katalogu nadrzędnym. Jeśli nie zostanie znaleziony żaden moduł soong_namespace, przyjmuje się, że moduł znajduje się w domyślnej ścieżce do korzenia.

Oto przykład: Soong próbuje rozwiązać zależność D zadeklarowaną przez moduł M w przestrzeni nazw N, która importuje przestrzenie nazw I1, I2, I3...

1. Następnie, jeśli D jest pełną i jednoznaczną nazwą formularza //namespace:module, tylko przeszukana jest przestrzeń nazw o podanej nazwie modułu.
2. W przeciwnym razie Soong najpierw szuka modułu o nazwie D zadeklarowanego w przestrzeni nazw. N.
3. Jeśli moduł nie istnieje, Soong szuka modułu o nazwie D w przestrzeniach nazw I1, I2, I3 itd.
4. Na koniec Soong sprawdza katalog główny.