Сборка для 32-битных и 64-битных архитектур.

Система сборки поддерживает сборку двоичных файлов для двух целевых архитектур ЦП: 32-разрядной и 64-разрядной в одной сборке. Эта двухцелевая сборка известна как многобиблиотекная сборка .

Для встроенных статических и общих библиотек система сборки устанавливает правила для сборки двоичных файлов для обеих архитектур. Конфигурация продукта ( PRODUCT_PACKAGES ) вместе с графом зависимостей определяет, какие двоичные файлы собираются и устанавливаются в образ системы.

Для исполняемых файлов и приложений система сборки по умолчанию собирает только 64-разрядную версию, но вы можете переопределить этот параметр с помощью глобальной переменной BoardConfig.mk или переменной области модуля.

Определите архитектуру второго ЦП и ABI.

BoardConfig.mk включает следующие переменные для настройки второй архитектуры ЦП и двоичного интерфейса приложения (ABI):

  • TARGET_2ND_ARCH
  • TARGET_2ND_ARCH_VARIANT
  • TARGET_2ND_CPU_VARIANT
  • TARGET_2ND_CPU_ABI
  • TARGET_2ND_CPU_ABI2

Пример make-файла, использующего эти переменные, см. build/make/target/board/generic_arm64/BoardConfig.mk .

В сборке с несколькими библиотеками имена модулей в PRODUCT_PACKAGES охватывают как 32-битные, так и 64-битные двоичные файлы, если они определены системой сборки. Для библиотек, включенных в зависимости, 32-разрядная или 64-разрядная библиотека устанавливается только в том случае, если она требуется другой 32-разрядной или 64-разрядной библиотеке или исполняемому файлу.

Однако имена модулей в командной строке make относятся только к 64-битной версии. Например, после запуска lunch aosp_arm64-eng make libc собирает только 64-битную версию libc. Чтобы собрать 32-битную версию libc, вам нужно запустить make libc_32 .

Определить архитектуру модуля в Android.mk

Вы можете использовать переменную LOCAL_MULTILIB , чтобы настроить сборку для 32-битной и 64-битной версии и переопределить глобальную переменную TARGET_PREFER_32_BIT .

Чтобы переопределить TARGET_PREFER_32_BIT , установите для LOCAL_MULTILIB одно из следующих значений:

  • both строят как 32-битную, так и 64-битную версию.
  • 32 строит только 32 бит.
  • 64 собирает только 64 бит.
  • first строит только для первой архитектуры (32 бита в 32-битных устройствах и 64 бита в 64-битных устройствах).

По умолчанию LOCAL_MULTILIB не установлен, и система сборки решает, какую архитектуру создавать на основе класса модуля и других переменных LOCAL_ * , таких как LOCAL_MODULE_TARGET_ARCH и LOCAL_32_BIT_ONLY .

Если вы хотите создать свой модуль для конкретных архитектур, используйте следующие переменные:

  • LOCAL_MODULE_TARGET_ARCH — установите для этой переменной список архитектур, например, arm x86 arm64 . Если создаваемая архитектура присутствует в этом списке, текущий модуль включается в систему сборки.

  • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH — эта переменная является противоположностью LOCAL_MODULE_TARGET_ARCH . Если создаваемая архитектура not в этом списке, текущий модуль включается в систему сборки.

Существуют второстепенные варианты этих двух переменных:

  • LOCAL_MODULE_TARGET_ARCH_WARN
  • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN

Система сборки предупреждает, если текущий модуль пропущен из-за перечисленных архитектур.

Чтобы настроить флаги сборки для конкретной архитектуры, используйте переменные LOCAL_ * зависящие от архитектуры, где * — суффикс, зависящий от архитектуры, например:

  • LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
  • LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
  • LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,

Эти переменные применяются только в том случае, если для этой архитектуры создается двоичный файл.

Иногда проще установить флаги в зависимости от того, создается ли двоичный файл для 32-битной или 64-битной версии. Используйте переменную LOCAL_ * с суффиксом _32 или _64 , например:

  • LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
  • LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
  • LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,

Установить путь установки библиотеки

Для сборки без нескольких библиотек вы можете использовать LOCAL_MODULE_PATH для установки библиотеки в местоположение, отличное от местоположения по умолчанию. Например, LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw .

Однако в сборке с несколькими библиотеками вместо этого используйте LOCAL_MODULE_RELATIVE_PATH :

LOCAL_MODULE_RELATIVE_PATH := hw

В этом формате и 64-битная, и 32-битная библиотеки устанавливаются в правильное место.

Если вы создаете исполняемый файл как в 32-разрядной, так и в 64-разрядной версии, используйте одну из следующих переменных, чтобы отличить путь установки:

  • LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64 — указывает имя установленного файла.
  • LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64 — указывает путь установки.

