Автоматизированные сборки Android‑приложений в Termux: Gradle, Docker‑контейнеры и кросс‑компиляция без ПК

Собрать и протестировать Android‑приложение можно без настольного ПК: достаточно современного смартфона, приложения Termux и аккуратной организации окружения. В этой статье Денис Усачёв (РыбинскЛАБ) покажет практический подход к автоматизированным сборкам: от Gradle‑цепочки до Docker‑контейнеров и кросс‑компиляции, с фокусом на воспроизводимость и безопасность.

Почему Termux подходит для сборки Android‑проектов

Termux — это полноценная командная среда Linux для Android. Практически любой задачей разработчика можно управлять через shell: зависимости ставятся пакетным менеджером, сборка запускается Gradle, а сложные компоненты (например, JDK/NDK и системные библиотеки) — в контейнерах. Такой подход полезен тем, что:

• вы сокращаете цикл «изменил‑собрал»;
• получаете воспроизводимое окружение (особенно при Docker‑подходе);
• ускоряете эксперименты с NDK и кросс‑сборками.

Важно: сборку делайте для собственных проектов или при наличии прав на исходный код и зависимости. Ниже — про легальную разработку и инженерную инфраструктуру.

Архитектура автоматизированной сборки: базовые принципы

Рекомендуемая схема для Termux:

1. Подготовка окружения: JDK, Gradle/Wrapper, Android SDK/Build‑tools, (при необходимости) NDK.
2. Собственная структура скриптов: один скрипт для настройки, один — для сборки, отдельный — для очистки/сбора отчётов.
3. Параметризация: параметры сборки (variant/flavor/buildType, путь к keystore) задаются переменными окружения.
4. Кэширование: сохраняйте кэши Gradle и зависимостей; по возможности используйте Docker слои/объёмы.

Далее рассмотрим два рабочих варианта: «без Docker» (проще и быстрее для старта) и вариант «с Docker» (максимальная воспроизводимость).

Вариант 1: сборка Android проекта с Gradle прямо в Termux

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

1) Установка базовых пакетов

Начните с обновления репозиториев и установки окружения разработки:

pkg update && pkg upgrade -y
pkg install -y openjdk-17 wget unzip git tar rsync

Если в вашем проекте требуется другая версия JDK, выбирайте её под Gradle/AGP (Android Gradle Plugin).

2) SDK: установка инструментов сборки

Android SDK в Termux обычно ставят одним из двух способов: вручную через командную загрузку commandline‑tools или через готовые обёртки. Общий подход одинаков:

• скачать commandline‑tools;
• положить их в структуру SDK;
• через sdkmanager установить платформу/Build‑tools/Platform‑tools;
• при необходимости — NDK.

Например, структура переменных окружения:

export ANDROID_SDK_ROOT="$HOME/android-sdk"
export PATH="$PATH:$ANDROID_SDK_ROOT/platform-tools:$ANDROID_SDK_ROOT/emulator"

Далее — установка commandline‑tools (схема показана концептуально; подставьте актуальные URL и версию tools):

mkdir -p "$ANDROID_SDK_ROOT/cmdline-tools"
cd "$ANDROID_SDK_ROOT/cmdline-tools"
wget -O tools.zip "https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip"
unzip tools.zip
# приведите структуру к ожидаемой (обычно требуется папка cmdline-tools/<version>/bin)

После этого используйте sdkmanager. Список компонентов зависит от проекта. На практике часто ставят:

yes | "$ANDROID_SDK_ROOT/cmdline-tools/bin/sdkmanager" --licenses
"$ANDROID_SDK_ROOT/cmdline-tools/bin/sdkmanager" \
  "platform-tools" \
  "platforms;android-34" \
  "build-tools;34.0.0" \
  "cmake;3.22.1" \
  "ndk;26.1.10909125"

Если вы планируете кросс‑компиляцию через CMake/NDK — устанавливайте NDK и нужный CMake.

3) Привязка к проекту: gradle.properties и окружение

В проекте Android часто используют gradle-wrapper.properties и gradle.properties. Для удобства в Termux:

