Verfasst von:

Tipps zum Akku-Fresser "Mobilfunk-Standby" - Teil 8: Zusammenfassung

Verfasst von: Izzy — 02.10.2012

In sieben Teilen haben wir uns nun mit der Frage beschäftigt: Was ist eigentlich "Mobilfunk-Standby" und warum verbraucht es so viel Energie? Und wie kann man diesem Akku-Fresser beikommen? Hintergründe wurden beleuchtet und Wege zur Abhilfe aufgezeigt. In diesem achten und letzten Teil folgt nun eine abschließende Zusammenfassung.

Zu Allererst jedoch wieder ein Index der einzelnen Teile, auf die natürlich in der Zusammenfassung Bezug genommen wird:

Allgemeines

Die Frage danach, warum "Standby" denn so viel Energie verbrauchen würde, haben wir im ersten Teil beantwortet: Das Wort muss hier im Sinne von "Stand by while I try to improve signal quality..." ("Bitte etwas Geduld, während ich versuche, die Signal-Qualität zu verbessern") verstanden werden. Bei starkem Signal wird der Antenne recht wenig Energie zugeführt – man hat ja schließlich nichts zu verschenken. Doch wenn das Signal schlechter wird, versucht Android dies mit "mehr Leistung" zu kompensieren. Bis zu einem gewissen Grad gelingt das natürlich auch; doch wenn nichts mehr da ist, geht die "Full-Power" ins Leere.

Leider ist das System nicht inteliigent genug zu wissen, wann es aufhören (oder eine Pause einlegen) sollte. Die Folge: Der Akku wird sinnlos von Ladung befreit, ohne dass sich daraus irgend ein Nutzen ergibt. In den Details unserer Akku-Statistiken zeigt sich dies dann in Form von gelben, grauen, oder gar roten Bereichen beim Telefonsignal:

Schlechtes Telefonsignal

Nach Erlangen dieser Erkenntnis sollte der Sache auf den Grund gegangen werden: Wo bzw. wann passiert das, und was kann man dagegen unternehmen?

Tote Zonen

Diese Funklöcher (die Fast-Funklöcher mit eingeschlossen) nennt man oft "Tote Zonen", da hier "tote Hose" in Sachen Funkqualität herrscht. Um festzustellen, wo man diese denn durchquert (hat), habe ich zwei Apps kurz vorgestellt: NoSignalAlert und OpenSignalMaps. Beide warnen den Anwender auf Wunsch auf verschiedene Weise (u. a. akustisch bzw. per Vibrator) beim Betreten einer solchen "Toten Zone", sodass er zumindest über den Zustand informiert ist. OpenSignalMaps kann zudem die Richtung zum nächstgelegenen Funkmast zeigen, sollte ein wichtiger Anruf (oder Datenaustausch) anstehen.

AntennasDank Eures Feedbacks hier nun noch die Anmerkung: Wenn NoSignalAlert nicht richtig tut, könnte das u. U. an Eurem Gerät liegen (bzw. daran, dass die App mit selbigem nicht richtig klar kommt). KrasssAndro berichtete hier von Problemen mit seinem Galaxy S3: Die Warnung des Signalverlusts erfolgte bei ihm erst zusammen mit der Entwarnung, nachdem das Signal wieder da war. Mit OpenSignalMaps gab es bei ihm offensichtlich keine Probleme. Gut, wenn man Alternativen hat!

Zur Sicherheit daher an dieser Stelle noch eine weitere App: Auch Antennas (rechtes Bild) mappt den Signalpegel, und kann die erfassten Daten sogar im KML-Format ("Keyhole Markup Language", ein spezieller XML-Dialekt für Google Earth und Google Maps) exportieren – gibt aber offensichtlich keinen Alarm aus, wenn man "Tote Zonen" betritt. Das (und mehr) kann jedoch wiederum RF Signal Tracker, welches sicher auch einen Blick Wert wäre. Aber alles kann auch ich mir nicht anschauen.

Automatische Abhilfen

