Middleware ist eine Reihe von Bibliotheken (Bibliotheken), die zur Lösung häufiger Probleme entwickelt wurden, die eine hohe Effizienz erfordern. Das heißt, diese Ebene ist dafür verantwortlich, implementierte Algorithmen für höhere Ebenen bereitzustellen, Dateiformate zu unterstützen, Informationen zu kodieren und zu dekodieren (z. B. Multimedia-Codecs), Grafiken zu zeichnen und vieles mehr. Die Bibliotheken sind in C/C++ implementiert und für spezifische Gerätehardware kompiliert, mit der sie vom Hersteller vorinstalliert ausgeliefert werden.

Lassen Sie uns einige der Low-Level-Bibliotheken auflisten:

Surface Manager – Android OS verwendet einen zusammengesetzten Fenstermanager, ähnlich wie Compiz (Linux), aber einfacher. Anstatt Grafiken direkt in den Anzeigepuffer zu zeichnen, sendet das System eingehende Zeichenbefehle an den Off-Screen-Puffer, wo sie zusammen mit anderen gesammelt werden, eine bestimmte Komposition bilden und dann dem Benutzer auf dem Bildschirm angezeigt werden. Dadurch kann das System interessante nahtlose Effekte erzeugen, Fenstertransparenz und sanfte Übergänge realisieren.

Media Framework – Bibliotheken implementiert auf Basis von PacketVideo OpenCORE. Mit ihrer Hilfe kann das System Audio- und Videodaten aufzeichnen, wiedergeben und ausgeben statische Bilder. Viele gängige Formate werden unterstützt, darunter MPEG4, H.264, MP3, AAC, AMR, JPG und PNG. Zukünftig soll OpenCORE durch ein einfacheres Stagefright-Framework ersetzt werden.

SQLite ist ein leichtes und leistungsstarkes relationales DBMS, das in Android als Hauptdatenbank-Engine verwendet wird.

3D-Bibliotheken – werden nach Möglichkeit zum hochoptimierten Zeichnen von 3D-Grafiken verwendet Hardware-Beschleunigung. Ihre Implementierungen basieren auf der OpenGL ES 1.0 API.

FreeType ist eine Bibliothek zum Arbeiten mit Bitmaps sowie zum Rastern von Schriftarten und zum Ausführen von Operationen daran. Dies ist eine hochwertige Schriftart- und Text-Rendering-Engine.

LibWebCore – Bibliotheken der berühmten WebKit-Browser-Engine, die auch im Desktop verwendet wird Google-Browser Chrome und Apple Safari.

SGL (Skia Graphics Engine) ist eine offene Engine für die Arbeit mit 2D-Grafiken. Die Grafikbibliothek ist ein Google-Produkt und wird häufig in anderen Programmen verwendet.

SSL – Bibliotheken zur Unterstützung des gleichnamigen kryptografischen Protokolls auf Basis von OpenSSL.

libc ist eine Bibliothek von Standard-C-Sprachaufrufen, ein Analogon von glibc (GNU libc von Linux) für kleine Geräte. Es heißt Bionic.

Reis. 1.5.

Auf der gleichen Ebene befindet sich die Android Runtime – die Umgebung zur Ausführung von Anwendungsprogrammen. Seine Hauptkomponenten sind eine Reihe von Standardbibliotheken und die virtuelle Dalvik-Maschine. Jede Anwendung im Android-Betriebssystem wird in einer eigenen Instanz ausgeführt virtuelle Maschine Dalvik. Somit sind alle laufenden Prozesse vom Betriebssystem und voneinander isoliert. Die Android Runtime-Architektur ist so ausgelegt, dass Programme ausschließlich in der Umgebung der virtuellen Maschine ausgeführt werden. Dadurch ist der Kernel des Betriebssystems vor möglichen Schäden durch seine anderen Komponenten geschützt. Daher können Fehlercodes oder Malware das Android-Betriebssystem und das darauf basierende Gerät nicht beschädigen. Diese Schutzfunktion ist neben der Programmcodeausführung eine der Schlüsselfunktionen der Android Runtime.

Die darüber liegende Schicht ist das Anwendungs-Framework, manchmal auch Anwendungs-Framework-Schicht genannt. Über Anwendungsframeworks erhalten Entwickler Zugriff auf APIs, die von zugrunde liegenden Systemkomponenten bereitgestellt werden. Darüber hinaus werden dank der Architektur des Frameworks jeder Anwendung bereits implementierte Funktionen anderer Anwendungen zur Verfügung gestellt, auf die zugegriffen werden darf. Zu den grundlegenden Diensten und Systemen, die jeder Anwendung zugrunde liegen und Teil des Frameworks sind, gehören:

Ein umfangreicher und erweiterbarer Satz von Ansichten, mit denen visuelle Anwendungskomponenten wie Listen, Textfelder, Tabellen, Schaltflächen oder sogar ein eingebetteter Webbrowser erstellt werden können.

Inhaltsanbieter, die die Daten verwalten, die einige Anwendungen anderen zur Verfügung stellen, damit diese sie für ihre Arbeit nutzen können.

Ressourcenmanager, der Zugriff auf nicht codierte Ressourcen wie Zeichenfolgendaten, Grafiken, Dateien und andere bietet.

Notification Manager, dank dem alle Anwendungen dem Benutzer ihre eigenen Benachrichtigungen in der Statusleiste anzeigen können.

Der Aktivitätsmanager verwaltet Anwendungslebenszyklen, speichert Aktivitätsverlaufsdaten und stellt auch ein Navigationssystem dafür bereit.

Location Manager, der es Anwendungen ermöglicht, regelmäßig aktualisierte Daten über den aktuellen geografischen Standort des Geräts zu empfangen.

An der Spitze des Android-Software-Stacks befindet sich die Anwendungsebene. Dazu gehört eine Reihe grundlegender Anwendungen, die auf dem Android-Betriebssystem vorinstalliert sind. Dazu gehört zum Beispiel ein Browser, Mail-Client, Programm für Senden von SMS, Karten, Kalender, Kontaktmanager und viele andere. Die Liste der integrierten Anwendungen kann je nach Gerätemodell und variieren Android-Versionen. Zusätzlich zu diesem Basisset umfasst die Anwendungsebene alle Anwendungsanwendungen für die Android-Plattform, einschließlich der vom Benutzer installierten.

In der Regel werden Anwendungen für Android in Java geschrieben, es ist jedoch möglich, Programme in C/C++ zu entwickeln (mithilfe des Native Development Kit). Die Verwendung von Basic (mit Simple) und anderen Sprachen kann als exotisch bezeichnet werden. Sie können auch Ihre eigenen Programme mit App-Buildern wie App Inventor erstellen.

1.6. Kernel-Funktionen

Der Kernel ist der wichtigste Teil des Linux-Betriebssystems und wurde im Gegensatz zu seinen anderen Teilen fast vollständig auf das Android-Betriebssystem übertragen. Während des Portierungsprozesses wurden jedoch etwa 250 Patches auf den Kernel angewendet.

