Mastodon IzzyOnDroid


Say thanks!
↓ Your product here? ↓
Das Inoffizielle Android-HandbuchAndroid kennenlernen, Tipps & TricksDas Inoffizielle Android-Handbuch
Android kennenlernen, Tipps & Tricks
Für EUR 16,99 bei Amazon kaufen
Das Inoffizielle Android SystemhandbuchTiefer ins System einsteigenDas Inoffizielle Android Systemhandbuch
Tiefer ins System einsteigen
Für EUR 7,00 bei Amazon kaufen
Die besten Android-AppsDen Androiden austattenDie besten Android-Apps
Den Androiden austatten
Für EUR 5,00 bei Amazon kaufen
 
enhelp

Die Krux mit den Updates

OTA updates
OTA updates; © Johan Larsson (CC-BY)
Quelle: Flickr

Updates bringen nicht nur neue Funktionalität, sondern beheben oftmals Probleme. Oder stopfen gar Sicherheits-Löcher. Daher ist es in der Regel eine gute Idee dafür zu sorgen, dass Apps und System möglichst aktuell sind.

Leider klingt das oft einfacher, als es sich in der Praxis darstellt: Ist wirklich jedes Update ein “gutes Update”? Sollte man ab und an eine Version besser überspringen – oder gar eine App dauerhaft auf der gerade installierten Version belassen? Wo kommen Updates her, und wie bekommt man sie auf seinen “Androiden”? Welche anderen Fragen stellen sich zum Thema? Ich hoffe, mit diesem Artikel ein wenig Licht ins Dunkel zu bringen.

Updates für Apps

Für Apps, die man über eine der “etablierten Market-Apps”1 installiert hat, beantwortet sich die Frage nach dem “Woher?” recht einfach: Hier tragen i. d. R. die Market-Apps selbst Sorge dafür, den Anwender über Updates zu informieren, und ihm deren Installation zu ermöglichen. Informationen über verfügbare Updates beziehen sie dabei auf ganz unterschiedliche Weise – jeweils speziell auf die dahinter stehenden Strukturen zugeschnitten. Zwei Beispiele:

Beide Varianten haben ihre Vor- und Nachteile: Während im Falle von Google Play nur die wirklich relevanten Informationen übertragen werden (und dies möglichst zeitnah zu ihrer Verfügbarkeit), sind im Falle von F-Droid (und ebenso Aptoide) alle Informationen offline verfügbar, und lassen sich somit auch ohne eine bestehende Internet-Verbindung durchsuchen2.

Permission Info
Permission-Info bei Google Play:
Was genau will diese App?

Aus Sicht von Sicherheit und Privatsphäre bringt Google Play dabei ein Handicap mit: Seit Juni 2014 hat man dort die Darstellung der von Apps angeforderten Berechtigungen “vereinfacht” (siehe Bild rechts). Es wird nicht mehr jede Berechtigung separat angezeigt, sondern nur noch auf die zugehörige Gruppe verwiesen. Dabei macht es sicherlich einen Unterschied, ob eine App lediglich die Liste laufender Apps (“which apps are running”) einsehen möchte, oder gleich Zugriff auf Browserverlauf und Lesezeichen erhält (“browsing history and bookmarks”)! Erschwerend kommt hinzu: Fordert eine App bei einem Update lediglich weitere Berechtigungen aus “bereits zugeteilten Gruppen” an, wird darauf gar nicht mehr hingewiesen (im Beispiel könnte sie somit zur ursprünglich angeforderten “Liste laufender Apps” klammheimlich den Zugriff “Browserverlauf und Lesezeichen” nachrüsten – ohne dass der Anwender davon informiert wird).

Dagegen hilft nur, automatische Updates vollständig abzuschalten, und bei anstehenden Aktualisierungen mühsam die gesamte Liste der geforderten Permissions mit dem Bestand abzugleichen.3 Was sicher kaum ein Anwender tun wird. Ganz davon abgesehen, dass es zumindest auf den kleinen Bildschirmen von Smartphones kaum möglich sein dürfte, beide Listen parallel zu betrachten. Man muss also auf dem Smartphone die bestehenden Berechtigungen über die App-Details4, und parallel die “aktuellen” im Web-Browser aufrufen – um dann alles einzeln durchzugehen. Besonders bei Apps mit vielen Berechtigungen ist dies recht mühselig. “Vereinfacht” wurde somit lediglich das “Untermogeln” zusätzlicher Permissions.

Updates für Services

“Services” sind irgendwo zwischen Apps und “dem System” angesiedelt. Google lagert in letzter Zeit immer mehr Betriebssystem-Funktionalität in die Google Play Services aus. Da es sich bei letzteren um Apps handelt, die über den Google Play Store verfügbar sind, werden diese auch wie oben beschrieben automatisch aktualisiert (i. d. R. auch dann, wenn “automatische Updates” abgeschaltet sind). In diesem Fall braucht der Anwender sich also um nichts gesondertes zu kümmern – er kann es auch gar nicht. Der große Vorteil dieser “Umverlagerung” ist, dass Updates wesentlich schneller beim Anwender ankommen – da der Umweg über Gerätehersteller und Provider (siehe OS Updates) entfällt.

