Erstellen eines Android-Projekts in einem Docker-Container

Wenn Sie ein Projekt für die Android-Plattform entwickeln, auch das kleinste, müssen Sie sich früher oder später mit der Entwicklungsumgebung auseinandersetzen. Zusätzlich zum Android SDK ist die neueste Version von Kotlin, Gradle, Platform-Tools und Build-Tools erforderlich. Und wenn auf dem Rechner des Entwicklers all diese Abhängigkeiten in größerem Umfang mit der Android Studio IDE gelöst werden, dann kann auf dem CI/CD-Server jedes Update zu Kopfschmerzen werden. Und wenn Docker in der Webentwicklung zur Standardlösung für das Umgebungsproblem geworden ist, warum versuchen Sie dann nicht, ein ähnliches Problem damit in der Android-Entwicklung zu lösen ...

Für diejenigen, die nicht wissen, was Docker ist – wenn es ganz einfach ist, dann ist dies ein Tool zum Erstellen des sogenannten. „Container“, die den minimalen Betriebssystemkernel und den erforderlichen Softwaresatz enthalten, den wir unter Beibehaltung der Umgebung überall bereitstellen können. Was genau in unserem Container sein wird, wird in der Docker-Datei festgelegt, die dann zu einem Image zusammengesetzt wird, das überall gestartet werden kann und über Idempotenzeigenschaften verfügt.

Der Installationsprozess und die Grundlagen von Docker werden auf ihm sehr schön beschrieben die offizielle Seite. Wenn wir also ein wenig in die Zukunft blicken, haben wir eine solche Docker-Datei

# Т.к. основным инструментом для сборки 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"

Wir speichern es im Ordner unseres Android-Projekts und beginnen mit dem Befehl mit dem Aufbau des Containers

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

Parameter -t legt das Tag oder den Namen unseres Containers fest, der normalerweise aus seinem Namen und seiner Version besteht. In unserem Fall haben wir es Android-Build genannt und in der Version eine Kombination aus Gradle-, Android-SDK- und Platform-Tools-Versionen angegeben. Mit einer solchen „Version“ wird es uns in Zukunft leichter fallen, das gesuchte Bild namentlich zu finden.

Nachdem der Build abgeschlossen ist, können wir unser Image lokal verwenden und es mit dem Befehl herunterladen Docker schieben in ein öffentliches oder privates Image-Repository kopieren, um es auf andere Computer herunterzuladen.

Lassen Sie uns als Beispiel ein lokales Projekt erstellen. Führen Sie dazu im Projektordner den Befehl aus

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

Lassen Sie uns herausfinden, was es bedeutet:

Andocklauf - der Image-Startbefehl selbst
-rm - bedeutet, dass der Container nach dem Stoppen alles löscht, was während seines Lebens erstellt wurde
-v "$PWD":/home/gradle/ - Mountet den aktuellen Ordner mit unserem Android-Projekt im internen Ordner des Containers /home/gradle/
-w /home/gradle - legt das Arbeitsverzeichnis des Containers fest
Android-Build:5.4.1-28-27 - der Name unseres Containers, den wir gesammelt haben
gradleassembleDebug - das Build-Team selbst, das unser Projekt zusammenstellt

Wenn alles gut geht, sehen Sie nach ein paar Sekunden/Minuten so etwas wie ERFOLGREICH BAUEN in 8 m 3 s! Und im Ordner app/build/output/apk befindet sich eine zusammengestellte Anwendung.

Ebenso können Sie andere Gradle-Aufgaben ausführen – das Projekt überprüfen, Tests ausführen usw. Der Hauptvorteil besteht darin, dass wir uns, wenn wir das Projekt auf einem anderen Computer erstellen müssen, nicht um die Installation der gesamten Umgebung kümmern müssen und es ausreicht, das erforderliche Image herunterzuladen und den Build darin auszuführen.

Der Container speichert keine Änderungen und jede Assembly wird von Grund auf neu gestartet, was einerseits die Identität der Assembly garantiert, unabhängig davon, wo sie gestartet wird, andererseits jedes Mal, wenn Sie alle Abhängigkeiten herunterladen müssen und kompilieren Sie den gesamten Code erneut, was manchmal sehr viel Zeit in Anspruch nehmen kann. Daher haben wir neben dem üblichen „Kaltstart“ die Möglichkeit, die Montage unter Beibehaltung des sogenannten zu starten. „Cache“, wo wir den Ordner ~/.gradle speichern, indem wir ihn einfach in den Arbeitsordner des Projekts kopieren, und ihn zu Beginn des nächsten Builds zurückgeben. Wir haben alle Kopiervorgänge in separate Skripte verschoben und der Startbefehl selbst sah nun so aus

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"

Dadurch wurde die durchschnittliche Projekterstellungszeit um ein Vielfaches verkürzt (abhängig von der Anzahl der Abhängigkeiten vom Projekt, aber das durchschnittliche Projekt begann somit in 1 Minute statt in 5 Minuten mit der Erstellung).

Das alles allein macht nur dann Sinn, wenn Sie über einen eigenen internen CI/CD-Server verfügen, den Sie selbst betreuen. Mittlerweile gibt es aber viele Cloud-Dienste, bei denen all diese Probleme gelöst sind und man sich darüber keine Gedanken machen muss und die notwendigen Build-Eigenschaften auch in den Projekteinstellungen festgelegt werden können.

An der Umfrage können nur registrierte Benutzer teilnehmen. Einloggenbitte.

Behalten Sie Ihr CI/CD-System intern oder nutzen Sie einen Drittanbieterdienst?

• Verwendung eines internen Servers

• Nutzung eines externen Dienstes

• Wir verwenden kein CI/CD

• Andere

42 Benutzer haben abgestimmt. 16 Benutzer enthielten sich der Stimme.

Source: habr.com