Im Android-Betriebssystem-Kernel wurde beschlossen, die Interprozess-Kommunikationstools des Linux-Betriebssystems aufzugeben und stattdessen einen einzigen Mechanismus namens Binder zu erstellen. Mit Binder können Sie Methoden eines Prozesses von einem anderen Prozess aus aufrufen, ihnen Argumente übergeben und ein Ergebnis erhalten, ähnlich wie Methoden innerhalb desselben Prozesses aufgerufen werden. Binder erledigt diese Aufgabe mit minimalem Speicherverbrauch.

Um das Debuggen auf kleinen Geräten zu ermöglichen, hat der Kernel eine Debug-Ausgabe zum seriellen Port hinzugefügt und Unterstützung für den Befehl logcat implementiert.

Große Veränderungen wirkten sich auf die Arbeit mit dem Gedächtnis aus. Der traditionelle Linux-Shared-Memory-Shmem wurde durch Ashmem ersetzt. Die gleiche Aufgabe, aber auf dem gleichen Niveau physikalischer Speicher, mit dem PMEM-Treiber gelöst. Es wurde ein spezieller Out-of-Memory-Handler namens Viking Killer hinzugefügt, der im einfachsten Fall den Prozess einfach abbricht, es können jedoch komplexere Regeln angegeben werden.

Dem Netzwerk-Stack wurden neue Sicherheitseinstellungen hinzugefügt, Unterstützung Dateisystem Für Flash-Medien ist YAFFS2 im Kernel enthalten.

1.7. Dalvik Java-Maschine

Dalvik Virtuelle Maschine ist Teil der mobilen Android-Plattform. Dies ist eine virtuelle Maschine, die von Dan Bronstein erstellt wurde. Es wird als freie Software unter der BSD-kompatiblen Apache 2.0-Lizenz vertrieben. Diese Tatsache spielte in vielerlei Hinsicht eine Rolle bei der Entscheidung von Google, auf JME (Java Micro Edition) zu verzichten, das von Sun hätte lizenziert werden müssen. Daher entwickelte das Unternehmen, dessen Ziel es war, ein offenes Betriebssystem zu schaffen, eine eigene virtuelle Maschine.

Im Gegensatz zu den meisten virtuellen Maschinen (der gleichen Java Virtual Machine), die stapelorientiert sind, ist Dalvik registerorientiert, was nicht als Standardlösung bezeichnet werden kann. Andererseits eignet es sich sehr gut für die Arbeit auf Prozessoren der RISC-Architektur, zu denen auch die in sehr weit verbreiteten ARM-Prozessoren gehören mobile Geräte Oh.

Dalvik wurde speziell für die Android-Plattform entwickelt. Dabei wurde berücksichtigt, dass die Plattform alle Prozesse isoliert aufbaut und jeder in seinem eigenen Adressraum läuft. Die virtuelle Maschine ist für geringen Speicherverbrauch optimiert und läuft auf mobiler Hardware. Ab Android 2.2 verwendet Dalvik die JIT-Kompilierung (Just-in-Time). Als Ergebnis dieser Funktionen entsteht eine schnelle und produktive virtuelle Maschine, die sich nur auf den Betrieb der Anwendungen insgesamt auswirken kann.

Dalvik verwendet seinen eigenen Bytecode. Bei der Entwicklung von Anwendungen für Android übersetzt der Compiler diese in speziellen maschinenunabhängigen Low-Level-Code. Bei der Ausführung auf der Plattform ist es Dalvik, der ein solches Programm interpretiert und ausführt.

Darüber hinaus ist Dalvik in der Lage, Java-Bytecodes in Codes seines eigenen Formats zu übersetzen und diese auch in seiner virtuellen Umgebung auszuführen. Der Programmcode ist in Java geschrieben und nach der Kompilierung ist alles erledigt. Klassendateien werden mit in das .dex-Format (geeignet für die Interpretation in Dalvik) konvertiert besonderer Nutzen dx, im Android SDK enthalten.

1.8. Bionisch

Bionic ist eine Bibliothek mit Standard-C-Sprachaufrufen, die unter der BSD-Lizenz (Berkeley Software Distribution – Vertriebssystem) vertrieben wird Software V Quellcodes, erstellt für den Erfahrungsaustausch zwischen Bildungseinrichtungen) und entwickelt von Google für Android. Bionic fehlen einige Nicht-Android-POSIX-Funktionen, die in der vollständigen Glibc-Implementierung verfügbar sind.

Hauptunterschiede der Bionik:

BSD-Lizenzen: Android verwendet den Linux-Kernel, der unter der GNU General Public License (GPL) steht, aber Google wollte Android-Anwendungen von den Auswirkungen der GPL isolieren. GNU libc, das häufig mit dem Linux-Kernel verwendet wird, ist als Alternative zu uClibc unter der GNU LGPL lizenziert.

Geringe Größe: Der bionische Objektcode ist viel kleiner (etwa 2-mal) als Glibc und etwas kleiner als uclibc.

Bionic ist für Prozessoren mit relativ niedrigen Taktraten konzipiert.

eine verkürzte, aber effiziente Implementierung von POSIX-Threads.

1.9. Übersicht über Java-Anw

Für einen Android-Anwendungsprogrammierer – eine Reihe von Schnittstellen in der Java-Sprache. Schauen wir uns an, wie es organisiert ist. Der Satz basiert auf Paketen, die im Java-Sprachstandard enthalten sind, wie z. B. java.util, java.lang, java.io. Sie sind auf jeder Plattform verfügbar, auf der Java-Anwendungen ausgeführt werden können, und sind nicht spezifisch für Android. Sie werden von Erweiterungen begleitet, die nicht im Sprachstandard enthalten sind, aber seit langem de facto zum Standard gehören – Pakete javax.net, javax.xml.

Android enthält auch weniger verbreitete Java-Erweiterungen – das Paket org.apache.http, die robusteste Implementierung des HTTP-Protokolls. Das Paket org.json ist für die Serialisierung von JavaScript-Objekten und die Unterstützung der AJAX-Technologie verantwortlich. Das Paket org.w3c.dom stellt das Dokumentobjektmodell bereit

Dateisystem des Android-Betriebssystems

Deshalb werden wir in diesem Artikel, wie Sie vielleicht anhand des Titels erraten haben, darüber sprechen allgemeine Struktur Android-Dateisystem. Beschreibung der Hauptverzeichnisse, Formatierungsmethoden, Sicherung usw.. Der Artikel richtet sich hauptsächlich an Anfänger. Ich hoffe, dass andere es interessant finden, es zu lesen.
Linux-Dateisystemstruktur

Android kennt keine Laufwerke, die vielen bekannt sind – etwa c oder d. Das Stammverzeichnis des Dateisystems ist „“. Alle anderen Verzeichnisse werden an das Stammverzeichnis angehängt. Schauen wir uns einige davon an:

