© microgen, 123RF

Eine lästige Barriere für frisch entschlossene Android-Programmierer, die Linux als Basis verwenden möchten, errichtet die Installation von Googles Android-Entwicklungsumgebung Android Studio. Der Artikel dröselt das vielteilige Prozedere am Beispiel von Debian 8.2 und Android Studio 2.1 auf.

Es klingt simpel: Android Studio [1] installieren, starten – und die erste App schreiben. In der Realität bringen Entwickler aber oft Stunden damit zu, Googles IDE mit dem eigenen Android-Smartphone oder -Tablet zu verkuppeln. Der Workshop soll dabei helfen, die Qual zu lindern. Als Grundlage dient ihm ein Debian 8.2 [2] mit allen Patches von Ende August 2016. Die grundlegenden Schritte dürften sich auf anderen Distributionen ähneln, können sich im Detail aber unterscheiden, was Paketnamen und Fehlermeldungen angeht.

Vorbereitung ist alles

Auf dem Smartphone versteckt Android einen Entwicklermodus, der Optionen für Programmierer anbietet. Die müssen den Modus allerdings explizit aktivieren. Ab Android 5.0 gilt es, die »Einstellungen« zu öffnen und die Option »Über das Telefon« zu wählen. Dort tippt der Entwickler dann den Eintrag »Build-Nummer« mehrfach an, bis Android den Entwicklermodus freischaltet.

Unter »Einstellungen« wartet der neue Eintrag »Entwickleroptionen« , über den der Programmierer den Punkt »USB-Debugging« aktiviert, über den Android Studio später Kontakt mit dem Telefon aufnimmt. Auf dem getesteten Galaxy S6 mit Android 6.0 fand sich die »Buildnummer« unter »Einstellungen | Geräteinformationen | Softwareinfo« . Mehrfaches Tippen schaltet auch hier die »Entwickleroptionen« frei.

Bevor er aber sein Smartphone per USB-Kabel mit dem Linux-Host verknüpft, sollte der Entwickler zunächst Android Studio einrichten.

Reif für die Insel

Debian installiert das freie Java 1.7.0 vor, das im Paket »openjdk-7-jdk« steckt. Android Studio empfiehlt jedoch Oracles Java in Version 8. Wer dem Hinweis folgen möchte, muss ein paar Extraschritte gehen, die das Debian-Wiki [3] auflistet.

Zunächst gilt es, in der »/etc/apt/sources.list« eine Zeile zu ergänzen, die eine zusätzliche Installationsquelle anzapft:

deb http://httpredir.debian.org/debian/  jessie main contrib

Damit Debian die neue Paketquelle auch einliest, aktualisiert der Entwickler die Liste, um dann Java zu installieren:

apt-get update && apt-get install  java-package

Wer jetzt glaubt, er hole sich Java 8 auf den Rechner, der irrt. Das Paket hilft nur beim Bau eines installierbaren Java-8-Pakets – und das braucht als weitere Zutat noch Java 8 von Oracle, das

wget http://download.oracle.com/otn-pub/ja va/jdk/8u102-b14/jdk-8u102-linux-x64.tar.gz

aus dem Internet holt. Die URL ändert sich dank neuer Java-Versionen regelmäßig. Der Entwickler packt das Tar.gz-Archiv nicht aus, es genügt, auf der Kommandozeile ins Verzeichnis zu wechseln, in dem es beim Download landet. Dort baut ihm ein beherztes

make-jpkg jdk-8u102-linux-x64.tar.gz

das gewünschte Debian-Paket (mit der Endung ».deb« ), das er im nächsten Schritt installiert:

dpkg -i oracle-java8-jdk_8u102_amd64.deb

Debian beeindruckt das wenig, es vertraut weiterhin auf Java 7. Also gilt es, Java 8 zum Standard zu machen. Ein »update-alternatives –config java« zeigt alle zur Wahl stehenden Java-Versionen, der Entwickler wählt Version 8 aus.

Android Studio

Hoffnungsfroh lädt er nun Android Studio herunter [1]. Mit Debians Browser Iceweasel gelang das erst nach einem Rechtsklick auf den Downloadlink und »Ziel speichern unter« . Das zugehörige Zip-File entpackt der Entwickler in ein Verzeichnis, im Test hieß es »Downloads« . Entsprechend wechselt er nach »~/Downloads/android-studio/bin« und führt mit normalen Nutzerrechten das im Archiv mitgelieferte Skript »./studio.sh« aus. Im Linux-Magazin-Test scheiterte dies an der Fehlermeldung »Unable to run mksdcard SDK…« , zum Glück ein bekanntes Problem [4]. Ein

apt-get install lib32stdc++6

