Android mit Arduinoâ„¢ Due. Manuel di Cerbo

diese ermöglicht das Ausführen von ls, cd, top, rm, reboot etc. Weiter sind Tools wie ping oder netstat vorhanden, welche für den Benutzer oder Entwickler hilfreich sein können.

      3.1.5 System Services

      Ein sehr Android-spezifischer Bestandteil sind die Android Services, welche auf den vorher genannten Elementen aufbauen. Diese sind überwiegend in Java geschrieben, weshalb Android auch eine virtuelle Maschine mitbringt, welche sogenannten »Dalvik-Bytecode« (im Gegensatz zu Java-Bytecode) interpretiert. Verwendet man auf dem PC die Sun Virtual Machine (heute Oracle), so ist es auf Android die Dalvik Virtual Machine. Das Format des Codes unterscheidet sich zwischen den beiden stark. Dalvik-Code ist optimiert für limitierte Ressourcen und für bestmögliche Performance. Die Android Services bieten den Applikationen des Systems Zugriff auf Betriebssystembestandteile oder auch auf Hardware.

      3.1.6 Applikationen, Provider

      Im Diagramm an oberster Stelle finden sich die Applikationen und Content-Provider. Sie bilden die direkte Schnittstelle zwischen Benutzer und Android und verwenden dabei die System Services, um die Funktionalität des Systems zu nutzen. Android-Software-Entwickler befassen sich fast ausschließlich mit dieser Schicht des Systems. Mittels Android-Entwickler-Tools (Android Software Development Kit / Native Development Kit) können solche Applikationen erstellt werden.

      3.2 Development-Tools

      Was Android von anderen Betriebssystemen im Embedded-Bereich unterscheidet, ist das Vorhandensein von Entwicklungs-Tools, die eine Entwicklung mit allen Bestandteilen des Betriebssystems ermöglichen. Das Android SDK (Software Development Kit) wird dabei für die Entwicklung von Apps zur Verfügung gestellt. Mit einer sehr engen Einbettung in der IDE (Entwicklungsumgebung) Eclipse ist das Entwickeln einer einfachen App schon fast ein Kinderspiel.

      3.3 Android-Applikationen

      Android-Applikationen (Apps) können aus verschiedenen Komponenten zusammengesetzt sein. Im Vergleich mit der Java-Entwicklung für den Desktop ist der Lebenszyklus einer Android-App wesentlich stärker in das Betriebssystem integriert. Eine App startet nicht in einer »main«-Methode, sondern eine spezielle App-Komponente wird vom System zu irgendeinem Zeitpunkt ins Leben gerufen.

      Die erste Komponente, die man im Zusammenhang mit Android kennenlernen wird, ist die Activity. Eine Activity ist an ein User Interface (UI) gebunden. Eine Activity wird zum Beispiel vom Benutzer aus dem App-Menü gestartet. Die Java-Klasse Activity überlässt es dem Entwickler, Methoden, die vom Android-Betriebssystem aufgerufen werden, zu überschreiben und zu implementieren.

      Ein Benutzer kann eine Activity stets mit dem »Back«-Button oder dem »Home«-Button verschwinden lassen und zu einem anderen Zeitpunkt wieder hervorholen. Android übernimmt daher die Aufgabe, das Memory dieser Apps zu behalten oder freizugeben und beim nächsten Aufruf alle Initialisierungen wieder zu übernehmen.

      Wie man schnell feststellen wird, unterscheidet sich die Entwicklung einer Android-App sehr stark von der Desktop-Entwicklung. Besonders Multithreading ist von hoher Bedeutung bei Android-Apps – das User Interface darf unter keinen Umständen blockiert werden. Der User soll stets geschmeidige Übergänge von einer Komponente in eine andere haben.

      Android läuft auf mobilen Systemen (verwandt mit Embedded-Systemen) mit speziellen Kriterien. Im Vergleich zum Desktop zeichnen diese Systeme folgende Eigenschaften aus:

      •   weniger Rechenleistung …

      •   weniger Speicher (RAM und Festplattenspeicher) …

      •   weniger Energieverbrauch …

      •   wesentlich kleiner (auch Screen ist kleiner)

      Typischerweise entwickelt man für Mikrocontroller mit der Programmiersprache C. Bei Systemen, welche über eine Memory Management Unit verfügen, wird oft auch C++ verwendet. Java hingegen benötigt eine virtuelle Maschine und wird daher eher auf rechenstarken Systemen benutzt.

      Android verwendet nicht die klassische Java Virtual Machine (JVM), sondern eine eigene, für Embedded-Systeme optimierte virtuelle Maschine, welche Dalvik Virtual Machine (DVM) genannt wird. Unterschiedlich ist auch das Code-Format für den Interpreter. Anstatt »Byte-Code« wird »Dalvik-Code« verwendet, welcher auf Systemen mit geringen Ressourcen eine bessere Performance liefert.

      Aus Sicherheitsgründen befindet sich jede Android-App in ihrem eigenen Linux-Prozess, welcher seine eigene virtuelle Maschine beherbergt. Dieses sogenannte »Sandboxing« stellt sicher, dass das Memory anderer Prozesse geschützt wird. Zudem erhält jede Android-App einen eigenen Linux-user/group-Eintrag (dies hat allerdings nichts mit dem Multi-User-Login für Tablets seit Android 4.2 zu tun).

      Nachdem eine Android-App von Java in Byte-Code und anschließend in Dalvik-Code übersetzt wurde, wird sie zusammen mit ihren Ressourcen (Bilder, Text, Layout, etc.) in ein APK-Paket gepackt. Ist dies geschehen, kann sie auf einem Android-Gerät installiert werden. Der Package-Manager des Betriebssystems nimmt so die APK entgegen, erstellt »Applikations-Menüeinträge« und registriert die neue App im System.

      Folgende Android-App-Komponenten existieren:

      Activity

      Eine Activity ist eine Komponente, welche im Vordergrund des Systems ein User Interface anzeigt. Eine Activity beherbergt mehrere »Views« wie z. B. Buttons oder Textfelder. Auch können ganz eigene Views erstellt werden, z. B. für Spiele. Activities werden vom System in den Vordergrund gerufen. Wenn vom User nicht mehr benötigt, setzt Android diese in den Hintergrund, und falls das Memory knapp wird, werden solche im Hintergrund vorhandenen Activities aus dem Memory entfernt. Beim nächsten Start der Activity wird folglich die ganze Komponente neu initialisiert oder aber das Abbild der Activity aus dem Memory verwendet.