Lektion 05: Die Struktur des erstellten Android Studio Projekts im Detail

Diese Projektelemente sind von essentieller Bedeutung für unsere Android App. Sie werden uns daher im Laufe des Kurses noch öfters begegnen.

1. Die wichtigsten Ordner und Dateien des Android Projekts

Das neu erstellte Android Projekt besitzt bereits eine Vielzahl an automatisch angelegten Ordnern und Dateien. Einige dieser Ordner bzw. Dateien sind zu Projektbeginn von sehr großer Bedeutung, wie bspw. die AndroidManifest.xml Datei oder die verschiedenen build.gradle Dateien.

Wir werden nun auf die zu Projektbeginn wichtigsten Dateien und Ordner kurz eingehen. Im Verlauf des Kurses werden wir sie dann noch ausführlicher kennenlernen und Änderungen an ihnen vornehmen.

Besonders wichtige Projektdateien und -ordner

1. Der Projektpfad – Ganz oben in der Liste im Project-View wird uns der Name unseres Projekts angezeigt. Auch der Pfad zu dem Projektordner mit allen Projektdateien wird an dieser Stelle mit angegeben.

2. Das Package – In dem Package Ordner werden wir unsere selbst erstellten Java Klassendateien ablegen. Im Moment ist der Ordner aber noch leer. Ein Package (Paket) enthält eine oder mehrere Klassen, die sich einen Geltungsbereich (Namespace) für Klassen teilen. Klassennamen müssen nur innerhalb eines Packages eindeutig sein. Dies vermeidet mögliche Namenskonflikte zwischen gleichnamigen Klassen verschiedener Bibliotheken.

3. Der Ressourcenordner – In dem res-Verzeichnis werden alle Ressourcen abgelegt die selbst keinen Programmcode enthalten. Solche Ressourcen sind bspw. XML Layouts, Strings für die Benutzeroberfläche und Bilder (Bitmap Images). Sie werden in ihnen entsprechenden Unterverzeichnissen aufgeteilt.

4. Das App Manifest – Jede Android Anwendung muss eine AndroidManifest.xml Datei (mit exakt diesem Namen) in ihrem Wurzelverzeichnis besitzen. Die Manifest-Datei stellt essentielle Informationen über die eigene Anwendung dem Android System zur Verfügung, welche das System benötigt, bevor es die App ausführen kann.

5. Die Gradle Datei – Mit der build.gradle Datei auf der Modul-Ebene (hier die app-Ebene) wird vorgegeben wie das jeweilige Modul (in unserem Fall die App) zusammengebaut werden soll. Über sie werden die Build Settings konfiguriert, wie compileSdkVersion, minSdkVersion und targetSdkVersion. Auch der eindeutige Name des Moduls (applicationId) wird hier festgelegt.

Die oben angesprochenen Dateien und Ordner sind für die Entwicklung der eigenen Android App essentiell. Natürlich sind die anderen hier nicht besprochenen Dateien und Ordner auch wichtig für das Projekt. Zu Beginn jedoch von eher untergeordneter Bedeutung, daher können sie in den meisten Fällen auch so belassen werden.

2. Der Package-Ordner unseres Android Studio Projekts

In dem Verlauf des Kurses werden wir mehrere Java Klassendateien erstellen, die unsere Anwendung implementieren und die Programmlogik enthalten. Alle Klassendateien werden dabei einem eindeutigen Package (Paket) zugeordnet, dessen Namen wir in der vorherigen Lektion beim Erstellen des neuen Android Studio Projekts bereits festgelegt haben.

Der Package-Name wird nach folgender Vorgehensweise vergeben: Er beginnt mit der Top Level Domain der eigenen Organisation (de), gefolgt von der Organisationsdomain (codeyourapp). Anschließend können weitere Subdomains folgen. Am Ende kommt dann der eigentliche Name des Packages (hier ist es zitate). Die einzelnen Elemente sind durch jeweils einen Punkt . voneinander abgetrennt. Alles zusammen ergibt dann den eindeutigen Package-Namen. Hierbei entspricht jeder Teil des mehrstufigen Paketnamens einem gleichnamigen Unterverzeichnis auf der Festplatte.

