До выпуска Android 7.0 Android использовал исключительно GNU Make для описания и выполнения своих правил сборки. Система сборки Make широко поддерживается и используется, но в масштабах Android стала медленной, подверженной ошибкам, немасштабируемой и сложной для тестирования. Система сборки Soong обеспечивает гибкость, необходимую для сборок Android.
По этой причине ожидается, что разработчики платформ перейдут с Make и примут Soong как можно скорее. Отправляйте вопросы в группу Google по сборке Android, чтобы получить поддержку.
Что такое Сунг?
Система сборки Soong была представлена в Android 7.0 (Nougat) вместо Make. Он использует инструмент клонирования Kati GNU Make и компонент системы сборки Ninja для ускорения сборки Android.
Общие инструкции см. в описании системы сборки Android Make в проекте Android с открытым исходным кодом (AOSP), а также в разделе «Изменения системы сборки для авторов Android.mk», чтобы узнать о модификациях, необходимых для адаптации от Make к Soong.
Определения ключевых терминов см. в записях, посвященных сборке, в глоссарии, а полную информацию — в справочных файлах Soong .
Сравнение Маке и Сунга
Вот сравнение конфигурации Make с Soong, выполняющим то же самое в файле конфигурации Soong (Blueprint или .bp ).
Сделать пример
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)
Пример Сонга
cc_library_shared {
name: "libxmlrpc++",
rtti: true,
cppflags: [
"-Wall",
"-Werror",
"-fexceptions",
],
export_include_dirs: ["src"],
srcs: ["src/**/*.cpp"],
target: {
darwin: {
enabled: false,
},
},
}
Примеры конфигурации Soong для конкретных тестов см. в разделе Простая конфигурация сборки .
Объяснение полей в файле Android.bp см. в разделе Формат файла Android.bp .
Специальные модули
Некоторые специальные группы модулей имеют уникальные характеристики.
Модули по умолчанию
Модуль по умолчанию можно использовать для повторения одних и тех же свойств в нескольких модулях. Например:
cc_defaults {
name: "gzip_defaults",
shared_libs: ["libz"],
stl: "none",
}
cc_binary {
name: "gzip",
defaults: ["gzip_defaults"],
srcs: ["src/test/minigzip.c"],
}
Готовые модули
Некоторые предварительно созданные типы модулей позволяют модулю иметь то же имя, что и его аналоги на основе исходного кода. Например, может существовать cc_prebuilt_binary с именем foo , если уже существует cc_binary с таким же именем. Это дает разработчикам возможность выбирать, какую версию включить в свой конечный продукт. Если конфигурация сборки содержит обе версии, значение флага prefer в определении предварительно созданного модуля определяет, какая версия имеет приоритет. Обратите внимание, что имена некоторых готовых модулей не начинаются с prebuilt , например android_app_import .
Модули пространства имен
Пока Android полностью не перейдет из Make в Soong, в конфигурации продукта Make должно быть указано значение PRODUCT_SOONG_NAMESPACES . Его значением должен быть список пространств имен, разделенных пробелами, которые Сунг экспортирует в Make для создания с помощью команды m . После завершения преобразования Android в Soong детали включения пространств имен могут измениться.
Soong предоставляет возможность модулям в разных каталогах указывать одно и то же имя, при условии, что каждый модуль объявлен в отдельном пространстве имен. Пространство имен можно объявить следующим образом:
soong_namespace {
imports: ["path/to/otherNamespace1", "path/to/otherNamespace2"],
}
Обратите внимание, что пространство имен не имеет свойства name; его путь автоматически назначается в качестве имени.
Каждому модулю Soong назначается пространство имен в зависимости от его местоположения в дереве. Считается, что каждый модуль Soong находится в пространстве имен, определенном пространством soong_namespace найденным в файле Android.bp в текущем каталоге или ближайшем родительском каталоге. Если такой модуль soong_namespace не найден, считается, что модуль находится в неявном корневом пространстве имен.
Вот пример: Сунг пытается разрешить зависимость D, объявленную модулем M в пространстве имен N, которая импортирует пространства имен I1, I2, I3…
- Тогда, если D — полное имя в форме
//namespace:module, поиск указанного имени модуля выполняется только в указанном пространстве имен. - В противном случае Сунг сначала ищет модуль с именем D, объявленный в пространстве имен N.
- Если этот модуль не существует, Сунг ищет модуль с именем D в пространствах имен I1, I2, I3…
- Наконец, Сунг просматривает корневое пространство имен.