Nur zu logisch, dass wir nicht nur das Problem analysiert, sondern uns auch nach Lösungsmöglichkeiten umgesehen haben. Während ShutUpBatterySaver allenfalls Nutzern mit hoher Datennutzung etwas bringen dürfte, habe ich auch drei andere Apps für alle Anwender mit "Toten Zonen" vorgestellt. Diese dürften etwa vergleichbare Leistungen bringen. Leider fiel auch hier gleich der erste Kandidat mit Kompatibilitätsproblemen auf: Battery Saver wollte sich auf meinem Milestone² absolut nicht um das Funksignal kümmern – und auch David berichtete in Bezug auf das Galaxy S3 Gleiches. Vielleicht haben wir die App auch nur nicht richtig konfiguriert? Andere Nutzer berichteten durchaus von Erfolgen, wie beispielsweise Lukas mit seinem Galaxy Nexus: Seine Werte lassen vermuten, dass sich die Leistungsfähigkeit von Battery Saver durchaus mit der der beiden anderen Kandidaten messen kann – so die App denn mit dem Gerät klar kommt.

Autopilot und NoBars schlugen sich auf meinem Milestone² vergleichbar, und zeigten beide ihre kleinen Vor- und Nachteile. Während Autopilot sich viel detaillierter konfigurieren lässt (u. a. ist hier auch das Festlegen eines Schwellwertes möglich, ab dem das Funksignal als "zu schwach" einzustufen ist; WLAN lässt sich parallel mit überwachen, und auch Bluetooth- Einstellungen sowie ein "Schlafmodus" (Zeitintervall, in dem generell in den Flugzeugmodus gewechselt werden soll) sind mit an Bord), und zudem ein Protokoll anbietet, nervte hier doch das kurze Aufflackern des Bildschirms bei jeder Signalprüfung. Ein Manko, welches NoBars nicht aufwies – dafür fehlten hier dann auch die zusätzlichen Möglichkeiten. Auf das Mobilfunk-Signal bezogen, brachten beide aber etwa die gleichen Einsparungen.

Einen gemeinsamen Haken weisen allerdings alle diesbezüglichen Lösungen auf: Systembedingt ist bei Deaktivierung des Flugzeugmodus die Eingabe der SIM-PIN erforderlich, so man selbige nicht komplett deaktiviert hat. Die Ursache dafür liegt im Android Quellcode, daher ist ihr etwas schwierig beizukommen. Zwei Hersteller haben das bislang bereits erkannt, wie es scheint: So haben viele von Euch berichtet, dass zumindest einige Samsung-Geräte dafür eine Lösung an Bord haben. Auch von LG habe ich ähnliches gehört. Bleibt zu hoffen, dass diese Hersteller-spezifischen Lösungen es auch in den AOSP (Android Open Source Project) Code schaffen, auf dem letztendlich jedes ROM basiert – oder sich zumindest "die großen" Custom-ROMs wie CyanogenMod der Sache annehmen. Ich habe diesbezüglich wieder einen Preis auf mögliche, allgemeingültige Lösungen ausgesetzt – das brachte bereits beim Thema Komplettbackup ohne root unerwartete Antworten zutage.

Tasker

Natürlich führte in dieser Reihe auch kein Weg an unserer Standard-sechs-Buchstaben-Antwort vorbei: Auch Tasker musste gegen die Konkurrenz antreten. Und schlug sich hervorragend! Hier ließen sich fast alle "Spielchen" (und mehr) integrieren, welche die anderen Test-Kandidaten aufwiesen: Schwellwerte für die Signalstärke, Meldungen in der Notification-Area, separate Behandlung des Datendienstes, und auch Vibrationsalarme. Der Übersicht halber habe ich die Beispiel-Profile schmal gehalten: Für eine tatsächliche Alltags-Lösung würde ich das sicher noch umbauen und erweitern.