Der eindeutige Name unseres Package lautet somit: de.codeyourapp.zitate

In diesem Package-Ordner werden alle von uns erstellten Java Klassendateien abgelegt. Im Moment ist dieser Ordner noch leer. Dies wird sich aber in der nächsten Lektion ändern.

Warum ist es notwendig ein Package zu verwenden? In einem Package abgelegte Klassen teilen sich einen gemeinsamen Geltungsbereich (Namespace). Daraus folgt, dass die gewählten Klassennamen nur innerhalb eines Packages eindeutig sein müssen. Dadurch werden mögliche Namenskonflikte zwischen gleichnamigen Klassen verschiedener Bibliotheken effektiv vermieden. Wir können somit die Namen unserer eigenen Klassen frei wählen, ohne dabei Konflikte mit anderen verwendeten Klassen befürchten zu müssen. Außerdem können mit Hilfe von Packages Klassen mit ähnlichen Funktionen oder der gleichen Kategorie effektiv organisiert werden. Dies ist besonders bei großen Projekten zwingend erfordlich.

3. Der Ressourcenordner unseres Android Studio Projekts

Mit Hilfe des Ressourcenordners res/ ist es möglich Anwendungsressourcen, wie Bilder, Strings und Layout-Dateien, vom eigentlichen Programmcode zu trennen. Auf diese Weise können Ressourcendateien und Quellcode unabhängig voneinander verwaltet werden. Was für größere Android Apps auch notwendig ist.

Besonders nützlich ist dieses Vorgehen bei mehrsprachigen Anwendungen. Mittels verschiedener String-Dateien kann dann abhängig von der auf dem Android System verwendeten Sprache entschieden werden, welche Strings auf der Benutzeroberfläche angezeigt werden sollen. Außerdem können auf diese Weise zur Laufzeit verschiedene Benutzeroberflächen-Layouts abhängig von der Bildschirmgröße und -orientierung zugewiesen werden.

Unser gerade erstelltes Android Studio Projekt besitzt zu Beginn die folgenden Unterverzeichnisse:

Der Ressourcenordner unseres Projekts

• drawable – Hier werden Bilddateien abgelegt die auf den Bildschirm gezeichnet werden können. Dies können bspw. Bitmap Dateien, wie .png, .jpg und .gif, sein. Es können aber auch komplexere Grafiken verwendet werden, wie Nine-Patches-Dateien (in der Größe veränderbare Bitmaps).

• mipmap-hdpi – In diesen Ordnern wird das Launcher Icon abgelegt. Es sind fünf verschiedene mipmap-Ordner automatisch angelegt worden. Jeder enthält das Standard Launcher Icon. Die Icons unterscheiden sich nur in ihrer Auflösung. Die Bezeichnung dpi steht für dots per inch, also die Dichte der Bildpunkte pro Zoll. Die Bezeichnung hdpi (high dpi) deutet auf eine hohe Pixeldichte hin.

• values – XML Dateien die einfache Werte, wie Strings, Integer- oder Farbwerte, enthalten, werden in dem values-Ordner abgelegt. Häufig werden die folgenden Ressourcendateien verwendet: arrays.xml, colors.xml, dimens.xml, strings.xml und styles.xml. In jeder dieser Dateien können mehrere Ressourcen angelegt werden. So können bspw. in der strings.xml Datei mehrere String-Ressourcen mit dem <string>-Tag angelegt werden.

Im Kursverlauf werden wir weitere Unterverzeichnisse in dem res-Ordner anlegen. In dem layout-Ordner werden unsere XML Layoutdateien abgelegt, über die das Layout der Benutzeroberfläche definiert wird. Den menu-Ordner verwenden wir für XML Menüdateien, welche die Menüs (Options Menu oder Context Menu) unserer App definieren. In dem xml-Ordner werden wir Konfigurationsdateien ablegen, mit deren Hilfe Einstellungsdialoge realisiert werden.