system - anhand des Namens können Sie bereits vermuten, dass sich hier Systemdateien befinden (so etwas, wie wir es im Microsoft-Betriebssystem c:windows sehen können). Die Dateien in diesem Ordner sind standardmäßig unveränderlich. Sie dienen der Funktionsfähigkeit des Betriebssystems. Es gibt auch integrierte Anwendungen, die in das Betriebssystem integriert sind. Wenn wir Root-Rechte erhalten, können wir unsere Änderungen in diesem Verzeichnis vornehmen. Dies sollte jedoch sorgfältig erfolgen, da gelöschte Dateien und die Ordner werden nicht von selbst wiederhergestellt. In diesem Fall hilft uns nur das Flashen oder Backup. Etwas Interessantes finden Sie im Systemmedia-Ordner. Das Archiv bootanimation.zip enthält Bilder, aus denen die Animation beim Einschalten des Geräts besteht. Im Stammverzeichnis des Systemordners finden Sie die Datei build.prop, die viele Einstellungen enthält, von der Beschreibung des Geräts bis zur Bildschirmdichte (es gibt viele Einstellungen zum Festlegen dieser Konfiguration). Anwendungen von Drittherstellern).Bildschirm

Daten – im Gegensatz zu Systemen werden sie hier gespeichert veränderbare Dateien. In der Unterkategorie „App“ werden sie gespeichert apk installiert uns Programme.Bildschirm

Wenn wir für eine Anwendung eine APK-Datei benötigen, können wir sie dort leicht finden. Und in datadata die Daten davon installierte Programme.
Mnt – Benutzerspeicher wird in dieser Partition gemountet (wenn Sie beispielsweise eine Flash-Karte installieren). Wenn wir also unsere TXT-Datei im Stammverzeichnis der Flash-Karte ablegen, sieht der vollständige Pfad so aus: mntsdcardfile.txt" Hier wird auch die eingebaute Festplatte von Smartphones ohne Speicherkartenunterstützung montiert. Bildschirm

So löschen Sie (Einstellungen zurücksetzen) auf Android

Es gibt mehrere Formatierungsoptionen. Nachfolgend sind einige davon aufgeführt.
1.Zurücksetzen über die Einstellungen. Gehen Sie zu Einstellungen >> Wiederherstellung und Zurücksetzen >> Einstellungen zurücksetzen. Setzt alle Einstellungen zurück und entfernt installierte Software. Zuvor können Sie einige Einstellungen sichern, indem Sie das entsprechende Kontrollkästchen aktivieren. Nach dem Neustart fragt das Gerät, ob diese Daten wiederhergestellt werden sollen.
Bildschirm

2.Reset per Recovery. Nützlich in einer Situation, in der sich das Gerät nicht einschalten lässt. Sie müssen den Root-Zugriff und die Wiederherstellung entsprechend installieren. Abhängig von der installierten Wiederherstellung kann der Speicherort der Elemente variieren. Für mich ist dies das erweiterte Wischelement. Enthält:
Dalvik Cache– Formatieren des Caches der virtuellen Dalvik-Maschine.
System- Formatieren der Systempartition.
Daten– Löschen aller Drittanbieteranwendungen im Gerätespeicher sowie der Benutzereinstellungen.
Cache – Cache löschen
SD-Karte formatieren– Formatieren der Speicherkarte. Alles auf der Speicherkarte löschen.
Formatieren Sie SD-Ext– Formatieren der ext-Partition auf der Speicherkarte (falls eine solche Partition erstellt wurde. Zum Beispiel, um das Skript der verweisenden Anwendung bei der Installation auf der Karte bereitzustellen).
3. Formatierung mit dem Servicecode. Wenn Sie * 2767 * 3855 # wählen. Unmittelbar nach dem Wählen erfolgt ein Reset. Seien Sie aufmerksam.
Wenn Sie beispielsweise den Inhalt des Ordners „datadata“ löschen, werden zwar Einstellungen und Anwendungsdaten gelöscht, nicht jedoch die Anwendungen selbst. Dies kann auch über die Anwendungseinstellungen „Daten löschen“ erfolgen. Wenn Sie einen Ordner löschen, wird das Datum gelöscht installierte Anwendungen.
Bitte hinterlassen Sie Ihre Wünsche, Korrekturen, Ergänzungen zum Artikel in den Kommentaren oder schreiben Sie mir eine PN. Der Artikel wird aktualisiert. Vielen Dank an die Leser, viel Glück.
-----------------
Sie können im Abschnitt „Artikelkatalog“ Kommentare hinterlassen. Haben Sie sich jemals gefragt, wie Fastboot oder ADB funktionieren? Oder warum ein Smartphone unter ist Android-Steuerung fast unmöglich in einen Ziegelstein zu verwandeln? Oder vielleicht wollten Sie schon lange wissen, wo die Magie des Xposed-Frameworks liegt und warum die Boot-Skripte /system/etc/init.d benötigt werden? Was ist mit der Wiederherstellungskonsole? Ist das Teil von Android oder eine Sache für sich und warum eignet sich die regelmäßige Wiederherstellung nicht für die Installation von Firmware von Drittanbietern? Antworten auf all diese und viele weitere Fragen finden Sie in diesem Artikel.

So funktioniert Android

Informieren Sie sich über versteckte Möglichkeiten Softwaresysteme können verstanden werden, indem man das Prinzip ihrer Funktionsweise versteht. In einigen Fällen ist dies schwierig, da der Systemcode möglicherweise geschlossen ist. Im Fall von Android können wir jedoch das gesamte System in- und auswendig untersuchen. In diesem Artikel werde ich nicht auf alle Nuancen eingehen Android funktioniert und ich werde nur darauf eingehen, wie das Betriebssystem startet und welche Ereignisse in der Zeit zwischen dem Drücken des Netzschalters und dem Erscheinen des Desktops stattfinden.

Unterwegs erkläre ich, was wir in dieser Ereigniskette ändern können und wie Entwickler benutzerdefinierter Firmware diese Funktionen nutzen, um Dinge wie die Optimierung von Betriebssystemparametern, die Erweiterung des Anwendungsspeicherplatzes, die Verbindung von Swap, verschiedene Anpassungen und vieles mehr zu implementieren. Mit all diesen Informationen können Sie Ihre eigene Firmware erstellen und verschiedene Hacks und Modifikationen implementieren.

Schritt eins. ABOOT und Partitionstabelle

Alles beginnt mit dem primären Bootloader. Nach dem Einschalten führt das System den darin gespeicherten Bootloader-Code aus permanentes Gedächtnis Geräte. Dann übergibt es die Kontrolle an den aboot-Bootloader mit integrierter Unterstützung für das Fastboot-Protokoll, aber der Hersteller des mobilen Chips oder Smartphones/Tablets hat das Recht, einen anderen Bootloader seiner Wahl zu wählen. Rockchip verwendet beispielsweise einen eigenen Bootloader, der nicht Fastboot-kompatibel ist und zum Flashen und Verwalten proprietäre Tools benötigt.