Und so wird es Euch wenig verwundern, dass mich auch einige Ergänzungs-Vorschläge erreichten: t0mm13b aus der StackExchange Community etwa habt Ihr die Ergänzung mit dem Roaming zu verdanken (seine Anregung: Daten nicht wieder aktivieren, wenn man im Roaming ist). Auch die Logging-Funktionalität ließe sich problemlos nachrüsten, wie mir Sebastian mitteilte, der seine Kopie des Profils entsprechend modifiziert hat:

  • Datei -> Schreibe Datei -> Log_Powersafe.txt [*] Hinzufügen: "%DATE %TIME; %CELLSIG; %BATT; %WIFI; %AIR; Text passend zum Task (alternativ %PACTIVE)"

Damit stehen sogar weit mehr Informationen zur Verfügung, als etwa im Protokoll von Autopilot. Und da es sich um eine CSV-Datei handelt, könnt Ihr diese auch mit der Tabellenkalkulation Eurer Wahl im Nachhinein grafisch aufbereiten. Mit einem der zahlreichen Office-Pakete vielleicht gar auf dem Androiden selbst?

Ein weiterer Tipp von Sebastian ist der Einbau einer Verzögerung in die Tasks SigLow und SigLost: Scheinbar kommt es gelegentlich beim Umschalten zwischen 2G und 3G zu kurzen "Aussetzern", die hier abgefangen werden sollten. Am Beispiel von SigLow könnte das folgendermaßen aussehen:

  • Task -> Wait: 5s
  • Task -> Stop IF %CELLSIG > 2

Und dann weiter wie gehabt. Bei einem "kurzen Aussetzer" von weniger als fünf Sekunden würde dann... genau nichts passieren. Aber auch wenn mann diese Wechsel-Aussetzer selbst nicht hat: Eine kurze Tunnel-Durchfahrt mit dem Auto/Fahrrad sollte damit auch abgefangen sein.

Christian stellte die berechtigte Frage, wie man das Abschalten des Datenverkehrs bei eingeschaltetem Display unterbinden kann: Wenn man gerade Online unterwegs ist, möchte man dies ja ggf. trotz schwachem Signal bleiben – dennoch aber bei vollständigem Signalverlust in den Flugzeugmodus wechseln. Als zusätzliche Bedingung lässt sich das leider nicht mehr aufnehmen, da weigert sich Tasker. Abhilfe schaffen könnte hier jedoch das Voranstellen dreier zusätzlicher Aufgaben im Task SigLow:

  • Task -> Wait 30s IF %SCREEN ~ on
  • Task -> Stop IF %SCREEN ~ on
  • Task -> Stop IF %CELLSIG "Math: Greater Than" 2

Was passiert hier? Wird das Profil aufgrund eines schwachen Signals aktiv, schaut der Task zunächst nach, ob das Display eingeschaltet ist. Falls das zutrifft, legt Tasker das Profil für 30s "schlafen" (dieses Zeitfenster könnt Ihr natürlich an Eure Bedürfnisse anpassen, es etwa gleich auf eine ganze Minute setzen), und lässt sich dann vom System wecken (dies soll einen schnellen Loop verhindern, da sich ja an den Ausgangs-Bedingungen nichts ändert). Dann prüft es nochmals, ob das Display noch an ist, und bricht in diesem Fall die Ausführung des Tasks ab. Ist das Display jedoch nun ausgeschaltet, wird sicherheitshalber noch einmal das Funksignal geprüft: Die Signalstärke könnte sich ja verbessert haben, und wenn dem so ist, wird der Task an dieser Stelle abgebrochen. Andernfalls geht es wie gewohnt weiter.

Wie Bernd richtig anmerkte, hat die hier vorgestellte Tasker-Lösung einen kleinen Haken: Wer desöfteren manuell in den Flugzeugmodus wechselt, löst damit das Profil SigLostCheck aus (das Funksignal ist schließlich weg). Folgerichtig schlägt wenig später SigReturnCheck zu, und der Flugzeugmodus deaktiviert sich wieder. Eine Teil-Lösung könnte darin bestehen, den Profilen SigLowCheck und SigLostCheck eine zusätzliche Bedingung zu verpassen:

  • State -> Network -> Airplane [x] Invert