Diese drei genannten Unterverzeichnisse existieren momentan noch nicht. Wir werden sie später im Kurs ausführlicher besprechen, wenn sie erstellt werden. Alle besprochenen Ordner müssen exakt die angegebenen Namen tragen. Dies wird so vom Android System zwingend vorausgesetzt.

Sind die Anwendungsressourcen auf diese Weise ausgelagert worden, kann auf sie mit Hilfe von Ressourcen-IDs zugegriffen werden. Diese IDs werden automatisch von Android Studio generiert und befinden sich in der R-Klasse des Projekts. Wie wir die Ressourcen in unserer Anwendung verwenden, werden wir in den nächsten Lektionen kennenlernen.

4. Das App Manifest unseres Android Studio Projekts

Die App Manifest Datei stellt essentielle Informationen über die erstellte Anwendung an das Android System bereit. Da diese Informationen für das Ausführen des Quellcodes erforderlich sind, muss jede Android App mindestens eine AndroidManifest.xml Datei besitzen.

Zu den Hauptaufgaben der Manifest Datei zählen:

• Bekanntgabe des Package-Namen – In dem App Manifest wird der vollständige Name des Packages angegeben. Der Package-Name dient als eindeutige Kennung der Anwendung.

• Beschreibung der App-Komponenten – Im Manifest müssen alle Komponenten der Anwendung beschrieben werden. Typischerweise sind das die Activities, Services, Broadcast Receivers und Content Providers, aus welchen sich die App zusammensetzt. Dabei werden auch die Java Klassen genannt, welche die jeweiligen Komponenten implementieren. Weiterhin werden die Fähigkeiten der Komponenten genannt, wie bpsw. die Intent-Nachrichten, die sie verarbeiten können.

• Deklarieren der benötigten Berechtigungen – Auch die erforderlichen Berechtigungen, über welche die App verfügen muss, wird in der Manifest Datei bekannt gegeben. Eine sehr oft benötigte Berechtigung ist die android.permission.INTERNET, die es Anwendungen erlaubt Network Sockets zu öffnen und diese somit Zugriff auf das Internet erhalten.

In unserem Android Studio Projekt ist die AndroidManifest.xml Datei bereits automatisch beim Anlegen des Projekts erstellt worden. Sie enthält momentan nur die grundlegenden Angaben über unsere Android App. Später werden wir Änderungen an ihr vornehmen, um die zusätzlich erstellten App Komponenten unserer Anwendung bekannt zu geben.

In der unteren Abbildung ist die AndroidManifest.xml Datei zu Projektstart zu sehen:

Das App Manifest, die AndroidManifest.xml Datei, unseres Android Studio Projekts

Wie anhand der oberen Abbildung zu erkennen ist, befindet sich die App Manifest Datei in dem app/src/main/ Ordner unseres Android Studio Projekts. Ihren Inhalt können wir auf der rechten Seite der Abbildung im Editorfenster betrachten.

Der Android Namespace und das package-Element

Jede Manifest-Datei besitzt ein <manifest> Element als Wurzelelement, für welches ein XML-Namespace und das Java-Package der Anwendung angegeben werden müssen. Der Namespace wird mit dem Attribut xmlns:android standardmäßig auf „http://schemas.android.com/apk/res/android“ gesetzt. Das Attribut package bekommt den Package-Namen der App, in unserem Fall de.codeyourapp.zitate (Markierung A), zugewiesen.

Das xmlns-Attribut mit dem Präfix android (xmlns:android) definiert hierbei den android-Namensraum und sollte daher immer den folgenden URI-Wert „http://schemas.android.com/apk/res/android“ erhalten. Auf diese Weise können XML-Elemente mit android:Elementname in den android-Namensraum gesetzt werden und somit Namenskonflikte bei Elementen und Attributen verhindert werden.

Der Wert des package-Attributs dient als eindeutige Anwendungskennung (unique identifier for the application). Außerdem wird er als Standard-Prozessname der Anwendung (default name for the application process) verwendet.

