Автоматизированный процесс сборки и развертывания пакетов AOSP в Termux с использованием Ninja и CMake

Termux — удобная среда для разработки на Android, позволяющая запускать полноценные сборочные цепочки, скрипты автоматизации и инструменты сборки вроде Ninja и CMake. В этой статье рассмотрим, как организовать автоматизированный процесс сборки и последующего развертывания (доставки артефактов) для компонентов уровня AOSP в рамках Termux.

Фокус будет на практичной архитектуре пайплайна: подготовка окружения, выбор структуры проекта, настройка CMake для конкретных модулей, использование Ninja как генератора/ускорителя сборки, а также согласованное управление артефактами (пакетирование, размещение в нужной директории и подготовка к дальнейшему использованию).

Предварительные замечания по применимости

Под “пакетами AOSP” в контексте Termux обычно понимают сборку отдельных компонентов или подсистем (например, библиотек, сервисов, утилит) либо сборку проектов, которые совместимы с подходом AOSP по зависимостям и ABI. В Termux мы не собираем “полный образ системы” как в официальной среде AOSP, но вполне можем организовать сборку модулей/пакетов, которые собираются через CMake/Наличие подходящего toolchain и необходимых зависимостей.

Важно: конкретные шаги зависят от целевой версии Android, архитектуры (arm64-v8a, armeabi-v7a) и выбранного набора модулей. Ниже — универсальный шаблон, который вы адаптируете под свою задачу.

Требования и подготовка окружения в Termux

Перед началом обновите индексы пакетов Termux и установите базовые компоненты сборки. Мы будем использовать cmake и ninja-build, а также инструменты для управления исходниками и зависимостями.

pkg update -y
pkg upgrade -y
pkg install -y git cmake ninja-build clang lld make python rsync zip unzip

Проверьте версии:

cmake --version
ninja --version
clang --version

Далее определите рабочие директории (пример):

export WORKDIR="$HOME/aosp-termux"
mkdir -p "$WORKDIR" && cd "$WORKDIR"

Стратегия проекта: исходники отдельно, сборка отдельно

Рекомендуется разделять исходники и папку сборки. Для CMake удобен подход out-of-source build: исходники хранятся в src/, а результаты сборки — в build/. Это упрощает повторные сборки и позволяет быстро переключать конфигурации.

mkdir -p "$WORKDIR"/src "$WORKDIR"/build

Склонируйте необходимые репозитории. Здесь пример-скелет; конкретный URL и состав репозиториев определяются вашим модулем.

cd "$WORKDIR"/src
# Пример:
# git clone <URL_репозитория> my-module
# cd my-module

Настройка CMake для сборки модулей AOSP-подобного уровня

Чтобы сборка была корректной, вам нужно подготовить toolchain и параметры компиляции. В Termux часто используют Clang, а также указывают системные include и ABI/архитектуру в зависимости от требований проекта.

Общий план:

1. Создать директорию сборки: build/<config>.
2. Сгенерировать build-систему через CMake с генератором Ninja.
3. Запускать сборку Ninja с параллелизмом.
4. Хранить артефакты в управляемом месте.

Пример скрипта генерации:

cd "$WORKDIR"/src/my-module
export BUILD_DIR="$WORKDIR"/build/release
mkdir -p "$BUILD_DIR"

cmake -G Ninja \
  -S . \
  -B "$BUILD_DIR" \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_C_COMPILER=clang \
  -DCMAKE_CXX_COMPILER=clang++ \
  -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" \
  -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=lld"

Если ваш модуль требует Android-специфичных переменных, обычно их добавляют через дополнительные -D параметры (например, target ABI, путь к NDK, специфические defines). В Termux вы делаете это в той мере, в какой проект допускает сборку вне полного Android build system.

Ускорение сборки с Ninja

Ninja быстрее за счёт минимального оверхеда. Используйте параллелизм, ориентируясь на ресурсы устройства.

cmake --build "$BUILD_DIR" --target all -- -j"$(nproc)"

Проверка наличия результата. В зависимости от проекта артефакты могут лежать в bin/, lib/, out/ или в путях, заданных через CMakeLists.txt.

ls -la "$BUILD_DIR"

Автоматизация: унифицированный сборочный скрипт

Чтобы процесс был повторяемым, удобно вынести шаги в один скрипт, который поддерживает несколько профилей (release/debug) и аккуратно складывает артефакты.

Пример build.sh:

cat > "$WORKDIR"/build.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

WORKDIR="$HOME/aosp-termux"
SRC_DIR="$WORKDIR/src/my-module"

MODE="${1:-release}"
BUILD_DIR="$WORKDIR/build/$MODE"

mkdir -p "$BUILD_DIR"

cd "$SRC_DIR"

cmake -G Ninja \
  -S . \
  -B "$BUILD_DIR" \
  -DCMAKE_BUILD_TYPE="$( [ "$MODE" = "debug" ] && echo Debug || echo Release )" \
  -DCMAKE_C_COMPILER=clang \
  -DCMAKE_CXX_COMPILER=clang++ \
  -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" \
  -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=lld"

cmake --build "$BUILD_DIR" --target all -- -j"$(nproc)"
EOF