Das Fastboot-Protokoll wiederum ist ein System zur Verwaltung des Bootloaders von einem PC aus, mit dem Sie Aktionen wie das Entsperren des Bootloaders, das Flashen eines neuen Kernels und die Wiederherstellung, die Installation von Firmware und viele andere ausführen können. Die Daseinsberechtigung von Fastboot besteht darin, ein Smartphone in einer Situation in seinen ursprünglichen Zustand zurückversetzen zu können, in der alle anderen Mittel versagen. Fastboot bleibt bestehen, auch wenn Sie aufgrund von Experimenten alle NAND-Speicherpartitionen mit Android und der Wiederherstellung von Ihrem Smartphone löschen.

Nachdem aboot die Kontrolle erhalten hat, überprüft es die Partitionstabelle und überträgt die Kontrolle an den Kernel, der in die Partition mit dem Namen boot geflasht wurde. Anschließend extrahiert der Kernel das RAM-Image aus derselben Partition in den Speicher und beginnt mit dem Laden von entweder Android oder der Wiederherstellungskonsole. Der NAND-Speicher in Android-Geräten ist in sechs bedingt erforderliche Abschnitte unterteilt:

• boot – enthält den Kernel und die RAM-Disk, normalerweise etwa 16 MB groß;
• Wiederherstellung – Wiederherstellungskonsole, besteht aus einem Kernel, einer Reihe von Konsolenanwendungen und einer Einstellungsdatei, Größe 16 MB;
• System - enthält Android, bei modernen Geräten beträgt die Größe mindestens 1 GB;
• Cache – dient zum Speichern zwischengespeicherter Daten, wird auch zum Speichern der Firmware während eines OTA-Updates verwendet und hat daher eine Größe, die der Größe der Systempartition ähnelt;
• Benutzerdaten – enthält Einstellungen, Anwendungen und Benutzerdaten, der gesamte verbleibende NAND-Speicherplatz ist ihm zugewiesen;
• misc – enthält ein Flag, das bestimmt, in welchem ​​Modus das System booten soll: Android oder Wiederherstellung.

Darüber hinaus kann es noch weitere Abschnitte geben, das allgemeine Markup wird jedoch in der Designphase des Smartphones festgelegt und im Fall von aboot in den Bootloader-Code eingenäht. Dies bedeutet, dass: 1) die Partitionstabelle nicht gelöscht werden kann, da sie jederzeit mit dem Befehl fastboot oem format wiederhergestellt werden kann; 2) Um die Partitionstabelle zu ändern, müssen Sie den Bootloader entsperren und mit neuen Parametern neu flashen. Es gibt jedoch Ausnahmen von dieser Regel. Beispielsweise speichert der Bootloader desselben Rockchip Informationen über Partitionen im ersten Block des NAND-Speichers, sodass ein Flashen des Bootloaders nicht erforderlich ist, um diese zu ändern.

Teil des Bootloader-Codes, der die Partitionstabelle definiert​

Besonders interessant ist der Abschnitt „Verschiedenes“. Es besteht die Vermutung, dass es ursprünglich zum Speichern verschiedener Einstellungen unabhängig vom Hauptsystem erstellt wurde, derzeit jedoch nur für einen Zweck verwendet wird: dem Bootloader anzuzeigen, von welcher Partition das System geladen werden soll – Booten oder Wiederherstellen. Diese Funktion wird insbesondere von der ROM Manager-Anwendung verwendet automatischer Neustart Systeme in der Wiederherstellung mit automatischer Installation der Firmware. Auf dieser Basis ist der Doppellademechanismus aufgebaut. Ubuntu Touch, wodurch der Ubuntu-Bootloader in die Wiederherstellung geflasht wird und Sie steuern können, welches System beim nächsten Mal gestartet werden soll. Die sonstige Partition gelöscht – Android lädt, mit Daten gefüllt – Wiederherstellung lädt … also Ubuntu Touch.

Schritt zwei. Boot-Bereich

Wenn der Abschnitt „Misc“ kein Recovery-Boot-Flag hat, überträgt aboot die Kontrolle an den Code im Boot-Abschnitt. Es ist nichts weiter als Linux Kernel; Es befindet sich am Anfang des Abschnitts und unmittelbar darauf folgt ein mit cpio- und gzip-Archivern gepacktes RAM-Disk-Image, das die für den Betrieb von Android erforderlichen Verzeichnisse, das Init-Initialisierungssystem und andere Tools enthält. Auf der Boot-Partition gibt es kein Dateisystem, Kernel und RAM-Disk folgen einfach aufeinander. Der Inhalt der RAM-Disk ist:

• data - Verzeichnis zum Mounten der gleichnamigen Partition;
• dev – Gerätedateien;
• proc – procfs wird hier gemountet;
• res – eine Reihe von Bildern für das Ladegerät (siehe unten);
• sbin – eine Reihe von Dienstprogrammen und Daemons (z. B. adbd);
• sys – sysfs wird hier gemountet;
• system – Verzeichnis zum Mounten der Systempartition;
• Ladegerät – Anwendung zur Anzeige des Ladevorgangs;
• build.prop – Systemeinstellungen;
• init – Initialisierungssystem;
• init.rc – Initialisierungssystemeinstellungen;
• ueventd.rc – Einstellungen des in init enthaltenen uventd-Daemons.

Dies ist sozusagen das Grundgerüst des Systems: eine Reihe von Verzeichnissen zum Verbinden von Dateisystemen aus NAND-Speicherpartitionen und ein Initialisierungssystem, das den Rest der Arbeit des Systemstarts übernimmt. Das zentrale Element hierbei ist die Init-Anwendung und ihre init.rc-Konfiguration, auf die ich später noch ausführlicher eingehen werde. In der Zwischenzeit möchte ich Sie auf die Dateien „charger“ und „ueventd.rc“ sowie auf die Verzeichnisse „sbin“, „proc“ und „sys“ aufmerksam machen.

Die Ladedatei ist eine kleine Anwendung, deren einzige Aufgabe darin besteht, das Batteriesymbol anzuzeigen. Es hat nichts mit Android zu tun und wird verwendet, wenn das Gerät im ausgeschalteten Zustand an das Ladegerät angeschlossen ist. In diesem Fall Android-Downloads passiert nicht, und das System lädt einfach den Kernel, schließt die RAM-Disk an und startet das Ladegerät. Letzteres zeigt ein Batteriesymbol an, dessen Bild in allen möglichen Zuständen in gewöhnlichen PNG-Dateien im res-Verzeichnis gespeichert wird.

Die Datei ueventd.rc ist eine Konfiguration, die bestimmt, welche Gerätedateien im sys-Verzeichnis während des Systemstarts erstellt werden sollen. Auf Kernelbasis Linux-Systeme Der Zugriff auf die Hardware erfolgt über spezielle Dateien im Dev-Verzeichnis, und der ueventd-Daemon, der Teil von init ist, ist für deren Erstellung in Android verantwortlich. In einer normalen Situation funktioniert es automatischer Modus, akzeptiert Befehle zum Erstellen von Dateien vom Kernel, einige Dateien müssen jedoch unabhängig erstellt werden. Sie sind in ueventd.rc aufgeführt.