Dennoch finden sich auch hier wieder Fallstricke. Der erste wäre, dass auf diese Weise immer mehr Open Source Komponenten in proprietären Code überführt werden.5 Dadurch werden Entwickler und Anwender stärker an Google gebunden: Für die Bereitstellung der Google Play Services auf einem Android Gerät müssen nämlich gewisse Bedingungen erfüllt sein – weshalb sie beispielsweise nicht von Haus aus in Custom ROMs6 integriert sind. Greift daher eine App für essentielle Funktionen auf derartige Schnittstellen zu, ist sie auf Geräten ohne dieses “Framework” nicht nutzbar, und nur mit großem Aufwand nutzbar zu machen. Je mehr Betriebssystem-Funktionalität auf diese Art ausgelagert wird, desto mehr zementiert sich diese Bindung – und desto mehr Apps sind “automatisch betroffen”. Aus Sicht der Privatsphäre wird es dann besonders kritisch, wenn in diesen “Diensten” Werbemodule fest verankert werden, wie es laut Auskunft eines Entwicklers für die Google Maps API der Fall zu sein scheint: Auch wenn man in der Kaufversion einer solchen App keine Werbung mehr zu Gesicht bekommt, wer garantiert, dass hier keine persönlichen Daten zur Profilerstellung gesammelt werden? Als fester Bestandteil der App hat das Modul schließlich vollen Zugriff auf alles, was auch der App zur Verfügung steht.

Desweiteren gibt es Geräte, die ausschließlich für den produktiven Einsatz gedacht sind. Auf diesen sind zusätzliche Dienste wie beispielsweise “Games Services” nicht nur überflüssig, sondern u. U. hinderlich (zusätzlicher Ressourcen-Verbrauch, kürzere Akku-Laufzeiten), oder gar ein “unnötiges Sicherheits-Risiko” (was nicht installiert ist, kann auch keine Sicherheitslücken mitbringen). Unter diesen Gesichtspunkten wäre es begrüßenswert, wenn Google dem Anwender zumindest die Wahl lassen würde. Die ganzen “Google Services” könnten modularer aufgebaut (das Xposed Framework macht es vor), und die “gewünschten Dienste” von der zentralen “Google Settings” App aus verwaltet werden: Was man nicht will, entfernt man hier – zusätzliche (optionale) Dienste ließen sich aus selbiger “Zentrale” heraus bei Bedarf installieren.

Updates für das Android OS

ClockworkMod
Update von der SD-Karte einspielen
(Quelle: AddictiveTips)

Hier wird es leider etwas komplexer, wie ein Heise Artikel im Detail beschreibt: Android System-Updates haben einen langen Weg. Da jeder Hersteller in seinen Geräten andere Hardware verbaut (deren Spezifikationen nicht immer offengelegt sind), kann man nicht einfach ein AOSP7 ROM nehmen und auf beliebige Geräte installieren. Zuerst einmal müssen die passenden Treiber integriert werden – was Aufgabe des jeweiligen Herstellers ist. Liefert Letztgenannter seine Geräte mit einer eigenen, angepassten Oberfläche aus8, muss auch diese zunächst aktualisiert und getestet werden. Hat man sein Gerät zu besonderen Konditionen über seinen Netzanbieter bezogen, kommt nun auch noch selbiger ins Spiel: Diese Geräte sind fast immer mit einem Branding9 versehen, welches bei einer neuen Android-Version ebenfalls einer Aktualisierung bedarf. Und so dauert es vom Erscheinen einer neuen Android Version bis zum Eintreffen derselben auf dem Gerät des Anwenders durchaus mehrere Monate, oder teilweise sogar über ein Jahr – wenn sie denn überhaupt dort ankommt. Nicht selten entscheidet nämlich ein Glied in dieser Kette, das betroffene Gerät nicht länger unterstützen zu wollen.

Doch selbst wenn diese Hürden genommen sind, und eine neue Android-Version für unser Gerät zur Verfügung steht: Wie kommt sie auf selbiges? Nicht immer geht es so einfach, wie das Bild zur Linken suggeriert. Natürlich gibt es OTA-Updates10 – zumindest ist in Foren die Rede davon, und auch Screenshots wie das Teaser-Bild dieses Artikels scheinen das zu belegen. Jedoch habe ich auf keinem meiner Geräte je eines gesehen: Mein LG Optimus 4X läuft beispielsweise noch immer mit Android 4.0.3, obwohl offiziell ein JellyBean Update verfügbar ist. Hier kocht nämlich leider wieder jeder Hersteller sein eigenes Süppchen: Während “kleinere Updates” (etwa von Android 4.0.3 auf 4.0.4) häufig noch per OTA verfügbar gemacht werden, müssen “größere Sprünge” (z. B. von 4.0.4 auf 4.1.2) häufig mit der herstellerspezifischen Saftware installiert werden – die dann oft nur für Windows verfügbar ist11:

Es gibt jedoch auch Hersteller, die es anders handhaben12 – und ein Update ganz normal direkt auf dem Android-Gerät ermöglichen. Wie im Bild dargestellt, wird sich für diese Aktion des “Recovery Modus” bedient: Man lädt das Update (beispielsweise mit dem Web-Browser auf dem Gerät selbst) herunter, speichert es auf der SD-Karte, und bootet in den “Recovery-Modus”. Von dort wählt man aus, das Update von der Karte installieren zu wollen. So sollte es sein, und so funktioniert es zumindest auf meinen Tablets von Cat-Sound. Ein Kollege von mir bekam sogar gerade sein Update auf Kitkat per OTA – für ein Huawei P6, was durchaus nicht das “aktuellste Gerät” der Chinesen ist.

Um diesem “Gefängnis” zu entkommen, bleibt dem Anwender oft nur ein Weg: Das Gerät rooten13, gegebenenfalls den Bootloader entsperren14, mit einem Custom-Recovery versehen, und ein Custom-ROM installieren. Je nach Popularität des Gerätes, stehen dafür teilweise eine Reihe von Alternativen zur Verfügung.

Fazit

Wer ohnehin immer mit dem Strom schwimmt, sich um seine Privatsphäre keine Gedanken macht, und für ein wenig Komfort auf alles andere pfeift: Der greife zu einem Google Nexus Gerät, lasse die “automatischen Updates” für Apps aktiviert, und freue sich über zügige Android-Updates. Für alle anderen ist ein wenig Bastelarbeit gefragt, um die Klippen zu umschiffen. Hilfe dazu findet sich u. a. bei Stack Exchange, aber auch in einschlägigen Foren.

appsprivacysecurity


  1. Einige “App-Märkte” habe ich im Artikel Android Markets: Wie sicher sind alternative Quellen? vorgestellt ↩︎

  2. Apps bzw. deren Updates lassen sich dabei auch zur späteren Installation vormerken – für die dann natürlich eine Netzverbindung nötig ist ↩︎

  3. Siehe auch Stack Exchange: Is there a way to know the actual permissions of an app now before installing? ↩︎

  4. Einstellungen→Apps, zur App scrollen, Details öffnen ↩︎

  5. Siehe auch Google’s iron grip on Android: Controlling open source by any means necessary, wo das bittere Fazit gezogen wird: Android is open—except for all the good parts ↩︎

  6. Custom ROM: eine alternative Betriebssystem-Version, die als solche nicht vom Hersteller ausgeliefert, sondern von Dritten bereitgestellt wird. Siehe auch Wikipedia ↩︎

  7. AOSP steht für das Android Open Source Project, welches sich um die Kernkomponenten des Android-Systems kümmert. AOSP ROMs laufen i. d. R. problemlos auf Nexus-Geräten. Fast alle für Android verfügbaren Custom ROMs bauen darauf auf – direkt, oder indirekt. ↩︎

  8. Das trifft auf eine ganze Reihe von Herstellern zu – beispielsweise Samsung mit Touchwiz, HTC mit Sense, und bis vor kurzem auch Motorola mit Motoblur ↩︎

  9. Branding bezeichnet hier die Vorinstallation spezifischer Apps sowie i. d. R. spezieller Boot-Animationen; siehe auch Debranding ↩︎

  10. Bei einem OTA-Update werden Software-Updates des Herstellers/Providers über das Mobilfunk-Netz (oder auch per WLAN) direkt auf das Gerät gebracht. Die Rede ist hier auch oft von "FOTA", "Firmware Over The Air". ↩︎

  11. Unverständlich, dass man für ein (auf Linux basierendes) Android-Gerät eine Windows-Lizenz benötigt. Da darauf vor dem Kauf nicht explizit hingewiesen wird, dürfte das sicher ein legitimer Rückgabe-Grund sein. Dass laut Gartner Tablets langfristig den Computer ablösen, erscheint vor diesem Hintergrund unwahrscheinlich. ↩︎

  12. Hier freue ich mich auf Rückmeldung meiner Leser, wie das für ihren Hersteller aussieht. Gern verarbeite ich das dann zu einer Übersicht! ↩︎

  13. Mittels “root” erlangt man System-Zugang zum Gerät – vergleichbar mit dem “Administrator” Account unter Windows, oder dem “root” account unter Linux/Unix. Hilfestellung dazu findet man beispielsweise bei Stack Exchange, sowie in den einschlägigen Foren. ↩︎

  14. Als Sicherheitsmaßnahme gegen die Installation “unautorisierter” System-Software, ist bei nahezu allen Android-Geräten der Bootloader gesperrt – vereinfacht gesagt, lassen sich somit nur System-Updates einspielen, die auch vom Hersteller “abgesegnet” sind. Hilfe zum Thema findet sich auch hier wieder bei Stack Exchange↩︎

2014-07-20