Damit würden sie nicht auf ein schwaches bzw. verschwundenes Signal prüfen, wenn sich das Gerät ohnehin bereits im Flugzeugmodus befindet. Ein Rest vom Haken bleibt jedoch: Was, wenn man den Flugzeugmodus aktiviert, wenn das Gespann sich bereits im Profil SigLostCheck befindet? Naja, das geht dann nicht: Er ist ja bereits aktiv. Man müsste in diesem Fall also warten, bis SigLostCheck fertig ist, und dann manuell eingreifen.

Komplett lässt sich das nicht so trivial abfangen: Außer der Deaktivierung von Tasker fällt mir da keine wirklich narrensichere Patentlösung ein. Ein Work-Around könnte sein, sich eine neue Variable (z.B. %MANUAL_AIRPLANE) zu basteln, sowie einen dazu passenden Task (der sie zwischen zwei Werten wechseln lässt – sagen wir, 0 und 1: "If 0 then 1 & Flugzeugmodus an" und umgekehrt). Für diesen Task dann ein Widget auf den Desktop, mit dem in den Flugzeugmodus gewechselt werden kann – und den hier vorgestellten Profilen die Bedingung "Variable %MANUAL_AIRPLANE !~ 1" zugesellen.

Weitere Quellen

Diese Blogserie hat hiermit ihren letzten Beitrag erhalten. Aber natürlich gibt es eine Reihe von Quellen, die sich (unter anderem) auch mit dem selben Thema befassen. Zwei davon möchte ich an dieser Stelle explizit erwähnen:

Die genannte Übersicht werde ich, wie gewohnt und wie auch meine anderen Übersichten, weiterhin auf dem aktuellen Stand zu halten versuchen. Dort seid Ihr ebenfalls herzlich eingeladen, Eure Erfahrungen mit den einzelnen Apps mitzuteilen – aber auch weitere Apps zum Thema zu benennen, die Euch über den Weg gelaufen sind.

Das genannte Buch ist sicher bereits dem Einen und der Anderen von Euch bekannt. Achtung, noch ein fetter Spoiler: Im November sollte es auch auf Papier und nochmals erweitert in den Regalen der Buchläden zu finden sein, als Das inoffizielle Android Systemhandbuch aus dem Franzis Verlag. Wer also noch nach Geschenken für das Jahresendflügelfigurenundlichterbaumfest sucht...

Schlusswort

Habt Ihr mit den vorgestellten Apps Erfahrungen gemacht? Welche habt Ihr ausprobiert? Oder habt Ihr Schlingel erst auf das Fazit gewartet um zu sehen, welche der Apps sich denn nun als "besonders lohnenswert" herauskristallisiert?

Wie Ihr in diesem Blog-Post sehen könnt, greife ich Euer Feedback mit auf, und baue es in mein Fazit mit ein. Dies möchte ich auch für eventuell folgende Blog-Serien so beibehalten. Besonders wertvolle Beiträge (aus meiner Sicht natürlich *lach*) werden dann sogar namentlich erwähnt. Also ran an die Tasten, und berichtet von Euren Erfahrungen mit den vorgestellten Apps. Auch Nennungen von Alternativen sind natürlich gern gesehen, sofern sich diese dem gleichen Thema widmen (also bitte jetzt nicht alle Akku-Spar-Apps aufzählen, sondern nur die zum Thema "Telefonsignal").

