Изграждане на Android проект в Docker контейнер

Когато разработвате проект за платформата Android, дори и най-малкият, рано или късно трябва да се справите със средата за разработка. В допълнение към Android SDK е необходимо да имате най-новата версия на Kotlin, Gradle, platform-tools, build-tools. И ако на машината на разработчика всички тези зависимости се решават в по-голяма степен с помощта на Android Studio IDE, тогава на CI / CD сървъра всяка актуализация може да се превърне в главоболие. И ако в уеб разработката Docker се превърна в стандартното решение на проблема със средата, тогава защо не опитате да разрешите подобен проблем с него в разработката на Android ...

За тези, които не знаят какво е Docker – ако е съвсем елементарен, то това е инструмент за създаване на т.нар. „Контейнери“, които съдържат минималното ядро ​​на ОС и необходимия набор от софтуер, който можем да разположим където пожелаем, като същевременно поддържаме средата. Какво точно ще има в нашия контейнер се определя в Dockerfile, който след това се сглобява в изображение, което може да се стартира навсякъде и има свойства на идемпотентност.

Процесът на инсталиране и основите на Docker са прекрасно описани на неговия официален сайт. Следователно, гледайки малко напред, имаме такъв Dockerfile

# Т.к. основным инструментом для сборки Android-проектов является Gradle, 
# и по счастливому стечению обстоятельств есть официальный Docker-образ 
# мы решили за основу взять именно его с нужной нам версией Gradle
FROM gradle:5.4.1-jdk8

# Задаем переменные с локальной папкой для Android SDK и 
# версиями платформы и инструментария
ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=28 
    ANDROID_BUILD_TOOLS_VERSION=28.0.3

# Создаем папку, скачиваем туда SDK и распаковываем архив,
# который после сборки удаляем
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
# В следующих строчках мы создаем папку и текстовые файлы 
# с лицензиями. На оф. сайте Android написано что мы 
# можем копировать эти файлы с машин где вручную эти 
# лицензии подтвердили и что автоматически 
# их сгенерировать нельзя
    && mkdir "$ANDROID_HOME/licenses" || true 
    && echo "24333f8a63b6825ea9c5514f83c2829b004d1" > "$ANDROID_HOME/licenses/android-sdk-license" 
    && echo "84831b9409646a918e30573bab4c9c91346d8" > "$ANDROID_HOME/licenses/android-sdk-preview-license"    

# Запускаем обновление SDK и установку build-tools, platform-tools
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

Записваме го в папката с нашия Android проект и започваме да изграждаме контейнера с командата

docker build -t android-build:5.4-28-27 .

Параметър -t задава етикета или името на нашия контейнер, което обикновено се състои от неговото име и версия. В нашия случай го нарекохме android-build и във версията посочихме комбинация от gradle, android-sdk и platform-tools версии. В бъдеще ще ни бъде по-лесно да търсим изображението, от което се нуждаем, по име, използвайки такава „версия“.

След като изграждането приключи, можем да използваме нашето изображение локално, можем да го изтеглим с командата докер натискане към публично или частно хранилище на изображения, за да го изтеглите на други машини.

Като пример, нека изградим локален проект. За да направите това, в папката на проекта изпълнете командата

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug

Нека да разберем какво означава:

докер - самата команда за стартиране на изображението
-рм - означава, че след спиране на контейнера, той изтрива всичко, което е създадено през живота му
-v "$PWD":/home/gradle/ - монтира текущата папка с нашия Android проект към вътрешната папка на контейнера /home/gradle/
-w /home/gradle - задава работната директория на контейнера
android-build: 5.4.1-28-27 - името на нашия контейнер, който сме събрали
gradle assembleDebug - самият строителен екип, който сглобява нашия проект

Ако всичко върви добре, след няколко секунди / минути ще видите нещо подобно УСПЕШНО ИЗГРАЖДАНЕ за 8m 3s! И в папката app/build/output/apk ще има сглобено приложение.

По подобен начин можете да изпълнявате други задачи на gradle - да проверявате проекта, да изпълнявате тестове и т.н. Основното предимство е, че ако трябва да изградим проекта на друга машина, не е нужно да се притесняваме за инсталирането на цялата среда, а ще бъде достатъчно да изтеглим необходимото изображение и да стартираме компилацията в него.

Контейнерът не съхранява никакви промени и всяка сглобка се стартира от нулата, което, от една страна, гарантира идентичността на сглобката, независимо къде е стартирана, от друга страна, всеки път, когато трябва да изтеглите всички зависимости и компилирайте целия код отново и това понякога може да отнеме значително време. Затова, освен обичайния „студен“ старт, имаме възможност за стартиране на монтажа при запазване на т.нар. "cache", където запазваме папката ~/.gradle, като просто я копираме в работната папка на проекта, и в началото на следващата компилация я връщаме обратно. Преместихме всички процедури за копиране в отделни скриптове и самата команда за стартиране започна да изглежда така

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 /bin/bash -c "./pre.sh; gradle assembleDebug; ./post.sh"

В резултат на това средното време за изграждане на проекта беше намалено няколко пъти (в зависимост от броя на зависимостите на проекта, но средният проект започна да се изгражда за 1 минута вместо за 5 минути).

Всичко това само по себе си има смисъл само ако имате собствен вътрешен CI / CD сървър, който вие сами поддържате. Но сега има много облачни услуги, в които всички тези проблеми са решени и не е нужно да се притеснявате за това, а необходимите свойства за изграждане също могат да бъдат посочени в настройките на проекта.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Поддържате ли вашата CI/CD система вътрешна или използвате услуга на трета страна

• Използване на вътрешен сървър

• Използване на външна услуга

• Ние не използваме CI/CD

• Друг

42 потребители гласуваха. 16 потребители се въздържаха.

Източник: www.habr.com