• используйте Gradle Wrapper (./gradlew), чтобы не зависеть от системы;
• задайте ANDROID_SDK_ROOT и (при необходимости) ANDROID_HOME в среде.

Пример команд на уровне проекта:

cd /path/to/your/android-project
export ANDROID_SDK_ROOT="$HOME/android-sdk"
./gradlew --version
./gradlew clean assembleDebug

4) Автоматизация сборки: единый скрипт

Соберите всё в один скрипт, например build.sh:

#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

export ANDROID_SDK_ROOT="${ANDROID_SDK_ROOT:-$HOME/android-sdk}"
export PATH="$PATH:$ANDROID_SDK_ROOT/platform-tools"

cd "${PROJECT_DIR:-$PWD}"

# Можно передавать переменные: BUILD_TYPE, FLAVOR
: "${BUILD_TYPE:=debug}"
: "${FLAVOR:=}"

if [ -n "$FLAVOR" ]; then
  ./gradlew clean \
    "assemble${FLAVOR^}${BUILD_TYPE^}"
else
  ./gradlew clean \
    "assemble${BUILD_TYPE^}"
fi

# Пример места артефактов (зависит от конфигурации проекта)
# echo "APK/Bundle готов"

Дайте права:

chmod +x build.sh

Запуск:

PROJECT_DIR=/path/to/project ./build.sh BUILD_TYPE=debug

Вариант 2: Docker‑контейнеры в Termux для воспроизводимых сборок

Когда вы хотите «всегда одинаково» запускать сборку на разных устройствах/после обновлений — Docker‑подход удобнее. Он помогает изолировать зависимости (JDK/SDK/NDK) и фиксировать версии.

Общий принцип:

• на хосте Termux — поднимаете Docker;
• в контейнер монтируете исходники и папку кэша;
• в контейнере — выполняете ./gradlew и (при необходимости) настройку SDK/NDK.

1) Подготовка: Docker в Termux

Способ зависит от версии Termux и инфраструктуры вашего окружения. Если вы уже настроили Docker для Termux — переходите к созданию образа. Если нет, начните с официальной документации и проверьте требования к ядру/привилегиям.

Пример контрольной проверки:

docker version
docker info

2) Dockerfile для Android build‑контейнера

Ниже — скелет подхода. В реальной сборке вам нужно подставить версии под ваш проект. Фокус: JDK + Android SDK tools + зависимости для Gradle.

FROM debian:stable-slim

ARG SDK_ROOT=/opt/android-sdk
ENV ANDROID_SDK_ROOT=$SDK_ROOT
ENV PATH=$PATH:$ANDROID_SDK_ROOT/platform-tools

