Настройка автоматичної сборки Android-додатків
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 днів для багатомодульного з нестандартними вимогами до пайплайну.