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

Android ohne Google 3: Unliebsame Apps loswerden

Staple Remover
Staple Remover; © Zoofari (PD)
Quelle: Wikimedia

Auf nahezu jedem Android-Gerät sind Apps vorinstalliert, die der Eigentümer/Anwender nicht benötigt. Dennoch tauchen sie an allen möglichen Stellen auf: Im “Teilen” Menü, im App-Drawer, auf dem Homescreen – einige sogar in der Liste laufender Apps! Das Entfernen des unliebsamen Icons vom Homescreen ist noch recht einfach zu bewerkstelligen – aber wie wird man diese Apps an den anderen Orten los? Und wie hält man sie davon ab, wertvolle System-Ressourcen zu verschwenden?

Obwohl es in dieser Artikel-Serie um “Android ohne Google” geht, betrifft das nicht ausschließlich “Google Apps”. Hersteller und Netzanbieter installieren auch einige Apps vor, teilweise nicht gerade wenige. Diese werden oft auch als Bloatware (Englisch: Bloat = Aufblähen) bezeichnet, da sie belegten Speicherplatz und RAM unnötig “aufblähen” – weit über das hinaus, was der Anwender wirklich nutzen würde. Da letzteres jedoch recht subjektiv ist, gilt das Gleiche für die Frage, welche Apps nun als “Bloatware” zu bezeichnen sind. Die Antwort auf das “Was ist” sei also dem Leser selbst überlassen – während sich dieser Artikel dem ”Wie loswerden" widmet.

Android ohne Google:

Ein “älterer” Artikel, der aber definitiv hierher gehört:

Ohne root: Deaktivieren

App Info
App Info

Auf Geräten ohne root-Zugriff sind die Möglichkeiten recht begrenzt. “Bloatware” ist üblicherweise auf der /system Partition vorinstalliert – welche im normalen Betrieb nur lesbar, aber nicht schreibbar eingebunden ist. Darüber hinaus sind die Zugriffsrechte auf die meisten Verzeichnisse beschränkt, und Hersteller/ROM-Köche können überdies Apps gegen Löschung/Deaktivierung sperren (“protected Apps”). Was bedeuted: Die folgenden Schritte lassen sich auf etliche, aber wahrscheinlich nicht auf alle Apps anwenden. Aus guten Grund kann man sich beispielsweise nicht von einigen “Kern-Apps” trennen, welche für das System essentiell sind – wobei unglücklicherweise einige Hersteller/Mobilfunkbetreiber recht seltsame Ansichten haben, was als “essentiell” zu betrachten ist.

Zusammengefasst: Ohne root lässt sich die meiste “Bloatware” nicht wirklich deinstallieren. Was man mit den meisten Exemplaren jedoch tun kann, ist sie zu deaktivieren. Und das wollen wir uns nun einmal anschauen:

Ausgehend vom Homescreen, öffnen wir dafür die Systemeinstellungen, und navigieren zu Apps verwalten (der Punkt ist abhängig von Hersteller und Android-Version u. U. leicht anders benannt). Dieser öffnet üblicherweise eine Liste aller Apps, die der Anwender selbst installiert hat. Da uns jedoch die vorinstallierten (System-) Apps interessieren, muss ggf. der Reiter “Alle” ausgewählt werden (der Name kann wiederum leicht abweichen). Jetzt gilt es, die unerwünschte App in der Liste ausfindig zu machen, und ihren Eintrag zu öffnen – was zu einer Ansicht ähnlich der im rechten Screenshot führen sollte.

Der Button oben rechts (im Screenshot: “Disable”) kann unterschiedlich beschriftet sein:

Sollte eine der “Drück-den-Button-Aktionen” sich nicht ausführen lassen, helfen oftmals die anderen Buttons: “Beenden erzwingen”, dann “Cache leeren”, und schließlich “Daten löschen”. Meist erscheint dann der ausgegraute “Deaktivieren”-Button in “neuem Licht”.

Einmal deaktiviert, ist die App nicht vollständig verschwunden. Man kann sie jederzeit wieder “Aktivieren” (was dann auch die Updates erneut anstößt) – auf die gleiche Weise, wie soeben beschrieben1. Auch lassen sich deaktivierte Apps noch immer über ihre Intents ansprechen2.

Mit root: Einfrieren

Einfrieren (“Freeze”) ist prinzipiell das Gleiche wie Deaktivieren – nur dass “root Powers” dies auch für “geschützte Apps” ermöglichen. Für die Durchführung gibt es mehrere Möglichkeiten, von denen ich zwei herausgreifen möchte:

Einfrieren mit Titanium Backup

Tibu Freeze
Titanium Backup: Freeze!

Titanium Backup ist eines der mächtigsten root-Tools – eine App, die selbst ich als “essentiell” bezeichnen würde.3 Wie der Name suggeriert, ist dessen Hauptaufgabe das Erstellen (und Wiederherstellen) von Backups, einschließlich dessen von Apps mit ihren Daten sowie System-Einstellungen. Darüber hinaus enthält die App jedoch auch eine Reihe von System-Tools, etwa zur Bereinigung des Dalvik-Cache4 oder – dem “Einfrieren” von Apps. Selbst wenn man erwägt, eine App komplett zu entfernen (was TiBu ebenfalls beherrscht), ist es äußerst ratsam, sie zunächst “einzufrieren” (sowie in einem zweiten Schritt optional auch sämtliche ihrer Broadcast-Receiver zu deaktivieren), um potentielle Abhängigkeiten aufzuspüren: wurde eine essentielle App entfernt, kann dies ernsthafte Probleme bedeuten (im schlimmsten Fall kann das System den Boot-Prozess nicht mehr erfolgreich beenden). Wurde sie jedoch lediglich deaktiviert/eingefroren, gibt es meist relativ einfache Möglichkeiten, diesen Schritt rückgängig zu machen (siehe unten).

Um nun eine App mit Hilfe von Titanium Backup einzufrieren, startet man TiBu zunächst (achwas!), und wechselt sodann auf den Reiter “Backup/Restore”. In der dort angezeigten Liste sucht man nun die betreffende App. Um die Suche insbesondere bei einer Vielzahl installierter Anwendungen zu vereinfachen, lässt sich die Liste nach diversen Kriterien sortieren (beispielsweise alphabetisch), oder mit Filtern (etwa “nur System-Apps, welche noch nicht eingefroren sind”) einschränken. Ist die fragliche App gefunden, fördert ein Antippen ihres Eintrags ein Menü wie das rechts abgebildete zutage, welches verfügbare Operationen anzeigt. Einfach den “Freeze!” Button antippen – und wenige Sekunden später sollte sich selbiger in “Defrost” umbenennen (womit sich die Aktion rückgängig machen ließe). Fertig.

Einfrieren an der Kommandozeile

Unter Android kümmert sich der PackageManager um die meisten Dinge, die “Packages” (d. h. “Apps aus System-Sicht”) betreffen. Dazu verwaltet es (vereinfacht gesagt) einen Katalog installierter Apps und deren “Properties” (Eigenschaften) – wie etwa Permissions, Features (z. B. ob sie Kamera-Funktionen unterstützt), Signatures (Wer hat das Package signiert?) – und ihren Zustand. Seine Schnittstellen lassen sich nutzen, um ausgewählte “Properties” auszulesen, zu verändern, oder gar eine App zu installieren/deinstallieren. Da hierfür auch ein Kommandozeilen-Tool namens pm bereitgestellt wird, können wir dies für unsere Zwecke einspannen5 – entweder via ADB, oder unter Zuhilfenahme einer Terminal-App.

Im ersten Schritt gilt es, den Paketnamen der App zu ermitteln. Der einfachste Weg dazu ist es, die zugehörige Seite im Playstore aufzusuchen – und sich die URL genauer anzuschauen. Im Falle von Titanium Backup wäre dies etwa https://play.google.com/store/apps/details?id=com.keramidas.TitaniumBackup. Die id bezeichnet hier den gesuchten Paketnamen – also com.keramidas.TitaniumBackup.

Für die weiteren Schritte gehe ich davon aus, dass wir uns bereits an der Kommandozeile befinden (entweder in einer Terminal-App, oder via adb shell) – sowie (optional) Super-User-Rechte erlangt haben (ohne selbige können wir beispielsweise keine geschützten bzw. System-Apps behandeln). Bleiben wir nun bei unserem Beispiel mit Titanium Backup:

# Prüfen wir zunächst, ob TiBu aktiviert (“enabled”) ist. Der folgende Befehl liefert dann den Paketnamen zurück:
$ pm list packages -e | grep TitaniumBackup
package:com.keramidas.TitaniumBackup
# Es ist also aktiviert. Deaktivieren wir es doch einfach:
$ pm disable com.keramidas.TitaniumBackup
Package com.keramidas.TitaniumBackup new state: disabled
# Gegenprüfung:
$ pm list packages -d | grep TitaniumBackup
package:com.keramidas.TitaniumBackup
# Prima. War aber nicht ganz ernst gemeint, wir brauchen TiBu doch noch:
$ pm enable com.keramidas.TitaniumBackup
Package com.keramidas.TitaniumBackup new state: enabled

