Настройка автоматической сборки Android-приложения (Build Automation)

Настройка автоматической сборки Android-приложения (Build Automation)

Gradle по умолчанию делает всё на одном потоке, если не трогать настройки. На проекте с 15+ модулями холодная сборка занимает 4–7 минут, инкрементальная — 90 секунд. В CI это превращается в очередь билдов, которая блокирует ревью. Автоматизация сборки — это не про «кнопку в пайплайне», а про то, чтобы Gradle работал предсказуемо на любой машине и выдавал подписанный AAB без ручных шагов.

Основные точки боли при Android Build Automation

Самая частая проблема — подпись APK/AAB в CI. Разработчики хранят keystore в репозитории (плохо) или передают через аргументы командной строки открытым текстом (ещё хуже). Правильная схема: keystore кодируется в Base64, кладётся в переменную окружения CI, перед сборкой декодируется во временный файл, после сборки — удаляется. В build.gradle.kts это выглядит так:

android {
    signingConfigs {
        create("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
            storePassword = System.getenv("KEYSTORE_PASSWORD") ?: "android"
            keyAlias = System.getenv("KEY_ALIAS") ?: "androiddebugkey"
            keyPassword = System.getenv("KEY_PASSWORD") ?: "android"
        }
    }
    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
    }
}

Конфигурация сборки по веткам — второй болевой узел. main → release AAB для Play Store, develop → debug APK с тестовыми эндпоинтами, release/* → staging APK для QA. Это реализуется через комбинацию buildFlavors + условия в CI-скрипте, не через отдельные build.gradle файлы для каждого окружения.

Кэширование Gradle в CI — отдельная история. Без кэша каждый раз скачивается 200–400 МБ зависимостей. С правильным кэшированием ~/.gradle/caches и ~/.gradle/wrapper — первая сборка после изменения build.gradle занимает полное время, остальные — инкрементально.

Как настраиваем

Базовый стек: Gradle 8.x + AGP (Android Gradle Plugin) 8.x + GitHub Actions / GitLab CI / Bitrise. Fastlane используем для задач, которые Gradle не умеет из коробки: загрузка в Google Play через supply, отправка уведомлений, управление треками (internal → alpha → production).

Структура типичного CI-пайплайна:

# .github/workflows/android-release.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: Cache Gradle
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
      - name: Decode Keystore
        run: echo "$KEYSTORE_BASE64" | base64 -d > app/release.keystore
        env:
          KEYSTORE_BASE64: ${{ secrets.KEYSTORE_BASE64 }}
      - name: Build Release AAB
        run: ./gradlew bundleRelease
        env:
          KEYSTORE_PATH: release.keystore
          KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
          KEY_ALIAS: ${{ secrets.KEY_ALIAS }}
          KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }}
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: release-aab
          path: app/build/outputs/bundle/release/app-release.aab

Отдельно настраиваем gradle.properties под CI: org.gradle.daemon=false (демон в CI не нужен), org.gradle.parallel=true, org.gradle.configureondemand=true. На проектах с несколькими модулями это реально сокращает время конфигурации.

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

Если проект монолитный, параллелизация почти не даёт эффекта. Но при модульной архитектуре (:core, :feature-auth, :feature-feed, :app) Gradle строит граф зависимостей и собирает независимые модули параллельно. ./gradlew assembleDebug --parallel на 8-ядерном агенте даёт ощутимый выигрыш.

Для больших команд имеет смысл подключить Gradle Build Cache — либо Remote Build Cache через Gradle Enterprise (платно), либо через build-cache плагин с S3 бэкендом (открытое решение). Повторяющиеся задачи берутся из кэша, не пересчитываются.

Процесс работы

Аудит текущего build.gradle → перевод на build.gradle.kts (если проект на Groovy DSL) → настройка signing config через переменные окружения → написание CI-конфигурации → настройка кэширования → тестирование на нескольких ветках → документация для команды.

Стоимость рассчитывается индивидуально после анализа требований. Срок: 2–3 дня для типичного одномодульного проекта, до 5 дней для многомодульного с нестандартными требованиями к пайплайну.