Das Sbin-Verzeichnis im Standard-Android enthält normalerweise nichts außer adbd, also dem ADB-Daemon, der für das Debuggen des Systems vom PC aus zuständig ist. Es wird früh beim Betriebssystemstart ausgeführt und ermöglicht die Erkennung mögliche Probleme in der Betriebssysteminitialisierungsphase. IN angepasste Firmware In diesem Verzeichnis finden Sie eine Reihe anderer Dateien, z. B. mke2fs, die möglicherweise benötigt werden, wenn die Partitionen auf ext3/4 umformatiert werden müssen. Außerdem platzieren Modder dort oft eine BusyBox, mit der man Hunderte von Linux-Befehlen aufrufen kann.

Das proc-Verzeichnis ist Standard für Linux; in den nächsten Phasen des Bootens stellt init eine Verbindung zu procfs her, einem virtuellen Dateisystem, das Zugriff auf Informationen über alle Prozesse auf dem System bietet. Das System verbindet sysfs mit dem sys-Verzeichnis, wodurch der Zugriff auf Informationen über die Hardware und ihre Einstellungen geöffnet wird. Mit sysfs können Sie beispielsweise das Gerät in den Ruhezustand versetzen oder den verwendeten Energiesparalgorithmus ändern.

Die Datei build.prop dient zum Speichern auf niedriger Ebene Android-Einstellungen. Später wird das System diese Einstellungen zurücksetzen und sie mit Werten aus der derzeit nicht zugänglichen Datei system/build.prop überschreiben.

Root-Bereich der OUYA TV-Set-Top-Box​

Schritt zwei, Alternative. Wiederherstellungsabschnitt

Wenn das Recovery-Boot-Flag im Abschnitt „Misc“ gesetzt ist oder der Benutzer das Smartphone einschaltet, während die Leiser-Taste gedrückt gehalten wird, übergibt aboot die Steuerung an den Code, der sich am Anfang des Wiederherstellungsabschnitts befindet. Sie enthält wie die Boot-Partition den Kernel und eine RAM-Disk, die in den Speicher entpackt wird und zum Stammverzeichnis des Dateisystems wird. Allerdings ist der Inhalt der RAM-Disk hier etwas anders.

Im Gegensatz zur Boot-Partition, die als Übergangsverbindung zwischen verschiedenen Ladephasen des Betriebssystems fungiert, ist die Wiederherstellungspartition völlig autark und enthält eine Miniatur Betriebssystem, was nichts mit Android zu tun hat. Recovery verfügt über einen eigenen Kern, einen eigenen Anwendungssatz (Befehle) und eine eigene Schnittstelle, die es dem Benutzer ermöglicht, Servicefunktionen zu aktivieren.

Bei einer standardmäßigen (Standard-)Wiederherstellung gibt es normalerweise nur drei solcher Funktionen: Installation der mit dem Schlüssel des Smartphone-Herstellers signierten Firmware, Löschen und Neustarten. Modifizierte Wiederherstellungen von Drittanbietern wie ClockworkMod und TWRP bieten viel mehr Funktionen. Sie können Dateisysteme formatieren, mit beliebigen Schlüsseln signierte Firmware installieren (sprich: benutzerdefiniert), Dateisysteme auf anderen Partitionen mounten (für Betriebssystem-Debugging-Zwecke) und Skriptunterstützung einschließen, mit der Sie den Firmware-Prozess und viele andere Funktionen automatisieren können.

Mithilfe von Skripten können Sie beispielsweise dafür sorgen, dass Recovery nach dem Booten automatisch die benötigte Firmware auf der Speicherkarte findet, diese installiert und einen Neustart in Android durchführt. Diese Funktion wird vom ROM Manager, dem Auto-Flasher und dem verwendet Automatisches Update CyanogenMod und andere Firmware.

Die benutzerdefinierte Wiederherstellung unterstützt auch Sicherungsskripte, die sich im Verzeichnis /system/addon.d/ befinden. Vor Firmware-Wiederherstellung sucht nach Skripten und führt diese aus, bevor die Firmware geflasht wird. Dank solcher Skripte verschwinden Gapps nach der Installation nicht neue Version Firmware.

Schritt drei. Initialisierung

Nachdem der Kernel die Kontrolle erhalten hat, verbindet er die RAM-Disk und startet nach der Initialisierung aller seiner Subsysteme und Treiber den Init-Prozess, der mit der Initialisierung von Android beginnt. Wie ich bereits sagte, hat init Konfigurationsdatei init.rc, aus der der Prozess erfährt, was genau er tun muss, um das System hochzufahren. In modernen Smartphones hat diese Konfiguration eine beeindruckende Länge von mehreren hundert Zeilen und ist außerdem mit einem Trailer mehrerer untergeordneter Konfigurationen ausgestattet, die über die Importdirektive mit der Hauptkonfiguration verbunden sind. Das Format ist jedoch recht einfach und besteht im Wesentlichen aus einer Reihe von Befehlen, die in Blöcke unterteilt sind.

Jeder Block definiert eine Ladephase oder, im Android-Entwicklerjargon, eine Aktion. Blöcke werden durch eine On-Direktive, gefolgt vom Namen der Aktion, voneinander getrennt, z. B. on Early-Init oder On Post-Fs. Der Befehlsblock wird nur ausgeführt, wenn der gleichnamige Trigger ausgelöst wird. Beim Booten aktiviert init nacheinander die Early-Init-, Init-, Early-Fs-, Fs-, Post-Fs-, Early-Boot- und Boot-Trigger und startet so die entsprechenden Befehlsblöcke.

Teil der init.rc-Konfiguration von CyanogenMod​

Wenn die Konfigurationsdatei mehrere weitere Konfigurationen enthält, die am Anfang aufgeführt sind (was fast immer der Fall ist), werden die darin enthaltenen Befehlsblöcke mit demselben Namen mit der Hauptkonfiguration kombiniert, sodass init dies tut, wenn der Trigger ausgelöst wird Befehle aus den entsprechenden Blöcken aller Dateien ausführen. Dies geschieht zur Vereinfachung der Erstellung von Konfigurationsdateien für mehrere Geräte, wenn die Hauptkonfiguration Befehle enthält, die allen Geräten gemeinsam sind, und die für jedes Gerät spezifischen Befehle in separate Dateien geschrieben werden.

Die bemerkenswerteste der zusätzlichen Konfigurationen heißt initrc.device_name.rc, wobei der Gerätename automatisch basierend auf dem Inhalt der Systemvariablen ro.hardware ermittelt wird. Dies ist eine plattformspezifische Konfigurationsdatei, die spezifische Befehlsblöcke enthält spezifisches Gerät. Zusätzlich zu den Befehlen, die für die Optimierung des Kernels zuständig sind, enthält es auch etwa Folgendes:

mount_all ./fstab.Gerätename

