Dalvik VM: Unterschied zwischen den Versionen

Aus Android Wiki
(Kategorie hinzugefügt)
Keine Bearbeitungszusammenfassung
Markierungen: Mobile Bearbeitung Mobile Web-Bearbeitung Visuelle Bearbeitung
 
(10 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Die '''Dalvik Virtual Machine''' ist eine von Google entwickelte virtuelle Registermaschine<ref>[[Wikipedia:de:Dalvik Virtual Machine|Wikipedia-Artikel zu Dalvik Virtual Machine]]</ref>, welche die Aufgabe hat, eine in Java programmierte App aus Bytecode in maschinenlesbaren Code zu übersetzen. Dieser Code wird anschließend vom Prozessor ausgeführt. Die Dalvik VM ist dementsprechend ein Zwischenschritt zwischen dem Quellcode und dem maschinenlesbaren, durch den Prozessor ausführbaren Code.
Die '''Dalvik VM''' (Dalvik '''V'''irtual '''M'''achine) ist eine von Google entwickelte virtuelle Registermaschine<ref>[[Wikipedia:de:Dalvik Virtual Machine|Wikipedia-Artikel zu Dalvik Virtual Machine]]</ref> für [[Android]], welche die Aufgabe hat, eine in Java programmierte App aus ''Bytecode'' in maschinenlesbaren Code zu übersetzen. Dieser Code wird anschließend vom Prozessor ausgeführt. Die Dalvik VM ist dementsprechend ein Zwischenschritt zwischen dem Quellcode und dem durch den Prozessor ausführbaren Code. Der Quellcode wird dabei zur Laufzeit übersetzt ([[Wikipedia:de:Just-in-time-Kompilierung|Just-in-time-Kompilierung]])
 
Entwickelt wurde die virtuelle Maschine vom Google Mitarbeiter Dan Bornstein, der diese nach der isländischen Stadt [[Wikipedia:de:Dalvík|Dalvík]] benannt hat.
 
Ab Android {{Android|4.4}} bietet das System eine alternative Registermschine zur Dalvik VM an, die [[Android Runtime]] (ART).


== Funktionsweise ==
== Funktionsweise ==
Die Funktionsweise ist sehr ähnlich zu einer Java-VM (JVM), die man z. B. von Java-Applets im Browser, Desktopanwendungen für Java oder Handyspielen älterer Generationen (MIDlets bzw. J2ME-Apps) kennt. Jede [[App]] muss grundsätzlich in der Dalvik VM ausgeführt werden, welche für jeden Prozess, also jede App, eine eigene Instanz generiert. Für die Ausführung der App werden Dateien im [[DEODEX|Dalvik Executable Format]] (.dex) gestartet. Bevor die Dalvik VM die App für den Prozessor übersetzt, wird aus dem Quellcode der App durch einen Compiler sogenannter Bytecode übersetzt. Dieser Bytecode wird schließlich von der Dalvik VM in maschinenlesbaren Code übersetzt.
Die Funktionsweise ist sehr ähnlich zu einer Java-VM (JVM), die man z. B. von Java-Applets im Browser, Desktopanwendungen für Java oder Handyapplikationen älterer Generationen (''MIDlets'' bzw. ''J2ME''-Apps) kennt. Jede [[App]] muss grundsätzlich in der Dalvik VM ausgeführt werden, welche für jeden Prozess, also jede App, eine eigene Instanz generiert. Für die Ausführung der App werden Dateien im [[DEODEX|Dalvik Executable Format]] (.dex) gestartet. Bevor die Dalvik VM die App für den Prozessor übersetzt, wird aus dem Quellcode der App durch einen Compiler sogenannter Bytecode übersetzt. Dieser Bytecode wird schließlich von der Dalvik VM in maschinenlesbaren Code übersetzt.


=== Sandbox ===
=== Sandbox ===
Die App läuft in einer sogenannten Sandbox (Referenz zu: Eigene Instanz für jeden Prozess, dadurch ist jede Instanz von anderen Instanzen unabhängig und kann diese nicht beeinflussen), einer isolierten Umgebung, die verhindert, dass das Programm direkte Hardware- oder Betriebssystemoperationen ausführen kann, z. B. Telefon ausschalten, Speicher oder andere Anwendungen löschen/manipulieren oder sogar das Dateisystem formatieren. Da ohne den Zugriff auf die Hardware (Display, Speicher, etc.) aber keine App funktionieren würde, stellt das Betriebssystem bzw. die VM wichtige Funktionen über die [[Android]]-APIs zur Verfügung (siehe Abschnitt [[#APIs|APIs]]).
Die Anwendung läuft in einer sogenannten Sandbox (Referenz zu: Eigene Instanz für jeden Prozess, dadurch ist jede Instanz von anderen Instanzen unabhängig und kann diese nicht beeinflussen), einer isolierten Umgebung, die verhindert, dass das Programm direkte Hardware- oder Betriebssystemoperationen ausführen kann (z. B. Telefon ausschalten, Speicher oder andere Anwendungen löschen/manipulieren oder das Dateisystem formatieren). Da ohne den Zugriff auf die Hardware (Display, Speicher, etc.) allerdings keine App funktionieren würde, stellt die VM wichtige Funktionen über die [[Android]]-APIs zur Verfügung (siehe Abschnitt [[#APIs|APIs]]).


=== APIs ===
=== APIs ===
Sogenannte APIs ('''A'''pplication '''P'''rogramming '''I'''nterfaces) stellen dem Programmierer fest definierte ''Methoden'' (Funktionsaufrufe), die eine App benötigen kann, zur Verfügung.
Sogenannte APIs ('''A'''pplication '''P'''rogramming '''I'''nterfaces) stellen dem Programmierer fest definierte ''Methoden'' (Funktionsaufrufe) zur Verfügung, die eine App benötigen könnte. Über eine API kann eine Anwendung Zugriff auf verschiedene Betriebssystemresourcen nehmen.


Da diese APIs meist mit jeder Android-Version erweitert und verändert werden (genau genommen mit jedem API-Level), kann es vorkommen, dass Apps, die Methoden einer neueren Android-Version benutzen, mit älteren Versionen nicht funktionieren. Zum Beispiel können [[Bluetooth]]-Funktionen erst ab Android 2.0 (API Level 5) verwendet werden;<ref>http://developer.android.com/reference/android/bluetooth/package-summary.html, Bluetooth API-Dokumentation</ref> [[NFC]] ('''N'''ear '''F'''ield '''C'''ommunication) gibt es erst seit Android 2.3.3 (API Level 10).<ref>http://developer.android.com/sdk/api_diff/10/changes.html, API Changes bei Level 10</ref> Der API-Level gibt im Groben an, auf welchem Softwarestand sich das Betriebssystem befindet.
Da diese APIs meist mit jeder Android-Version erweitert und verändert werden (genau genommen mit jedem [[Android#API-Level|API-Level]]), kann es vorkommen, dass Apps, die Methoden einer neueren Android-Version benutzen, mit älteren Versionen nicht funktionieren. Zum Beispiel können [[Bluetooth]]-Funktionen erst ab Android 2.0 (API Level 5) verwendet werden<ref>http://developer.android.com/reference/android/bluetooth/package-summary.html, Bluetooth API-Dokumentation</ref>; [[NFC]]-Unterstützung ('''N'''ear '''F'''ield '''C'''ommunication) gibt es erst seit Android 2.3.3 (API Level 10).<ref>http://developer.android.com/sdk/api_diff/10/changes.html, API Changes bei Level 10</ref> Der API-Level gibt im Groben an, auf welchem Softwarestand sich das Betriebssystem befindet.


=== Berechtigungen ===
=== Berechtigungen ===
{{Hauptartikel|App#Apps_und_Zugriffsrechte}}
{{Hauptartikel|Berechtigungen}}
[[Datei:Dolphin-permissions-screen.png|thumb|Ganz oder gar nicht: Der Benutzer kann ausgehend von den benötigten Berechtigungen entscheiden, ob er eine App wirklich installieren möchte.]]
[[Datei:Dolphin-permissions-screen.png|thumb|Ganz oder gar nicht: Der Benutzer kann ausgehend von den benötigten Berechtigungen entscheiden, ob er eine App wirklich installieren möchte.]]
Da manche API-Operationen jedoch die Daten auf dem Gerät (Dateisystem, Kontakte etc.) oder die Funktionsfähigkeit gefährden, besonders viel Strom verbrauchen (Kamera, Bluetooth, ...) oder Kosten für den Benutzer verursachen könnten (Internetnutzung, SMS), sind diese nur über bestimmte Berechtigungen erreichbar, über die der Benutzer bei der Installation informiert wird. Dazu gehören:
Da manche API-Operationen die Daten auf dem Gerät (Dateisystem, Kontakte etc.) oder die Funktionsfähigkeit beeinflussen, besonders viel Akkuleistung verbrauchen (Kamera, Bluetooth, Leuchte...), persönliche Daten auslesen (Telefonbucheinträge, Identität, Browserhistory) oder Kosten für den Benutzer verursachen könnten (Internetnutzung, SMS), sind diese nur über bestimmte Berechtigungen erreichbar. Der Benutzer wird bei der Installation einer App über die geforderten Berechtigungen informiert. Dazu gehören unter Anderem:
* Zugriff auf die Kamera
* Zugriff auf die Kamera
* Zugriff auf das ''[[Radio]]'' (Bluetooth, Telefon, Internet etc.)
* Zugriff auf [[Radio|Funkdienste]] (Bluetooth, Telefon, Internet etc.)
* Zugriff auf Kontakte, die auf dem Gerät gespeichert sind
* Zugriff auf Kontakte, die auf dem Gerät gespeichert sind
* Zugriff auf ein externes Dateisystem (meist microSD-Speicherkarte)
* Zugriff auf ein externes Dateisystem (meist microSD-Speicherkarte)
* Verwendung des GPS-Empfängers zur Positionsermittlung
* Verwendung des GPS-Empfängers zur Positionsbestimmung
* ...
* Positionsermittlung über Funkmasten oder [[WLAN]]-Netzwerknamen
 
Die Berechtigungen lassen sich vom Benutzer nicht App-bezogen einschränken. Das bedeutet, das man entweder alle Berechtigungen bei der Installation gewährt, oder die App nicht installiert. Diese Berechtigungen werden bei der Ausführung der App von der Dalvik VM gewährt. Benötigen Apps die Möglichkeit selbstständig, also außerhalb der Dalvik VM, Code auszuführen, ist dies über die API möglich.


== Einzelnachweis ==
== Einzelnachweis ==
Zeile 31: Zeile 33:
[[Kategorie:Allgemein]]
[[Kategorie:Allgemein]]
[[Kategorie:Software]]
[[Kategorie:Software]]
[[Kategorie:Abkürzungen]]

Aktuelle Version vom 25. Mai 2016, 19:35 Uhr

Die Dalvik VM (Dalvik Virtual Machine) ist eine von Google entwickelte virtuelle Registermaschine[1] für Android, welche die Aufgabe hat, eine in Java programmierte App aus Bytecode in maschinenlesbaren Code zu übersetzen. Dieser Code wird anschließend vom Prozessor ausgeführt. Die Dalvik VM ist dementsprechend ein Zwischenschritt zwischen dem Quellcode und dem durch den Prozessor ausführbaren Code. Der Quellcode wird dabei zur Laufzeit übersetzt (Just-in-time-Kompilierung)

Entwickelt wurde die virtuelle Maschine vom Google Mitarbeiter Dan Bornstein, der diese nach der isländischen Stadt Dalvík benannt hat.

Ab Android 4.4 KitKat "KitKat" bietet das System eine alternative Registermschine zur Dalvik VM an, die Android Runtime (ART).

Funktionsweise[Bearbeiten | Quelltext bearbeiten]

Die Funktionsweise ist sehr ähnlich zu einer Java-VM (JVM), die man z. B. von Java-Applets im Browser, Desktopanwendungen für Java oder Handyapplikationen älterer Generationen (MIDlets bzw. J2ME-Apps) kennt. Jede App muss grundsätzlich in der Dalvik VM ausgeführt werden, welche für jeden Prozess, also jede App, eine eigene Instanz generiert. Für die Ausführung der App werden Dateien im Dalvik Executable Format (.dex) gestartet. Bevor die Dalvik VM die App für den Prozessor übersetzt, wird aus dem Quellcode der App durch einen Compiler sogenannter Bytecode übersetzt. Dieser Bytecode wird schließlich von der Dalvik VM in maschinenlesbaren Code übersetzt.

Sandbox[Bearbeiten | Quelltext bearbeiten]

Die Anwendung läuft in einer sogenannten Sandbox (Referenz zu: Eigene Instanz für jeden Prozess, dadurch ist jede Instanz von anderen Instanzen unabhängig und kann diese nicht beeinflussen), einer isolierten Umgebung, die verhindert, dass das Programm direkte Hardware- oder Betriebssystemoperationen ausführen kann (z. B. Telefon ausschalten, Speicher oder andere Anwendungen löschen/manipulieren oder das Dateisystem formatieren). Da ohne den Zugriff auf die Hardware (Display, Speicher, etc.) allerdings keine App funktionieren würde, stellt die VM wichtige Funktionen über die Android-APIs zur Verfügung (siehe Abschnitt APIs).

APIs[Bearbeiten | Quelltext bearbeiten]

Sogenannte APIs (Application Programming Interfaces) stellen dem Programmierer fest definierte Methoden (Funktionsaufrufe) zur Verfügung, die eine App benötigen könnte. Über eine API kann eine Anwendung Zugriff auf verschiedene Betriebssystemresourcen nehmen.

Da diese APIs meist mit jeder Android-Version erweitert und verändert werden (genau genommen mit jedem API-Level), kann es vorkommen, dass Apps, die Methoden einer neueren Android-Version benutzen, mit älteren Versionen nicht funktionieren. Zum Beispiel können Bluetooth-Funktionen erst ab Android 2.0 (API Level 5) verwendet werden[2]; NFC-Unterstützung (Near Field Communication) gibt es erst seit Android 2.3.3 (API Level 10).[3] Der API-Level gibt im Groben an, auf welchem Softwarestand sich das Betriebssystem befindet.

Berechtigungen[Bearbeiten | Quelltext bearbeiten]

Hauptartikel: Berechtigungen
Ganz oder gar nicht: Der Benutzer kann ausgehend von den benötigten Berechtigungen entscheiden, ob er eine App wirklich installieren möchte.

Da manche API-Operationen die Daten auf dem Gerät (Dateisystem, Kontakte etc.) oder die Funktionsfähigkeit beeinflussen, besonders viel Akkuleistung verbrauchen (Kamera, Bluetooth, Leuchte...), persönliche Daten auslesen (Telefonbucheinträge, Identität, Browserhistory) oder Kosten für den Benutzer verursachen könnten (Internetnutzung, SMS), sind diese nur über bestimmte Berechtigungen erreichbar. Der Benutzer wird bei der Installation einer App über die geforderten Berechtigungen informiert. Dazu gehören unter Anderem:

  • Zugriff auf die Kamera
  • Zugriff auf Funkdienste (Bluetooth, Telefon, Internet etc.)
  • Zugriff auf Kontakte, die auf dem Gerät gespeichert sind
  • Zugriff auf ein externes Dateisystem (meist microSD-Speicherkarte)
  • Verwendung des GPS-Empfängers zur Positionsbestimmung
  • Positionsermittlung über Funkmasten oder WLAN-Netzwerknamen

Einzelnachweis[Bearbeiten | Quelltext bearbeiten]