beseitigte den Fehler auf Debian 8.2 (64 Bit), Ubuntu- und Fedora-User sollen laut einem Ratschlag unter [4] noch ein paar weitere Pakete einspielen.

Im zweiten Durchgang sollte das Skript durchlaufen. Der Entwickler wählt »Standard« als Installationstyp, dann folgen zwei Klicks auf »Next« . Dabei informiert ihn Android Studio, dass es das neueste Android-SDK mit weiteren Komponenten herunterladen will. Ein Klick auf »Finish« beendet die Installation, die aufgrund umfangreicher Downloads eine Weile gedauert hat, schließlich erscheint ein Startbildschirm (Abbildung 1).

Abbildung 1: Der Startbildschirm von Android Studio lässt Entwicklern die Wahl, Beispielprojekte zu importieren. Das ist gut für erste Tests.

Projekt am Start

Im Test suchte die IDE nach dem Start zunächst vergeblich das SDK für das neueste Android (Abbildung 2), das sich unter »/home/Benutzer/Android/Sdk« versteckte. Über »Configure | SDK Manager« trägt der Entwickler den Pfad zum SDK manuell nach. Bei einer Neuinstallation tauchte das Problem später nicht mehr auf.

Abbildung 2: Beim Erststart musste der Entwickler den Pfad zum SDK mitunter manuell nachtragen.

Nun kann der Nutzer erst einmal testen, ob Android Studio samt seinem Buildsystem überhaupt ordnungsgemäß arbeitet. Dazu wählt er am besten »Import an Android Code Sample« und schaut sich ein vorhandenes Projekt an. Läuft das auf dem Zielgerät ordentlich, beginnt er per Klick auf »Start a new Android Studio project« ein eigenes Projekt. Projekte legt die Software übrigens standardmäßig unter »/home/Benutzer/AndroidStudioProjects« ab.

Hürdenlauf

Für den Test im Linux-Magazin fiel die Wahl des Beispielprojekts auf das sehr schlichte »Actionbar | Action Bar Compat« . Nach zwei Klicks auf »Next« und »Finish« versucht Gradle, Androids Buildtool, den Quellcode der Software herunterzuladen und gleich zu kompilieren. Leider fehlen die »Build Tools» noch, es erscheint die Fehlermeldung »Failed to find Build Tools revision 24.0.1« . Ein Klick auf den blau gefärbten Link »Install Build Tools 24.0.1 and sync project« behebt das Problem.

Android Studio empfiehlt dann in einem weiteren kleinen Fenster ein Update des Buildsystems Gradle auf die neueste Version 2.14.1, ein Klick auf »Update« setzt den Schritt in die Tat um.

Als Nächstes stellt Android Studio fest, dass die eben besorgten »Buildtools 24.0.1« Java 1.8 oder höher brauchen, aber Version 1.7 installiert ist. Moment mal, das kann eigentlich nicht sein – und tatsächlich, ein »java -version« zeigt Version 8 an. Android Studio scheint nicht in der Lage zu sein, das Standard-Java zu identifizieren. Über »File | Project Structure« lässt sich der Pfad unter »JDK location« auf Version 8 ausrichten. Der zugehörige Ordner befindet sich im selben Verzeichnis wie der von Java 1.7.

Geräteturnen

Nach diesen Extraschritten tauchen keine weiteren Fehlermeldungen mehr auf und der Kompiliervorgang erreicht endlich sein Ziel (»Gradle build finished« ). Nun ist es Zeit, das Handy per USB-Kabel mit dem Rechner zu verbinden und sich die Beispiel-App anzusehen.

Gesagt, getan: »Run | Run Application« soll die Anwendung direkt auf das per USB-Kabel mit dem Rechner verbundene Handy zaubern. Zuvor fordert ein Fenster den Entwickler auf, ein »Deployment Target« auszuwählen. In der Liste sollte das Smartphone auftauchen.

Ist das nicht der Fall, führt der Weg über den Menü-Eintrag »Tools | Android | Android Device Monitor« . Das zugehörige Fenster zeigt angeschlossene Smartphones an. Zudem sollte der Programmierer den Eintrag »Tools | Android | Enable ADB Integration« aktivieren. Nach einigem Hin und Her tauchte das Handy im Linux-Magazin-Test nach dem Aufruf »Run | Run Application« schließlich als »Deployment Target« auf.

Der Entwickler wählt das Gerät aus und klickt auf »OK« . Nacheinander erscheinen mehrere Meldungen auf dem Display des Mobilgeräts (»USB-Debugging zulassen« und »Erlauben von Zugriff…« ), die es abzunicken gilt. In einem Fall musste der Tester auf dem Linux-Rechner zudem seine Handy-PIN und das Benutzerpasswort angeben.

