Android OS - Problem unter JVB/JVH

  • 262 Antworten
  • Letztes Antwortdatum
reichenwoerm schrieb:
wie kann das denn sein?
Keine Ahnung. Aber viel wichtiger ist die Frage: Was hat das in diesem Thread zu suchen?
 
bei mir hat der bug heute zum 3. mal zu geschlagen. das beste:

heute morgen dachte ich noch: "ey ganz schön lange her dass ich diesen bug hatte..." heute in der mittagspause habe ich mal aufs handy geschaut: kaum noch akku - grund: android os hat 25 % akkuverbrauch. schätze mal, dass das letzte mal dass sich der bug bemerkt gemacht hat, ist ca. 1 monat her.

ich vermute, das sgs kann gedanken lesen und will einen hin und wieder mal ärgern :scared:
 
mit 25% is der bei dir ja eh noch relativ niedrig, hatte beizeiten werte zwischen 60-75% (!), da war der akku binnen zwei stunden von 90% auf knapp über null.

mittlerweile hab ich im verdacht dass der bug einfach willkürlich auftritt, meist wenn so zwischen 5 und 10 ladezyklen durch sind. (also ohne das sgs zwischenzeitlich auszuschalten)
ab da tritt er bei mir wieder auf.
dann brauchts zwei, drei reboots und es geht wieder. trotzdem nervig.

LG
 
Ich habe seit Wochen keine Android OS Probleme mehr. Liegt bei nur 2%. Ich habe immer Autorotation aus.
 
Beir mir ist jetzt auch der/ein(?) Android OS Bug aufgetreten. Nach den Logs hat es die Nacht über vermutlich neu gestartet - eine PIN eingabe war aber nicht nötig. In den logs konnte ich zumindest nichts mit uart_clk finden.
top hat mir (aber auch nach einem bewußten Neustart) eine CPU-Auslastung des "system_server" von 25% bis 50% an.

PDA: XWJVI
PHONE: XXJVO
CSC: DBTJV2
Das gerät ist nicht gerootet. Kann man noch weitere Infos zum bei mir aktiven Bug gewinnen? Im Moment hängt das Galaxy S noch am USB-Debugging und lädt fröhlich.
 
Ich bin mir jetzt sicher, dass es "den" Android OS Bug nicht gibt und noch nie gab.

Ich hab jetzt auch ein SGS2 und kann deshalb gut vergleichen. Auf dem SGS2 ist die Problematik mit der hohen Verbrauchsanzeige bei Android OS noch viel schärfer. Wenn man die Sache näher analysiert, stellt man fest, dass Android OS nicht ein Verbraucher ist, sondern mehrere Verbrauchesquellen vereint. Beim SGS2 gehört z.B. WLAN dazu, das dort nicht gesondert aufgeführt wird (und dort einen Großteil vom Android OS Verbrauch ausmacht).

Ebenfalls vom SGS2 weiß ich, dass man über die Kernelkonfiguration Einfluss auf die Anzeige hat. Der Speedmod Kernel auf dem SGS2 z.B. zeigt überhaupt kein Android OS mehr in der Liste an. Supercurio hat alle "Android OS Verbraucher" anderswo untergebracht. Die Akku-Laufzeit wird dadurch zwar nicht besser, aber die Anzeige nervt nicht mehr. Man muss dazu sagen, dass die Akkulaufzeit auf dem SGS2 trotz hoher Android OS Anzeige nicht schlecht ist. Es verbraucht bei vergleichbarer Konfiguration nur unwesentlich mehr, als mein SGS. Und im SGS steckt der starke Momax Akku.

Vergegenwärtigen wir uns jetzt noch mal die Schilderungen über den Android OS Bug:
- Bei einigen Tritt er durch Spiele auf
- Bei anderen durch GPS Nutzung
- Beim dritten durch den SNS Service
- Beim vierten ist es die automatische Ausrichtung
- Der fünfte kann die Ursache gar nicht ausmachen
- usw.
Das alles deutet doch sehr darauf hin, dass hier verschiedene Probleme zuschlagen, die zufällig alle die Android OS Anzeige nach oben treiben.

