Erstellen von Java-Apps für Android

  • Artikel

Wichtig

Visual Studio App Center wird am 31. März 2025 eingestellt. Sie können Visual Studio App Center zwar weiterhin verwenden, bis es vollständig eingestellt ist, es gibt jedoch mehrere empfohlene Alternativen, zu denen Sie eine Migration in Betracht ziehen können.

Erfahren Sie mehr über Supportzeitpläne und Alternativen.

Führen Sie die folgenden Schritte aus, um Ihre erste Android-App zu erstellen:

  1. Stellen Sie eine Verbindung mit Ihrem Repositorydienstkonto her (GitHub, Bitbucket, VSTS, Azure DevOps).
  2. Wählen Sie ein Repository und einen Branch aus, in dem sich Ihre App befindet.
  3. Wählen Sie das Android-Projekt aus, das Sie erstellen möchten.
  4. Richten Sie Ihren ersten Build ein.

Hinweis

Damit die App auf einem echten Gerät ausgeführt werden kann, muss der Build mit einem gültigen Zertifikat signiert sein.

Hinweis

Das App Center verfolgt das Projekt nach, indem die Verzeichnisdateien gradle (und gradlew) des Android-Projekts durchsucht werden. Schließen Sie diese Dateien nicht in das Projekt .gitignore ein, da App Center Build sie nicht finden kann.

Warnung

Aufgrund des kürzlichen Herunterfahrens von JCenter können bei bestimmten Apps Gradle Task-Fehler auftreten, wenn sie mit App Center erstellt werden. Sehen Sie sich den Migrationsleitfaden von Gradle an. Als Problemumgehung können alle Instanzen von jcenter() aus der build.gradle Datei entfernt und durch jcenter { url "http://jcenter.bintray.com/"}ersetzt werden. Weitere Informationen zum Herunterfahren von JCenter finden Sie hier.

1. Verknüpfen Ihres Repositorys

Sie müssen eine Verbindung mit Ihrem Repositorydienstkonto herstellen, falls dies noch nicht geschehen ist. Nachdem Ihr Konto verbunden ist, wählen Sie das Repository aus, in dem sich Ihr Android-Projekt befindet. Um einen Build für ein Repository einzurichten, benötigen Sie administrator- und Pullberechtigungen dafür.

2. Auswählen einer Verzweigung

Nachdem Sie ein Repository ausgewählt haben, wählen Sie den Branch aus, den Sie erstellen möchten. Standardmäßig werden alle aktiven Branches aufgelistet.

3. Einrichten Ihres ersten Builds

Vor dem ersten Build muss das Android-Projekt konfiguriert werden.

3.1. Buildtrigger

Standardmäßig wird bei jedem Pushvorgang eines Entwicklers in einen konfigurierten Branch ein neuer Build ausgelöst. Dies wird als "Continuous Integration" bezeichnet. Wenn Sie einen neuen Build lieber manuell auslösen möchten, können Sie diese Einstellung im Konfigurationsbereich ändern.

3.2. Buildvariante

Die verfügbaren Buildvarianten werden aus den Buildtypen und Produktvarianten aufgefüllt, die in der Datei build.gradle (App-Ebene) angegeben sind. Wählen Sie aus, welche Buildvariante erstellt werden soll.

Hinweis

App Center Build unterstützt die Suche nach Buildvarianten als Kombination aus einem Buildtyp (Debuggen, Release oder benutzerdefinierten Definierten) und einer Ihrer von Ihnen als Product Flavors deklarierten Versionen. Die Erkennung von Geschmacksdimensionen (Kombinationen mehrerer Produktaromen) wird derzeit nicht unterstützt.

3.3. Erstellen eines Android-App-Pakets (.aab)

Das Android App Bundle ist ein Verteilungsformat, das in den Play Store hochgeladen und zum Generieren optimierter APKs für bestimmte Geräte verwendet wird. Weitere Informationen zum Android App Bundle finden Sie in der offiziellen Android-Dokumentation.

Schalten Sie die Option für Das Android-App-Paket um, um zusätzlich .aab zu zu .apkerstellen. Wenn die build.gradle Datei auf App-Ebene den android.bundle Block enthält, ist diese Option bereits aktiviert.

3.4. Versionsnummer inkrementieren

Wenn diese Option aktiviert ist, wird der Versionscode im AndroidManifest.xml Ihrer App automatisch für jeden Build erhöht. Die Änderung erfolgt während des eigentlichen Builds und wird nicht in Ihr Repository committet.

3.5. Codesignierung

Ein erfolgreicher Build erzeugt eine .apk Datei und eine zusätzliche .aab Datei, falls aktiviert. Um den Build im Play Store freizugeben, muss er mit einem gültigen Zertifikat signiert werden, das in einem Keystore gespeichert ist. Um die aus einem Branch erstellten Builds zu signieren, aktivieren Sie die Codesignatur im Konfigurationsbereich, laden Sie Ihren Keystore in Ihr Repository hoch, und geben Sie die relevanten Anmeldeinformationen im Konfigurationsbereich an. Weitere Informationen zur Codesignatur finden Sie in der Android-Codesignaturdokumentation von App Center. Wird .aab mit den gleichen Anmeldeinformationen wie der .apksigniert.