Hinweis: Sobald die eigene App veröffentlicht wird, kann der Package-Name nicht mehr geändert werden. Der Package-Name definiert die Identität der App. Wird er geändert, so wird die Anwendung als eine neue App betrachtet und vorherige Nutzer können nicht auf die neue Version aktualisieren.

Das application-Element beschreibt die Komponenten der App

In dem manifest-Element ist das application-Element eingebettet. Diese beiden Elemente müssen in jeder Manifest-Datei vorhanden sein. Das application-Element muss dabei das letzte Element innerhalb des manifest-Elements sein. Alle anderen Elemente (außer activity-alias) können in einer beliebigen Reihenfolge innerhalb des manifest-Elements auftreten.

Das application-Element beschreibt die Anwendung. Es enthält Unterelemente, welche die Komponenten der Anwendung beschreiben, und Attribute, welche sich auf die gesamte App auswirken. Zu Projektbeginn enthält unsere Android App noch keine Komponenten. Daher besitzt das application-Element auch noch keine Kinderelemente, sondern nur einige Attribute mit denen bspw. der App-Name und das Launcher Icon gesetzt werden.

5. Die Gradle Dateien unseres Android Studio Projekts

In Android Studio ist ein komplexes Build System integriert, welches den Quellcode und die Ressourcen der erstellten Anwendung kompiliert und anschließend in eine APK-Datei (Android Application Package), die auf Android Geräten ausgeführt werden kann, packt.

Für diesen Erstellungsprozess verwendet das Android Build System das Build-Management-Tool Gradle, welches über das Android Plugin for Gradle in Android Studio eingebunden ist. Das Gradle-Tool automatisiert und verwaltet den Erstellungsprozess mit Hilfe von build.gradle Dateien.

In dem Wurzelverzeichnis unseres Android Studio Projekts befindet sich die oberste build.gradle Datei. Sie gibt die Build-Anweisungen für das gesamte Projekt vor, ist aber in unserem Fall von nur geringer Bedeutung. Viel wichtiger sind hingegen die Gradle-Dateien auf Modulebene.

Jedes Anwendungsmodul verfügt dabei über eine eigene build.gradle Datei, die den Build-Prozess für das jeweilige Modul vorgibt. Unser Projekt besteht nur aus einem einzigen Modul, dem app-Modul, und besitzt demzufolge auch nur eine Gradle-Datei auf Modulebene.

In der unteren Abbildung ist die build.gradle Datei des app-Moduls unseres Android Projekts dargestellt. Sie ist bereits im Editorfenster im app-Tab geöffnet:

Die build.gradle Datei auf der Modulebene (hier app)

Zu Projektbeginn sind die in der oberen Abbildung markierten Angaben besonders wichtig:

1. compileSdkVersion – Mit der compileSdkVersion wird der Android API Level vorgegeben, den Gradle zum Kompilieren der App verwenden soll. Die App kann dann alle API Funktionen des angegebenen API Levels und denen darunter nutzen. Der angegebene Wert muss dem der Support Library entsprechen.

2. applicationId – Die applicationId ist die eindeutige Kennung des Packages beim Veröffentlichen. Zwar kann die ID frei gewählt werden, sie sollte jedoch ähnlich oder gleich dem verwendeten Package-Namen sein, um Namenskonflikte mit anderen Entwicklerstudios zu vermeiden.

   Da sich die applicationId und der Package-Name unterscheiden können, muss im Quellcode darauf geachtet werden, immer auf den Package-Namen zu referenzieren, der mit dem package-Attribut in der AndroidManifest.xml Datei definiert wurde.

3. minSdkVersion – Die minSdkVersion gibt an, welcher Android API Level mindestens benötigt wird, damit die App ausgeführt werden kann. Sie legt fest auf welchen Android Systemen die App installiert werden kann. Ist für die minSdkVersion kein Wert gesetzt, wird als mindest Android API Level der Wert 1 angenommen. Zur Laufzeit kann es dann auf älteren Android Systemen zu Abstürzen kommen, wenn auf eine API zugegriffen wird, die nicht auf dem Zielsystem vorhanden ist.

   Ist die minSdkVersion angegeben, kann Android Studio prüfen, ob im Projekt eine API verwendet wird, die über der minSdkVersion liegt und eine Warnung ausgeben. Der minimale Android API Level sollte daher immer vorgegeben werden und gut überlegt sein.