Das bedeutet, dass init nun alle Dateisysteme mounten sollte, die in der Datei ./fstab.device_name aufgeführt sind, die die folgende Struktur hat:

Gerätename (Partition) Mount_Point Dateisystem FS_Options andere Optionen

Es enthält normalerweise Anweisungen zum Mounten von Dateisystemen von internen NAND-Partitionen in die Verzeichnisse /system (Betriebssystem), /data (Anwendungseinstellungen) und /cache (zwischengespeicherte Daten). Durch eine leichte Änderung dieser Datei können wir jedoch init zwingen, das System von der Speicherkarte zu starten. Teilen Sie dazu einfach die Speicherkarte in drei 4 Abschnitte auf: 1 GB/ext4, 2 GB/ext4, 1 GB/ext4 und den restlichen Fat32-Speicherplatz. Als nächstes müssen Sie die Namen der Speicherkartenpartitionen im Verzeichnis /dev ermitteln (z verschiedene Geräte sie sind unterschiedlich) und ersetzen Sie sie durch die ursprünglichen Gerätenamen in der fstab-Datei.

Typischer Inhalt einer fstab-Datei​

Am Ende des Boot-Init-Blocks wird er höchstwahrscheinlich auf den Standardbefehl class_start stoßen, der Sie darüber informiert, dass Sie dann alle in der Konfiguration aufgeführten Dienste starten sollten, die sich auf die Standardklasse beziehen. Die Beschreibung von Diensten beginnt mit der Dienstanweisung, gefolgt vom Namen des Dienstes und dem Befehl, der ausgeführt werden muss, um ihn zu starten. Im Gegensatz zu den in den Blöcken aufgeführten Befehlen müssen Dienste ständig ausgeführt werden, sodass init während der gesamten Lebensdauer des Smartphones im Hintergrund bleibt und dies überwacht.

Modernes Android umfasst Dutzende Dienste, zwei davon haben jedoch einen Sonderstatus und bestimmen den gesamten Lebenszyklus des Systems.

Schritt vier. Zygote und app_process

In einer bestimmten Ladephase wird init am Ende der Konfiguration auf so etwas wie diesen Block stoßen:

Service Zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
Klassenstandard
Socket Zygote Stream 660 Root-System
onrestart write /sys/android_power/request_state wake
onrestart schreibt /sys/power/state auf
onrestart Neustartmedium
onrestart netd neu starten

Dies ist eine Beschreibung des Zygote-Dienstes, einer Schlüsselkomponente jedes Android-Systems, die für die Initialisierung, das Starten von Systemdiensten, das Starten und Stoppen von Benutzeranwendungen und viele andere Aufgaben verantwortlich ist. Zygote wird mit einer kleinen Anwendung /system/bin/app_process gestartet, die im obigen Teil der Konfiguration sehr deutlich sichtbar ist. Die app_proccess-Aufgabe besteht darin, die virtuelle Dalvik-Maschine zu starten, deren Code sich in der gemeinsam genutzten Bibliothek /system/lib/libandroid_runtime.so befindet, und dann Zygote darauf auszuführen.

Sobald dies alles erledigt ist und Zygote die Kontrolle hat, beginnt es mit dem Aufbau der Java-Anwendungslaufzeit, indem es alle Java-Klassen des Frameworks lädt (derzeit über 2000 davon). Anschließend wird system_server gestartet, der die meisten übergeordneten (in Java geschriebenen) Systemdienste enthält, darunter Window Manager, Status Bar, Package Manager und vor allem Activity Manager, der in Zukunft für den Empfang von Start und Ende verantwortlich sein wird Signalanwendungen.

Danach öffnet Zygote den Socket /dev/socket/zygote, geht in den Ruhezustand und wartet auf Daten. Zu diesem Zeitpunkt sendet der zuvor gestartete Activity Manager einen Broadcast Intent Intent.CATEGORY_HOME, um die Anwendung zu finden, die für die Erstellung des Desktops verantwortlich ist, und gibt ihren Namen über den Socket an Zygote weiter. Letzterer wiederum verzweigt die Anwendung und führt sie auf der virtuellen Maschine aus. Voila, wir haben einen Desktop auf unserem Bildschirm, der vom Activity Manager gefunden und von Zygote gestartet wird, und eine Statusleiste, die von system_server als Teil des Status Bar-Dienstes gestartet wird. Nachdem Sie auf das Symbol getippt haben, sendet der Desktop eine Absicht mit dem Namen dieser Anwendung, der Aktivitätsmanager empfängt diese und sendet einen Befehl zum Starten der Anwendung an den Zygote-Daemon

Das alles sieht vielleicht etwas verwirrend aus, aber das Wichtigste ist, sich drei einfache Dinge zu merken:

Systemdienste und Kernel-Threads​

Schlussfolgerungen

In vielerlei Hinsicht unterscheidet sich Android stark von anderen Betriebssystemen und es ist schwer, es auf den ersten Blick zu erkennen. Wenn Sie jedoch verstehen, wie alles funktioniert, sind die Möglichkeiten einfach endlos. Im Gegensatz zu iOS und Windows Phone Das Betriebssystem von Google verfügt über eine sehr flexible Architektur, die es Ihnen ermöglicht, sein Verhalten erheblich zu ändern, ohne Code schreiben zu müssen. In den meisten Fällen reicht es aus, die notwendigen Konfigurationen und Skripte zu korrigieren.

• Übersetzung

In diesem Artikel betrachten wir die Architektur von Android-Anwendungen.

Ehrlich gesagt, offizielles Google Ich denke nicht, dass es zu diesem Thema sehr nützlich ist. Während die Frage „Wie“ im Detail beantwortet wird, wird das „Was“ und „Warum“ überhaupt nicht erklärt. Hier ist meine Version und ich hoffe, sie bringt etwas Klarheit. Übrigens empfehle ich Ihnen dringend, Google-Artikel zu lesen, da sie nützliche Informationen enthalten, die ich nicht wiederholen werde.

Architektur des Android-Betriebssystems – ein wenig Geschichte Wie so oft in der IT können viele Dinge nicht isoliert von der Geschichte einer bestimmten Software erklärt werden. Deshalb müssen wir zu den Ursprüngen des Android-Betriebssystems zurückkehren.

Die Entwicklung des Android-Betriebssystems wurde 2003 von der jungen Firma Android Inc. begonnen. Im Jahr 2005 wurde dieses Unternehmen von Google gekauft. Ich glaube, dass die Hauptmerkmale der Android-Architektur in dieser Zeit definiert wurden. Dies ist nicht nur das Verdienst von Android Inc.; Architekturkonzepte und Finanzen Google-Ressourcen hatte einen entscheidenden Einfluss auf die Android-Architektur. Im Folgenden werde ich einige Beispiele nennen.