Was sagt uns das jetzt? Es reicht nicht, zu sagen, "Ich hab den Android OS Bug". Wenn plötzlich der Energieverbrauch ungewöhnlich stark ansteigt, muss man mit weiteren Tools näher hinsehen, was genau die Ursache ist, z.B. mit dem "System Panel", "Better Battery Stats" oder "Where is my Droid Power". Mit etwas Glück findet man dann tatsächlich die richtige Ursache.
 
glaube die lösung gefunden zu haben, zumindest bei mir hats funktioniert und Fleckdalm hat das bestätigt:

aOS-Bug is weg nach formatierung der sd-karten im laufenden betrieb. bei fleckdalm hats gereicht die interne zu formatieren, ich hab gleich die externe auch noch gekillt.

das war vor gut einer woche, seitdem is der bug weg.
davor is er bei mir fast jeden tag, zumindest aber jeden 2., aufgetreten und hat mir den akku leer gesaugt.
jetzt is ruhe.


LG Hermz
 
Ich wollte auch mal was dazu sagen,

Klar gibt es tager da ist das mal mehr und mal weniger os verbrauch, aber er war noch nie über 5% bei mir. ich habe die letzte woche nix neues installiert und auch nichts anderes gemacht als sonnst. Heute nach dem ich das handy auf arbeit weggesteckt hatte und nach 9 std standbay wieder raus holte war das android os mit 54% dabei und akku war bei 10 %. Normalerweise ist nach der arbeit das os bei 3-5 % und der akku bei guten 85 %. Daher das war absolut NICHT normal. habe alle laufenden przesse kontroliert, aber keiner der neutarte oder ungewöhnlich hohen verbrauch hatte. Habe jetzt ein paar mal neu gestartet und hoffe das Morgen alles wieder normal ist. Daher kann ich nur sagen ES GIBT "DEN" BUG! Die frage ist immernoch wo kommt er her und wie kann man dagegen steuern? Ich hoffe natürlich das er irgendwann der vergangenheit angehört!

Gruss Jobbe
 
JobbeDeluxe schrieb:
Daher kann ich nur sagen ES GIBT "DEN" BUG!
So? Dann kannst du ja sicher sagen, welche der vielen Bestandteile von Android OS für das Problem verantwortlich ist.
 
Ich kann nicht sagen was dafür verantwortlich ist, ich kann nur sagen das bei selber Benutzung es zu einem "Fehler" kommen kann welcher den akku verbrauch erheblich steigert. daher kann ich sagen das das nicht normal ist. Ich bin schließlich Benutzer und nicht Programmierer. aber wenn du mit deinem Auto mit einer Tankfüllung 600 km weit kommst und bei der nächsten auf einmal nur 100 km dann würdest du doch auch sagen das da was nicht stimmt oder? Und weist du deshalb was es ist? nein, du fährst auch in die Werkstatt. eine Toleranz gibt es immer klar, aber kein von 80 % leistungs Verlust.

Gruss jobbe
 
JobbeDeluxe schrieb:
Ich kann nicht sagen was dafür verantwortlich ist, ich kann nur sagen das bei selber Benutzung es zu einem "Fehler" kommen kann welcher den akku verbrauch erheblich steigert. daher kann ich sagen das das nicht normal ist.
Ja eben, genau das sag ich doch. Du kannst nicht beurteilen, was letztlich die Ursache ist, und kannst also auch nicht sagen, dass es "der Android OS Bug" war. Der Android OS Bug sind nämlich eigentlich viele verschiedene Bugs.

JobbeDeluxe schrieb:
aber wenn du mit deinem Auto mit einer Tankfüllung 600 km weit kommst und bei der nächsten auf einmal nur 100 km dann würdest du doch auch sagen das da was nicht stimmt oder? Und weist du deshalb was es ist? nein, du fährst auch in die Werkstatt.
Richtig. Es kann ein Loch im Tank sein, oder eine defekte Zylinderkopfdichtung. Beides sind aber vollkommen unterschiedliche Probleme, die eben nur den gleichen Effekt haben: Du kommst nicht so weit, wie gewünscht. Und deshalb ist es auch blöd, wenn du ein Loch im Tank hast, und ein anderer Forumnutzer empfiehlt dir, die Zylinderkopfichtung auszutauschen, weil es bei ihm geholfen hat. Dir mit dem Loch im Tank wird es nicht helfen.