4. targetSdkVersion – Mit der targetSdkVersion wird das System informiert, für welchen Android API Level die App entwickelt wurde. Die Anwendung läuft dann zwar auch auf älteren Android Versionen, bis zurück zur minSdkVersion, jedoch werden dann mitunter Support-Bibliotheken eingesetzt.

   Durch die targetSdkVersion wird auch das Kompatibilitätsverhalten der App vorgegeben. Abhängig von der angegebenen targetSdkVersion wird von der Android Plattform auf dem jeweiligen Android Gerät entschieden, welche Maßnahmen ergriffen werden, um die Kompatibilität der App sicherzustellen.

   Wenn eine App auf einer Android Version ausgeführt wird, die neuer als die targetSdkVersion ist, werden verschiedene Kompatibilitätsmechanismen aktiviert. Auf diese Weise wird sichergestellt, dass die App auch auf neueren Android Versionen funktioniert. Jedoch können dann einige visuelle Elemente deplatziert wirken.

   Beispiel: Ist für die targetSdkVersion ein Wert niedriger als API Level 14 vorgegeben, kann es auf neueren Android Systemen vorkommen, dass die App mit einem Action Overflow Button dargestellt wird.

Die vier oben besprochenen Build-Anweisungen sind für das Android Projekt von sehr großer Wichtigkeit. Daher haben wir sie auch etwas ausführlicher beschrieben. Für Android Programmier-Anfänger können die oberen Erklärungen noch etwas verwirrend klingen. Mit der Zeit und Erfahrungen in der App-Entwicklung werden die beschriebenen Zusammenhänge klarer werden. Daher ist es ratsam, von Zeit zu Zeit diese Lektion zu wiederholen und die eigenen Kenntnisse über den Android Build-Prozess zu vertiefen.

In der Gradle-Datei auf Modulebene sind noch einige weitere Angaben enthalten. Zum jetzigen Zeitpunkt sind diese jedoch nur von untergeordneter Bedeutung. Daher werden wir erst später im Kurs auf sie eingehen.

Zum besseren Verständnis ist die build.gradle im unteren Code-Block noch einmal beispielhaft aufgeführt worden. Dabei sind ihre wichtigsten Elemente mit ausführlichen Kommentaren versehen worden:

build.gradle

/*
 * Als erste Anweisung in der Build Configuration wird das 
 * Android plugin for Gradle angewandt.
 * Dadurch wird der "android" Block verfügbar, durch den 
 * spezielle Android-Build-Options verfügbar werden.
 */
  
plugins {
   id 'com.android.application'
}
  
/*
 * Im "android"-Block werden alle Android-spezifischen 
 * Build Options eingestellt.
 */
  