Auch verschiedene andere Fragen tauchten in den Kommentaren auf. Sie hatten oftmals ebenfalls den Akku-Verbrauch zum Thema, betrafen allerdings andere Ursachen als das hier behandelte Telefonsignal. Zu diesen Themen musste ich dann leider "vertrösten", damit wir uns nicht zu weit verzetteln. Und habe dabei wohl die eine oder andere Erwartung auf weitere Blog-Reihen geweckt: Unter dem "Telefonsignal" sind in den Akku-Statistiken ja noch weitere Balken verfügbar, die als Thema für selbige herhalten könnten. Ich kann und möchte an dieser Stelle nichts versprechen, was ich später nicht halten kann. Dank Eurer regen Beteiligung hat mir diese Blog-Reihe großen Spaß gemacht, und Dank Eurer Anregungen habe ich auch gleich weiteres dazugelernt. Gern möchte ich daher weitermachen, so ich die Zeit dazu habe. Mit Recherche und Schreiben der Beiträge allein ist es dabei nicht getan: Ich sehe es auch als Pflicht des Bloggers, nach Veröffentlichung meines Beitrages Rede und Antwort zu stehen. Und anders, als manch einer das vielleicht denkt, stehe ich nicht auf der Gehaltsliste von AndroidPIT – ich mache das also in meiner Freizeit neben meiner regulären Arbeit, dem Schreiben meiner Bücher, dem Pflegen der Übersichten, etc. Daher meine Bitte um Euer Verständnis, wenn es jetzt nicht sofort weitergeht – haltet es mit Paulchen Panther: Heute ist nicht aller Tage, dies ist mein Cliffhanger, keine Frage

 

46 Kommentare

