fipsy
Stamm-User
- 293
Ich habe whatsapp auch mal testhalber installiert. Rein gefühlsmäßig trat das Problem danach auf. Aber sicher bin ich mir nicht, da der Battery Mix für whatsapp nie mehr als 5-6% Akkuverbrauch anzeigte. Meist sogar nur 2-3%.
[Diskussion] CyanogenMod 7 mit 2ndboot für das Milestone (CM7)
- 688 Antworten
- Letztes Antwortdatum
Otandis_Isunos
Ehrenmitglied
- 6.741
Man kann doch die Geräte an den Computer anschliessen und via ddms das komplette Log für 24h mitschneiden lassen. Dann sieht man doch, welche App in welchen Abständen sich wie aktualisiert, selbst bei ausgeschaltetem Display.
Allerdings: a: Wer logging aktiviert hat -> frisst Akku
b: 1% Akkuanzeige frisst ebenfalls zuviel Akku.
c: Widgets, speziell Wetterwidgets oder Wetterzeugs allgemein frisst unglaublich Akku, auch wenn das Display ausgeschaltet ist.
Bei meinem Milestone hat HSDPA massiv am Akku gezogen. Es können auch einzelne Hardwarekomponenten sein, die einfach mal so am Akku saugen. Welche das genau sind, lässt sich nicht wirklich ausmachen, vllt durch Glück.
Allerdings: a: Wer logging aktiviert hat -> frisst Akku
b: 1% Akkuanzeige frisst ebenfalls zuviel Akku.
c: Widgets, speziell Wetterwidgets oder Wetterzeugs allgemein frisst unglaublich Akku, auch wenn das Display ausgeschaltet ist.
Bei meinem Milestone hat HSDPA massiv am Akku gezogen. Es können auch einzelne Hardwarekomponenten sein, die einfach mal so am Akku saugen. Welche das genau sind, lässt sich nicht wirklich ausmachen, vllt durch Glück.
-FuFu-
Ikone
- 3.296
- Themenstarter
- #283
sag ich ja ^^ mit viel Glück findet man den Übeltäter 
ich nutz die 1% Akkuanzeige nicht, alleinschon weil man mitzählen kann, wie der Akkustand runter geht und ich es noch ungenauer finde wie bei 10% schritten.
widgets hab ich maximal 2 drauf, setcpu (passiv, also ohne anzeige des aktuellen taktes) und SysInfo Widget, welches sich auch nur sehr passiv aktualisiert und ich hab keinen unterschied festgestellt wenn ich die beiden widgets raus nehme, von daher denke ich, das die beiden kaum akku ziehen.
und bis auf whatsapp hab ich nichts drauf, was permanent im internet ist und sich aktualisiert, den Play Store stopp ich immer nach der nutzung, der muß nicht permanent laufen.
man kann zwar gut per ddms loggen, das problem ist, das der Akku permanent geladen wird per usb und das ergibt unteranderem das Problem, dass das Gerät nicht in den deepsleep geht und das ergebniss verfälschen würde... dann könnte man besser per logcat in eine Datei loggen, was aber wie du sagst den Akkuverbrauch erhöht und nach 24h den log auswerten würd sicher sehr viel spaß machen
und jap, wie du sagst können es auch Hardwarekomponenten sein, die am Akku ziehen, die man aber nur schwer ausmachen kann, denn z.b. wenn man das Gerät in der Hosentasche hat und unterwegs ist wird der Lagesensor permanent ausgelöst, in wie weit das aber bei ausgeschaltetem Dispay der fall ist kann ich nicht sagen...
da ich aber keine größeren Probleme derzeit hab, forsch ich auch nicht
und ich denke das man den Übeltäter auch nicht so einfach finden wird, es könnte ja auch ein Problem mit dem deepsleep sein, leider kann man das seit dem Custom Kernel nicht mehr Prüfen, da kein "TimeInState" mehr ausgegeben wird, was man ja bequem in setcpu prüfen konnte...
ich nutz die 1% Akkuanzeige nicht, alleinschon weil man mitzählen kann, wie der Akkustand runter geht und ich es noch ungenauer finde wie bei 10% schritten.
widgets hab ich maximal 2 drauf, setcpu (passiv, also ohne anzeige des aktuellen taktes) und SysInfo Widget, welches sich auch nur sehr passiv aktualisiert und ich hab keinen unterschied festgestellt wenn ich die beiden widgets raus nehme, von daher denke ich, das die beiden kaum akku ziehen.
und bis auf whatsapp hab ich nichts drauf, was permanent im internet ist und sich aktualisiert, den Play Store stopp ich immer nach der nutzung, der muß nicht permanent laufen.
man kann zwar gut per ddms loggen, das problem ist, das der Akku permanent geladen wird per usb und das ergibt unteranderem das Problem, dass das Gerät nicht in den deepsleep geht und das ergebniss verfälschen würde... dann könnte man besser per logcat in eine Datei loggen, was aber wie du sagst den Akkuverbrauch erhöht und nach 24h den log auswerten würd sicher sehr viel spaß machen
und jap, wie du sagst können es auch Hardwarekomponenten sein, die am Akku ziehen, die man aber nur schwer ausmachen kann, denn z.b. wenn man das Gerät in der Hosentasche hat und unterwegs ist wird der Lagesensor permanent ausgelöst, in wie weit das aber bei ausgeschaltetem Dispay der fall ist kann ich nicht sagen...
da ich aber keine größeren Probleme derzeit hab, forsch ich auch nicht
und ich denke das man den Übeltäter auch nicht so einfach finden wird, es könnte ja auch ein Problem mit dem deepsleep sein, leider kann man das seit dem Custom Kernel nicht mehr Prüfen, da kein "TimeInState" mehr ausgegeben wird, was man ja bequem in setcpu prüfen konnte...
fipsy
Stamm-User
- 293
Hallo Allerseits,
also erstmal muss ich sagen, dass ich es super finde, dass sich so viele des Problems nochmal ernsthaft annehmen.
Mir hat es auch keine Ruhe gelassen und ich habe die Sache weiter genau beobachtet, um die Vermutungen, die hier geäußert wurden zu belegen oder zu widerlegen.
Widerlegt ist nach meinen Beobachtungen ganz eindeutig, dass eine App Schuld an dem (nur zeitweise) hohen Stromverbrauch ist. Wenn der Stromverbrauch extrem ansteigt (dauerhaft über 200 mA), dann wird das Gerät auf der Rückseite über dem Akku sogar warm und der Akku ist in etwa 7-9 Stunden leer. Und zwar ohne dass das Display eingeschaltet oder das Handy bewegt wurde!
In der ersten Grafik sieht man dies wunderbar: Um 12 Uhr habe ich einen neu geladenen Akku eingelegt und um 21 Uhr ist er leer. Das Gerät wurde fast gar nicht benutzt, wie man daran erkennen kann, dass das Display kaum eingeschaltet war. Es saugt also etwas dauerhaft und durchgehend am Akku!
Dann habe ich um 21 Uhr wieder einen neu geladenen Akku eingelegt und man sieht, dass der bis etwa 23:00 Uhr genauso leer gesogen wurde, wie der Akku zuvor: In etwa 2 Stunden war der Akkustand von 100% auf 80% abgesunken, obwohl ich nichts mit dem Handy gemacht habe.
Und was habe ich dann getan? Ich habe das Gerät um 23 Uhr einfach nur neu gestartet (reboot). Und siehe da: Die Entladekurve knickt nach dem Neustart geradezu waagerecht ab. Von 23 Uhr bis jetzt (= 12 Stunden) ist der Ladezustand lediglich von 80% auf 66% gesunken. So sollte es sein! Auch die mittlere CPU-Last ist beim "Saug-Zustand" im Standby etwa dreimal so hoch, wie beim "Normal-Zustand". Irgendetwas beschäftigt die CPU also gewaltig. Einen "normalen" Entladeverlauf mit durchschnittlicher Nutzung des Gerätes sieht man im zweiten Diagramm: Die Nutzungsdauer beträgt rund 24-36 Stunden.
Wie komme ich nun darauf, dass keine App schuld ist? In der aufgeschlüsselten Statistik sieht man, Dass sich das prozentuale Verhältnis des Stromverbrauchs zwischen "Android-System" und den Apps immer etwa gleich verhält: Es entfallen stets etwa 30-40% der Akkuleistung auf das Android-System und der Rest verteilt sich immer etwa im gleichen Verhältnis auf die Apps. Wäre eine App an der Misere Schuld, müsste sich dieses Verhältnis jedoch deutlich verschieben!
Ich vermute die Ursache daher im 2nd boot Kernel! Ich meine hier auch mehrfach gelesen zu haben, dass das Problem erst seit der Einführung des 2nd boot Kernels auftritt. Vorher trat es nicht auf, soweit ich das mitbekommen habe. Und deshalb kann es m.E. auch nicht an der Hardware liegen! Ich kann dazu nichts sagen, weil ich bei CM7 schon mit dem 2nd boot Kernel eingestiegen bin. Unter Eclair trat das Problem aber definitiv nicht auf.
Eines ist aber klar: Es muss etwas gegen dieses Problem getan werden!
also erstmal muss ich sagen, dass ich es super finde, dass sich so viele des Problems nochmal ernsthaft annehmen.
Mir hat es auch keine Ruhe gelassen und ich habe die Sache weiter genau beobachtet, um die Vermutungen, die hier geäußert wurden zu belegen oder zu widerlegen.
Widerlegt ist nach meinen Beobachtungen ganz eindeutig, dass eine App Schuld an dem (nur zeitweise) hohen Stromverbrauch ist. Wenn der Stromverbrauch extrem ansteigt (dauerhaft über 200 mA), dann wird das Gerät auf der Rückseite über dem Akku sogar warm und der Akku ist in etwa 7-9 Stunden leer. Und zwar ohne dass das Display eingeschaltet oder das Handy bewegt wurde!
In der ersten Grafik sieht man dies wunderbar: Um 12 Uhr habe ich einen neu geladenen Akku eingelegt und um 21 Uhr ist er leer. Das Gerät wurde fast gar nicht benutzt, wie man daran erkennen kann, dass das Display kaum eingeschaltet war. Es saugt also etwas dauerhaft und durchgehend am Akku!
Dann habe ich um 21 Uhr wieder einen neu geladenen Akku eingelegt und man sieht, dass der bis etwa 23:00 Uhr genauso leer gesogen wurde, wie der Akku zuvor: In etwa 2 Stunden war der Akkustand von 100% auf 80% abgesunken, obwohl ich nichts mit dem Handy gemacht habe.
Und was habe ich dann getan? Ich habe das Gerät um 23 Uhr einfach nur neu gestartet (reboot). Und siehe da: Die Entladekurve knickt nach dem Neustart geradezu waagerecht ab. Von 23 Uhr bis jetzt (= 12 Stunden) ist der Ladezustand lediglich von 80% auf 66% gesunken. So sollte es sein! Auch die mittlere CPU-Last ist beim "Saug-Zustand" im Standby etwa dreimal so hoch, wie beim "Normal-Zustand". Irgendetwas beschäftigt die CPU also gewaltig. Einen "normalen" Entladeverlauf mit durchschnittlicher Nutzung des Gerätes sieht man im zweiten Diagramm: Die Nutzungsdauer beträgt rund 24-36 Stunden.
Wie komme ich nun darauf, dass keine App schuld ist? In der aufgeschlüsselten Statistik sieht man, Dass sich das prozentuale Verhältnis des Stromverbrauchs zwischen "Android-System" und den Apps immer etwa gleich verhält: Es entfallen stets etwa 30-40% der Akkuleistung auf das Android-System und der Rest verteilt sich immer etwa im gleichen Verhältnis auf die Apps. Wäre eine App an der Misere Schuld, müsste sich dieses Verhältnis jedoch deutlich verschieben!
Ich vermute die Ursache daher im 2nd boot Kernel! Ich meine hier auch mehrfach gelesen zu haben, dass das Problem erst seit der Einführung des 2nd boot Kernels auftritt. Vorher trat es nicht auf, soweit ich das mitbekommen habe. Und deshalb kann es m.E. auch nicht an der Hardware liegen! Ich kann dazu nichts sagen, weil ich bei CM7 schon mit dem 2nd boot Kernel eingestiegen bin. Unter Eclair trat das Problem aber definitiv nicht auf.
Eines ist aber klar: Es muss etwas gegen dieses Problem getan werden!
Anhänge
Zuletzt bearbeitet:
Otandis_Isunos
Ehrenmitglied
- 6.741
@fipsy
Wenn das Problem, deiner Meinung nach, mit dem 2ten Kernel zusammen hängt. Dann flash doch einfach eine ältere Version von CM7, wo es den noch nicht gab.
Und um das auch mal klarzustellen: Gingerbread gab es offiziell auch NIE für das Milestone. Es könnte nämlich auch sein, dass gerade das gesamte CM für alles verantwortlich ist.
Also flash eine ältere Version von CM und berichte weiter. Ich kann nicht. Mir ist auch das 2te Milestone flöten gegangen -> Touch Schrott Vllt versuch ichs mal im Backofen, wenn ich wieder in Köln bin, da gibts Umluft
Wenn das Problem, deiner Meinung nach, mit dem 2ten Kernel zusammen hängt. Dann flash doch einfach eine ältere Version von CM7, wo es den noch nicht gab.
Und um das auch mal klarzustellen: Gingerbread gab es offiziell auch NIE für das Milestone. Es könnte nämlich auch sein, dass gerade das gesamte CM für alles verantwortlich ist.
Also flash eine ältere Version von CM und berichte weiter. Ich kann nicht. Mir ist auch das 2te Milestone flöten gegangen -> Touch Schrott
Vllt versuch ichs mal im Backofen, wenn ich wieder in Köln bin, da gibts Umluft
-FuFu-
Ikone
- 3.296
- Themenstarter
- #286
wenn das Gerät über dem Akku (auf höhe der Kamera) warm wird, ist es das wlan oder hsdpa Modul, denn die liegen dort...
diese werden aber nur bei Datennutzung oder Netzwerksuche sehr warm, wäre aber ein indikator, gut zu testen, wenn man einfach mal irgendeine große Datei per Browser runterläd, mit hsdpa wird das Milestone dann zum Taschenwärmer ^^ mit wlan wird es auch recht warm...
andere möglichkeit wäre die cpu (diese liegt glaub ich auch in diesem Bereich), dann würd dies aber bedeuten, das sie permanent auf maximum läuft und bei 1ghz wird es da dann auch recht warm... aber dann müßte es irgendeinen service/app geben, was permanent läuft und eine hohe cpu last verursacht...
da aber bei dir nicht besonderes in der liste auftaucht kann es auch am "Android-System" liegen, denn dieser verwaltet auch die Hardwarekomponenten (Lagesensor, Helligkeitssensor, Magnetsensor usw.), oder das Mobilfunksignal schwankt und das Gerät schaltet permanent die Leistung des Modems hin und her...
und selbst wenn in beiden Geräten eine Sim des selbem Providers ist kann es sein, das der Empfang unterschiedlich stark ist....
aber wie ich sagte, es wird schwer den wirklichen fehler/problem/übeltäter zu finden...
und sicher kann es auch am Kernel liegen aber auch wie Otandis_Isunos sagte an CM selbst... selbst der Unterschied zwischen 2.1 und 2.2.1 ist was den Akkuverbrauch angeht schon recht groß... sogar 2.0 hat mehr Akku verbraten wie 2.1...
um aber die Firmware selbst auszuschliessen, müßte man die Messung unter einer Identischen/Ähnlichen Konfiguration auch mal mit der Originalen 2.1 und 2.2.1 machen...
dort ist aber schon das Problem, das dort die CPU nur mit 550mhz läuft und diverse andere Module anders sind, allein was die Govs angeht aber dort gäbe es ja Addonpacks (von mir für 2.2.1 und ich glaub nen 2.1 hab ich auch da) oder man müßte ein "vorgetuntes" nandroid nutzen, wo overclock, govs und apps2ext schon mit drin ist...
und dann kann ich jetzt schon sagen, das 2.1 am besten abschneiden wird aber leider fehlen viele Funktionen von CM, die man schnell vermissen wird und das andere Problem ist, das unter 2.1 viele apps nicht laufen, die man aber gern nutzen würde (mir persönlich fällt zwar gerade keins ein, aber es gibt sicher welche)
diese werden aber nur bei Datennutzung oder Netzwerksuche sehr warm, wäre aber ein indikator, gut zu testen, wenn man einfach mal irgendeine große Datei per Browser runterläd, mit hsdpa wird das Milestone dann zum Taschenwärmer ^^ mit wlan wird es auch recht warm...
andere möglichkeit wäre die cpu (diese liegt glaub ich auch in diesem Bereich), dann würd dies aber bedeuten, das sie permanent auf maximum läuft und bei 1ghz wird es da dann auch recht warm... aber dann müßte es irgendeinen service/app geben, was permanent läuft und eine hohe cpu last verursacht...
da aber bei dir nicht besonderes in der liste auftaucht kann es auch am "Android-System" liegen, denn dieser verwaltet auch die Hardwarekomponenten (Lagesensor, Helligkeitssensor, Magnetsensor usw.), oder das Mobilfunksignal schwankt und das Gerät schaltet permanent die Leistung des Modems hin und her...
und selbst wenn in beiden Geräten eine Sim des selbem Providers ist kann es sein, das der Empfang unterschiedlich stark ist....
aber wie ich sagte, es wird schwer den wirklichen fehler/problem/übeltäter zu finden...
und sicher kann es auch am Kernel liegen aber auch wie Otandis_Isunos sagte an CM selbst... selbst der Unterschied zwischen 2.1 und 2.2.1 ist was den Akkuverbrauch angeht schon recht groß... sogar 2.0 hat mehr Akku verbraten wie 2.1...
um aber die Firmware selbst auszuschliessen, müßte man die Messung unter einer Identischen/Ähnlichen Konfiguration auch mal mit der Originalen 2.1 und 2.2.1 machen...
dort ist aber schon das Problem, das dort die CPU nur mit 550mhz läuft und diverse andere Module anders sind, allein was die Govs angeht
aber dort gäbe es ja Addonpacks (von mir für 2.2.1 und ich glaub nen 2.1 hab ich auch da) oder man müßte ein "vorgetuntes" nandroid nutzen, wo overclock, govs und apps2ext schon mit drin ist...und dann kann ich jetzt schon sagen, das 2.1 am besten abschneiden wird
aber leider fehlen viele Funktionen von CM, die man schnell vermissen wird und das andere Problem ist, das unter 2.1 viele apps nicht laufen, die man aber gern nutzen würde (mir persönlich fällt zwar gerade keins ein, aber es gibt sicher welche)
fipsy
Stamm-User
- 293
@Otandis_Isunos: Okay, das könnte ich mal auf dem einen Gerät machen! Nur muss ich das dann schon über eine längere Zeit beobachten, denn das Problem tritt ja nicht immer auf .
Der ursprüngliche Beitrag von 12:27 Uhr wurde um 12:47 Uhr ergänzt:
Okay, ich werde das nächste Mal, wenn das Handy wieder in den "Saug-Modus" umschaltet, einfach mal WLAN abschalten und weiter beobachten ohne zu booten. Und wenn das nicht hilft, mal auf 2G umschalten. Damit könnte man die Ursache vielleicht etwas einkreisen.
Jepp, bei mir sind 800 MHz das Maximum und dann wird das Ding auch schon leicht warm.
Nicht zwangsläufig. Es würde ja auch schon reichen, dass der Governor Mist baut und das Handy permanent auf höchster Taktrate betreibt. Du weißt ja, dass ich die Governor schon von Anfang an auf dem "Kieker" habe ;-). Ich hoffe sehr, dass es nicht wirklich daran liegt, sonst würde ich Schläge verteilen müssen.
Ich denke auch eher, dass es am Android-System oder am Kernel liegt. Was dabei gegen die von dir genannten Komponenten spricht ist die Tatsache, dass der zu hohe Energieverbrauch dauerhaft über Stunden hinweg auftritt, aber nach dem Booten gar nicht mehr, obwohl die Einsatzbedingungen vorher und nachher weitgehend gleich waren. Wenn es am Lagesensor, Helligkeitssensor, Magnetsensor oder Mobilfunksignal läge, dürfte die Sache eigentlich nicht so sehr eindeutig sein.
Eben! Mir fällt sofort eine ein: Telekom Programm Manager. Für mich als Entertain-Kunde unverzichtbar. Und in der aktuellen Version auch endlich richtig brauchbar.
Selbst wenn wir zweifelsfrei feststellen könnten, dass das Problem unter älteren OS-Versionen nicht auftritt, sind wir bezüglich der Ursachenforschung auch keinen Schritt weiter. Deshalb bin ich nicht so überzeugt von dem konkreten Nutzen den es bringen soll, nun ältere Versionen zu testen.
.Der ursprüngliche Beitrag von 12:27 Uhr wurde um 12:47 Uhr ergänzt:
-FuFu- schrieb:
Okay, ich werde das nächste Mal, wenn das Handy wieder in den "Saug-Modus" umschaltet, einfach mal WLAN abschalten und weiter beobachten ohne zu booten. Und wenn das nicht hilft, mal auf 2G umschalten. Damit könnte man die Ursache vielleicht etwas einkreisen.
-FuFu- schrieb:
Jepp, bei mir sind 800 MHz das Maximum und dann wird das Ding auch schon leicht warm.
-FuFu- schrieb:
Nicht zwangsläufig. Es würde ja auch schon reichen, dass der Governor Mist baut und das Handy permanent auf höchster Taktrate betreibt. Du weißt ja, dass ich die Governor schon von Anfang an auf dem "Kieker" habe ;-). Ich hoffe sehr, dass es nicht wirklich daran liegt, sonst würde ich Schläge verteilen müssen.
-FuFu- schrieb:
Ich denke auch eher, dass es am Android-System oder am Kernel liegt. Was dabei gegen die von dir genannten Komponenten spricht ist die Tatsache, dass der zu hohe Energieverbrauch dauerhaft über Stunden hinweg auftritt, aber nach dem Booten gar nicht mehr, obwohl die Einsatzbedingungen vorher und nachher weitgehend gleich waren. Wenn es am Lagesensor, Helligkeitssensor, Magnetsensor oder Mobilfunksignal läge, dürfte die Sache eigentlich nicht so sehr eindeutig sein.
-FuFu- schrieb:
Eben! Mir fällt sofort eine ein: Telekom Programm Manager. Für mich als Entertain-Kunde unverzichtbar. Und in der aktuellen Version auch endlich richtig brauchbar
.Selbst wenn wir zweifelsfrei feststellen könnten, dass das Problem unter älteren OS-Versionen nicht auftritt, sind wir bezüglich der Ursachenforschung auch keinen Schritt weiter. Deshalb bin ich nicht so überzeugt von dem konkreten Nutzen den es bringen soll, nun ältere Versionen zu testen.
TeCci
Stamm-User
- 48
Also vorweg mal: Ich finds ja gut, dass es noch Leute gibt, die sich so intensiv mit dem Milestone beschaeftigen, aber....
Ich finds ein bisschen frech, Forderungen an andere zu stellen, dass wenn ein Bug ( maybe we call it feature ) gefunden wird er ja unmittelbar behoben werden muss. Nadla und co machen das alles nur aus Spass an der Freude, vergesst das bitte nicht. Ich fuer meinen Teil bin einfach nur schon froh darueber, dass mein Stein trotz seines Alters so viel kann und so fix unterwegs ist, aber die Zeit bleibt nicht stehen und ewig wird auch der Stein nicht leben, vergesst das nicht.
Es ist natuerlich interessant, neue Erfahrungsberichte zu lesen und eigene Erfahrungen zu machen, aber alles in allem kommt das mehr als 2 Jahre zu spaet ^^
Der Stein ist zu alt, als dass sich jetzt nochmal jemand ernsthaft dran setzen wuerde um eine Software speziell nur fuer den Stein umzuschreiben, die so komplex ist, dass so viele Fehler vorprogrammiert sind, sodass es Ewigkeiten dauert bis es ordentlich laeuft.
Versucht euch mal vorzustellen, wieviele Arbeitsstunden Nadlabak und die anderen Devs ins Milestone gesteckt haben und seit Dankbar. Wenn man noch Bugs findet kann man die posten und die gucken sich das an, aber wenn keine Loesung zu finden ist oder es einfach ein zu utopischer Aufwand waere das zu fixen kann ich das voll und ganz nachvollziehen.
Es gab mal ne Zeit, da hatten viele das Problem, dass der Stein nach 3 Stunden leer war. Das Ursache wurde erforscht, das Problem gefunden und letztendlich gefixt.
Nun haelt der Stein bei manchen Usern 3 Tage und es wird wegen Winzigkeiten so ein Aufwand betrieben?
Fipsy: Klar, dein Akkudrain ist schon heftig und interessant waere es, herauszufinden woran das liegt, aber deine staendigen Kommentare wie "dann MUSS da etwas gemacht werden" etc. finde ich unangebracht.
Wenn du ein Geraet willst, dass jede App problemlos ruckelfrei darstellen kann und sofort reagiert, musst du dir wohl oder uebel ein aktuelles Device besorgen. Du kannst mit nem Kaefer auch keine 300 km/h auf der Autobahn heizen, egal wie gut dein Feintuning ist
Ich finds ein bisschen frech, Forderungen an andere zu stellen, dass wenn ein Bug ( maybe we call it feature
) gefunden wird er ja unmittelbar behoben werden muss. Nadla und co machen das alles nur aus Spass an der Freude, vergesst das bitte nicht. Ich fuer meinen Teil bin einfach nur schon froh darueber, dass mein Stein trotz seines Alters so viel kann und so fix unterwegs ist, aber die Zeit bleibt nicht stehen und ewig wird auch der Stein nicht leben, vergesst das nicht.Es ist natuerlich interessant, neue Erfahrungsberichte zu lesen und eigene Erfahrungen zu machen, aber alles in allem kommt das mehr als 2 Jahre zu spaet ^^
Der Stein ist zu alt, als dass sich jetzt nochmal jemand ernsthaft dran setzen wuerde um eine Software speziell nur fuer den Stein umzuschreiben, die so komplex ist, dass so viele Fehler vorprogrammiert sind, sodass es Ewigkeiten dauert bis es ordentlich laeuft.
Versucht euch mal vorzustellen, wieviele Arbeitsstunden Nadlabak und die anderen Devs ins Milestone gesteckt haben und seit Dankbar. Wenn man noch Bugs findet kann man die posten und die gucken sich das an, aber wenn keine Loesung zu finden ist oder es einfach ein zu utopischer Aufwand waere das zu fixen kann ich das voll und ganz nachvollziehen.
Es gab mal ne Zeit, da hatten viele das Problem, dass der Stein nach 3 Stunden leer war. Das Ursache wurde erforscht, das Problem gefunden und letztendlich gefixt.
Nun haelt der Stein bei manchen Usern 3 Tage und es wird wegen Winzigkeiten so ein Aufwand betrieben?
Fipsy: Klar, dein Akkudrain ist schon heftig und interessant waere es, herauszufinden woran das liegt, aber deine staendigen Kommentare wie "dann MUSS da etwas gemacht werden" etc. finde ich unangebracht.
Wenn du ein Geraet willst, dass jede App problemlos ruckelfrei darstellen kann und sofort reagiert, musst du dir wohl oder uebel ein aktuelles Device besorgen. Du kannst mit nem Kaefer auch keine 300 km/h auf der Autobahn heizen, egal wie gut dein Feintuning ist
-FuFu-
Ikone
- 3.296
- Themenstarter
- #289
ich hab ja keine Probleme und forsch auch nicht...
und fipsy forscht ja für sich selbst und stellt ja keine forderung, sonden lässt uns ans seinen vermutungen teilhaben...
und hier ein post im xda Forum, der auch für uns alle interessant sein kann: xda-developers - View Single Post - [ROM] CyanogenMod 7.2.4e (Android 2.3.7) [20121230]
und es ist auch wichtig für nadlabak, falls wir probleme haben, da so ein bugreport erstellt werden kann, den man ihm zukommen lassen kann...
und TeCci, zu deinem letzten Satz:
nen Käfer mit nem Porschemotor drin könnte das vielleicht schaffen
aber lassen wir das sonst ändet das ganze wieder in nem OT Wahn ^^
und fipsy forscht ja für sich selbst und stellt ja keine forderung, sonden lässt uns ans seinen vermutungen teilhaben...
und hier ein post im xda Forum, der auch für uns alle interessant sein kann: xda-developers - View Single Post - [ROM] CyanogenMod 7.2.4e (Android 2.3.7) [20121230]
und es ist auch wichtig für nadlabak, falls wir probleme haben, da so ein bugreport erstellt werden kann, den man ihm zukommen lassen kann...
und TeCci, zu deinem letzten Satz:
nen Käfer mit nem Porschemotor drin könnte das vielleicht schaffen
aber lassen wir das sonst ändet das ganze wieder in nem OT Wahn ^^
TeCci
Stamm-User
- 48
Wie ich wusste, dass sowas kommt, aber damit wuerdest du implizieren, dass wir ne bessere CPU in den Stein einbauen koennten
Und das hat bisher keiner geschafft oder?
Und das hat bisher keiner geschafft oder?
-FuFu-
Ikone
- 3.296
- Themenstarter
- #291
nein, ich glaub es hat niemand nen quad-core in seinem Stein
aber beim Käfer ist das ganze auch einfacher zu erledigen
aber beim Käfer ist das ganze auch einfacher zu erledigen
fipsy
Stamm-User
- 293
Hallo!
@TeCci: Also ich finde, dass du das aber ziemlich verzerrt darstellst. Es ist mit Sicherheit kein "Feature", wenn der Akku ohne weiteren Nutzen innerhalb von 7 Stunden leer ist. Es sei denn, wir wollen uns ins Lächerliche begeben und den Stein als Hosentaschenwärmer deklarieren. :-(
Natürlich machen sich Leute bei der Programmierung ehrenamtlich Mühe, das hat auch keiner bezweifelt. Aber wer seine Freizeit investiert, um einem schwer zu diagnostizierenden Programmierfehler auf die Spur zu kommen, macht auch ehrenamtliche Arbeit für die Gemeinde der CM7-Nutzer. Irgendwie wird das aber gar nicht wahrgenommen! Ich bin als Entwickler jedenfalls immer äußerst froh, wenn mir jemand mit fundierten Hinweisen bei der Fehlerbehebung behilflich ist.
Die Ursache liegt am neu eingeführten 2ndboot Kernel (siehe unten). Vorher lief das Gerät auch mit CM7 ja wohl ohne diese Probleme. Und wenn ein Problem durch eine Änderung nachträglich eingebaut wurde, sich über zahlreiche Releases hinzieht (ist das "unmittelbar"?) und man als User nichts anderes dagegen tun kann, als auf eine ganz alte Version umzusteigen, dann darf man ja mal sagen, dass da dringend was getan werden muss. Und mehr habe ich nicht gemacht. Insbesondere wenn man den Eindruck gewonnen hat, dass das Problem von vielen nicht ernst genommen wird, weil sie es selbst nicht haben.
Der ganze, große Nutzen eines so schönen Betriebssystems wird durch einen solchen Fehler in weiten Teilen wieder zunichte gemacht. Da ist es letztlich auch egal, ob das Gerät nun uralt oder ganz neu ist. Und wenn jemand investigativ tätig ist und etwas Druck macht, so wie ich es getan habe, passiert erfahrungsgemäß auch was. Wenn keiner was sagt, wird der Fehler auch nie behoben.
Und nun zum Fehler selbst:
Gestern Abend trat er wieder auf. Wie von FuFu vorgeschlagen, habe ich dann einmal WiFi deaktiviert: Keine Änderung. Dann habe ich 3G / UMTS abgeschaltet: Keine Änderung. Daran liegt es also nicht. Dann habe ich einen sogenannten "Hot Reboot" gemacht, also nur das Android System neu geladen ohne den Kernel neu zu laden (also ab dem Zeitpunkt, wo beim Booten die CM7-Animation erscheint): Keine Wirkung. Erst als ich auch den Kernel neu geladen habe, verschwand der Saug-Modus wieder (siehe Diagramm unten).
Für mich ist damit hieb- und stichfest belegt, dass der neue Kernel schuld an dem Akku-Problem ist. Und das deckt sich ja auch mit den vielen Aussagen, dass das Problem erst mit Einführung des neuen Kernels auftrat. Es ist also irgendwie eine Verschlimmbesserung eingetreten.
Leider kann man den Kenel als User nicht ohne weiteres durch einen älteren austauschen und auch die Governors, die ich weiterhin stark im Verdacht habe, kann man nicht mehr wie früher als separate Module nachladen, was sehr schade ist. Dadurch entzieht sich jede weitere Debug-Mission dem Zugriff aller User, die sich nicht mit Kernel-Programmierung beschäftigen können oder wollen.
@TeCci: Also ich finde, dass du das aber ziemlich verzerrt darstellst. Es ist mit Sicherheit kein "Feature", wenn der Akku ohne weiteren Nutzen innerhalb von 7 Stunden leer ist. Es sei denn, wir wollen uns ins Lächerliche begeben und den Stein als Hosentaschenwärmer deklarieren. :-(
Natürlich machen sich Leute bei der Programmierung ehrenamtlich Mühe, das hat auch keiner bezweifelt. Aber wer seine Freizeit investiert, um einem schwer zu diagnostizierenden Programmierfehler auf die Spur zu kommen, macht auch ehrenamtliche Arbeit für die Gemeinde der CM7-Nutzer. Irgendwie wird das aber gar nicht wahrgenommen! Ich bin als Entwickler jedenfalls immer äußerst froh, wenn mir jemand mit fundierten Hinweisen bei der Fehlerbehebung behilflich ist.
Die Ursache liegt am neu eingeführten 2ndboot Kernel (siehe unten). Vorher lief das Gerät auch mit CM7 ja wohl ohne diese Probleme. Und wenn ein Problem durch eine Änderung nachträglich eingebaut wurde, sich über zahlreiche Releases hinzieht (ist das "unmittelbar"?) und man als User nichts anderes dagegen tun kann, als auf eine ganz alte Version umzusteigen, dann darf man ja mal sagen, dass da dringend was getan werden muss. Und mehr habe ich nicht gemacht. Insbesondere wenn man den Eindruck gewonnen hat, dass das Problem von vielen nicht ernst genommen wird, weil sie es selbst nicht haben.
Der ganze, große Nutzen eines so schönen Betriebssystems wird durch einen solchen Fehler in weiten Teilen wieder zunichte gemacht. Da ist es letztlich auch egal, ob das Gerät nun uralt oder ganz neu ist. Und wenn jemand investigativ tätig ist und etwas Druck macht, so wie ich es getan habe, passiert erfahrungsgemäß auch was. Wenn keiner was sagt, wird der Fehler auch nie behoben.
Und nun zum Fehler selbst:
Gestern Abend trat er wieder auf. Wie von FuFu vorgeschlagen, habe ich dann einmal WiFi deaktiviert: Keine Änderung. Dann habe ich 3G / UMTS abgeschaltet: Keine Änderung. Daran liegt es also nicht. Dann habe ich einen sogenannten "Hot Reboot" gemacht, also nur das Android System neu geladen ohne den Kernel neu zu laden (also ab dem Zeitpunkt, wo beim Booten die CM7-Animation erscheint): Keine Wirkung. Erst als ich auch den Kernel neu geladen habe, verschwand der Saug-Modus wieder (siehe Diagramm unten).
Für mich ist damit hieb- und stichfest belegt, dass der neue Kernel schuld an dem Akku-Problem ist. Und das deckt sich ja auch mit den vielen Aussagen, dass das Problem erst mit Einführung des neuen Kernels auftrat. Es ist also irgendwie eine Verschlimmbesserung eingetreten.
Leider kann man den Kenel als User nicht ohne weiteres durch einen älteren austauschen und auch die Governors, die ich weiterhin stark im Verdacht habe, kann man nicht mehr wie früher als separate Module nachladen, was sehr schade ist. Dadurch entzieht sich jede weitere Debug-Mission dem Zugriff aller User, die sich nicht mit Kernel-Programmierung beschäftigen können oder wollen.
Anhänge
Zuletzt bearbeitet:
fipsy
Stamm-User
- 293
-FuFu- schrieb:
Eine sehr feine Sache! Aber bei diesem speziellen Fehler hilft uns das leider nicht, weil es ja kein offensichtlicher Bug ist, der durch ein Logfile analysiert werden könnte, da er nicht zu einem bestimmten Zeitpunkt festzumachen ist.
M
MOMaTriX
Neues Mitglied
- 2
fipsy schrieb:
Hi,
ich melde mich auch al zu dem thema:
ich hatte damals (ich glaube bei der ho!no! mod und bei dem standard cm7 das problem, dass auch mein handy nach einer gewissen laufzeit aufeinmal total schnell leerging. die apps waren soweit immer im normalen % bereich, nur android-system (oder service?) ist dann ziemlich angestiegen.
ich musste das handy dann zwingend neustarten, danach war aber auch wieder alles in butter und der verbrauch ganz normal. erst nach ich sag mal ca 180std laufzeit des handys (ohne neustart, akku dazwischen immer geladen) trat der fehler dann wieder auf.
ich weiß nicht ob das evtl der selbe fehler ist/war aber dieser trat halt auch bei versionen ohne den 2ndbootkernel auf.
TeCci
Stamm-User
- 48
Fipsy: Wie ich schon schrieb, finde ich es ja gut, dass sich jemand so intensiv damit befasst, seine Erfahrungen mit anderen teilt um gemeinsam nach einer Loesung zu finden.
Dennoch ist es ja nunmal nicht so, dass der Fehler bei allen auftritt. Wenn es gravierende Fehler gibt, die bei allen auftreten, werden diese Erfahrungsgemaeß innerhalb weniger Stunden/Tage behoben.
Bei deinem Problem ist das interessante, dass ein Stein dieses Problem hat, ein anderer jedoch nicht.
Die Ursachenforschung wird sich vermutlich noch sehr lang hinziehen, denn ein einfach zu findener Fehler ist es auf jeden fall nicht.
Jeder legt seine Prioritaeten anders, benutzt sein Smartphone in Relation gesehen anders und fuer jeden das perfekte Universalbuild gibt es nun mal nicht.
Zu deinem letzten Post: Scheinbar hast du das Problem auf den Kernel eingrenzen koennen, aber wieso zum Teufel tritt das Problem bei dem anderen Stein dann nicht auf, wenn alles auf demselben Stand ist?
Das ist wieder so ein Fehler, der entweder an unterschiedlicher Hardware liegen muss oder sich einfach nicht logisch erklaeren laesst.
Dennoch ist es ja nunmal nicht so, dass der Fehler bei allen auftritt. Wenn es gravierende Fehler gibt, die bei allen auftreten, werden diese Erfahrungsgemaeß innerhalb weniger Stunden/Tage behoben.
Bei deinem Problem ist das interessante, dass ein Stein dieses Problem hat, ein anderer jedoch nicht.
Die Ursachenforschung wird sich vermutlich noch sehr lang hinziehen, denn ein einfach zu findener Fehler ist es auf jeden fall nicht.
Jeder legt seine Prioritaeten anders, benutzt sein Smartphone in Relation gesehen anders und fuer jeden das perfekte Universalbuild gibt es nun mal nicht.
Zu deinem letzten Post: Scheinbar hast du das Problem auf den Kernel eingrenzen koennen, aber wieso zum Teufel tritt das Problem bei dem anderen Stein dann nicht auf, wenn alles auf demselben Stand ist?
Das ist wieder so ein Fehler, der entweder an unterschiedlicher Hardware liegen muss oder sich einfach nicht logisch erklaeren laesst.
fipsy
Stamm-User
- 293
TeCci schrieb:
Ich bin mir ziemlich sicher, die Ursache mittlerweile gefunden zu haben. So lange hats also gar nicht gedauert. Es liegt mit sehr hoher Wahrscheinlichkeit schlichtweg am conservative Governor! Das erklärt auch, warum der eine das Problem hat und der andere nicht. Die meisten benutzen nicht den conservative, sondern den on demand oder interactive. Ich vermute mal, dass das Problem dort nicht auftritt.
Wie alle wissen, habe ich die Governors schon seit vielen Wochen im Verdacht, schwere Probleme zu verursachen. Also sowohl Lags, als auch Battery-Drains oder inadäquate CPU-Taktungen. Aber irgendwie wird meine Vermutung bis heute nicht richtig ernst genommen.
Als dieses Problem regelmäßig auftrat, hatte ich den conservative Governor ohne CPU-Tuner benutzt. Jetzt habe ich den CPU-Tuner wieder aktiviert und so eingestellt, dass er den conservative Governor bei jedem Ein- und Ausschalten des Displays neu aktiviert. Und seitdem ist dieser Drain nicht ein einziges Mal mehr aufgetreten! Ich bleibe bei dem, was ich hier seit vielen Wochen gebetsmühlenartig aber nutzlos wiederhole: Die Governors (zumindest aber der Conservative) haben riesige Macken!
Vielleicht mag jemand von euch ja mal versuchen, meinen Fehler zu reproduzieren, indem er bei sich den conservative Governor aktiviert?!
Gruß, Volker
Der ursprüngliche Beitrag von 12:07 Uhr wurde um 12:17 Uhr ergänzt:
MOMaTriX schrieb:
Ich glaube, das ist noch wieder ein anderer Fehler. Ich habe das Gefühl, dass dieser Fehler mehr in die Kategorie "Mein Handy wird nach 2-3 Tagen so langsam" gehört, wovon auch sehr viele berichten. Dieser Fehler hat vermutlich nichts mit den Governorn zu tun, wie ich es zuerst dachte. Denn es hatte jemand mit diesem Problem mal meinen Vorschlag getestet, es mit CPU-Tuner zu versuchen. Aber das war leider nicht erfolgreich.
T
thisismespam
Fortgeschrittenes Mitglied
- 4
Ich würde gerne ein gravierenden Bug hinzufügen, den in entdeckt habe.
Leider möchte ich mich durch den ganzen thread quälen.
Ich habe CM7 drauf, mit FUFUs Script für die swap datei.
Und zwar, wenn man angerufen wird, dann ist es besetzt. Reboot behebt das Problem. Aber so ist das unbenutzbar. Ich werde wohl wechseln.
Leider möchte ich mich durch den ganzen thread quälen.
Ich habe CM7 drauf, mit FUFUs Script für die swap datei.
Und zwar, wenn man angerufen wird, dann ist es besetzt. Reboot behebt das Problem. Aber so ist das unbenutzbar. Ich werde wohl wechseln.
fipsy
Stamm-User
- 293
thisismespam schrieb:
Hast du das Problem grundsätzlich? Ist es nicht möglich, dich anzurufen? Hat es bei anderen CM7-Versionen funktioniert und welche Version genau benutzt du? Hört sich für mich sehr seltsam an der Fehler!
Der ursprüngliche Beitrag von 01:15 Uhr wurde um 01:19 Uhr ergänzt:
Ich hatte den Modem-Fehler mit Reboot übrigens wieder. Er ist also doch noch nicht behoben!
Ich habe mal den Bugreport mit dem oben geschilderten "Left-Shift + Del" erzeugt. Die Frage ist aber: Wo soll ich den hinsenden? Das schreibt nadlabak leider nicht ;-).
-FuFu-
Ikone
- 3.296
- Themenstarter
- #300
einfach im xda forum im cm7 thread posten und den log anhängen und natürlich ne fehlerbeschreibung mit in den post hauen ^^
und natürlich ne fehlerbeschreibung mit in den post hauen ^^