Mir fallen da sogleich einige andere Situationen ein, in denen diese Befehle sich als nützlich erweisen könnten:

Im Laufe der Zeit hat man einige Apps auf verschiedene Weise deaktiviert – und plötzlich ist ein Factory-Reset angesagt. Um sich anschließend nicht wieder alles mühsam zusammensuchen zu müssen, machen wir uns einfach obiges zunutze, und lassen dabei einfach den grep-Teil weg – womit wir eine vollständige Liste aller Apps im jeweiligen Status erhalten. Vor dem Reset also ein pm list packages -d >/sdcard/disabled.list, und die erzeugte Datei entsprechend bearbeiten (sodass jede Zeile dem Muster pm disable <package_name> entspricht). Nach dem Reset deaktivieren wir das ganze Rudel nun auf einen Schlag: sh /sdcard/disabled.list.

Eine andere Situation: Da hat man doch dummerweise die einzige installierte Keyboard-App (besser noch: Den Homescreen) deaktiviert! Kein Problem: adb shell und der Befehl pm enable <Paketname> haben das Ruck-Zuck behoben :)

Mit root: Broadcast-Listener deaktivieren

ROM Toolbox - Listener
ROM Toolbox: Broadcast Listeners

Ich habe sie ja bereits weiter oben erwähnt: Broadcast-Listener. Android sendet bei verschiedensten Ereignissen “Broadcasts” (Englisch: Rundrufe/Rundfunk), wie beispielsweise “Boot abgeschlossen”, “Niedriger Akku-Stand”, “Package installiert”, “Netwerk-Status geändert”, “SDCard eingebunden”, und viele mehr. Apps können “Listener” (Empfänger) für diese Broadcasts registrieren, um benachrichtigt zu werden, wann immer etwas “für sie relevantes” passiert. Ein gutes Beispiel wäre hier der “Medien-Scanner”, der z. B. informiert werden möchte, wenn eine SD-Karte eingebunden wird – um dann zu prüfen, ob sich darauf neue Fotos, Videos, oder Musik-Dateien befinden, welche er in seiner internen Datenbank eintragen sollte.6 Während dieses Beispiel absolut Sinn macht, und es wohl kaum jemand deaktivieren möchte – kann das in anderen Fällen ganz anders aussehen. Einige Apps nutzen dieses Prinzip nämlich wirklich ein wenig extensiv – besonders, wenn man selbige (so gut wie) nie verwendet. Außerdem scheint es, dass sogar deaktivierte Apps auf diese Art gestartet werden: auf meinem LG Optimus 4X HD habe ich beispielsweise die LG Remote Care App7 eingefroren. Dennoch taucht nach jedem Boot deren “Willkommens-Popup” auf.

Es gibt eine ganze Reihe Apps, die sich darum zu kümmern versprechen. In der Vergangenheit habe ich Autorun Manager PRO dafür eingesetzt, und war mit der App sehr zufrieden. Mittlerweile verwende ich jedoch ROM Toolbox Pro für verschiedene andere Dinge, und diese App kann sich auch um die “Listener” kümmern (siehe Screenshot rechts) – also bin ich zur Verwaltung der “Autostart-Rampen” ebenfalls auf sie umgestiegen (warum auch sollte ich eine zusätzliche App nutzen).

Ein Blick auf den gerade genannten Screenshot mag einen leichten Schock auslösen, wie viele Listeners manche Apps registrieren8. Mir sind da einige untergekommen, bei denen es 50 oder mehr waren! ROM Toolbox zeigt auf Wunsch einige Details dazu (das blaue ⓘ Icon neben jedem Eintrag deutet es bereits an). Tippt man einen Eintrag an, werden die einzelnen registrierten Listener aufgeführt9; jeder davon kann separat “unregistriert” werden. Welche davon gefahrlos deaktiviert werden können, lässt sich entweder am Namen “erraten” – oder durch “Ausprobieren” herausfinden. Sollten bestimmte Funktionalitäten danach nicht mehr richtig gewährleistet sein, aktiviert man die Listener einfach wieder.