Genau deshalb kannst du nicht sagen "Es gibt DEN Android OS Bug". Du hast ein Problem mit erhöhtem Akkuverbauch, wie viele andere auch. Trotzdem ist bei dir die Ursache möglicherweise eine andere, als bei den anderen Nutzern.

Es gibt nicht "den Bug". Wie im Auto gibt es viele Ursachen für den erhöhten Akkuverbrauch. Eine davon hat bei dir zugeschlagen. Welche das ist, ob das Loch im Tank oder die Zylinderkopfdichtung, kannst du nicht sagen. Und du könntest es nur, wenn du die Systemwrkzeuge benutzt, die ich oben aufgezählt habe. Nur die Verbrauchsstatistik aus den Akkuinformationen ist nicht aussagekräftig.
 
  • Danke
Reaktionen: Donald Nice
frank_m schrieb:
Ich bin mir jetzt sicher, dass es "den" Android OS Bug nicht gibt und noch nie gab.

.. Vergegenwärtigen wir uns jetzt noch mal die Schilderungen über den Android OS Bug:
- Bei einigen Tritt er durch Spiele auf
- Bei anderen durch GPS Nutzung
- Beim dritten durch den SNS Service
- Beim vierten ist es die automatische Ausrichtung
- Der fünfte kann die Ursache gar nicht ausmachen
- usw.
Das alles deutet doch sehr darauf hin, dass hier verschiedene Probleme zuschlagen, die zufällig alle die Android OS Anzeige nach oben treiben.

Was sagt uns das jetzt? Es reicht nicht, zu sagen, "Ich hab den Android OS Bug". Wenn plötzlich der Energieverbrauch ungewöhnlich stark ansteigt, muss man mit weiteren Tools näher hinsehen, was genau die Ursache ist, z.B. mit dem "System Panel", "Better Battery Stats" oder "Where is my Droid Power". Mit etwas Glück findet man dann tatsächlich die richtige Ursache.

Schön wär's. Ich habe die 2.3.3 JVI/JVO (Original, nicht gerootet) seit dem 11.06.2011 drauf, eigentlich auch immer die gleichen Apps. Und ich bin mir sicher, daß ich die ersten 1,5 Monate Ruhe hatte. Den Spuk habe ich seit ca. 3 Wochen - anfangs selten, jetzt immer häufiger. Das SGS ist eigentlich kaum noch brauchbar, da man sich nicht mehr darauf verlassen kann.
Ich habe "Battery Monitor Widget Pro" drauf, sehe also schon im Vorfeld wenn es wieder losgeht (>30mA Stromverbrauch), parallel sieht man in Telefoninfo/Akkuverbrauch, daß "Aufwachen" an bleibt, das SGS also nicht mehr in den Schlafmodus geht. Ausschalten/neu starten bringt nicht. Irgendwann kriegt es sich dann wieder ein und es herrscht Friede bis zum nächsten "Rappel" - wohlbemerkt bei identisch laufenden Anwendungen!

Meine Verdachtsmomemte:
- mein interner USB-Speicher war mal fast voll gewesen und ich habe ein Verzeichnis mit >5000 Dateien - vielleicht läuft irgend ein Reorg analog Win Scandisk an, kommt nicht klar, versucht es aber immer wieder
- auch wenn ich die gleichen Apps darauf habe, Updates habe ich natürlich eingespielt - vielleicht ist es ja doch eines davon.
Skype ist jedenfalls schon runter da dessen Hintergrundservice dafinitv etwas damit zu tun hatte. Nach der Deinstallation ging es spürbar besser.
Das mit dem Bug analog Nexus WiFi Treiber war mir vorher nicht klar, werde ich aber mal beobachten - glaube ich aber eigentlich nicht, da das SGS bei mir 1,5 Monate unter 2.3.3 eigentlich brav gelaufen ist. Schade, daß man nicht ganz offiziell zur 2.2.1 zurück kommt.
 
