Grundlegendes Android Wissen (Deodexing, SDK, Dalvik VM, etc.)

Hallo zusammen

<table border="0" width="1px" height="1px" align="right" cellpadding="2" bgcolor="#55AA00" ><tr><td bgcolor="#55AA00" nowrap="nowrap" ><div align="center"><font color="#D0E8D1" size="2"><strong>Inhaltsverzeichnis</strong></font></div></td></tr><tr><td bgcolor="#D0E8D1" nowrap="nowrap" ><font size="2"><a href="#sdk">Android SDK</a></font></td></tr><tr><td bgcolor="#D0E8D1" nowrap="nowrap" ><font size="2"><a href="#kernel">Kernel</a></font></td></tr><tr><td bgcolor="#D0E8D1" nowrap="nowrap"><font size="2"><a href="#dvm">Dalvik VM / Dalvik Cache</a></font></td></tr><tr><td bgcolor="#D0E8D1" nowrap="nowrap"><font size="2"><a href="#deodexing">Deodexing</a></font></td></tr><tr><td bgcolor="#D0E8D1" nowrap="nowrap"><font size="2"><a href="#busybox">Busybox</a></font></td></tr></tr><tr><td bgcolor="#D0E8D1" nowrap="nowrap"><font size="2"><a href="#jit">JIT - Just in Time Compiler</a></font></td></tr></table>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.

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.
  Anhang 33329 Anhang 33330
• 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:
  Anhang 33332
• 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	[FONT="Courier New"]adb devices[/FONT]
Beendet den ADB-Server	[FONT="Courier New"]adb kill-server[/FONT]
Startet den ADB-Server	[FONT="Courier New"]adb start-server[/FONT]
APK-Datei installieren	[FONT="Courier New"]adb install <pfad_zur_apk>[/FONT]
Datei von Gerät auf PC kopieren	[FONT="Courier New"]adb pull <pfad_auf_gerät> <pfad_auf_pc>[/FONT]
Datei von PC auf Gerät kopieren	[FONT="Courier New"]adb push <pfad_auf_pc> <pfad_auf_gerät>[/FONT]
Gerät ins Bootloader menü booten	[FONT="Courier New"]adb reboot bootloader[/FONT]

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:

http://www.pocketpc.ch/attachment.ph...2&d=1296666776
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	Anhang 33199	Anhang 33198
Inhalt der APK	Anhang 33196	Anhang 33200

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

Code:

---

cd /bin
ln -l

---

ohne busybox und symlinks zeigt viele Dateien mit entspr. Größe an.
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.

Im Moment bin ich in der Ausbildung leider sehr ausgelastet, daher finde ich wahrscheinlich nicht viel Zeit, diesen Thread weiterzuführen. Wenn jemand eine weiter Begriffserklärung oder etwas dergleichen hätte, könnte er mir das (selbst verfasst) per PM schicken, so dass ich es nur noch hier einfügen könnte ;)

Danke für euer Verständnis

Gruss

Also mal für Protokoll:

root
Höhster Benutzer unter Linux (Bei Windows Administrator). Mit root Rechten hat man Zugriff auf Funktionen, Programme und Dateien, auf denen einem sonnst der Zugriff verweigert wird.

App2SD
Die Möglichkeit Apps auf der SD Karte zu übertragen. Ab Android 2.2 bereits eingebaut.


Finde es eine tolle Idee, Android Begriffe in einem Thread zu sammeln und zu erklären.:bindafür:

EXT 2/3/4
Dateisystem von Linux (Android), kann von Windows nicht ohne weiteres gelesen werden. Android-Geräte nutzen dieses Dateisystem für den Internen Speicher. Nur die SD-Karte nutzt normalerweise FAT32, welches von Linux und Windows gelesen werden kann.
Eine EXT-Partition auf der SD-Karte war bisher für APPS2SD nötig.

SWAP
Auch "SWAP" ist ein Dateisystem von Linux, vergleichbar mit der Auslagerungsdatei von Windows. Eine SWAP-Partition auf der SD-Karte war bisher für APPS2SD notwendig.

FAT32
"FAT32" ist ein Dateisystem, welches von vielen Betriebssystemen genutzt werden kann. Deswegen ist es das weitverbreitetste Dateisystem für Wechseldatenträger wie USB-Sticks oder Speicherkarten.

hoffe, das stimmt halbwegs :p

JIT (Just-in-Time Compiler)
könnte mir das jemand erklären? verstehe nich wie es android schneller macht :confused:

Danke euch, für die Ideen.

Der JIT und das Android SDK sind wahrscheinlich die nächsten Dinge die ich erklären werde. (Das ganze nimmt halt schon ziemlich viel Zeit in Anspruch ;))

Die Idee dieses Threads ist eigentlich nicht, dass ihr selbst Sachen erklären sollt. Aber wenn ihr das wollt könnt ihr das natürlich auch ;)

Hi there...

Finde diesen Thread sehr gut... :-)

Was ist "Busybox" oder "Busy Box"?

Ich habe dazu zwar diesen Wiki-Beitrag gefunden, aber werde nicht so recht schlau was man damit genau tun kann. Offenbar kann man dies auf Andorid installieren, wenn das Gerät gerootet ist...
http://de.wikipedia.org/wiki/Busybox

Danke und Grüsse

Jarjar

BusyBox:
Ok, kompliziert :-)
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% ;-)