Wie Sie sich erinnern, waren die Jahre 2003 bis 2005 von einer erhöhten Aufmerksamkeit für AJAX-Anwendungen geprägt. Ich denke, dass dies einen grundlegenden Einfluss auf die Architektur von Android hatte: In vielen Aspekten ähnelt es eher der Architektur einer typischen AJAX-Anwendung als der einer Desktop-Anwendung GUI-Anwendung geschrieben in Java, C#, C++, VB usw.

Ich weiß nicht, warum das passiert ist. Ich vermute, dass sich jemand bei Google dies zu einer Zeit ausgedacht hat, als Rich Internet Applications (RIAs) im Sinne von Google Docs oder Gmail als Lösung aller Probleme galten. Meiner Meinung nach kann diese Idee weder gut noch schlecht genannt werden. Denken Sie daran, dass sich Android-Apps stark von Desktop-Apps unterscheiden.

Der Einfluss der Architekturphilosophie von Eclipse zeigt sich in der Wahl der GUI-Implementierung, die eher SWT als Swing ähnelt.

Die Android-Code-Designstandards enthalten die „ungarische Notation“, die innerhalb der Mauern von MS entstanden ist. Es kann davon ausgegangen werden, dass derjenige, der diese Standards geschrieben hat, zuvor für Windows entwickelt hat.

Android-Architekturschichten Das Android-Betriebssystem verfügt über drei sehr unterschiedliche und weit voneinander entfernte Schichten:

Es basiert auf einem modifizierten und abgespeckten Modell Linux-Version, wie ich in einem meiner vorherigen Artikel erwähnt habe.

Oberhalb der Linux-Schicht befindet sich die Anwendungsinfrastrukturschicht, die die virtuelle Dalvik-Maschine, einen Webbrowser, eine SQLite-Datenbank, einige Infrastruktur-„Krücken“ und eine Java-API enthält.

Und zum Schluss noch das eingetragene Level Google Android-Anwendungen. Im Allgemeinen stellen sie eine Erweiterung der Infrastrukturschicht dar, da der Entwickler diese Anwendungen oder Teile davon als Bausteine ​​für seine eigenen Entwicklungen nutzen kann.

Schauen wir uns diese Schichten einzeln und genauer an. Linux-Schicht Stellen Sie sich vor, Sie sind Architekt in einem jungen Unternehmen. Sie müssen ein Betriebssystem für einen neuen Gerätetyp entwickeln. Was werden sie machen?

Grob gesagt haben Sie zwei Möglichkeiten: Ihre eigenen Ideen umsetzen, bei Null anfangen, oder ein bestehendes Betriebssystem nutzen und es an Ihre Geräte anpassen.

Die Implementierung von Grund auf klingt für Programmierer immer spannend. In diesen Momenten glauben wir alle, dass wir dieses Mal alles besser machen werden als andere und sogar besser als wir selbst es zuvor getan haben.

Dies ist jedoch nicht immer praktikabel. Durch den Einsatz des Linux-Kernels konnten beispielsweise die Entwicklungskosten erheblich gesenkt werden (teilweise bereits zu hoch). Seien wir ehrlich: Wenn jemand beschließt, etwas zu erstellen, das dem Linux-Kernel in seinem aktuellen Zustand ähnelt, wird er mehrere Millionen Dollar benötigen.

Wenn Sie Android Inc. betreiben, können Sie per Definition nicht so viel Geld haben. Wenn Sie Google betreiben, haben Sie so viel Geld, aber Sie werden es sich wahrscheinlich zweimal überlegen, ob Sie es für die Entwicklung Ihres eigenen Betriebssystems ausgeben sollen. Es wird auch mehrere Jahre dauern, bis Sie den aktuellen Stand von Linux erreichen; Ein paar Jahre Verzögerung könnten für einen Markteintritt zu spät sein.

In einer ähnlichen Situation beschloss Apple, Mac OS auf Basis von Free BSD zu entwickeln. Android Inc. hat beschlossen, Linux als Basis für Android zu verwenden. Die Quellen von Free BSD und Linux sind frei verfügbar und bieten eine gute Grundlage für jede Entwicklung, sei es Apple oder Google.

Allerdings war es damals nicht möglich, Standard-Linux auf einem mobilen Gerät auszuführen (das ist heute nicht mehr der Fall). Die Geräte hatten zu wenig RAM und nichtflüchtigen Speicher. Die Prozessoren waren im Vergleich zu Computerprozessoren, auf denen normalerweise Linux ausgeführt wird, deutlich langsamer. Aus diesem Grund entschieden sich Android-Entwickler für eine Minimierung System Anforderungen Linux.

Wenn wir Linux auf einem hohen Niveau betrachten, dann ist es eine Kombination aus dem Kernel (auf den man nicht verzichten kann) und vielen anderen, optionalen Teilen. Sie können sogar einen einzelnen Kernel ohne weitere Schritte ausführen. Daher ist Google in jedem Fall gezwungen, den Linux-Kernel als Teil des Android-Betriebssystems zu verwenden. Darüber hinaus wurden optionale Teile berücksichtigt und die notwendigsten ausgewählt. Beispielsweise wurden die Netzwerk-Firewall IPTables und die Ash-Shell hinzugefügt. Es ist merkwürdig, dass Ash hinzugefügt wurde und nicht Bash, obwohl letzterer um eine Größenordnung mächtiger ist; Diese Entscheidung beruhte wahrscheinlich auf der Tatsache, dass Ash weniger ressourcenintensiv ist.

Android-Entwickler haben den Linux-Kernel geändert und Unterstützung für Hardware hinzugefügt, die in mobilen Geräten verwendet wird und in den meisten Fällen auf Computern nicht verfügbar ist.

Die Wahl von Linux als Basis hatte große Auswirkungen auf alle Aspekte des Android-Betriebssystems. Das Erstellen von Android ist im Wesentlichen eine Variation des Linux-Erstellungsprozesses. Android-Code wird von git verwaltet (einem Tool zur Verwaltung von Linux-Code). Usw.

Obwohl dies alles interessant ist, werden Sie höchstwahrscheinlich nie alle diese spezifischen Punkte ansprechen, solange Ihr Ziel lediglich darin besteht, Anwendungen für Android zu entwickeln. Die einzige Ausnahme wäre das Durchsuchen des Dateisystems mithilfe von Ash-Befehlen. Das Wichtigste, was Sie bei der Entwicklung von Anwendungen für Android wissen sollten, ist die Ebene der Anwendungsinfrastruktur.

Sie fragen sich vielleicht, was zu tun ist, wenn Sie eine native Android-Anwendung entwickeln müssen? Google rät dringend davon ab. Technisch ist das natürlich möglich, allerdings wird es Ihnen in Zukunft nicht mehr möglich sein, diese Anwendung zu verbreiten der normale Weg. Denken Sie also zweimal darüber nach, bevor Sie mit der nativen Android-Entwicklung beginnen, es sei denn natürlich, Sie arbeiten am Android Open Source Project (AOSP), d. h. Android OS selbst.

Anwendungsinfrastrukturebene Trotz einiger Ähnlichkeiten zwischen Apple iOS und Android OS gibt es erhebliche Unterschiede zwischen den Architekturlösungen auf der Infrastrukturebene beider Betriebssysteme.