android {
  
  /*
   * compileSdkVersion gibt den Android API Level vor, den Gradle zum Kompilieren
   * der App verwenden soll. Somit kann die App die API Funktionen des angegebenen
   * API Levels und denen darunter nutzen.
   *
   * buildToolsVersion gibt an, welche Version der SDK Build Tools, der Kommandozeilen-
   * Werkzeuge und des Compiler von Gradle zum Erstellen der App verwenden soll. Die
   * angegebenen Build Tools müssen mit dem SDK Manager geladen werden, falls notwendig.
   */
  
   compileSdkVersion 30
   buildToolsVersion "30.0.3"
  
  /*
   * Der "defaultConfig"-Block umschließt die allgemeinen Einstellungen für alle
   * Build Varianten. Durch ihn können einige Attribute der main/AndroidManifest.xml
   * dynamisch vom Build System überschrieben werden.
   */
  
  defaultConfig {
  
    /*
     * Die applicationId ist die eindeutige Kennung des Packages beim Veröffentlichen.
     * Die ID kann frei gewählt werden. Jedoch muss im Quellcode weiterhin auf den
     * Package-Namen referenziert werden, der mit dem package-Attribut in der 
     * AndroidManifest.xml Datei definiert wurde.
     */
  
    applicationId "de.codeyourapp.zitate"
  
  
    // Gibt den Minimum API Level an, der zum Ausführen der App benötigt wird.
    minSdkVersion 17
  
    // Gibt den API Level an, der zum Testen der App verwendet wird.
    targetSdkVersion 30
  
    // Gibt die Versionsnummer der Anwendung an.
    versionCode 1
  
    // Definiert einen benutzerfreundlichen Versionsnamen für die App.
    versionName "1.0"
  
    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
  }
  
  /*
   * Mit dem "buildTypes"-Block werden multiple Build Types konfiguriert.
   * Standardmäßig werden die beiden Build Types debug und release definiert.
   * Der debug Build Type wird nicht explizit angezeigt.
   * Der release Build Type nutzt die Proguard Einstellungen als Optimierung.
   */
  
  buildTypes {
  
    /*
     * Standardmäßig aktiviert Android Studio für den release Build Type Code
     * Shrinking (Code-Reduzierung) und gibt die Proguard Settings Datei vor.
     */
  
    release {
      minifyEnabled false // Deaktiviert Code Shrinking für den release Build Type.
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
  }

  /*
   * Mit dem "compileOptions"-Block werden diverse Kompilieroptionen vorgegeben.
   * In diesem Beispiel wird die zu verwendende Java Version festgelegt.
   */

  compileOptions {
      sourceCompatibility JavaVersion.VERSION_1_8
      targetCompatibility JavaVersion.VERSION_1_8
    }
    
}
  
/*
 * Der "dependencies"-Block in der Build Configuration Datei auf Modulebene
 * gibt nur die Dependencies vor, die für das Modul selbst benötigt werden.
 * Dependencies sind Bibliotheken, die von der eigenen App verwendet und
 * für das Ausführen der App benötigt werden.
 */
  
dependencies {
  implementation 'androidx.appcompat:appcompat:1.2.0'
  implementation 'com.google.android.material:material:1.2.1'
  testImplementation 'junit:junit:4.+'
  androidTestImplementation 'androidx.test.ext:junit:1.1.2'
  androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}

Zusammenfassung

Wir haben nun die Struktur unseres Android Studio Projekts näher kennengelernt. Auf einige gerade zu Beginn sehr wichtige Dateien und Ordner sind wir dabei ausführlicher eingegangen.

Besondere Beachtung fanden das Package, der Ressourcenordner, die App Manifest-Datei und der Android Build-Prozess mit seinen Gradle-Dateien. Im Verlauf dieses Android Kurses werden wir Änderungen an den hier vorgestellten Projektdateien vornehmen und auch einige neue Dateien und Ordner unserem Android Studio Projekt hinzufügen.

Ziel dieser theoretischen Lektion war es, einen allgemeinen Überblick über die Projektstruktur zu geben, so dass man ein besseres Verständnis für den grundlegenden Aufbau des Android Studio Projekts erlangt und weiß, welche Dateien wofür verantwortlich sind.

Nach so viel Theorie zu Beginn des Kurses wenden wir uns nun der Praxis zu. In der nächsten Lektion werden wir mit dem Programmieren beginnen und die Start-Activity unserer Android App implementieren.

Weiterführende Literatur

• Wikipedia.org: Java Package
• Developer.android.com: Resources -> Overview
• Developer.android.com: Resources -> Dimension
• Developer.android.com: App Manifest
• Wikipedia.org: XML -> Definition
• Wikipedia.org: XML -> Namensraum
• Wikipedia.org: Android Application Package
• Developer.android.com: Gradle -> uses-sdk-Element
• Developer.android.com: Support Library
• Medium.com: Picking compileSdkVersion and minSdkVersion
• Googleblog.com: The Menu Button on newer Android Devices
• Developer.android.com: Android API Level and what has changed