chmod +x "$WORKDIR"/build.sh

Запуск:

$WORKDIR/build.sh release
$WORKDIR/build.sh debug

Сборка пакета (артефакты) и “развертывание” в Termux

Под “развертыванием” в контексте Termux чаще всего подразумевают подготовку артефактов к установке/использованию: копирование собранных .so, бинарников, конфигураций и ресурсов в заданную структуру, создание архива или сборку “пакета” под последующую установку (например, вручную на устройство или передачу на другой стенд).

Создадим директорию артефактов:

export ARTIFACTS_DIR="$WORKDIR/artifacts"
mkdir -p "$ARTIFACTS_DIR"

Пример упаковки результата для модулей, где ожидаются lib и bin (адаптируйте под вашу структуру):

MODE="release"
BUILD_DIR="$WORKDIR/build/$MODE"
OUT_DIR="$ARTIFACTS_DIR/$MODE"
rm -rf "$OUT_DIR" && mkdir -p "$OUT_DIR"

# Примеры путей (замените на ваши реальные):
if [ -d "$BUILD_DIR/bin" ]; then rsync -av "$BUILD_DIR/bin/" "$OUT_DIR/bin/"; fi
if [ -d "$BUILD_DIR/lib" ]; then rsync -av "$BUILD_DIR/lib/" "$OUT_DIR/lib/"; fi

# Конфиги/ресурсы:
if [ -d "$BUILD_DIR/config" ]; then rsync -av "$BUILD_DIR/config/" "$OUT_DIR/config/"; fi

# Архивирование:
cd "$OUT_DIR" && zip -r "$WORKDIR"/aosp-module-$MODE.zip .

Организация локальной доставки (без обхода блокировок)

Если вы хотите быстро передать артефакты с Termux на другое устройство или ПК в рамках одного локального сегмента, используйте инструменты обмена по локальной сети. Например, вы можете поднять локальный HTTP-сервер в Termux и открыть его доступ только в пределах вашей локальной сети (без сценариев обхода ограничений).

Пример: запуск простого сервера для выдачи архива:

cd "$WORKDIR"
python -m http.server 8080

Далее на клиентском устройстве скачайте файл по URL вида http://<local-ip>:8080/aosp-module-release.zip.

При необходимости можно использовать VPN для создания локальной сети между устройствами, если это предусмотрено вашей инфраструктурой (например, для стабильного доступа).

CI-подход и повторяемость сборок

Даже без полного CI сервера на Android, полезно добиться повторяемости на уровне:

• Фиксации версий инструментов: cmake, clang, ninja.
• Согласованного набора параметров CMake (одинаковые -D опции).
• Чистых build-директории между значимыми изменениями (или контроль инкрементальности).
• Логирования параметров сборки и окружения (например, вывод uname -a, версии компилятора и команд генерации).

Вы можете дополнить скрипт логированием:

echo "=== Environment ===" >> "$WORKDIR/build.log"
echo "clang:" >> "$WORKDIR/build.log"; clang --version >> "$WORKDIR/build.log"
echo "cmake:" >> "$WORKDIR/build.log"; cmake --version >> "$WORKDIR/build.log"
echo "ninja:" >> "$WORKDIR/build.log"; ninja --version >> "$WORKDIR/build.log"
echo "date:" >> "$WORKDIR/build.log"; date >> "$WORKDIR/build.log"

# Затем вывод команды cmake и сборки можно отправлять в лог при необходимости.

Типовые проблемы и как их диагностировать

1) Ошибки линковки (.so / символы)
Проверьте совместимость ABI и наличие нужных зависимостей. В CMake убедитесь, что правильно указаны пути к библиотекам и флаги линковщика. Если используется lld, проверьте корректность флагов -fuse-ld=lld.

2) Некорректные include-пути
Проверьте, как проект ожидает структуру зависимостей. Иногда AOSP-компоненты подразумевают определённые переменные (NDK paths, системные include). В Termux эти пути могут отличаться.

3) Конфликты версий CMake/clang
Зафиксируйте “рабочие” версии и не меняйте инструменты без понимания последствий. Поддерживайте воспроизводимость.

4) Долгая сборка
Убедитесь, что используете Ninja и параллелизм. Также важно включить кэш и избегать лишних пере-генераций, если это возможно в вашей архитектуре.

Рекомендуемая структура “рабочего” репозитория

Пример структуры, которая помогает держать порядок:

aosp-termux/
  src/
    my-module/
  build/
    release/
    debug/
  artifacts/
    release/
    debug/
  scripts/
    build.sh
    package.sh
  build.log

Заключение

Автоматизированная сборка компонентов AOSP-подобного уровня в Termux с использованием Ninja и CMake вполне реализуема при грамотной организации out-of-source build, корректной настройке toolchain и дисциплине управления артефактами. Такой подход позволяет ускорить итерации, стандартизировать сборку, а затем удобно “развернуть” результат в виде архива или скопированных библиотек/бинарников для дальнейшего использования.

Если вам нужна помощь с настройкой конкретного модуля, оптимизацией CMake под вашу архитектуру или построением надежного пайплайна под ваши условия, обращайтесь в РыбинскЛАБ — поможем спроектировать и внедрить решение под вашу задачу.