ja habe ich.
Edit: Wenn ich den nicht aktualisiere, werden mir keine Programme angezeigt die noch im Hintergrund laufen .
Druckbare Version
dann deinstalliere das update und schau dann ob es weiterhin probleme gibt
Kann es sein dass bei der JPU das aktivieren von XT9 nicht gespeichert wird? Wenn ich mein Handy neustarte ist der Haken immer wieder weg.
Ich muss sagen obwohl JPU so schön schnell ist, dafür aber voll verbugt, es muss bald die 2.2.2 raus :D
doch bei mir werden alle programme angezeigt die ich in den hintergrund lege.
oder welche programme meinst du ?
gibt es eigentlich schon ne lösung für kies?
Bugliste
Fassen wir mal zusammen:
In der JPU gibt es einige Bug's,
diese Bug's können, aber müssen nicht bei allen genau so sein.
- Kies geht nicht
- Gallerysensor Bug (Sensor schaltet nicht ab)
- Taskmanager verschwindet nach Neustart
- XT9 ebenso, anscheinend werden die Einstellungen nicht gespeichert (Dateizugriffsrechte falsch?)
- Manche haben höheren Akkuverbauch
Hab ich was vergessen?
Das einige was ich als Bug hab ist Kies.
Aber das wäre mir ohne Test nicht mal aufgefallen, da ich Kies nicht brauch. (wozu auch).
Achja und XT9, hat Swype XT9 ? Ich merk da nix beim sliden.
Also die sind mir auch bekannt. Einige Apps gehen wohl auch nicht Sprich Probleme mit dem Market das die Apps garnicht da sind. Bei Swype hast du denke ich kein XT9 wozu auch.
Naja das mit dem Market ist ja ein Problem von allen geleakten Firmwares seit je her.
Man muss den Fingerprint ändern.
Was aber wirklich schön ist. Seit ich das SGS hab (Juli), hab ich es noch nie Erlebt, dass es ohne Lagfix so "fix" ist.
Auch nach Tagen und mit über 130 Apps nicht.
Zum Thema Akkuverbrauch: zwei Tage lang lief alles in Ordnung, am gestrigen Abend hatte ich noch ~70% Strom (obwohl es in der letzten 2 Stunden verdächtig schnell weniger wurde), heute um 8 Uhr nur noch 2%! Akkustatistik meinte, dass ganze 23% der Gesamtleistung WLAN verbraucht hat und 20% "Akku bei Standby" (Radio).
Der Akku muss ja auch mehr liefern. Mehr Leistung kann man softwarebasiert nur rausholen wenn irgendwo ein Leistungsloch vorhanden ist. Von nix kommt nix. Habe mal separate Tests durchgeführt mit so ziemlich jeder FW und diversen ROM's. Am besten war die Kombination aus Stock JPO + ULF. Danach Stock 2.2.1 also JPU und dann Darky. Cyanogen ist noch ein akkufresser bringt aber am meisten Leistung.
Was auch erstaunlich ist: Ich habe von relativ vielen Seiten schon gehört das im Standby unmengen an Energie verloren geht. Habe deswegen auchschon einmal Verpennt weil ich vergessen hatte das Teil an die Buchse zu hängen ;)
Ja mit WLAN brauchts viel derzeit, merk ich auch.
Jedoch ist es irgendwie nicht gleichmässig mal so, mal so.
Mit dem ersten SGS hab ichin 8h über Nacht 1% Akkuverlust, dabei alles (APN, WLAN) ausgeschaltet.
Mit dem anderen sind es bei aktivierten WLAN 7-8% gewesen.
Jedoch ruft das letztere nichts ab, kein Push etc.
Ist die automatische und vom Displayinhalt abhängige Helligkeitsregelung bei der JPU-Firmware noch aktiv?
Nun, es gibt ja eigentlich nicht DIE Helligkeitsregelung. Bei den Froyos sind es ja zwei. Einmal die, die ja alle kennen und vom Lichtsensor abhängig ist und dann noch eine, die je nach Bildinhalt die Helligkeit etwas verringert oder erhöht.
Ich hoffe du verstehst was ich meine.
Mal ein kleines Beispiel wo man das gut sehen kann... Öffne bei Opera Mobile mal die Menüauswahl (unten rechts der Maulschlüssel). Dabei wirst du (oder vielleicht auch nicht xD) feststellen, dass sich die Displayhelligkeit erhöht, sobald sich dieses Menü öffnet.
Du kannst auch zBsp. auf die Seite http://project-voodoo.org/ gehen, ein Stück weit reinzoomen so dass der Banner mit dem Voodoo-Androiden halbe Displayhöhe hat und dann diesen Banner übers Display scrollen. Je mehr der Banner von der Displayfläche einnimmt, desto heller. Wenn er ganz aus dem Sichtbereich gescrollt ist, ist's wieder dunkler.
Hmm, nicht dass du jetzt denkst ich will dich verarschen... das ist wirklich so (zumindest bei mir). :D
Edit:
Und entschuldige bitte, dass ich vorhin im falschen Thread danach gefragt habe. :)
Bin heut etwas durcheinander...
Bis dato hatte ich beim "normalen" arbeitstag mittags 99%, manchmal auch 98%. Jetzt sinds 90% xD Also ich finde das schon eine gewaltige steigerung. Ich hoffe das da noch was geregelt wird.
Der Gallery Sensor Bug ist kein Batteriefresser!
Hab nun extra die "kaputte" Galerie geladen.
Mein Senso meint, er wäre seit fast 13 Stunden am laufen (in der Batteriestatistik).
Ich hab aber dennoch über Nacht nur 1% Akkuverlust.
Hab genau den selben Versuch gemacht, Sensor lief 9std - dann ging das SGS aus, wohlgemerkt, vorher war es vollgeladen.
oO In der Nacht bewegst du dein Telefon auch nicht, oder?^^ ich denke man merkt den Unterschied erst wenn man es rumträgt und bewegt damit der sensor auch wa szu tun hat ;)
:D in der Nacht liegt das Tele ruhig. Bin im Moment aber auch wieder zurück auf JPO, da ich nicht rausfinden konnte woran es lag...
Ich dachte das wär nen Witz, als ich meinte, man müsse das SGS ruhig halten.
Meinst Du echt, der Sensorbug und das Shaken machts?
Lass doch mal den Monitor alufen und geh eine Runde laufen mit der Bug Galerie.
auf jeden Fall. Die Sensoren "melden" sich ja bei jeder Bewegung und das App versucht darauf zu reagieren. Ich weiss nicht wie das ganze Programmiert wurde und welche Schnittstellen angesprochen werden. Aber ich gehe stark davon aus das die App nur dann Leistung bezieht (nebst grundbedarf) wenn sie durch Bewegung angesprochen wird.
Ich glaub' ich habe zum ersten Mal mein Handy mit JPU und eingeschaltetet WLAN über Nacht gelassen. WLAN Standby Richtlinie ist standardmäßig auf "nie abschalten" gestellt. Mit den anderen Firmwares hatte ich dabei aber keine Akku-Fresserei. Höchstens 7% über die Nacht auch mit WLAN, nicht doch wie jetzt 70%!
Was glaubst Du was ich mach :-)
Gallery taucht so garnicht im Monitoring auf.
Unter Systemprozesses gibts sensorserver_ya, der hat sich bisher knapp 3 min genommen.
Mediaserver 2 sekunden.
Welcher Prozess ist das "Gallerie" was in der Akkunutzungsstatistik angezeigt wird?
com.cooliris.media?
Edit:
war vorhin 1 Stunde kräftig Schnee schieben, ich dnke das wackelt genug.
Kein Prozess hat bei mir 1h sonderlich gezogen.
ich denke das geht eher unter "android system" oder sonstwas undurchsichtiges. Das ganze hat dann ne Schnittstelle für applikationen die eigtl. nur Informationen über diese Schnittstelle beziehen. Einen spezielle Prozess kann ich dir nicht nennen, aber wird wie bei windows ähnlich dem "svchost" sein ;)
Schnee "schieben" ? o0 Meinst du schaufeln? Ich stelle mir das kurios vor wenn ich da nen Typen sehe der schnee rumschiebt^^
Achtet mal bitte auf die Standarteinstellungen die JPU mit sich bringt!
WLAN: Nie aus.
Anzeige: Keine Animation
EDIT: Mit neuem Quadrant sind die Werte einfach miserabel, 1014 bei mir, wo es schon mal 2380 war mit OC/UV :D
Ich schiebe ja, die Honda Schneefräse vor mir her, bzw. ich laufe mit :-)
Ich hab im Monitoring sämtliche Prozesse (System Prozesses).
Keiner von denen zeigt einen fortwährend hohen (unnormalen) Akkuverbrauch.
Es kann auch genausogut sein, dass die Anzeige des Sensors falsch ist und alle sich verrückt machen?!
Es kann demnach auch sein, dass wie bei vygi eher was mit dem Modem nicht stimmt und manchmal WLAN oder auch 3G nicht mehr von Vollpower auf idle schalten kann?!
Vygi müsste, wenn er jetzt immer 70% Akkuverbrauch hat, mit der JPP Modemdatei testen.
Am schönsten wäre es ja noch, wenn er auch diesen angeblichen Sensorbug hat.
Ich würd ja auch selber testen, aber ich hab derzeit keinen ungewöhnlichen Verbrauch, weder mit dem Handy das den Sensorbug hat, noch mit dem was immer mit WLAN läuft.
So sieht es bei wem aus der den Bug hat. Anscheinend sind jedoch nicht alle Geräte betroffen. StrangeZitat:
Menu -> Settings -> About phone -> Battery use:
18h 39m 34s since unplugged
Gallery: 37%
Display: 36%
Wi-Fi: 10%
Cell standby: 6%
Android System: 6%
Phone idle: 3%
mobi.mgeek.TunnyBrowser: 2%
Seltsam.
Ich hab da 14h 1m 15s seit letztem Ausstecken:
Display 85%
Akku bei Standby 7%
WLAN 5%
Telefon in Standby 3%
sonst nix, wobei mir eben das andere sagt, seit 13 Stunden zieht der Sensor der Gallery
Ist bei mir aber auch so der Sensor von der Galerie steht bei 19 Stunden.Und ich merke vom Akku rein garnichts daran das der saugt. Hab jetzt innerhalb eines Tages 45% verloren. Was für meine Verhältnisse vollkommen normal ist.
Also, bei den XDA liesst man auch, dass die Anzeige des Sensor's bei der Batterie in den meissten Fällen doch keine Auswirkung auf die Batterie hat.
Es gibt da einen ganz interessanten Thread:
http://forum.xda-developers.com/show....php?p=9759824
Und was man ganz häufig liest, dass die Richthofen Dateien mehr Bugs haben als die von Samfirmware (mid- und lowlevel Package)
Ach und nen Kies Fix gibts auch schon:
http://forum.xda-developers.com/show...postcount=1125
Jup, das "hilft" mir. Ich hatte anfangs gehofft, dass dies nur ein Bug sei... ist wohl aber doch ein Feature :(
Wahrscheinlich bin ich auch wieder der einzige den das nervt. Ich versteh echt nicht warum Samsung das Display so "kaputt" machen muss. Als wäre der Blaustich nicht schon schlimm genug. So wie es jetzt (bei mir) ist, ist das Display nur oberer Durchschnitt. Umso schlimmer ist's für mich, weil ich genau weiß (Eclair + Voodoo Beta4) was das Display wirklich kann :(
Was ich grad lese, Samsung hat einen neuen Bootloader integriert.
Daher haben auch manche den 3 Tastenmodus (Affengriff) wieder.
Nun bekommt das ganze auch Licht :-)
Die Lowlevelpackage hat den Bootloader mit drin, die Midlevel nicht. Gell?
Es wird berichtet, dass der Akkuverbrauch sich vom Mid- zu Lowlevel unterscheidet.
Demnach kann man ja nur Schlussfolgern. ohne den neuen Bootloader ist die JPU eben nicht komplett und spinnt herum.
Zitat:
About SBL included:
Samsung Secondary Bootloader (SBL) v3.0.. Copyright (C) Samsung Electronics Co., Ltd. 2006-2010.... Board Name: %s %s....ARIES...REV 03.. Build On: %s %s..Dec 3 2010.00:34:06....boot_kernel.%s: Debug Level 0x%x....%s: Debug Level Low.....loadkernel.
My SBL from device (not sure when it was flashed)
Samsung Secondary Bootloader (SBL) v3.0.. Copyright (C) Samsung Electronics Co., Ltd. 2006-2010.... Board Name: %s %s....ARIES...REV 03.. Build On: %s %s..Sep 21 2010.14:07:24....boot_kernel.%s: Debug Level 0x%x....%s: Debug Level Low.....loadkernel.