3.6. Starten Sie Ihren erfolgreichen Build auf einem echten Gerät

Verwenden Sie Ihre neu erstellte APK-Datei, um zu testen, ob Ihre App auf einem echten Gerät gestartet wird. Dadurch wird die Gesamtbuildzeit um etwa 10 Minuten erhöht. Weitere Informationen zum Konfigurieren von Starttests finden Sie hier.

3.7. Konfigurieren über die Datei "build.gradle" (App-Ebene)

Spezifische Informationen zu Ihrem Build werden aus Ihrer Gradle-Datei gesammelt, einschließlich Abhängigkeiten, Version der Buildtools, Buildtypen und Produktversionen.

3.8. Verteilen des Builds

Sie können jeden erfolgreichen Build aus einem Branch so konfigurieren, dass er an eine zuvor erstellte Verteilergruppe oder ein Speicherziel verteilt wird. Sie können innerhalb des Verteilungsdiensts eine neue Verteilergruppe hinzufügen oder eine Speicherverbindung konfigurieren . Es gibt immer eine Standardverteilergruppe namens "Collaborators", die alle Benutzer enthält, die Zugriff auf die App haben.

Hinweis

Bei der Verteilung an den Google Play Store wird ein Android App Bundle (.aab) bevorzugt, das bei Aktivierung verteilt wird. Für App Center-Verteilergruppen und Intune Store-Ziele wird ein regulärer .apk verwendet, auch wenn ebenfalls generiert .aab wird.

4. Erstellen von Ergebnissen

Nachdem ein Build ausgelöst wurde, kann er sich in den folgenden Zuständen befinden:

  • queued : Der Build befindet sich in einer Warteschlange, die darauf wartet, dass Ressourcen freigegeben werden.
  • Erstellen : Die App erstellt und führt verwandte Aufgaben aus.
  • erfolgreich : Der Buildvorgang wurde erfolgreich abgeschlossen.
  • Fehler : Der Build wurde abgeschlossen, aber er ist fehlgeschlagen. Sie können das Buildprotokoll herunterladen und zur Problembehandlung überprüfen.
  • canceled : Der Build wurde von einer Benutzeraktion abgebrochen, oder es ist ein Timeout aufgetreten.

4.1. Buildprotokolle

Laden Sie für einen abgeschlossenen Build (erfolgreich oder fehlgeschlagen) die Protokolle herunter, um mehr über den Buildvorgang zu erfahren. App Center stellt ein Archiv mit den folgenden Dateien bereit:

|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
    |-- <build-step-1>
    |-- <build-step-2>
    |--
    |-- <build-step-n> (e.g. n_Post Job Cleanup.txt)

Die buildschrittspezifischen Protokolle (im Build-/Verzeichnis des Archivs) sind hilfreich, um die Problembehandlung zu beheben und zu verstehen, in welchem Schritt und warum der Build fehlgeschlagen ist.

4.2. Das App-Paket (APK)

Das APK ist ein Paket, das die Android-App und -Ressourcen enthält. Wenn der Build ordnungsgemäß signiert ist, kann das APK auf einem echten Gerät installiert und im Play Store bereitgestellt werden. Wenn der Build nicht signiert wurde, kann das APK auf einem Emulator ausgeführt oder für andere Zwecke verwendet werden.

4.3. Erstellen mehrerer APKs

Wenn Ihre App-Konfiguration mehrere APKs erstellt, müssen Sie auch ein universelles APK erstellen. Unser Buildsystem arbeitet mit einer Standard APK-Datei und ignoriert alle APKs, die für eine bestimmte CPU-ABI oder Bildschirmdichte spezifisch sind. Weitere Informationen zu APK-Splits und zum Erstellen eines universellen APK finden Sie im ABI-Split-Leitfaden.

4.4. Die Datei deobfuscation-mapping (mapping.txt)

Die mapping.txt Datei enthält Informationen zum Zuordnen verschleierter Stapelablaufverfolgungen für die App den ursprünglichen Klassen- und Methodennamen.

  • Wenn Sie zuvor das App Center SDK in Ihre App integriert haben und das Absturzberichtsmodul aktiviert ist, und entweder Proguard oder R8 verwenden, um die App-Binärdatei zu minimieren und zu verschleiern, benötigt der Absturzberichtsdienst diese mapping.txt Datei für einen Build, um lesbare (deobfusierte) Absturzberichte anzuzeigen.
  • Wenn Sie zuvor ein anderes SDK für Absturzberichterstattungszwecke in Ihre App integriert haben (z. B. HockeyApp SDK), benötigt der entsprechende Dienst die mapping.txt Datei, um lesbare Absturzberichte anzuzeigen.

5. Unterstützte Versionen und Anforderungen

Die zum Erstellen von Android-Apps unterstützte Mindestversion ist 7.0 (API-Ebene 24). Android-Apps können für die Ausführung eine niedrigere MINDEST-API-Ebene aufweisen, müssen aber mindestens auf API-Ebene 24 abzielen.

Apps müssen mit Gradle und dem Android Gradle-Plug-In erstellt werden, um ordnungsgemäß konfiguriert zu werden. Ihr Repository muss einen Gradle-Wrapper enthalten.

Siehe auch: Cloud Build Machine-Informationen