Nebenbei: Wird die “verwaltende App” deinstalliert, verbleiben die Listener (in den meisten Fällen) im zuletzt konfigurierten Status – was man also besser vor der Deinstallation prüft. Hat man dies vergessen, hilft die Neuinstallation des “Managers” in der Regel nicht (dessen Datenbanken sind ja auch mit “deinstalliert” worden) – wohl aber die Neuinstallation (oder das Update) der betroffenen App.

Mit root: Löschen

Bevor man zu diesem Schritt schreitet (oops), sollte man sichergestellt haben, dass:

(!) Die De-Installation/Löschung einer (System-) App ist ein Schritt, der sich nicht “einfach umkehren” lässt: Weg ist weg, und ohne Backup gibt es oft keinen Weg zurück. Ich habe viele Fälle gesehen, in denen die Anwender mit einem (teilweise) unbrauchbaren Gerät zurückblieben, weil sie obige Schritte “vergessen” hatten. Bezüglich der Betätigung der “Ja-ich-Will” Box sollte man langsam und vorsichtig sein, lieber drei Mal genau überlegen – auch hier liefen mir bereits genügend Fälle über den Weg, in denen jemand “versehentlich die falsche App gelöscht” hatte. Ebenfalls ein wichtiger Fakt: Nicht einmal ein Factory-Reset bringt gelöschte Apps zurück. Was man in der /system Partition “kaputt gemacht” hat, bleibt kaputt – es sei denn, man hat das notwendige Reparatur-Werkzeug und -Material zur Hand. I’ve warned you! (!)

Einige Werkzeuge zur Durchführung dieser Aufgabe habe ich ja bereits genannt: Titanium Backup und ROM Toolbox Pro sind zwei davon, weitere Kandidaten finden sich in dieser App-Liste. Alles Weitere wurde ja bereits oben erklärt :)

appshowto


  1. Bei einigen Android-Versionen werden deaktivierte Apps ans Ende der Liste verschoben. Findet sich eine App also nicht in der “alphabetischen Reihenfolge”, einfach nach ganz unten scrollen, und dort nachschauen. ↩︎

  2. “Intents” und “Broadcasts” sind Bestandteil von Androids Inter-Prozess-Kommunikation. Die Begrifflichkeiten sind u. a. in diesem Artikel bei Stack Exchange (EN) gut erklärt. ↩︎

  3. Ich kann den Kauf von Titanium Backup Pro wirklich nur empfehlen, da sich damit der volle Funktionsumfang der App nutzen lässt! Dies war eine der ersten Android-Apps, die ich erworben habe – und ich habe es bis heute nicht bereut. ↩︎

  4. Im “Dalvik Cache” wird der optimierte Byte-Code von Apps für Androids Dalvik VM abgelegt, dessen Dateinamen üblicherweise auf .odex (Optimized Dalvik EXexutable) enden. Werden häufiger Apps installiert und deinstalliert, kann dieser Cache “fragmentieren” (manchmal bleiben auch .odex Dateien von längst deinstallierten Apps zurück). Titanium Backup kann hier für ein wenig Ordnung sorgen, was in einem rascher reagierenden System resultiert – auch wenn das nicht immer “subjektiv spürbar” ist. Nicht selten behebt diese Säuberung auch “unerklärliche Phänomene” ;) ↩︎

  5. wie beispielsweise in einem Artikel bei Stack Exchange erklärt ↩︎

  6. Viele Apps greifen auf diese Informationen zurück, um bei ihrem Aufruf nicht erst sämtliche Medien selbst scannen (oder eine eigene Datenbank pflegen) zu müssen – etwa die Galerie, oder diverse Musik-Apps. ↩︎

  7. eine App, die dem LG Support den Remote-Zugriff auf das Gerät ermöglichen soll – offiziell natürlich nur mit Zustimmung des Anwenders, wenn dieser die Hotline angerufen hat und selbige es für sinnvoll erachtet. Dummerweise handelt es sich hier um regelrechte “Mafia-ware” – sie fordert bereits nach Start des Gerätes zur Zustimmung auf – bietet aber nur die Buttons “Ja” und “Später” an, jedoch keine Möglichkeit zur Ablehnung. “Später” bedeutet dann, dass das Popup alle 30 Minuten auftaucht… bis der Nutzer schließlich entnervt aufgibt. Oder die App “einfriert”  :D ↩︎

  8. Hey, das ist die Facebook-App – was soll man da anderes erwarten? Facebook möchte schließlich auch wissen, wann der User gepupst hat – nur dass es dafür (noch?) keinen Broadcast-Event gibt  :D ↩︎

  9. Wie man sehen kann, lassen sich für einen Listener mehrere Intents registrieren. ↩︎

2014-08-14