hm. verständlich erklärt?

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

Code:

---

cd /bin
ln -l

---

ohne busybox und symlinks zeigt viele Dateien mit entspr. Größe an.
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.

:-)




So. was bringt Dir jetzt ne Busybox?
Hier endet langsam mein Wissen und ich muss raten: ungerootet hast du nicht wirklich eine Shell auf dem Gerät, daher auch die meisten der Kommandos nicht.
Rootest Du Dein Gerät, willst Du aber auch alles nutzen können inkl. shell.
-> einzelne Dateien für jeden Befehl kopieren oder gleich 1 große Datei mit allen Befehlen kopieren und gleichzeitig Platz sparen.

:-)

mfg
Rumbel
(gefährliches Linux-Halbwissen)

erklärt mal bitte den begriff adb und shell.

mfg DauL

adb = android developer bridge, damit kannst du konsolen befehle die die ADB unterstützt direkt eingebe

und shell ist in diesem falle ein adb befehl ^^ aber du kannst in der shell alle linux befehle ausführen die linux bzw android halt so hat ;)

Zitat:

---

Zitat von x10i DauL

erklärt mal bitte den begriff adb und shell.

mfg DauL

---

Wie wäre es denn, wenn du mal im ersten Post nachschauen würdest? ;)

Da habe ich bereits etwas über ADB geschrieben.

Die Shell ist wie man so schön sagt ein interaktiver Befehls Interpreter. Es gibt verschiedene Arten von Shells, z.B. Bash. Das ist die Standard Shell bei zum Beispiel Ubuntu oder Debian.
Oder aber es gibt auch die ADB-Shell.

Zitat:

---

Zitat von localhost

Wie wäre es denn, wenn du mal im ersten Post nachschauen würdest? ;)

Da habe ich bereits etwas über ADB geschrieben.

Die Shell ist wie man so schön sagt ein interaktiver Befehls Interpreter. Es gibt verschiedene Arten von Shells, z.B. Bash. Das ist die Standard Shell bei zum Beispiel Ubuntu oder Debian.
Oder aber es gibt auch die ADB-Shell.

---

Oder, um Shell noch einfacher zu erklären:
Die Shell ist die CLI (Command-Line-Interface = Kommandozeileneingabe) bei Android und ist im groben mit der CMD.exe unter Windows gleichzusetzen :)
Eben eine Benutzeroberfläche ohne grafischen "Schnickschnack"

aha^^.
u was ist ubuntu oder debian?
mfg DauL

Ubuntu und Debian sind beides (sehr ähnliche) Linux Distributionen.

Auf Wikipedia gibt es ein sehr interessantes Bild, wo alle Linux Distributionen aufgelistet sind: http://upload.wikimedia.org/wikipedi...eline_10_3.png

wie siehts mit JIT beschreibung aus? :)

hab ne frage: was ist gemeint mit 2g und 3g netz, ist da irgend ein unterschied?

Zitat:

---

Zitat von klaffi3

hab ne frage: was ist gemeint mit 2g und 3g netz, ist da irgend ein unterschied?

---

2G = Standard der zweiten Generation ; meist GSM
3G = Standard der dritten Generation ; meist UMTS
(4G = Standard der vierten Generation ; in DE meist LTE)

Für den Otto-Normal-Nutzer, ist der entscheidende Unterschied einfach die Übertragungsgeschwindigkeit.

• 2G: bis zu 220 kbit/s (bei Einsatz des "Daten-Turbos" EDGE)
• 3G: bis zu 14,4 Mbit/s (bei Einsatz des "Daten-Turbos" HSDPA)
• (4G: bis zu 100 Mbit/s)

@Ecki
danke für die Antwort und die links zu wikipedia

dann habe ich noch eine frage: beherrscht android 2.1 bzw. 2.2 multitasking und steht die copy und paste funktion zur verfügung?
Danke

Zitat:

---

Zitat von localhost

Ubuntu und Debian sind beides (sehr ähnliche) Linux Distributionen.

Auf Wikipedia gibt es ein sehr interessantes Bild, wo alle Linux Distributionen aufgelistet sind: http://upload.wikimedia.org/wikipedi...eline_10_3.png

---

*räusper*
Ubuntu basiert zu großen Teilen auf Debian ;-)
Aber offtopic - sorry.

Zitat:

---

Zitat von klaffi3

@Ecki
danke für die Antwort und die links zu wikipedia

dann habe ich noch eine frage: beherrscht android 2.1 bzw. 2.2 multitasking und steht die copy und paste funktion zur verfügung?
Danke

---

Hi,
es is nicht mein Thread. Ich denke aber, das dieser Post hier besser in einem Thema wie "Android Allgemein" passt.

JIT - Just in Time compiling

Compiling - kompilieren
Das kompilieren wurde früher auch einfach "übersetzten" genannt. Denn genau das passiert wenn man sich das ganze betrachtet. Es wird eine bestimmte Sprache übersetzt in eine Sprache die 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 übersetzten. Man nennt diese Art des kompilierens oder übersetzten 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 Auführung gebracht.
Das bringt den entscheidenden Vorteil, da der gesamte Block breiets übersetzt ist und nicht noch zeilen "nach rutschen" 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.

Hier die Wikipedia Quellen dazu:

JIT Just in Time
Dynamische Optimierung
Closed World Assumption