RUN apt-get update && apt-get install -y \
    openjdk-17-jdk \
    wget unzip ca-certificates git \
    tar rsync \
  && rm -rf /var/lib/apt/lists/*

# Добавьте установку commandline-tools (примерно)
RUN mkdir -p $ANDROID_SDK_ROOT/cmdline-tools && cd $ANDROID_SDK_ROOT/cmdline-tools \
  && wget -O tools.zip "https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip" \
  && unzip tools.zip \
  && rm tools.zip

# Примите лицензии и установите нужные пакеты (пример)
RUN yes | $ANDROID_SDK_ROOT/cmdline-tools/bin/sdkmanager --licenses
RUN $ANDROID_SDK_ROOT/cmdline-tools/bin/sdkmanager \
    platform-tools \
    platforms;android-34 \
    build-tools;34.0.0 \
    ndk;26.1.10909125 \
    cmake;3.22.1

WORKDIR /workspace

# Поднять gradle из проекта (wrapper будет скачан внутри контейнера)
CMD ["bash", "-lc", "./gradlew assembleDebug"]

3) Сборка: монтирование исходников и кэшей

При запуске контейнера монтируйте:

• исходники из Termux;
• Gradle кэш (желательно — отдельным volume);
• SDK (или хотя бы папку кэша) — чтобы ускорить повторные сборки.

Пример команды запуска (концептуально):

docker build -t android-build:termux -f Dockerfile .

docker run --rm \
  -v "$PWD":/workspace \
  -v "$HOME/.gradle":/root/.gradle \
  -v "$HOME/android-sdk":/opt/android-sdk \
  -e ANDROID_SDK_ROOT=/opt/android-sdk \
  android-build:termux \
  bash -lc "./gradlew clean assembleDebug"

Если SDK внутри образа уже установлен, монтирование $HOME/android-sdk можно не делать — но монтирование обычно ускоряет инкрементальные сборки.

Кросс‑компиляция в Android: практический контур NDK/CMake

Кросс‑компиляция в Android‑проекте обычно означает сборку native‑кода (C/C++) через NDK и CMake/ndk-build. Термин «без ПК» здесь означает: вы запускаете компиляцию нативных модулей на Android‑устройстве в рамках Gradle/NDK toolchain.

1) Настройка Gradle для внешних native‑модулей

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

• CMake‑сборку через externalNativeBuild;
• или ndk-build;
• или prefab/со‑зависимости.

Минимальная иллюстрация (концептуально; адаптируйте под свой модуль):

android {
  defaultConfig {
    ndk {
      abiFilters "arm64-v8a", "armeabi-v7a"
    }
  }
  externalNativeBuild {
    cmake {
      path "src/main/cpp/CMakeLists.txt"
    }
  }
}

2) Указание NDK пути и версий

Обычно Gradle сам находит NDK через установленный SDK. Если не находит — задайте ndkVersion и убедитесь, что NDK установлен в SDK. Например:

android {
  ndkVersion "26.1.10909125"
}

3) Ускорение сборки native‑кода на мобильном устройстве

Мобильное устройство ограничено по CPU/RAM и тепловому режиму. Повысьте предсказуемость:

• ограничьте ABI набор (не все сразу);
• используйте инкрементальные сборки (не гоняйте clean без необходимости);
• в контейнере не теряйте кэши (Gradle и NDK/CMake).

Автоматизация «под ключ»: рекомендации по запуску и отчётности

Чтобы сборка была «инженерно управляемой», добавьте такие практики:

• Собирайте артефакты в фиксированную директорию (например, app/build/outputs);
• Сохраняйте логи: перенаправляйте stdout/stderr в файл;
• Добавьте проверки перед сборкой: существование SDK/NDK, доступность keystore (для release).

Пример запуска с логом:

./gradlew assembleDebug --no-daemon --stacktrace > build_$(date +%F_%H-%M).log 2>&1

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

• Gradle не видит SDK: проверьте ANDROID_SDK_ROOT и наличие platform-tools.
• Конфликт версий build-tools/AGP: сопоставьте версии, которые ожидает ваш проект.
• NDK/CMake не найден: проверьте установку через sdkmanager и корректность ndkVersion.
• Проблемы прав в Docker: убедитесь, что монтируемые каталоги доступны пользователю внутри контейнера.

Чтобы быстрее понять причину, используйте --stacktrace и (при необходимости) --info в Gradle.

Про VPN (коротко и по делу)

Если вам нужен доступ к ресурсам внутри локальной сети (например, к внутреннему репозиторию артефактов или локальному серверу файлов) — используйте VPN для создания локальной сети. Это не предназначено для обхода блокировок, а только для организации адресации и доступа в вашей сети.

Заключение

Автоматизированные сборки Android‑приложений в Termux вполне достижимы: вы можете собирать проект напрямую через Gradle, а для максимальной воспроизводимости — использовать Docker‑контейнеры. Для нативных модулей подключайте NDK и CMake через тот же SDK‑контур, а затем закрепляйте всё скриптами и логированием, чтобы сборки были повторяемыми и управляемыми.

Если хотите ускорить настройку, подобрать версии JDK/SDK/NDK под ваш проект или выстроить «сборку как процесс» (скрипты, контейнеры, кэши, артефакты и отчёты) — обратитесь в РыбинскЛАБ. Мы поможем разработать и внедрить инфраструктуру сборки под ваши задачи.