Hayabusa_80 schrieb:
Meine Verdachtsmomemte:
- mein interner USB-Speicher war mal fast voll gewesen und ich habe ein Verzeichnis mit >5000 Dateien - vielleicht läuft irgend ein Reorg analog Win Scandisk an, kommt nicht klar, versucht es aber immer wieder
- auch wenn ich die gleichen Apps darauf habe, Updates habe ich natürlich eingespielt - vielleicht ist es ja doch eines davon.
Skype ist jedenfalls schon runter da dessen Hintergrundservice dafinitv etwas damit zu tun hatte. Nach der Deinstallation ging es spürbar besser.
Also ich komme auch mit Skype (meistens nicht aktiv, aber ein Service läuft ja trotzdem) zu 95% ohne AOS bug zurecht (1-2 mal seit kies update).
Trotzdem habe ich mir zur mir zur Analyse eine kleine App geschrieben, mit der man alle sich alle laufenden Prozesse anzeigen lassen kann. Dabei bin ich auch darauf gestoßen, dass eine App einen Prozess anstoßen kann, der evtl. nicht mehr zu beenden ist - zumindest nicht mit Boardmitteln. Wie der Enegieverbrauch eines solchen Prozesses abgerechnet wird habe ich nicht untersucht - der hat zumindest die Linux UID der App, die ihn angestoßen hat.

Wenn Interesse an der App besteht, die lediglich >top ausführt und das Ergebnis von einer Momentaufnahme in eine TextView schreibt, meldet Euch ruhig. Ich kann dann eine .apk, die 1 Woche lang installierbar ist hier reinstellen (einmal installiert kann man sie aber auch über die Woche hinaus nutzen).

Gegen meine These mit dem Geisterprozess spricht, dass ein Neustart abhilfe bringen sollte, es bei eingen aber wohl nicht tut. Bei mir hat er es getan, d.h. der relative verbrauch von AOS war noch sehr hoch, ist aber dann langsam gefallen.
Leute, bei denen "der" AOS Bug zuverlässig auftritt können aber vielleicht feststellen, welcher Prozeß mit daran beteiligt ist - ich habe mein Handy noch nie beim aktiven Bug erwischt.
 
Zuletzt bearbeitet:
Tools wie Better Battery Stats und vor allem System Panel zeigen ja auch schon die Prozessorbelastung einzelner Apps an. Interessant könnten diese Zombie-Prozesse sein, von denen du schreibst. Vielleicht sind das Restbestände von weggeräumten Apps?
 
Ich habs gerade ausprobiert. Die freie Version des Systempanels zeigt nicht die Prozessorbelastung der einzelnen Apps an, höchstens einen Großteil also wahrscheinlich den des zugehörigen Java Prozesses. Wenn man aus diesem aber einen Linux Prozess startet, wird letzterer nicht angezeigt und auch nicht gekillt, wenn man den die App die ihn gestartet hat killt. Dann wird letztere App als nicht laufend angezeigt - der Prozeß läuft aber trotzdem munter weiter.

Außerdem wird bei weitem nicht jeder Systemprozeß angezeigt, selbst wenn man Systemtools einblendet - ich habe das SystemPanel Lite umgehend wieder deinstalliert.
Fazit: Es ist zwar nicht ausgeschlossen, dass man mit so einer App den Eigenschaften des Android Bugs näher auf die Pelle rückt, sie lassen aber locker genug spielraum, Nutzung von Systemressourcen zu übersehen.

Edit:
Zu den Zombiprozessen. Ich habe bei mir nur selbst verursachte gefunden (um zu sehen, was mit solchen Prozessen passiert), kann mir aber gut vorstellen, dass auch andere Apps solche Prozesse hinterlassen - ob bewußt oder unbewußt sei dahingestellt.

So ganz lückenlos scheint das Berechtigungssystem von Android auch nicht zu sein - dadurch dass ich mir die laufenden Prozesse aus einer Linux shell hole, braucht meine App keine extra Berechtigungen im gegensatz zum Systempanel, das wohl über das Android SDK geht.
 
