Automatisch generierter Sicherheitshinweis 
Grundlegendes Android Wissen (Deodexing, SDK, Dalvik VM, etc.) Hallo zusammen
In diesem Thread werde ich euch ein paar wichtige/elementare Begriffe aus der Android Welt erklären. Man stolpert z.B. hier im Forum oder bei den xda-devs sehr häufig darüber, weiss aber nicht, was sie genau bedeuten. So ging es mir am Anfang (und auch heute noch) auch, daher habe ich mich entschlossen, mein Wissen, das ich mir durch Recherchieren angeeignet habe, mit euch zu teilen.
Android SDK Kernel Dalvik VM / Dalvik Cache Deodexing Busybox JIT - Just in Time Compiler
Wenn ihr einen Begriff kennt, der hier reinpassen würde, dann gebt bitte bescheid
~~~~~~~~ Begriffe ~~~~~~~~
Android Software Development Kit (SDK)
Unter diesem Punkt erkläre ich die (für mich) wichtigsten Eigenschaften des Android SDKs. Wenn nach euer Meinung etwas fehlt, meldet es einfach.
Der Download vom Android SDK und weitere Informationen findet man hier: http://developer.android.com/sdk/
Den Ordner, der in der ZIP-Datei enthalten ist kann man an einen x-beliebigen Ort auf den PC entpacken (am besten eignet sich wohl direkt nach C:\)
Emulator:
Das Entwickler Paket von Android ist ein Open Source Projekt, das unter anderem aus einem Android Emulator zum testen der selbst erstellten Software besteht. Mit diesem Android Emulator kann man sich ein virtuelles Android Phone erstellen, mit jeder Version von Android (von 1.1 bis 2.2).
Hier zeige ich kurz, wie man so ein Virtuelles Gerät einrichten kann.
- Wenn man den benötigten Ordner entpackt hat, findet man darin eine Datei namens "SDK Setup.exe", die man ausführen muss.
- Danach folgt einfach den Installationsanweisungen.
- Wahrscheinlich erscheint plötzlich diese Fehlermeldung: "Failed to fetch URL https://dl-ssl.google.com/android/re...repository.xml, reason: HTTPS SSL error. You might want to force download through HTTP in the settings". Dies ist aber nicht weiter schlimm. Klickt auf "close" und nachher auf der linken Seite auf "Settings". Dort müsst ihr nun einen Haken bei "Force https://…….." setzen und auf "Save &Apply" klicken. Nun sollte der Download gehen.
- Hat man das ganze installiert, müsst ihr jetzt links in der Liste auf "Virtual Devices" klicken.
- Mit dem Klick auf den Button "New...", erscheint ein Setup zum Einrichten eines neuen Virtuellen Gerätes.
- Hier könnt ihr die Einstellungen der AVD treffen. Für mich sind sie so, wie sie auf dem Bild sind gar nicht so schlecht (HVGA ist NICHT 800x480px
). Mit einem klick auf "Create AVD" wird das Virtuelle Android Gerät erstellt.
- Jetzt sollte in der Liste euer neu erstelltes Gerät sichtbar sein. Wenn ihr jetzt einmal drauf klickt und danach auf der rechten Seite auf "Start..." klickt, könnt ihr das Gerät starten.
- Nun müsst ihr etwas geduld haben, bis das ganze aufgestartet ist. Ist es dann endlich hochgefahren, könnte das ganze dann so aussehen:
- Fertig! Jetzt habt ihr euer eigenes virtuelles Android Gerät.
Android Debug Bridge (ADB):
Kurz gesagt, ist ADB ein Tool um mit ihr über die Konsole mit dem Android Phone zu "kommunizieren". Unter "kommunizieren" verstehe ich Dateien löschen, verschieben, kopieren, das Phone in den Bootloader zu rebooten etc.
ADB ist ein ziemlich mächtiges Tool. Alles über ADB könnt ihr hier erfahren (Englisch): http://developer.android.com/guide/d...tools/adb.html
Hier liste ich einmal die wichtigsten ADB-Befehle auf:
(Um die ausführen zu können, muss man zu erst mit der Konsole in den Ordner "tools" im SDK wechseln)
Das macht der Befehl Befehl Alle mit dem PC verbundenen Geräte anzeigen adb devices Beendet den ADB-Server adb kill-server Startet den ADB-Server adb start-server APK-Datei installieren adb install Datei von Gerät auf PC kopieren adb pull Datei von PC auf Gerät kopieren adb push Gerät ins Bootloader menü booten adb reboot bootloader
Android/Linux Kernel
"Was ist der Android Kernel?"
Das haben sich wahrscheinlich schon manche gefragt. Deshalb werde ich hier versuchen ein wenig Licht in die Sache zu bringen.
Android basiert auf dem Linux 2.6 Kernel und ist somit OpenSource. Ok, aber was ist denn jetzt ein Kernel??
Ein Kernel (auf deutsch Betriebssystemkern) ist der "Grundbaustein" eines Betriebssystems. Er regelt die ganze Prozess- und Datenverwaltung. In einem Betriebssystem bildet er die unterste Schicht (Layer) der Software. Das heisst, er ist der Hardware am nächsten und hat somit direkten Zugriff auf sie. Man kann den Kernel auch als Vermittler zwischen den Anwendungsprogrammen und der Hardware bezeichnen.
Der Kernel kontrolliert u.A. den Zugriff auf die CPU und den Speicher. Das heisst, er entscheidet welche Applikation wie viel Speicher bekommt und was zuerst ausgeführt werden soll.
Im Kernel sind auch die meisten Treiber abgelegt, welche die einzelnen Hardware Komponenten benötigen. Zum Beispiel die Treiber von der Kamera, oder die W-LAN Treiber.
Natürlich hat der Kernel noch weitere Aufgaben, aber ich denke diese sind die wichtigsten.
Dieses Diagramm zeigt die wichtigsten Software-Komponenten von Android:
Quelle: developer.android.com
Dalvik Virtual Machine / Dalvik Cache
Die Dalvik VM ist eine für mobile Geräte entwickelte Java Virtual Machine (JVM).
Die Dalvik Virtual Machine besitzt einen eigenen Bytecode, was sie von vielen anderen JVMs unterscheidet. Dalvik kann mit dem Programm dx herkömmliche CLASS-Dateien von Java in DEX-Dateien konvertieren (Dalvik Executable). Dabei werden mehrere CLASS-Dateien zu einer DEX-Datei zusammengefasst und einige Optimierungen bezüglich des Speicherbedarfs vorgenommen.
Das Dalvik Cache Verzeichnis beinhaltet alle vorkompilierten DEX-Dateien, die von den APK- und JAR-Dateien auf dem Android Phone erstellt wurden. Diese Dateien werden immer dann generiert, wenn die Dalvik Virtual Machine entdeckt, dass die existierende DEX-Datei mit einer älteren Version erstellt wurde. Daher dauert häufig der erste Start, nachdem man ein neues ROM geflasht hat, etwas länger. Weil er dann zuerst alle neuen DEX-Dateien erstellen muss.
Deodexing / De-odex’ing
Was ist deodexing? | Was ist/bedeutet deodexed?:
Bei den Stock ROMs hat es jeweils im /system/app oder im /system/framework Ordner nicht nur APK- bzw. JAR-Dateien, sondern auch die dazugehörigen ODEX-Dateien.
Beim Deodexing wird die ODEX-Datei zurück in eine classes.dex Datei konvertiert und in die APK/JAR Datei gepackt.
Was bringt ein deodextes ROM?:
Diese deodexten Dateien sind meistens kleiner als die APK/JAR + die ODEX-Datei zusammen. Wenn man z.B. den ganzen /system/app und /system/framework Ordner deodext, kann man da schon einige Megabytes sparen.
Deodexte ROMs sind auch für Designer/Themer ganz interessant. Denn bei diesen ROMs kann man ohne weiteres die Schriftgrösse oder Schriftfarbe verändern.
ODEX-Dateien:
Kurz gesagt ist eine ODEX-Datei eine optimierte Version einer classes.dex Datei, welche Geräte spezifische Optimierungen beinhaltet. Insbesondere hat eine ODEX-Datei Abhängigkeiten auf jede "BOOTCLASSPATH" Datei, die geladen wird, wenn sie generiert wird.
Diese ODEX-Datei ist nur dann gültig, wenn man sie mit genau diesen "BOOTCLASSPATH" Dateien verwendet. Die Dalvik Virtual Machine erzwingt dies, indem sie eine Prüfsumme für jede Datei erstellt, auf die die ODEX-Datei abhängig ist und stellt sicher, dass die Prüfsumme für jede Datei übereinstimmt, wenn die ODEX-Datei geladen wird.
BOOTCLASSPATH:
Der BOOTCLASSPATH ist eine einfache Liste, welche die Klassen, der APK-/JAR-Dateien beinhaltet, die geladen werden können. (Zusätzlich zu den wichtigsten APK-/JAR-Dateien, die geladen werden.)
Ein normales Android System hat 5 JAR-Dateien in seiner "BOOTCLASSPATH" Datei: core.jar, ext.jar, framework.jar, android.policy.jar und services.jar. Diese Dateien befinden sich alle im Ordner /system/framework. Einige APKs haben auch gewisse Abhängigkeiten zu zusätzlichen JAR- oder APK-Dateien über die fünf Basis JARs hinaus.
Beispiel:
Für die Anwendung, die Google Maps verwendet, wird com.google.android.maps.jar an die BOOTLCLASSPATH-Datei für die APK der App angehängt werden.
Diese ODEX Abhängigkeiten machen das Leben ein wenig schwerer:
- Mann kann nicht eine APK+ODEX-Datei von einem System nehmen und es auf ein anderes kopieren. Ausser sie benutzen das exakt gleiche Framework.
- Wenn man nur eine kleine Änderung an einer BOOTCLASSPATH-Datei macht, wird jede ODEX-Datei, welche auf diese BOOTCLASSPATH-Datei angewiesen ist, nicht mehr gültig sein. Das heisst eigentlich jede APK-/JAR-Datei des Systems.
Hier ein Beispiel zu einer APK mit ODEX-Datei und einer deodexten APK:
Vergleich: APK mit ODEX Deodexte APK Im Ordner /system/app 
Inhalt der APK 
Bei der ersten Variante ist die optimierte classes.dex Datei aus der APK datei "extrahiert" worden und wird separat als Calendar.odex gespeichert.
Bei der zweiten Variante ist die ODEX-Datei in der APK unter dem Namen classes.dex "integriert" worden.
Busybox (Danke an Rumbel)
Was ist eine Busybox?
Generell hat man eine größere Ansammlung "loser" Dateien auf dem Dateisystem.
Jeder Unix-Befehl der Unix-Shell wäre eine eigene Datei. "ls", "ps", "cat", "cd", etc... (unter Windows Befehle wie "dir" "copy" "cd" "echo" "mkdir" usw).
Unter Windows würde das bedeuten, dass man im C:\Windows\ und C:\Windows\System(32) Ordner ne Menge exe-Dateien hat. Jeweils eine für dir, copy, echo... etc.
Da die Dateien aber weniger als 1 kB groß sind, belegen sie aber immer mindestens die kleinste Sektorgröße des Speichers. Somit belegen (bei einer Sektorgröße von 2kB) auch Dateien mit 0.1kB ganze 2kB auf der Festplatte / SD-Karte.
Bei Linux kann man es wie folgt lösen: man nimmt statt 100000 einzelnen Dateien (o.g. Befehle der linux shell) eine groooooße Datei und packt alles dort rein. Dies nennt man dann (unter anderem) Busybox.
Der Vorteil der Busybox: man packt dort durch einen bestimmen Konfigurator nur die shell-Dateien rein, die man auch wirklich braucht.
Beispiel-Rechnung: angenommen wir hätten 100 Shell-Befehle, die jeweils 0.99kB groß sind und eine Sektorgröße von 2kB . Einzeln belegen die Dateien dann 200kB. (0.99kB aufgerundet auf 2kB * 100)
Zusammengepackt als Busybox belegen sie 0.99kB * 100 100kB. (0.99kB * 100 = 99kB, dann auf Sektorgröße aufrunden = 100kB).
-> selbst bei 100 kleinen Dateien spart man schon 50%
Wie genau werden diese befehle dann in der Datei angesprochen wenn die eigentliche "exe" (windows) bzw executable binary (linux) nicht existiert?
ganz einfach. Linux kennt sogenannte symlinks. (aka "symbolic links"). das sind quasi die verknüpfungen unter windows. allerdings "existiert" auch diese verknüpfung nicht wirklich sondern verweist direkt auf das ziel.
Unter Linux wären die dateien wie cp, echo, cat, copy, ls, ln und so weiter unter "/bin" gespeichert.
statt dessen sind dort diese symlinks.
mit folgendem code kann man das man anschauen
ohne busybox und symlinks zeigt viele Dateien mit entspr. Größe an.Code:cd /bin ln -l
mit busybox steht dort dann "cp -> busybox" bzw "mount -> busybox" (der -> zeigt dass es ein symlink auf busybox ist).
also werden alle befehle "weitergeleitet" und statt "mount" die busybox aufgerufen.
Allerdings "erfährt" die busybox durch die befehlszeile welcher befehl ausgeführt werden sollte und wird das dann intern selbst ausführen. ganz so, als hätte man die original-datei aufgerufen.
JIT - Just in Time Compiling (Danke an rari2003)
Compiling - kompilieren
Das Kompilieren wurde früher auch einfach "übersetzen" genannt. Denn genau das passiert wenn man sich das ganze betrachtet. Es wird eine bestimmte Sprache übersetzt in eine Sprache, welche die Maschine, also der Prozessor, versteht. Eine Programmiersprache funktioniert also immer nur mit einem bestimmten Übersetzter, der das pendant von der Programmiersprache in der Prozessorsprache kennt.
Herkömmliche vorgehensweise: Interpretieren
Herkömmliche Compiler verabeiten Programmcode Zeilenweise, um diesen dann in Maschinen Code zu übersetzen. Man nennt diese Art des kompilierens, oder übersetzen, auch AOT - Ahead Of Time - kompilieren.
Das rührt von der Tatsache her, da das Programm vor seiner Ausführung übersetzt wird.
Fachlich nennt man den Vorgang dann Interpretieren.
Just in Time - zur Laufzeit
Mit JIT - Just in Time - wird der Programmcode zur Laufzeit und oder bei bedarf Blockweise übersetzt und dann zur Ausführung gebracht.
Das bringt den entscheidenden Vorteil, da der gesamte Block bereits übersetzt ist und nicht noch zeilen "nachrutschen" müssen.
Moderne JIT - Compiler können besonders effektiv arbeiten. Sie können dynamische Optimirung bei sogenannten dynamischen Sprachen übersetzten.
Dynamische Optimierung kann man z.B. so kurz umschreiben: Eine Variable (Ein Wert in einem Speicher der nicht stetig ist) kann zur Laufzeit eines Programms immer den selben Wert enthalten. Statt weiter mit dieser Variable zu arbeiten erkennt das der Compiler und macht daraus kurzer Hand eine Constante (ein festgeschriebener Wert in einem Speicher) bis dieser Wert sich tatsächlich wieder ändert.
Eine Tatsache die dabei hilft solche Dinge zu erkennen ist die Closed World Assumption.
Übersetzt bedeutet es in etwas Weltgeschlossenheit. Damit erreicht man folgendes: Alles was nicht klar definiert ist, gibt es auch nicht. Wenn man also sagt: Ein Flugzeug fliegt einmal die Woche Mittwoch nach Mallorca ist der umkehrschluss daraus, das es sonst nicht fliegt.
Würde ich eine Variable bauen "Fliegen" dann währe diese von Mitwoch nach Abflug bis Mittwoch vor Abflug Falsch, was doch dann ein ziemlich konstanter Wert wäre.
Zitat von x10i DauL 
