We detected you are likely not from a Russian-speaking region. Would you like to switch to the international version of the site?

  Назад к списку статей
Termux

CI/CD для Android‑проекта в Termux: настройка GitLab‑Runner, Maven/Gradle пайплайна и автоматическая публикация в Play Console

12 июл 2026 в 01:01 Усачёв Денис Евгеньевич

CI/CD для Android‑проекта в Termux позволяет собрать единый контур разработки: вы храните код в GitLab, собираете артефакты с помощью Gradle или Maven, запускаете тесты и автоматически формируете подписанные релизы для последующей загрузки в Play Console. Ниже — практический сценарий, который можно развернуть на локальном устройстве (смартфон/мини‑ПК), с GitLab‑Runner, конфигурациями пайплайнов и публикацией релиза через официальные механизмы.

Статья ориентирована на корректное использование штатных возможностей Android‑сборки и безопасное хранение секретов в GitLab CI/CD. Все шаги описаны так, чтобы вы могли адаптировать их под свой проект и структуру репозитория.

Архитектура решения

Рассмотрим компоненты:

  • Termux — среда для запуска GitLab‑Runner и вспомогательных инструментов (SDK/Java/Gradle или Maven).
  • GitLab Runner — агент, исполняющий job’ы из .gitlab-ci.yml.
  • Android build — сборка через Gradle (типично для Android) или через Maven (если ваш проект/модули так устроены).
  • Play Console — публикация сборок (обычно через загрузку подписанного AAB или APK с помощью инструмента, поддерживаемого Google).
  • Секреты — храните в GitLab CI/CD Variables (например, ключ подписи, service account для загрузки в Play).

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

Убедитесь, что на устройстве доступны:

  • Установленный Termux.
  • Java JDK (обычно 17 для современных Android проектов).
  • Android SDK (через command line tools) и нужные платформы/системные образы.
  • Gradle или Maven (в большинстве случаев Gradle лучше подходит для Android).
  • Доступ к интернету для скачивания зависимостей и SDK.

Базовая установка пакетов в Termux (пример):

pkg update
pkg install -y git wget tar zip unzip openjdk-17 curl

Проверьте Java:

java -version

Рекомендуется создать отдельный каталог для runner и окружения:

mkdir -p ~/gitlab-runner && cd ~/gitlab-runner

Установка Android SDK в Termux

Обычно удобнее поставить Android SDK в домашнюю директорию Termux и зафиксировать переменные окружения в профиле. Примерная структура:

mkdir -p ~/android-sdk/cmdline-tools
mkdir -p ~/android-sdk/platform-tools
mkdir -p ~/android-sdk/platforms
mkdir -p ~/android-sdk/build-tools

Дальше скачайте command line tools (выберите актуальную версию на стороне Google). В Termux выполните загрузку и распаковку в нужную структуру. Формат разнится по версиям, поэтому ориентируйтесь на структуру папок, где должен появиться каталог cmdline-tools/latest/bin.

После установки настройте переменные окружения (в ~/.bashrc или ~/.zshrc):

export ANDROID_HOME="$HOME/android-sdk"
export PATH="$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/build-tools"

Пример установки нужных компонентов через SDK Manager (используйте актуальные пакеты для вашей версии проекта):

sdkmanager --list
sdkmanager "platform-tools" "platforms;android-34" "build-tools;34.0.0"

Согласуйте версию compileSdk/targetSdk в проекте с установленными платформами.

Настройка GitLab Runner в Termux

Скачивание GitLab Runner

Скачайте бинарник GitLab Runner для вашей архитектуры (arm/arm64). В Termux корректнее использовать официальный runner под Linux‑ARM. После загрузки:

chmod +x gitlab-runner
mv gitlab-runner /data/data/com.termux/files/usr/bin/gitlab-runner

Регистрация runner

В GitLab проекта (или группы) создайте Runner и получите регистрационный токен. Затем зарегистрируйте агент в Termux:

gitlab-runner register

Во время регистрации укажите:

  • GitLab URL
  • Registration token
  • Description (например, termux-android-runner)
  • Tags (например: android, termux)
  • Executor. Для Android сборок обычно подходит shell (проще). В вариантах с контейнерами требуется дополнительная инфраструктура.

Пример (как текстовые значения в подсказках), без жесткой привязки:

gitlab-runner register
# URL: https://gitlab.example.com/
# Token: <registration-token>
# Executor: shell
# Tags: android, termux
# Run untagged: false
# Lock to current project: false

Запуск runner

Запустите runner. В зависимости от того, как вы установили бинарник, используйте:

gitlab-runner run

Для более удобного управления можно поднять запуск в фоне и логирование через termux-services или screen/tmux (без изменения функционала, только удобство).

CI/CD переменные: как хранить секреты

Для подписи сборок и загрузки в Play Console вам почти наверняка понадобятся секреты:

  • Keystore (файл) + пароль + alias + пароль ключа.
  • Либо конфигурация на основе Google Play App Signing (в зависимости от процесса релизов).
  • Service account для доступа к Play Developer API (если используете загрузку через официальные инструменты).

Рекомендуемая практика: хранить секреты в GitLab как CI/CD Variables:

  • KEYSTORE_B64 (keystore, закодированный в base64)
  • KEYSTORE_PASSWORD
  • KEY_ALIAS
  • KEY_PASSWORD
  • PLAY_SERVICE_ACCOUNT_B64 (json ключ, base64)
  • PLAY_PACKAGE_NAME (com.your.app)

И добавьте маскирование/защиту (Protected) для релиз‑пайплайнов.

Пример .gitlab-ci.yml для Android (Gradle)

Ниже — каркас пайплайна: сборка, (опционально) тесты и подготовка артефакта AAB для релиза. Пример рассчитан на shell executor и runner с тегами android.

stages:
  - build
  - test
  - release

variables:
  GRADLE_USER_HOME: "$CI_PROJECT_DIR/.gradle"
  ANDROID_HOME: "$HOME/android-sdk"
  # PATH можно расширить в before_script, если нужно

before_script:
  - export PATH="$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools"
  - chmod +x ./gradlew || true

build_aab:
  stage: build
  tags: ["android", "termux"]
  script:
    - ./gradlew --version
    - ./gradlew clean bundleRelease
  artifacts:
    when: always
    paths:
      - app/build/outputs/bundle/release/.aab
    expire_in: 14 days

unit_tests:
  stage: test
  tags: ["android", "termux"]
  script:
    - ./gradlew testDebugUnitTest
  artifacts:
    when: always
    reports:
      junit: app/build/test-results/testDebugUnitTest/.xml
    expire_in: 7 days

release_upload:
  stage: release
  tags: ["android", "termux"]
  rules:
    - if: '$CI_COMMIT_TAG'  # пример: релиз по тегу
  script:
    - echo "Preparing Google Play service account..."
    - echo "$PLAY_SERVICE_ACCOUNT_B64" | base64 -d > "$CI_PROJECT_DIR/play-service-account.json"
    - export PLAY_PACKAGE_NAME="$PLAY_PACKAGE_NAME"
    - ls -la app/build/outputs/bundle/release || true
    - AAB_PATH="$(ls app/build/outputs/bundle/release/.aab | head -n 1)"
    - test -f "$AAB_PATH"
    - echo "Uploading: $AAB_PATH"
    # Здесь подставьте команду загрузки в Play Console (официальный инструмент/скрипт)
    # Например, через Google Play Developer API tooling:
    # - bundletool / googleapis / upload script (зависит от выбранного метода)
  artifacts:
    when: always
    paths:
      - "$CI_PROJECT_DIR/play-service-account.json"
    expire_in: 1 day

Важно: конкретная команда загрузки зависит от выбранного вами инструмента. Универсальный принцип — использовать подписанный релиз‑артефакт и service account с минимальными правами. Не выводите секреты в лог.

Подпись релиза в CI (Gradle)

Подпись обычно настраивается в app/build.gradle через signingConfigs. В CI вы подставляете keystore и пароли. Вариант через параметры окружения:

// app/build.gradle (фрагмент, пример идеи)
android {
  signingConfigs {
    release {
      storeFile file(System.getenv("KEYSTORE_FILE") ?: "")
      storePassword System.getenv("KEYSTORE_PASSWORD")
      keyAlias System.getenv("KEY_ALIAS")
      keyPassword System.getenv("KEY_PASSWORD")
    }
  }
  buildTypes {
    release {
      signingConfig signingConfigs.release
    }
  }
}

А в job добавьте создание keystore из base64:

echo "$KEYSTORE_B64" | base64 -d > "$CI_PROJECT_DIR/release.keystore"
export KEYSTORE_FILE="$CI_PROJECT_DIR/release.keystore"
export KEYSTORE_PASSWORD="$KEYSTORE_PASSWORD"
export KEY_ALIAS="$KEY_ALIAS"
export KEY_PASSWORD="$KEY_PASSWORD"

Если keystore уже используется в проекте локально, в CI его не коммитьте и не храните в репозитории.

Вариант пайплайна для Maven (если нужен)

Android‑проекты чаще собираются через Gradle. Однако, если ваш пайплайн использует Maven (например, отдельные модули/артефакты, или вы публикуете библиотеку), вы можете сделать стадию сборки через Maven. Принцип тот же: отдельный build job, затем публикация артефакта.

stages:
  - build
  - release

maven_build:
  stage: build
  tags: ["android", "termux"]
  script:
    - mvn -v
    - mvn -B -DskipTests package
  artifacts:
    when: always
    paths:
      - target/.jar
      - target/*.aar
    expire_in: 14 days

Публикация в Play Console для Android‑приложений обычно всё равно требует корректных apk/aab. Если вы делаете это через Maven‑профили — убедитесь, что результат соответствует требованиям Play (подписан, нужные форматы, версия и package name корректны).

Автоматическая публикация в Play Console: практические нюансы

Чтобы автоматизация прошла гладко:

  • Используйте release‑ветку/теги для запуска release_upload.
  • Проверьте, что собранный артефакт — именно AAB для App Bundle (часто предпочтительнее для новых релизов).
  • Убедитесь в согласованности versionCode/versionName. Play требует уникальности versionCode.
  • Не печатайте секреты в лог job’а. В GitLab переменные можно сделать masked.
  • Настройте rollout/track в Play Console (например, internal testing). Это зависит от API и сценария загрузки.

При локальном запуске на Termux обязательно следите за стабильностью сети и тайм‑аутами скачивания зависимостей. Для ускорения можно кэшировать .gradle и зависимости, используя cache в GitLab (по желанию добавьте, например, кэш Gradle).

Кэширование и ускорение сборок на Termux

Для снижения времени сборки добавьте кэширование Gradle:

cache:
  key: "gradle-cache"
  paths:
    - .gradle/wrapper
    - .gradle/caches

Расположения путей подстройте под ваш workspace. В примере выше мы использовали GRADLE_USER_HOME внутри проекта.

Рекомендованный workflow для релизов

  • Merge request в основную ветку запускает build и test.
  • После успешного тестирования создавайте тег (или релиз‑флаг) — запускается release_upload.
  • В Play Console загружайте релиз в нужный трек (internal/closed/open) и отслеживайте результаты.

Частые ошибки

  • Runner не находит команды: проверьте PATH для sdkmanager/platform-tools и наличие JDK.
  • Ошибка подписи: убедитесь, что keystore и пароли реально подставляются в job, а путь storeFile корректный.
  • Несовпадение SDK: сборка падает из‑за отсутствия нужных platform/build-tools — установите нужные версии на Termux.
  • Ошибка versionCode: Play отклоняет повторно используемый versionCode — добавьте автоинкремент через Gradle task или скрипт.

Заключение

CI/CD для Android‑проекта в Termux реально построить на базе GitLab Runner: вы поднимаете runner в Termux, настраиваете сборку через Gradle (или Maven для отдельных артефактов), безопасно храните секреты в GitLab CI/CD Variables и автоматизируете загрузку подписанных сборок в Play Console по тегам/релизам. Такой подход ускоряет разработку, уменьшает ручные действия и повышает воспроизводимость релизов.

Если хотите, чтобы мы помогли вам спроектировать пайплайн под ваш проект (Gradle-модули, подпись, tracks в Play, кэширование и надежность runner в Termux), обратитесь в РыбинскЛАБ — услуги по внедрению и сопровождению CI/CD для Android и инфраструктуры DevOps.

* Текст статьи подготовлен и структурирован с использованием технологий искусственного интеллекта. Проверен и доработан перед публикацией.

Нужна помощь с настройкой Termux, Linux и серверов?

Я оказываю ИТ-услуги: настройка серверов, автоматизация, безопасность, помощь с Linux и инфраструктурой. Материалы сайта — только в ознакомительных и образовательных целях.

Связаться со мной
Поддержать проект