Nach Abschluss der Prozedur sollte die App auf dem Display erscheinen – stattdessen zeigte das »Event-Log« im unteren Bereich (Abbildung 3) die Fehlermeldung »Error Installing APK« .

Abbildung 3: Die APK-Fehlermeldung verschwand nach der Installation des SDK für Android 6.0 (API-Level 23) und kleineren Korrekturen im Gradle-Buildskript.

Passendes SDK

Wählt der User nichts anders aus, installiert Android Studio die neueste SDK-Version. Für Android 7.0 ist das die mit dem API-Level »24« . Auf dem Testgerät lief aber noch Android 6.0, entsprechend musste das SDK mit API-Level »23« her. Für noch ältere Geräte wären dann noch ältere SDKs gefragt.

Die Auswahl von »Tools | Android | SDK-Manager« ruft ein Fenster auf den Schirm, in dem der Programmierer ein zu seinem Zielgerät passendes SDK auswählt, indem er ein Häkchen bei »Android 6.0« setzt und anschließend »Ok« anklickt. Das allein genügt aber nicht, auch das Softwarebeispiel »Actionbar« muss er auf das SDK vorbereiten. Dazu klickt er oben links auf den vertikalen Reiter »Project« und wählt »Gradle Scripts« aus, um doppelt auf den darunterliegenden Eintrag »build.gradle« zu klicken.

Der Code der Datei erscheint in der Mitte des Bildschirms, nun stellt der Entwickler die Zeilen »compileSdkVersion« und »targetSdkVersion« auf die Version »23« um (Abbildung 3).

Startet Gradle nicht von selbst einen neuen Build, schiebt der Entwickler dies an. Am Ende sollte die App auf dem Bildschirm des Handys erscheinen – gegebenenfalls muss er auf dem Handy noch mal den Zugang erlauben. Über »Build | Build APK« lässt sich zudem ein verteil- und installierbares APK-Paket bauen, das dann unter

/home/Benutzer/AndroidStudioProjects/ Projektname/Application/build/outputs/apk/

erscheint. Es sollte mindestens auf Android-6.0-Smartphones laufen, vermutlich auch auf weiteren Geräten.

Emulation

Der Vorteil, das eigene Handy zu verwenden, besteht darin, so den Build- und Anzeigevorgang zu beschleunigen. Alternativ besteht die Möglichkeit, beliebige Android-Hardware zu emulieren. Das ergibt dann Sinn, wenn ein Entwickler will, dass seine App auf Dutzenden von Zielgeräten zu Hause ist. Allerdings liefen die Emulatoren im Test vergleichsweise langsam, zudem ist von Android-Entwicklern zu hören, dass einige Fehler der Apps erst beim Einsatz auf echter Hardware auftauchen.

Über »Tools | Android | AVD-Manager« und dann »Create Virtual Device« lassen sich verschiedene virtuelle Zielgeräte einrichten. Wer sein eigenes Smartphone nicht in der Liste findet, kann es über »New Hardware Profile« selbst definieren (Abbildung 4). Die Daten des eigenen Handys liefert eine einfache Internetsuche unter dem Stichwort “Hardware Profil”.

Abbildung 4: Um ein virtuelles Android-Device zu erzeugen, sind bestimmte Eckdaten in die Maske einzutragen. Die Hardwareprofil-Daten für das Galaxy S6 lieferte im Test eine Webseite von Samsung.

Ist der Emulator konfiguriert, fordert Android Studio den User gegebenenfalls dazu auf, ein passendes Systemimage für das Gerät herunterzuladen. Die Macher empfehlen dafür das 32-Bit-Image (x86), das im Gegensatz zum 64-Bit-Image auch im Test reibungslos kooperierte.

Startet der Entwickler seine Anwendung beim nächsten Mal über »Run« , legt er im zweiten Schritt über »Create New Emulator« seine neuen virtuellen Zielgeräte einfach als »Deploy Targets« an und sollte schon kurz darauf seine Beispiel-App auf dem Emulator sehen können (Abbildung 5).

Abbildung 5: Über Emulatoren testet der Entwickler seine Apps gegen verschiedene neuere und ältere Geräte.

Fazit

Der Aufwand, den ein Entwickler betreiben muss, um Apps für eine oder mehrere Android-Geräte zu entwickeln, ist überraschend hoch. Das lässt sich zumindest für den Linux-Desktop behaupten, möglicherweise verläuft das Prozedere auf anderen Plattformen besser. Klar, der Entwicklungsprozess an sich ist komplex und Linux-Entwickler sind Kummer gewöhnt, doch die Android-Studio-Macher könnten diese Komplexität besser vor den App-Developern verstecken. Das würde es denen erlauben, zügiger mit der eigentlichen Arbeit zu beginnen.