Zuletzt bearbeitet von einem Moderator:
JanF schrieb:
kann mir aber gut vorstellen, dass auch andere Apps solche Prozesse hinterlassen - ob bewußt oder unbewußt sei dahingestellt.
Besonders im Umgang mit Task Killern kann ich mir das gut vorstellen.
 
Als ich das SGS neu hatte, habe ich mal einen Test mit "nur Handy-Netzempfang an aber sonst ruhig liegen lassen" gemacht - ja, viel echt schwer ;-) Das Ding hat 6 komplette Tage durchgehalten!

Habe heute Mittag alles was selbstinstalliert war und mit WiFi in Kontakt kommen konnte, deaktiviert, WiFi und Paketmodus natürlich aus, dann neu gestartet > heute Nachmittag gings trotzdem wieder los ... An den WiFi-Treiberfehler glaube ich daher eigentlich nicht.

Ich bin schon vom GoLauncher wieder bei der Hausmannkost angelangt, habe keinerlei Widget mehr laufen, nützt aber alles nichts.

Ich glaube auch nicht, daß das irgendeine wild gewordene Anwendung ist. Ich sehe ja den Stromverbrauch wenn's passiert, laut "Battery Monitor Widget Pro" auch in der Ruhepahse bei mir i.d.R. 35mA im Gegensatz zu 3-6mA bei echtem Standby. Dieser angezeigte Wert mag nicht sehr genau sein (sonst wäre ein 1500mAh Akku nicht nach einem Tag alleine davon leer), zeigt aber in seiner Beschränkung sehr wohl die Tendenz. Wenn eine Anwendung richtig CPU zieht, z.B. ein Bildbetrachter der Unmengen Thumbnails neu aufbauen muß, geht der Verbrauch auch schon mal auf über 300mA hoch.

Nein, da läuft bestimmt keine App Amok, insofern dürfte auch eine TOP-Anzeige nichts bringen. Meiner Meinung nach gibt es unter 2.3.3 einen Systemfehler, der durch was auch immer angetriggert wird, oder ein mieses App-Update (Standard-App, die fast alle drauf haben), die einfach verhindert, daß das SAS in seinen wohlverdienten Standby-Modus umschalten kann . Zumindest bei mir ist das ziemlich eindeutig.
 
Hayabusa_80 schrieb:
Nein, da läuft bestimmt keine App Amok, insofern dürfte auch eine TOP-Anzeige nichts bringen.
Oh, doch, gerade da hätte TOP Vorteile, denn TOP zeigt nicht nur die Apps an, sondern auch alle Hintergrund- und Systemprozesse.

Hayabusa_80 schrieb:
Meiner Meinung nach gibt es unter 2.3.3 einen Systemfehler, der durch was auch immer angetriggert wird
Exakt so ist es.

Hayabusa_80 schrieb:
oder ein mieses App-Update (Standard-App, die fast alle drauf haben)
Nee, die eben nicht fast alle drauf haben. Die Quote der Betroffenen ist nicht sonderlich hoch, nicht mal in Bezug auf die Teilnehmer in diesem Forum. Ich glaube, SGS-weit liegt sie deutlich unter 1%.

Ich würde dir empfehlen, CPU Spy und Better Battey Stats auszuprobieren. Beide sind kostenlos (nimm die xda Version von Better Battey Stats) und gegen schon viele Hinweise auf Verbraucher abseits der reinen Apps.
 
Danke, werde mir die von dir empfohlenen Apps mal gönnen - obwohl mein letzter Test mich eher noch ratloser gemacht hat.

Konkret:
Gestern abend noch den bisher zuverlässigen "Akku 1min raus" Trick angewandt und neu gestartet => SGS Akku ging danach die ganze Nacht über von 29% nur auf 22% runter, 5mA Durchschnittsstrom am Morgen direkt nach dem Einschalten. Fein, so könnte es bleiben.

Dann Akku voll geladen (Rotationsmodus, Paketmodus, GPS, alles war seit dem letzten Booten aus) und als einzige Aktion WLAN kurz aktiviert, mit Dolphin Browser HD hier im Forum ein paar Seiten angesehen, Browser und WLAN beendet, Handy weggelegt.