Получить промежуточный каталог для исходных файлов

В сборке с несколькими библиотеками, если вы создаете исходные файлы в $(local-intermediates-dir) (или $(intermediates-dir-for) с явными переменными), это работает ненадежно. Это связано с тем, что промежуточные сгенерированные источники требуются как для 32-битной, так и для 64-битной сборки, но $(local-intermediates-dir) указывает только на один из двух промежуточных каталогов.

Система сборки предоставляет выделенный, удобный для работы с несколькими библиотеками, промежуточный каталог для генерации исходных кодов. Чтобы получить путь к промежуточному каталогу, используйте макрос $(local-generated-sources-dir) или $(generated-sources-dir-for) . Использование этих макросов аналогично $(local-intermediates-dir) и $(intermediates-dir-for) .

Если исходный файл создается в этом выделенном каталоге и подбирается LOCAL_GENERATED_SOURCES , он создается как для 32-битной, так и для 64-битной версии в многобиблиотечной сборке.

Укажите системную архитектуру предварительно созданных двоичных целей

В сборке с несколькими библиотеками вы не можете использовать TARGET_ARCH или TARGET_ARCH в сочетании с TARGET_2ND_ARCH для указания системной архитектуры предварительно созданных двоичных целей. Вместо этого используйте переменные LOCAL_ * LOCAL_MODULE_TARGET_ARCH или LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH .

С помощью этих переменных система сборки может выбрать соответствующий 32-битный предварительно созданный двоичный файл, даже если он работает над 64-битной многобиблиотекной сборкой.

Если вы хотите использовать выбранную архитектуру для вычисления исходного пути для предварительно созданного двоичного файла, вызовите $(get-prebuilt-src-arch) .

Обеспечьте создание 32-битных и 64-битных файлов ODEX.

Для 64-битных устройств Google по умолчанию создает как 32-битные, так и 64-битные файлы ODEX для загрузочного образа и любых библиотек Java. Для APK-файлов Google по умолчанию генерирует ODEX только для основной 64-битной архитектуры. Если приложение запускается как в 32-битном, так и в 64-битном процессах, используйте LOCAL_MULTILIB := both , чтобы убедиться, что создаются как 32-битные, так и 64-битные файлы ODEX. Если в приложении есть 32-битные или 64-битные библиотеки JNI, этот флаг также сообщает системе сборки о необходимости их включения.

,

Система сборки поддерживает сборку двоичных файлов для двух целевых архитектур ЦП: 32-битной и 64-битной, в одной сборке. Эта двухцелевая сборка известна как многобиблиотекная сборка .

Для встроенных статических и общих библиотек система сборки устанавливает правила для сборки двоичных файлов для обеих архитектур. Конфигурация продукта ( PRODUCT_PACKAGES ) вместе с графом зависимостей определяет, какие двоичные файлы собираются и устанавливаются в образ системы.

Для исполняемых файлов и приложений система сборки по умолчанию собирает только 64-разрядную версию, но вы можете переопределить этот параметр с помощью глобальной переменной BoardConfig.mk или переменной области модуля.

Определите архитектуру второго ЦП и ABI.

BoardConfig.mk включает следующие переменные для настройки второй архитектуры ЦП и двоичного интерфейса приложения (ABI):

  • TARGET_2ND_ARCH
  • TARGET_2ND_ARCH_VARIANT
  • TARGET_2ND_CPU_VARIANT
  • TARGET_2ND_CPU_ABI
  • TARGET_2ND_CPU_ABI2

Пример make-файла, использующего эти переменные, см. build/make/target/board/generic_arm64/BoardConfig.mk .

В сборке с несколькими библиотеками имена модулей в PRODUCT_PACKAGES охватывают как 32-битные, так и 64-битные двоичные файлы, если они определены системой сборки. Для библиотек, включенных в зависимости, 32-разрядная или 64-разрядная библиотека устанавливается только в том случае, если она требуется другой 32-разрядной или 64-разрядной библиотеке или исполняемому файлу.

Однако имена модулей в командной строке make относятся только к 64-битной версии. Например, после запуска lunch aosp_arm64-eng make libc собирает только 64-битную версию libc. Чтобы собрать 32-битную версию libc, вам нужно запустить make libc_32 .

Определить архитектуру модуля в Android.mk

Вы можете использовать переменную LOCAL_MULTILIB , чтобы настроить сборку для 32-битной и 64-битной версии и переопределить глобальную переменную TARGET_PREFER_32_BIT .

Чтобы переопределить TARGET_PREFER_32_BIT , установите для LOCAL_MULTILIB одно из следующих значений:

  • both строят как 32-битную, так и 64-битную версию.
  • 32 строит только 32 бит.
  • 64 собирает только 64 бит.
  • first строит только для первой архитектуры (32 бита в 32-битных устройствах и 64 бита в 64-битных устройствах).