Neuen Kommentar schreiben:
  • Daniel Seifert vor 1 Monat Link zum Kommentar

    Ein toller Beitrag. So praktisch und vielseitig. Gern bitte mehr davon.

    • Izzy vor 1 Monat Link zum Kommentar

      @Daniel Ich schreibe jetzt hauptsächlich auf meiner eigenen Site: http://android.izzysoft.de/ Komme zwar viel zu wenig dazu (irgendwomit muss ich ja auch meine Brötchen verdienen) - hoffe aber, es sind dennoch hilfreiche Artikel :) Danke für das Lob!

  • Izzy 07.11.2012 Link zum Kommentar

    Noch ein Tool mal schnell nachgetragen: G-NetTrack (siehe http://www.xda-developers.com/android/put-your-network-to-the-test-with-g-nettrack/ -- gibt es aber auch im Playstore). Gehört in die Kategorie "Tote Zonen aufspüren", und führt scheinbar gut Protokoll...

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Ja, hast bzgl. der Farbbenennung schon generell Recht.

    Jetzt kommt übrigens der absolute Hammer für alle Galaxy-S3-Besitzer, die sich über ihren hohen 'Akku im Standby'-Anteil gewundert haben (wie ich; darum hab ich ja auch auch den Blog so intensiv verfolgt) und das, was da drin steht noch nicht gewusst haben (wie ich):
    http://www.xda-developers.com/android/international-galaxy-s-iii-cell-standby-power-drain-issue-identified/

    Füg ich doch gleich noch eine kurze deutsche Zusammenfassung dazu: Der Basiswert für die 'Akku im Standby'-Berechnung ist zu hoch und zwar 10 mal zu hoch !! D.h. der Anteil #Akku im Standby' ist wesentlich weniger als es lt. Grafik angezeigt wird. Mann oh Mann.
    Ich weiß nicht, wieviel Stunden da auf der Welt bei S3-Besitzern an Grübeln/Studieren/Probieren schon drauf gegangen sind. Ich bin da bestimmt mit 10 Stunden dabei.
    Andererseits hätte ich den Blog nicht gelesen und der war ja wirklich sehr informativ.

  • Izzy 07.10.2012 Link zum Kommentar

    @SuperSam: Wie bei mir. Obwohl, derzeit nicht mehr, denn ich nutze die ~20% jetzt zum Musikhören xD

    @KrasssAndro: Danke für den Link! Aber die ganzen "schmutziggelben" Farbtöne kann doch keine Socke auseinanderhalten... Ich bleibe daher bei vier Zuständen: Schwarz (Flugzeug), Rot (nix Empfang), Alles Gelbe (schlechter Empfang) und Grün (alles im grünen Bereich)...

  • PeterShow 07.10.2012 Link zum Kommentar

    Dankeschön! Bekomme damit gut 20 % mehr Akku raus..

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Hab just grad einen Link aus einem XDA Forum erhalten. Grau ist besser als Gelb. Wobei die da dort auch darüber diskutiert haben, ob das überhaupt Grau ist :-)

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Ehrlich gesagt, glaub ich das nicht so recht. Oben in deiner Grafik ist doch ca. 50% grau. Und geht normal direkt von grün nach grau über. Muss die Reihenfolge m. E. Grün Grau Gelb Rot sein. Meinst du nicht?

  • Izzy 07.10.2012 Link zum Kommentar

    Da muss ich mangels besserer Erkenntnisse auch raten. Hätte ich die Farben gewählt, wären sie von Sehr Gut bis Sehr Schlecht in obiger Reihenfolge. Die Vermutung liegt nahe, dass dem auch tatsächlich so ist.

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Aber ich nenn jetzt mal mein schmutziges Gelb Grau und das andere Gelb. Was wäre dann besser? Grau oder Gelb?

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Grau :-) Das les ich heute nicht zum ersten Mal. Ich seh in der Grafik kein Grau. Nur ein sehr schmutziges Gelb. Und dann noch ein minimal saubereres Gelb. Abgesehen von Rot und Grün.

  • Izzy 07.10.2012 Link zum Kommentar

    Keine Ahnung -- kann allenfalls sagen, wie viele ich bereits gesehen habe. Und das steht schon da: Grün + Gelb + Grau + Rot = 4.

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Und gleich noch eine Frage: Wieviel Farben gibts denn jetzt eigentlich bei Mobilfunksignal?

  • KrasssAndro 07.10.2012 Link zum Kommentar

    Hab zwar schon mein Fazit geschrieben, muss aber nich was hinzufügen, nämlich: Ist jetzt bei meinem S3 der Stromverbrauch des Bildschirms soviel besser im Verhältnis zu 'Akku im Standby' als beim S1. Oder der Mobilfunkverbrauch so viel höher. Befürchte eigentlich eher zweiteres. Hab eigentlich fast durchgehend keine schlechte Signalstärke und trotzdem ist der Mobilfunkverbrauch einfach die Nummer 1. Im negativen Sinne.

  • Izzy 07.10.2012 Link zum Kommentar

    Gut zu lesen dass es jetzt funktioniert! Bei der Frage mit der App kann ich Dir leider nicht helfen; ein Work-Around wäre ein Lesezeichen im Browser...

  • Torsten 07.10.2012 Link zum Kommentar

    Hmm, hab nix geändert aber heute erkennt er es richtig. Gestern hat er CELLSIG immer trotz starkem Empfang auf -1 (=unbekannt) gesetzt. Heute habe ich wieder kontrolliert und siehe da, es klappt. Was auch immer ihn gestern aus der Bahn geworfen hat, es war wohl nur temporär.

    Wie komme ich eigentlich später mal wieder an diese Blog-Serie? Ich lese hier immer mit der Android App. Da verschwinden die Blog ja nach ein paar Tagen. Ich würde mir da eine Lesezeichen Funktion wünschen.

  • Izzy 07.10.2012 Link zum Kommentar

    Jo. %CELLSIG groß schreiben. Andernfalls fiele mir nur der Support seitens des Entwicklers ein... Aber warum sollte das auf Deinem SGS2 anders funktionieren? Vielleicht findest Du ja noch jemanden mit gleicher Konstellation, der das zunächst einmal prüfen kann?

  • Torsten 07.10.2012 Link zum Kommentar

    So, hab die Taskerprofile jetzt mal ausprobiert. %Cellsig liefert bei mir (SGS2 mit CM9) immer den Wert -1. Daher will das ganze nicht so richtig laufen. Kann ich tasker irgendwie davon überzeugen den Wert richtig auszulesen?

  • Izzy 04.10.2012 Link zum Kommentar

    @Sascha siehe meinen vorigen Kommentar. Danke :-)

Zeige alle Kommentare