Normalerweise sieht man eine Kurzbeschreibung der Permission (z. B. bei der Installation einer App). Die technische Bezeichnung taucht selten im Klartext für den Anwender auf – man kann aber z. B. auch einen Blick auf das Manifest werfen, und da stehen sie im Klartext.
Nun werde ich aber hier nicht alle Permissions aufführen, das wäre einfach zu viel. Die findet man bei Interesse im Entwickler-Handbuch (allerdings auf Englisch). Ein Wiki zum Thema, an dem sich jeder beteiligen kann, existiert ebenfalls, und zwar bei Stack Exchange (wiederum auf Englisch), eine weitere gute (englische) Übersicht mit zusätzlichen Sicherheits-Tipps findet sich bei AndroidForums.Com, und auch bei Go2Android findet sich ein gut erklärter Artikel von MaTT (übrigens Teil der Serie "anDROID für Anfänger"). Ein paar ausgewählte, die doch häufiger einmal auftauchen könnten, möchte ich aber hier kurz erklären.
Zunächst einmal sind die Permissions in "Berechtigungs-Gruppen" eingeteilt. Besucht man die Playstore-Seite einer App, findet man diese "Permission Groups" als Überschriften bei den "Berechtigungen" wieder. Eine vollständige Auflistung gibt es in der API Dokumentation auf den Entwicklerseiten. Da selbige in englischer Sprache gehalten sind, hier ein übersetzter (und mit Erklärungen ergänzter) Auszug:
| Permission-Group | Erklärung |
|---|---|
| ACCOUNTS | Konten. Permissions für den direkten Zugriff auf vom Account Manager verwaltete Konten. |
| AFFECTS_BATTERY | Auswirkungen auf den Akku. Ruhezustand deaktivieren u. ä. |
| AUDIO_SETTINGS | Audio Einstellungen. Permissions, die direkten Zugriff auf Lautstärke-Einstellungen ermöglichen. |
| BLUETOOTH_NETWORK | Bluetooth. Zugriff auf andere Geräte via Bluetooth. |
| BOOKMARKS | Lesezeichen. Permissions zur Verwaltung von Lesezeichen und Browserverlauf. |
| CALENDAR | Kalender. Alles, was auf den Kalender zugreift. |
| CAMERA | Kamera. Zugriff auf selbige zum Aufnehmen von Fotos und Videos. |
| COST_MONEY | Kosten verursachen. SMS verschicken, Anrufe tätigen, etc., alles ohne Zutun des Anwenders. |
| DEVELOPMENT_TOOLS | Entwicklerwerkzeuge. Diese Gruppe sollte eigentlich in Apps für Endanwender nicht auftauchen, hier gilt daher besondere Vorsicht. Wie ein aktuelles Beispiel zeigt, lässt sich damit u. U. auf Dinge zugreifen, für die die passende Permission gar nicht angefordert wurde. |
| LOCATION | Standort. Alles, was für Zugriffe auf den aktuellen Standort benötigt wird. |
| MESSAGES | Nachrichten. Empfangen, Lesen, Schreiben, und Versenden von SMS/MMS etc., auch ohne Zutun des Anwenders. Definitiv eine Überschneidung mit COST_MONEY. |
| NETWORK | Netzkommunikation. (Besser: "Netzwerk") Beinhaltet sowohl den Zugang zum Internet, als auch die Anpassung von Netzwerkeinstellungen, Erstellung/Löschung von Zugangspunkten, etc. |
| PERSONAL_INFO | Personenbezogene Daten. Lesender und schreibender Zugriff auf Dinge wie Kontakte, Kalender (ah, wieder eine Überschneidung: CALENDAR), etc. |
| PHONE_CALLS | Telefonanrufe. Passen auch in COST_MONEY. Anrufe automatisch tätigen, abfangen, beantworten... |
| SOCIAL_INFO | Soziale Informationen. Permissions für den lesenden und schreibenden Zugriff auf Informationen im sozialen Umfeld: Kontakte, Anruf-Protokolle, etc. |
| STORAGE | Speicher. Bezieht sich auf die SD-Karte, lesend und schreibend. |
| SYNC_SETTINGS | Synchronisierungseinstellungen. Für alles, was mit selbigen zu tun hat, wie beispielsweise das Ein- und Ausschalten der Synchronisation. |
| SYSTEM_TOOLS | System-Tools. Laut API Beschreibung als "ungefährlich" eingestuft ("das Meiste wird der Anwender ohnehin nicht verstehen", aha). Ändern von Systemeinstellungen beispielsweise. "Schädliche Apps können so die Systemkonfiguration beschädigen." Naja, alles ist relativ. |
Dies ist, wie beschrieben, lediglich ein Auszug der gebräuchlichsten Gruppen. Das, worauf man wirklich achten muss, findet sich jedoch in den einzelnen Permissions.
Eine weitere Einteilung stellen die so genannten Protection Level dar (siehe Developers Reference: Permission Element). Vier verschiedene Ebenen legen dabei fest, wie mit den entsprechenden Permissions umgegangen wird (die Kürzel in Klammern sind für die Referenz in der eigentlichen Permissions-Tabelle):
| Level | Erklärung |
|---|---|
| normal (no) | niedriges Risko bzw. "Standard". Diese Permissions werden dem Anwender bei der Installation nicht extra "vorgeführt", sondern stillschweigend akzeptiert. |
| dangerous (da) | höheres Risiko: Zugriff auf persönliche Daten, oder Kontrolle über das Gerät mit potentiellem negativen Impakt für den User. Das sind die Permissions, die bei der Installation vom Anwender explizit bestätigt werden müssen. |
| signature (si) | Der Herausgeber des Zertifikats muss mit dem des ROM-Zertifikats übereinstimmen. In der Regel heißt dies: Eine solche App muss vom gleichen Hersteller stammen. |
| signatureOrSystem (sy) | Wie "Signature"; alternativ darf es aber auch eine beliebige "System-App" sein. Da man eine solche nur mit root-Rechten installieren kann, ist dies für "normale Anwender" eher uninteressant. |
| development (dv) | Das ROM muss mit einem Entwickler-Key signiert sein. Diese Permissions sind eigentlich nur für Entwickler/Entwicklung gedacht. I. d. R. scheinbar als "developmentOrSignatureOrSystem" zu verstehen. |
Auch hier wieder ein Auszug einiger gerbäuchlicherer Kandidaten. Nochmals kurz zur Erklärung: "PL" bezeichnet den Protection Level. "Risk" steht für das mit der jeweiligen Permission verbundene Risiko:
Dieses Risiko muss jedoch auch immer im Zusammenhang mit dem Protection Level gesehen werden: Von einer "kritischen Permission" ist der Normal-Anwender (ohne root) beispielsweise überhaupt nicht betroffen, wenn der Protection Level "Signature" bzw. "SignatureOrSystem" heißt. Gelegentlich ändert sich eine solche Zuordnung mit neueren Android-Versionen (Beispiel: READ_LOGS wanderte ab Android 4.1 nach "sy"). Quelle für die Risiko-Klassen ist hier übrigens der bereits genannte Artikel bei AndroidForums.Com, die meisten Protection-Level finden sich in einem Blog-Eintrag zugeordnet.
| Permission | PL | Risk | Erklärung |
|---|---|---|---|
| ACCESS_COARSE_LOCATION | da | ? | Ungefährer (netzwerkbasierter) Standort. Hier kommt kein GPS zum Einsatz, sondern die Informationen von Funkmasten (Cell-ID) sowie WLANs |
| ACCESS_FINE_LOCATION | da | ? | Genauer (GPS-) Standort. Exakte, per GPS ermittelte Standortdaten. |
| ACCESS_LOCATION_EXTRA_COMMANDS | no | 2-3 | Zusätzliche Standort-Befehle verwenden. Die Dokumentation ist hier wieder nicht sehr aussagekräftig, doch offensichtlich sollen zusätzliche Daten zum Standort erlangt werden. |
| ACCESS_MOCK_LOCATION | da | 2 | Falsche Standortquellen für Testzwecke. Fake Location (falsche Standortdaten vom System anfordern). Für Testzwecke gedacht (z. B. im Emulator); wird aber scheinbar auch benötigt, um ein externes GPS Gerät nutzen zu können. Hier geht es nicht darum, einer anderen App eine Fake-Location unterzujubeln – das ginge allenfalls in Verbindung mit INSTALL_LOCATION_PROVIDER. |
| ACCESS_NETWORK_STATE | no | ? | Netzwerkstatus anzeigen. Informationen über Netzwerke (besteht eine Verbindung, und wenn ja zu welchem Netzwerk?) |
| ACCESS_SURFACE_FLINGER | sy | ? | Zugriff auf die API des "Surface Flinger" (Teil des Medien-Frameworks unter Android: Stellt einen systemweiten "Oberflächen-Kompositor" bereit, der sich um das Rendering in Framebuffer-Devices kümmert - also Grafik, Grafik-Beschleunigung und so). |
| ACCESS_WIFI_STATE | no | ? | WLAN-Status anzeigen. Informationen über WiFi-Netzwerke (besteht eine Verbindung, und wenn ja zu welchem Netzwerk? Welche Netzwerke sind verfügbar?) |
| ACCOUNT_MANAGER | sy | ? | Als Konto-Manager fungieren. App darf mit Konto-Authentifizierern interagieren. (für Systemanwendungen reserviert). |
| AUTHENTICATE_ACCOUNTS | da | 4 | Als Kontoauthentifizierer fungieren. Konto-Authentifizierungsfunktionen verwenden, Konten erstellen, Abrufen und Einstellen der zugehörigen Passwörter. In der Regel stellt eine solche App eine Schnittstelle zu einem neuen Dienst bereit, der nicht von Haus aus in Android integriert ist (Beispiel: Dropbox) – implementiert also die Art und Weise, wie bei diesem die Anmeldung funktioniert. Darüber hinaus kann die App u. U. auch einschränken, was eine aufrufende App mit dem Zugang anstellen darf. |
| BATTERY_STATS | no | 0 | Akku-Statistiken sammeln. |
| BIND_APPWIDGET | sy | ? | Widgets auswählen. Erlaubt einer App dem AppWidget-Service mitzuteilen, welche App auf die AppWidget-Daten zugreifen darf. Mit dieser Berechtigung kann anderen Anwendungen Zugriff auf persönliche Daten gewährt werden. Laut API-Referenz sollten nur sehr wenige Apps diese Permission benötigen. |
| BLUETOOTH | da | ? | Bluetooth-Verbindungen herstellen. Zugriff auf bereits "autorisierte" Bluetooth-Geräte |
| BLUETOOTH_ADMIN | da | 2 | Bluetooth-Verwaltung. Bluetooth-Geräte "autorisieren" (also "pairen" und so). Eine mit dieser Permission ausgestattete App darf selbständig Bluetooth-Verbindungen aufbauen und etablieren – auch zu "wildfremden" Geräten. |
| CALL_PHONE | da | 3 | Telefonnummern direkt anrufen. Anruf ohne Bestätigung durch den Anwender tätigen. Wird z. B. für Kontakt-Widgets benötigt, wenn ein "Tapp" auf selbige direkt einen Anruf auslösen soll – macht aber bei einer Mal-App herzlich wenig Sinn. Gilt nicht für Notruf-Nummern. |
| CALL_PRIVILEGED | sy | ? | Alle Telefonnummern direkt anrufen. Wie CALL_PHONE, aber inklusive Notruf-Nummern ("Hallo, Polizei – Anwender ist gerade in Bank eingebrochen... Bitte Fußboden reparieren...") |
| CAMERA | da | 1-3 | Fotos aufnehmen. Vollzugriff auf die Kamera. Nebenwirkung: Diese App lässt sich nicht auf Geräten installieren, die über keine Kamera verfügen. Die API-Referenz schreibt sinngemäß: "Wenn die App auch ohne Kamera bedienbar ist, diese Permission nicht anfordern." Da sei die Frage erlaubt: Braucht man sie dann überhaupt, wenn es auch ohne geht? |
| CHANGE_CONFIGURATION | da | 2-3 | UI-Einstellungen ändern. Änderungen an der Umgebung durchführen. API-Ref nennt als Beispiel "Locale", also Ländereinstellungen wie Währung und Zeitformat. Beschreibung sehr vage. |
| CHANGE_NETWORK_STATE | da | ? | Netzwerkkonnektivität ändern. Netzwerk-Status ändern (also z. B. Verbindung trennen) |
| CHANGE_WIFI_MULTICAST_STATE | da | ? | WLAN-Multicast-Empfang zulassen. WiFi MultiCast aktivieren. Damit können Datenpakete an mehrere Empfänger zeitgleich verschickt werden, ohne dass dies zusätzliche Bandbreite erfordert. Macht z. B. Sinn bei einem Streaming-Server, der mehrere Clients bedient ("Radio"). Gleichzeitig ermöglicht dies auch den Empfang von Netzwerk-Paketen, die nicht an das eigene Gerät gerichtet sind (Netzwerk-Sniffer). |
| CHANGE_WIFI_STATE | da | ? | WLAN-Status ändern. CHANGE_NETWORK_STATE für WiFi. Kann auch Änderungen an konfigurierten WLAN-Netzen vornehmen. |
| CLEAR_APP_CACHE | da | 0 | Alle Cache-Daten der Anwendung löschen. Cache beliebiger/aller Anwendungen leeren |
| CLEAR_APP_USER_DATA | sy | ? | Alle Cache-Daten der Anwendung löschen. Benutzerdaten beliebiger/aller Apps löschen (siehe Einstellungen → Anwendungen verwalten, der Button "Daten löschen" bei jeder Anwendung) – richtiger wäre also Anwendungsdaten löschen oder CLEAR_APP_DATA, das "User" verwirrt hier ein wenig. |
| DELETE_CACHE_FILES | sy | ? | (einzelne) Dateien aus dem Cache löschen |
| DELETE_PACKAGES | sy | ? | Anwendungen löschen. Apps entfernen/löschen/deinstallieren/wegmachen |
| DEVICE_POWER | sy | ? | Tiefgreifender (low-level) Eingriff in die Energieverwaltung (Power Management). Hat nicht direkt etwas mit "Power Off" zu tun, könnte aber bei Missbrauch durchaus zu selbigem führen… |
| DIAGNOSTIC | sy | ? | Lese-/Schreibberechtigung für zu Diagnosegruppe gehörige Elemente. Lese- und Schreibzugriff auf "diagnostic ressources" – die API-Referenz beschreibt leider nichts genaueres. |
| DISABLE_KEYGUARD | da | 2-3 | Tastensperre deaktivieren. Tastensperre (inkl. deren Passwort-Schutz) deaktivieren, sodass der Bildschirm nicht mehr automatisch gesperrt wird. Sinnvoll z. B. bei Video-Apps und insbesondere bei Navis – und bei eingehenden Telefonaten. |
| EXPAND_STATUS_BAR | no | 2-3 | Statusleiste ein-/ausblenden. Status-Bar (Notification?) erweitern/kollabieren. Wohl die Lite-Version von STATUS_BAR |
| GET_ACCOUNTS | no | ? | Bekannte Konten suchen. Liste konfigurierter Accounts abrufen (nur die Accounts, nicht die Zugangsdaten selber). Mit dieser Permission lässt sich lediglich feststellen, welche Accounts existieren. So kann beispielsweise eine App, die Dropbox verwenden möchte, feststellen, ob bereits ein passendes Zugangskonto eingerichtet ist. |
| GET_TASKS | da | 2-3 | Laufende Anwendungen abrufen. Informationen über laufende Anwendungen abrufen. Wird natürlich von Task-Managern und -Killern, aber auch von Akku-Statistik-Apps benötigt. "Böse Apps" können dies nutzen um auszukundschaften, wo sich lohnende Daten zum Klauen finden lassen. |
| INJECT_EVENTS | si | ? | Tasten und Steuerungstasten drücken. "Generieren" und "ausführen" bestimmter Events, wie z. B. Benutzer-Eingaben. Die App kann also vermutlich andere Apps "fernbedienen". |
| INSTALL_DRM | ? | 1-3 | DRM Installieren. DRM steht für Digital Rights Management (Digitale Rechteverwaltung), wird aber auch oft als "Digital Restriction Management" (Digitale Einschränkungs-Verwaltung) genannt. Damit soll kontrolliert werden, wer auf welche Medien wann Zugriff hat. Genutzt wird DRM beispielsweise von Google Books/Musik/Film oder Amazon's Kindle. Wenn jemand jedoch ein spezielles DRM in meinem System installieren will, werde ich argwöhnisch: Besser weist man diesem Vertreter die Tür. Zumal diese Permission in die Gruppe "Hardware Controls" fällt… |
| INSTALL_LOCATION_PROVIDER | sy | ? | App will selber Ortsdaten bereitstellen ("Du bist jetzt hier"). Woher sie die nehmen will? Naja, vielleicht von einem Bluetooth-GPS o. ä. |
| INSTALL_PACKAGES | sy | ? | Anwendungen direkt installieren. Andere Apps installieren. Kann OK sein (App-Manager), muss aber nicht (Wallpaper etc. wollen vielleicht eher Schadsoft nachladen, wenn sie diese Permission anfordern) |
| INSTALL_SHORTCUT | ? | 1-3 | Verknüpfungen auf dem Homescreen erstellen. Malware nutzt dies, um unerwünschte Dinge dort abzulegen. Beispielsweise ein Icon, dass wie das vom Playstore aussieht – allerdings ganz woanders hinführt. |
| INTERNET | da | ? | Uneingeschränkter Internetzugriff. Öffnen von Netzwerk-Sockets. Die App kann also beliebige Internet-Verbindungen herstellen. Wird von allen Apps gebraucht, die Werbung anzeigen wollen. |
| KILL_BACKGROUND_PROCESSES | no | 3 | alle Anwendungen im Hintergrund schließen. Hintergrund-Prozesse "töten", also beenden. Dabei kann es sich um die eigenen Prozesse handeln (was dem Anwender die Möglichkeit gibt, das Programm tatsächlich zu beenden, statt es nur in den Hintergrund zu schieben) – es können aber eben so gut fremde Prozesse beendet werden. i. d. R. handelt es sich dann um einen Task-Manager oder Task-Killer. Eine böswillige App könnte dies jedoch auch nutzen, um Schutzmechanismen auszuhebeln (etwa eine Anti-Malware-App abzuschießen, bevor sie mit ihrem eigentlichen Unwesen beginnt). |
| MANAGE_ACCOUNTS | da | ? | Als Konto-Manager fungieren. Accounts/Zugangsdaten verwalten – also auch verändern. Die Doku ist leider wieder einmal sehr vage. Laut einem Post bei Stack Exchange heißt dies jedoch nur, dass die betreffende App ihre eigenen Konten (nicht aber andere) mit Unterstützung des (system-eigenen) Account-Managers verwalten darf. |
| MODIFY_PHONE_STATE | sy | ? | Telefonstatus ändern. Status der Telefonie anpassen: Power, MMI-Codes (z. B. Rufumleitung [de]aktivieren, Rufnummernübermittlung ein/ausschalten) etc. – jedoch nicht Anrufe tätigen. Allerdings kann das Netzwerk (zu einem anderen Anbieter, Roaming) gewechselt oder die Mobilfunkverbindung ein- bzw. ausgeschaltet werden, ohne dass der Benutzer davon informiert wird. Auch können mit dieser Permission eingehende Anrufe abgefangen werden. |
| MOUNT_FORMAT_FILESYSTEMS | da | 2 | Externen Speicher formatieren. Externe Dateisysteme (SD-Karten etc.) formatieren (Vorsicht! Nach dem Formatieren ist das entsprechende Dateisystem leer, die (vorher) darauf befindlichen Daten sind weg!). Nix für Wallpaper, Spiele, etc.! |
| MOUNT_UNMOUNT_FILESYSTEMS | da | 1 | Dateisysteme bereitstellen oder Bereitstellung aufheben. Dateisysteme ein- und ausbinden. Toll für externe Festplatten am Telefon – gilt aber ebenso für SD-Karten. |
| NFC | da | 2 | NFC-Operationen ausführen. |
| PROCESS_OUTGOING_CALLS | da | 4 | Abgehende Anrufe abfangen. Ausgehende Anrufe beobachten, verändern oder abbrechen. Hm, könnte das einen Anruf bei der Mailbox ins Ausland weiterleiten? Für eingehende Anrufe siehe MODIFY_PHONE_STATE. |
| READ_ATTACHMENT | da | 3 | Attachments lesen. Bezieht sich auf Dateianhänge in E-Mails der Stock-Mail-App (trifft also weder auf die GMail-App, noch auf K-9 Mail zu). Dateianhänge können sensible Informationen enthalten, die eine böswillige App an andere Stellen weiterleiten könnte. |
| READ_CALENDAR | da | 2 | Kalenderdaten lesen. Sollte klar sein: Alle Termine können damit gelesen werden. |
| READ_CONTACTS | da | 2-3 | Kontaktdaten lesen. Damit ist das Adressbuch fällig. Was damit alles einsehbar ist, verrät die App permission.READ_CONTACTS. |
| READ_FRAME_BUFFER | sy | ? | Zugriff auf die Frame-Buffer Daten (vereinfacht gesagt: Den Inhalt des Bildschirms). Erlaubt u. a. das Erstellen von Screenshots. |
| READ_HISTORY_BOOKMARKS | da | 2-3 | Erlaubt lesenden Zugriff auf Lesezeichen und Browserverlauf (Chronik). Was das im Einzelnen bedeutet. lässt sich mit der READ_HISTORY_BOOKMARKS App ermitteln. |
| READ_LOGS | sy | 4 | System-Protokolldateien lesen. Lesender Zugriff auf die Log-Dateien des Systems. Hier werden allgemeine Informationen zu durchgeführten Aktionen gespeichert, i. d. R. jedoch keine vertraulichen Informationen (es sei denn, ein Programmierer hat etwas verbockt). Ab Android 4.1 ist diese Permission System-Anwendungen vorbehalten. |
| READ_OWNER_DATA | da | ? | Eigentümerdaten lesen. Auslesen der auf dem Gerät gespeicherten Eigentümerdaten. |
| READ_PHONE_STATE | da | ? | Telefonstatus lesen und identifizieren. Zugriff auf die Telefonfunktionen des Gerätes. Eine Anwendung erhält mit dieser Berechtigung unter anderem die Möglichkeit, die Telefon- und Seriennummer des Telefons zu ermitteln. Um festzustellen, ob ein Anruf aktiv ist,wird sie jedoch trotz gegenteiliger Behauptungen keineswegs benötigt, wie die App permission.READ_PHONE_STATE zeigt. Bei Werbung (z. B. AdMob) wird dies häufig zum Auslesen der IMEI/IMSI genutzt um festzustellen, welche Werbung auf dem Gerät bereits angezeigt wurde (eindeutige Identifizierung, Tracking). Apps, die auch für Android 1.6 und früher kompatibel sein sollen, wird diese Permission automatisch gesetzt. |
| READ_PROFILE | da | 2-3 | Das persönliche Profil des Anwenders lesen. Bezieht sich auf den neuen "Me" Kontakt für das eigene Profil. Macht beispielsweise Sinn für Messenger-Apps, die den Diskussionsverlauf darstellen. |
| READ_SECURE_SETTINGS | ? | ? | Lesezugriff auf Systemeinstellungen (u. a. Umschalter für die mobile Datenverbindung). Eigentlich dem System vorbehalten. |
| READ_SMS | da | 1-3 | SMS oder MMS lesen. Damit lassen sich bereits gespeicherte Kurznachrichten lesen. Darunter können natürlich auch vertrauliche Informationen sein… |
| READ_SOCIAL_STREAM | da | 3 | Den Social-Media-Stream lesen. Diese Permission wurde mit Android 4.0 eingeführt. Eine damit ausgestattete App kann Status-Updates der sozialen Netzwerke lesen – sowohl eingehende, als auch ausgehende. |
| READ_SYNC_SETTINGS | no | 0-1 | Synchronisierungseinstellungen lesen. Lesezugriff auf die Einstellungen der Synchronisation – etwa um festzustellen, ob selbige für Kontakte aktiviert ist. Ein gutes Zeichen: Die App möchte vielleicht wissen, ob der Anwender eine Datensynchronisation im Hintergrund erlaubt, und sich (hoffentlich) entsprechend verhalten. |
| READ_SYNC_STATS | no | 1 | Synchronisierungsstatistiken lesen. Beispielsweise den Verlauf bereits durchgeführter Synchronisationen einsehen. |
| REBOOT | sy | ? | Erlaubt den Neustart des Gerätes. Wie der Name es bereits andeutet: Diese App kann mal eben einen Reboot veranlassen. |
| RECEIVE_BOOT_COMPLETED | no | 1-3 | Automatisch nach dem Booten starten. App möchte benachrichtigt werden, wenn der Bootvorgang abgeschlossen ist. i. d. R. heißt das: Sie möchte nach dem Booten automatisch gestartet werden. |
| RECEIVE_MMS, RECEIVE_SMS | da | 3 | MMS empfangen, SMS empfangen. Eingehenden MMS/SMS abfangen – da möchte wohl jemand mitlesen. Kann aber durchaus OK sein, wenn die App auf MMS/SMS reagieren soll. Auf der anderen Seite kann man damit eingehende Nachrichten auch "im Nirvana" verschwinden lassen... |
| RECORD_AUDIO | da | 1-3 | Audio aufnehmen. Tonaufnahmen erstellen. Das kann sowohl für ein "Diktaphon" genutzt werden – als auch zum Mitschneiden von Telefonaten. |
| RESTART_PACKAGES | no | 3 | Anwendungen neu starten. Laufende Apps neu starten. Wird z. B. verwendet, um von selbigen ein Backup erstellen zu können. (In der API-Referenz mittlerweile auf "deprecated" gesetzt, sollte also in neueren Versionen nicht mehr genutzt werden) |
| SEND_SMS | da | 3 | Kurznachrichten senden. Und zwar ohne Zutun des Benutzers, auch an richtig teure Premium-Dienste (womit klar ist, wozu "böse Apps" das gern hätten). Es gibt aber auch "gute" Gründe für diese Permission: Natürlich die SMS-Apps, aber teilweise auch In-App-Käufe, die nicht über Google Checkout abgewickelt werden. |
| SET_ACTIVITY_WATCHER | sy | ? | Die Ausführung von Systemaktivitäten beobachten. Wird meist für Debugging benutzt. Wenn es also keine Beta ist, hat der Entwickler vielleicht nur vergessen, das wieder raus zu nehmen. |
| SET_ALWAYS_FINISH | da | ? | App kann sich selber beenden – also wirklich beenden, nicht nur in den Hintergrund gehen. |
| SET_ANIMATION_SCALE | dv | ? | Allgemeine Animationsgeschwindigkeit einstellen. Anpassung der Animationsgeschwindigkeit (schnellere/langsamere Animationen). |
| SET_PREFERRED_APPLICATIONS | da | ? | App kann jeder Aktivität eine Default-App zuweisen (etwa den Browser zum Öffnen einer URL). In neueren Android-Versionen ohne Auswirkung. |
| STATUS_BAR | sy | ? | Kann die Status-Bar (Notification?) öffnen, schließen, und ausblenden. Meist will die App wohl letzteres, um einen "Vollbild-Modus" zu ermöglichen. |
| SUBSCRIBED_FEEDS_READ | no | 2 | Abonnierte Feeds lesen. Abrufen von Details zu den derzeitig synchronisierten Feeds. |
| SUBSCRIBED_FEEDS_WRITE | da | 0-2 | Abonnierte Feeds schreiben. Änderungen an kürzlich synchronisierten Feeds vornehmen. |
| SYSTEM_ALERT_WINDOW | da | 3 | Warnungen auf Systemebene anzeigen. Fenster mit Systemwarnungen einblenden. Eine böswillige App kann so den gesamten Bildschirm blockieren. Sollte eigentlich nicht benutzt werden, da dies für System-Meldungen gedacht ist. Erlaubt das anzeigen von "Alert Windows", d. h. Nachrichtenfenstern, die immer im Vordergrund angezeigt werden. |
| USE_CREDENTIALS | da | ? | Authentifizierungsinformationen eines Kontos verwenden. Möchte die konfigurierten Zugangsdaten verwenden. Das heißt nicht unbedingt, dass es sie "zu sehen bekommt" – aber die App kann sich quasi "im Namen des Anwenders" anmelden. Beim ersten Mal wird der Anwender jedoch vom Account Manager gefragt, ob er dies zulassen möchte. |
| USE_SIP | da | 2-3 | App kann Internet-Telefonie nutzen (SIP ist das Protokoll dafür) |
| VIBRATE | no | 0 | Vibrationsalarm steuern. Wird gern genutzt, um beispielsweise auf die Beendigung (oder auch den Start) einer Aktivität hinzuweisen – oder generell, um die Aufmerksamkeit des Anwenders zu wecken. Laute Töne sind ja nicht immer erwünscht. „Vibrieren“ heißt: Lass das Gerät zittern und summen... |
| WAKE_LOCK | no | ? | Standby-Modus deaktivieren. App kann das System daran hindern, einen Ruhezustand einzunehmen (also den Bildschirm zu dimmen, die CPU "schlafen" zu lassen, etc.) Wäre doch blöd, wenn die Navi-App läuft und plötzlich der Bildschirm ausgeht. |
| WRITE_APN_SETTINGS | sy | ? | Einstellungen für Zugriffspunktname schreiben. App kann die Zugangsdaten zum Internet etc. (siehe APN) verändern. Meist geht es der App nur darum, den Namen des APN zu ändern – um die Verwendung des mobilen Datenverkehrs zu steuern (Beispiel: APNDroid). |
| WRITE_CALENDAR | da | 2 | Kalenderdaten schreiben. Diese Permission erlaubt lediglich den Schreib-, nicht aber den Lesezugriff auf den Kalender. Die damit versehene App kann also Termine hinzufügen, nicht aber lesen oder ändern. |
| WRITE_CALL_LOG | da | 2-3 | Anruflisten schreiben. Macht sicher Sinn für VoIP- und Backup-Apps. Andere Apps sollten hier jedoch nichts verloren haben. |
| WRITE_CONTACTS | da | 1-3 | Kontaktdaten schreiben. Wie WRITE_CALENDAR, nur in Bezug auf die Kontaktdaten bzw. Browser-History (Chronik) und Lesezeichen. |
| WRITE_HISTORY_BOOKMARKS | da | 2-3 | |
| WRITE_EXTERNAL_STORAGE | da | 2 | App darf beliebige Daten auf der (externen) SD-Karte lesen, schreiben, verändern und auch löschen – prinzipiell auch die Daten anderer Apps. Diese Permission ist aber beispielsweise essentiell für diverse Backup- und Kamera-Apps, die natürlich Daten auf der Karte manipulieren müssen. Warnung: Apps, die für Android 1.5 oder älter geschrieben wurden, erhalten diese Permission implizit! |
| WRITE_OWNER_DATA | da | ? | Eigentümerdaten schreiben. Schreiben/verändern der auf dem Gerät gespeicherten Eigentümerdaten. |
| WRITE_PROFILE | da | 1-3 | Das persönliche Profil des Anwenders schreiben. Gegenstück zu READ_PROFILE. |
| WRITE_SECURE_SETTINGS | dv | 4 | Allgemeine Systemeinstellungen ändern. Lesen und Schreiben von Systemeinstellungen. "Secure Settings" können nur von Systemanwendungen (also solchen, die ins "ROM" integriert wurden) angefordert werden. |
| WRITE_SETTINGS | da | 2 | |
| WRITE_SMS | da | 3 | SMS Nachrichten schreiben (jedoch nicht senden). Eine böswillige App könnte darauf hoffen, dass der Anwender die "ungesendete Nachricht" dann doch noch auf den Weg bringt. |
| WRITE_SYNC_SETTINGS | da | 2 | Synchronisierungseinstellungen schreiben. Schreibzugriff auf die Einstellungen der Synchronisation. Eine mit dieser Permission ausgestattete App kann u. a. die Synchronisation von Kontakten und Kalendern aktivieren bzw. deaktivieren. Sinn macht so etwas u. U. bei einer SMS Backup App. |
| com.android.vending.BILLING | ? | 5 | In-App Payment (in der App integrierte Bezahldienste, die über den Play Store abgewickelt werden) |
Weniger gebräuchliche sowie offensichtlich klingende Permissions (was heißt wohl BRICK? Ja, genau: Phone in Sachen Brauchbarkeit mit einem Ziegelstein vergleichbar zu machen, also unbrauchbar. Nicht lachen – diese Permission gibt es wirklich! So, jetzt lachen...) habe ich hier ausgelassen; die müssen also bei Bedarf unter eingangs genanntem Link selber nachgeschlagen werden. Oder man wirft einen Blick auf die App AllPermissions (bei AndroidPIT – aus dem Play Store wurde sie entfernt). Wie der Name bereits suggeriert, handelt es sich hier um eine dummy-App, die alle (unter Android 2.1 verfügbaren) Permissions verlangt.
Wer noch immer "Bahnhof" versteht, dem sei ein kleines Tutorial bei N-Droid.DE empfohlen. Etwas tiefgreifender wird das Thema bei LifeHacker beschrieben. Für Anfänger gut verständlich, sofern sie keine Probleme mit der englischen Sprache haben – definitiv empfohlene Lektüre!