По умолчанию LOCAL_MULTILIB не установлен, и система сборки решает, какую архитектуру создавать на основе класса модуля и других переменных LOCAL_ * , таких как LOCAL_MODULE_TARGET_ARCH и LOCAL_32_BIT_ONLY .

Если вы хотите создать свой модуль для конкретных архитектур, используйте следующие переменные:

  • LOCAL_MODULE_TARGET_ARCH — установите для этой переменной список архитектур, например, arm x86 arm64 . Если создаваемая архитектура присутствует в этом списке, текущий модуль включается в систему сборки.

  • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH — эта переменная является противоположностью LOCAL_MODULE_TARGET_ARCH . Если создаваемая архитектура not в этом списке, текущий модуль включается в систему сборки.

Существуют второстепенные варианты этих двух переменных:

  • LOCAL_MODULE_TARGET_ARCH_WARN
  • LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN

Система сборки предупреждает, если текущий модуль пропущен из-за перечисленных архитектур.

Чтобы настроить флаги сборки для конкретной архитектуры, используйте переменные LOCAL_ * зависящие от архитектуры, где * — суффикс, зависящий от архитектуры, например:

  • LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
  • LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
  • LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,

Эти переменные применяются только в том случае, если для этой архитектуры создается двоичный файл.

Иногда проще установить флаги в зависимости от того, создается ли двоичный файл для 32-битной или 64-битной версии. Используйте переменную LOCAL_ * с суффиксом _32 или _64 , например:

  • LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
  • LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
  • LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,

Установить путь установки библиотеки

Для сборки без нескольких библиотек вы можете использовать LOCAL_MODULE_PATH для установки библиотеки в местоположение, отличное от местоположения по умолчанию. Например, LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw .

Однако в сборке с несколькими библиотеками вместо этого используйте LOCAL_MODULE_RELATIVE_PATH :

LOCAL_MODULE_RELATIVE_PATH := hw

В этом формате и 64-битная, и 32-битная библиотеки устанавливаются в правильное место.

Если вы создаете исполняемый файл как в 32-разрядной, так и в 64-разрядной версии, используйте одну из следующих переменных, чтобы отличить путь установки:

  • LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64 — указывает имя установленного файла.
  • LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64 — указывает путь установки.

Получить промежуточный каталог для исходных файлов

В сборке с несколькими библиотеками, если вы создаете исходные файлы в $(local-intermediates-dir) (или $(intermediates-dir-for) с явными переменными), это работает ненадежно. Это связано с тем, что промежуточные сгенерированные источники требуются как для 32-битной, так и для 64-битной сборки, но $(local-intermediates-dir) указывает только на один из двух промежуточных каталогов.

Система сборки предоставляет выделенный, удобный для работы с несколькими библиотеками, промежуточный каталог для генерации исходных кодов. Чтобы получить путь к промежуточному каталогу, используйте макрос $(local-generated-sources-dir) или $(generated-sources-dir-for) . Использование этих макросов аналогично $(local-intermediates-dir) и $(intermediates-dir-for) .

Если исходный файл создается в этом выделенном каталоге и подбирается LOCAL_GENERATED_SOURCES , он создается как для 32-битной, так и для 64-битной версии в многобиблиотечной сборке.

Укажите системную архитектуру предварительно созданных двоичных целей

В сборке с несколькими библиотеками вы не можете использовать TARGET_ARCH или TARGET_ARCH в сочетании с TARGET_2ND_ARCH для указания системной архитектуры предварительно созданных двоичных целей. Вместо этого используйте переменные LOCAL_ * LOCAL_MODULE_TARGET_ARCH или LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH .

С помощью этих переменных система сборки может выбрать соответствующий 32-битный предварительно созданный двоичный файл, даже если он работает над 64-битной многобиблиотекной сборкой.

Если вы хотите использовать выбранную архитектуру для вычисления исходного пути для предварительно созданного двоичного файла, вызовите $(get-prebuilt-src-arch) .

Обеспечьте создание 32-битных и 64-битных файлов ODEX.

Для 64-битных устройств Google по умолчанию создает как 32-битные, так и 64-битные файлы ODEX для загрузочного образа и любых библиотек Java. Для APK-файлов Google по умолчанию генерирует ODEX только для основной 64-битной архитектуры. Если приложение запускается как в 32-битном, так и в 64-битном процессах, используйте LOCAL_MULTILIB := both , чтобы убедиться, что создаются как 32-битные, так и 64-битные файлы ODEX. Если в приложении есть 32-битные или 64-битные библиотеки JNI, этот флаг также сообщает системе сборки о необходимости их включения.