Apple hat sich entschieden, Objective-C als Programmiersprache und Laufzeitumgebung zu verwenden iOS-Apps. Objective-C scheint mehr oder weniger eine natürliche Wahl für ein auf Free BSD basierendes Betriebssystem zu sein. Sie können sich Objective-C als normales C++ mit einem benutzerdefinierten Präprozessor vorstellen, der einige spezifische linguistische Konstrukte hinzufügt. Warum können wir nicht Standard-C++ verwenden, in dem Free BSD geschrieben ist? Meiner Meinung nach liegt der Grund darin, dass Apple versucht, alles im eigenen „Apple“-Stil zu machen.

Die Grundidee besteht darin, dass iOS-Apps mehr oder weniger in derselben Sprache geschrieben sind wie das dahinter stehende Betriebssystem.

Android-Apps sind in diesem Sinne sehr unterschiedlich. Sie sind in Java geschrieben, einer völlig anderen Technologie als C++ (obwohl die Syntax von C++ geerbt ist).

Ich denke, der Hauptgrund ist die Notwendigkeit, dass dieselbe Anwendung auf unterschiedlicher Hardware ausgeführt werden muss. Dieses Problem tritt nur unter Android-Betriebssystemen auf; Die Jungs von Apple haben dieses Problem nicht. iOS läuft nur auf seiner eigenen Hardware und Apple hat die vollständige Kontrolle über den gesamten Prozess. Bei Android ist das Gegenteil der Fall: Google hat keine Kontrolle über die Hardwarehersteller. Beispielsweise läuft das Android-Betriebssystem auf x86-, ARM- und Atom-Prozessoren (die Kommentare deuten darauf hin, dass x86 Atom enthält und Android auf x86-, ARM-, PPC- und MIPS-Prozessoren läuft – Anmerkung des Übersetzers). Auf binärer Ebene sind diese Architekturen inkompatibel.

Hätten Android-OS-Architekten den gleichen Weg eingeschlagen wie Apples Architekten, wären Android-Anwendungsentwickler gezwungen gewesen, mehrere Versionen derselben Anwendung gleichzeitig zu verteilen. Dies wäre ein ernstes Problem, das zum Zusammenbruch des gesamten Android-Projekts führen könnte.

Damit dieselbe Anwendung auf unterschiedlicher Hardware laufen kann, nutzte Google eine Container-basierte Architektur. In einer solchen Architektur wird der Binärcode von einem Softwarecontainer ausgeführt und ist von den Details des Spezifischen isoliert Hardware. Die Beispiele sind jedem bekannt – Java und C#. In beiden Sprachen ist der Binärcode hardwareunabhängig und wird von einer virtuellen Maschine ausgeführt.

Natürlich gibt es noch eine andere Möglichkeit, Hardware-Unabhängigkeit auf binärer Ebene zu erreichen. Eine Möglichkeit ist die Verwendung eines Hardware-Emulators, auch bekannt als QEMU. Damit können Sie beispielsweise ein Gerät mit einem ARM-Prozessor auf der x86-Plattform usw. emulieren. Google könnte C++ als Sprache verwenden, um Anwendungen innerhalb von Emulatoren zu entwickeln. Tatsächlich verwendet Google diesen Ansatz in seinem Android-Emulatoren, die auf QEMU aufbauen.

Es ist gut, dass sie diesen Weg nicht gegangen sind, denn dann müsste jemand das Betriebssystem auf einem Emulator ausführen, was viel mehr Ressourcen erfordert und dadurch die Geschwindigkeit verringern würde. Um die beste Leistung zu erzielen, wurde die Emulation nur dort belassen, wo sie nicht vermieden werden konnte, in unserem Fall – in Android-Anwendungen.

Wie dem auch sei, Google hat sich entschieden, Java als Hauptsprache für die Entwicklung von Anwendungen und deren Ausführungsumgebung zu verwenden.

Ich denke, dass dies eine entscheidende architektonische Entscheidung war, die Android von anderen mobilen Betriebssystemen unterscheidet. Linux-basiert aktuell vorgestellt. Meines Wissens ist keiner von ihnen mit Binärcode auf Anwendungsebene kompatibel. Nehmen wir MeeGo als Beispiel. Es verwendet C++ und das Qt-Framework; Trotz der Tatsache, dass Qt plattformübergreifend ist, besteht die Notwendigkeit, unterschiedliche Builds dafür zu erstellen verschiedene Plattformen verschwindet nicht.

Nachdem Sie sich für Java entschieden hatten, bestand der nächste Schritt darin, zu entscheiden, welche virtuelle Maschine (JVM) verwendet werden soll. Aufgrund begrenzter Ressourcen war die Verwendung der Standard-JVM schwierig. Die einzig mögliche Wahl war die Verwendung der Java ME JVM, die für mobile Geräte konzipiert ist. Allerdings wäre Googles Glück ohne die Entwicklung einer eigenen virtuellen Maschine nicht vollständig, und Dalvik VM war geboren.

Dalvik VM unterscheidet sich von anderen Java Virtual Machines in folgenden Punkten:

• Es verwendet ein spezielles DEX-Format zum Speichern von Binärcode, im Gegensatz zu den JAR- und Pack200-Formaten, die der Standard für andere virtuelle Java-Maschinen sind. Google hat angegeben, dass DEX-Binärdateien kleiner sind als JARs. Ich denke, sie hätten Pack200 genauso gut nutzen können, aber sie haben beschlossen, ihren eigenen Weg zu gehen.
• Dalvik VM ist für die gleichzeitige Ausführung mehrerer Prozesse optimiert.
• Dalvik VM verwendet eine registerbasierte Architektur im Vergleich zur stapelbasierten Architektur anderer JVMs, was zu einer höheren Ausführungsgeschwindigkeit und kleineren Binärgrößen führt.
• Es verwendet seinen eigenen Befehlssatz (kein Standard-JVM-Bytecode).
• Es ist möglich, (bei Bedarf) mehrere unabhängige Android-Anwendungen in einem Prozess auszuführen
• Die Anwendungsausführung kann sich „natürlich“ über mehrere Dalvik-VM-Prozesse erstrecken (was das bedeutet, besprechen wir später). Zur Unterstützung hinzugefügt:
  • Ein spezieller Objektserialisierungsmechanismus basierend auf den Klassen Parcel und Parcelable. Funktionell verfolgt es dieselben Ziele wie Java Serializable, die resultierenden Daten sind jedoch kleiner und möglicherweise toleranter gegenüber der Klassenversionierung.
  • Eine besondere Möglichkeit, Interprozessaufrufe (IPC) durchzuführen, basierend auf der Android Interface Definition Language (AIDL).
• Vor Android 2.2 unterstützte Dalvik VM die JIT-Kompilierung nicht, was einen ernsthaften Leistungseinbruch darstellte. Ab Version 2.2 die Ausführungsgeschwindigkeit häufig verwendeter Anwendungen