Nach 4 Stunden Kontrolle, und es war schon wieder am Gange. 85% Stromverbrauch durch "Android System", konkret 45mA Stromaufnahme und jetzt kommt's: In der Akkustandverlaufsanzeige gab es genau einen Knick nach unten, und zwar ungefähr 1,25 Stunden nachdem ich das SGS einfach weggelegt hatte. Es gab da also keinen App-Start von mir, 1,25 Stunden nachdem es in Ruhe da gelegen hatte ging von selbst der Rappel los. Echt zum k*t*en (sorry).

Ich probiere jetzt noch deine Apps aus, ansonsten lege ich das SGS jetzt erstmal in die Ecke, da man sich nicht mehr drauf verlassen kann. Wenn die 2.3.4 offiziell kommt gibt es nochmal einen Versuch, ansonsten werde ich wohl doch flashen müssen (wollte ich nie tun) und die alte 2.2.1 draufladen. Obwohl, da hat hier im Forum auch schon jemand das gleiche zu gemeldet.

Ich hole jetzt jedenfalls mein altes Nokia 5230 wieder raus - ist zwar hardware-mäßig Steinzeit gegen das schöne SGS und damit will auch niemand wirklich ins Internet gehen, aber wenigstens läuft es inkl. Navi-App absolut stabil, hält auch ohne Android-Bug 2-3mal so lange mit einer Akkuladung durch und vefügt über eine bauchbaren Wecker ohne Schockmodus sowie einen Lock-Screen, der den Namen verdient.

Mit diesem Bug braucht Apple Google/Samsung gar nicht wegen Patentverletzungen zu verklagen, mit diesem Mist zieht sich Google selbst aus dem Verkehr. Wenn soetwas Microsoft mit Windows passiert wäre, wäre das längst in allen Nachrichten und alle am schreien.
 
So, mit verstreichender Zeit wird es natürlich immer schwieriger bei diesem eigentlich wunderbaren Beispiel etwas konkret nachzuvollziehen, aber grob zusammengefaßt läßt sich ungefähr folgendes ableiten:

CPU Spy sagt nicht viel mehr, als daß das SGS die relevante Zeit eben nicht in "Deep Sleep" war (wußte ich auch so schon) sondern fast vollständig im "100MHz State" verbracht hat. Das wäre 1/10 der Endleistung und würde zum Stromverbrauch passen (wenn der linear mit der Frequenz wäre).

BetterBatteyStats ist da schon besser:
Unter Process ist "Android System" angeblich in Summe nur ca. 5 Min aktiv gewesen
Unter "Partial Wakelocks" steht allerdings ebenfalls "Andoid System" jedoch mit 6,5 Stunden und zwar nur für den "LocationManagerService", alles andere ist Kleinkram.

Offenbar gibt/gab es damit Probleme beim Abschalten, siehe z.B.:
codetastrophe: Accessing hidden System Service APIs in Android
Android :: How To Stop Location Manager Service?

Wenn man jetzt noch sehen könnte, was/welche App diesen Service benutzen möchte, könnte man/ich Land sehen. Evtl. hängt das auch mit Gingerbread zusammen, da Apps damit meines Wissens nach GPS nicht mehr ein- bzw. ausschalten können - da ich jedoch GPS ausgeschaltet gelassen hatte, könnte evtl. eine alte oder dumme, jedenfalls nicht angepaßte Apps das dennoch (andauernd erfolglos) probieren?!

An GPS-Anwendungen benutzte ich bewußt eigentlich nur Google Maps und Sygic Aura, aber letzteres hat zumindest offiziell keinen Hintergrundservice der permanent am laufen bleibt.

Ich gehe mal meine laufenden / neueren Apps durch, vielleicht hat ja einesdavon vor kurzem ein "GPS"/"Localisation" Freature neu vom Entwickler spendiert bekommen ...
 

Ähnliche Themen

Islaris
Antworten
8
Aufrufe
5.379
Toccata
Toccata
P
Antworten
6
Aufrufe
1.777
PrinzPoldi007
PrinzPoldi007
J
Antworten
1
Aufrufe
1.799
JoHo-Man
J
Zurück
Oben Unten