[Diskussion] CyanogenMod 7 mit 2ndboot für das Milestone (CM7)

[fipsy]

Mal ne neue Frage:

Ich habe meine build.prop nach den Hinweisen hier modifiziert, um eine App dauerhaft im Speicher zu halten. Leider geht diese Änderung bei OS-Updates wieder verloren. Komplette Dateien kann man ja über Einträge in /system/etc/custom_backup_list.txt vor der Löschung bewahren, aber wie sieht das mit Änderungen an einer Datei wie build.prop aus? Kann man die auch irgendwie "bewahren" und nach dem Update wieder zusammenführen? Hat da jemand ne Lösung?

 

[-FuFu-]

per script, was man z.b. beim einspielen der cmupdate.zip ausführen lässt?
oder man braut sich halt nen script, was man selbst per OR nach dem updaten ausführt...

ich geb dir mal ne zeile als beispiel ^^

#!/sbin/bash
sed -i "s/sys.keep_app_1.*/sys.keep_app_1=com.android.phone/g" /system/build.prop

oder du hängst deine zeilen einfach hinten an die build.prop

echo "sys.keep_app_1=com.android.phone" >> /system/build.prop

 

[fipsy]

Dankeschön! Hätte ich eigentlich auch selbst drauf kommen können, aber am Karfreitag bin ich faul.

Mir war noch gar nicht aufgefallen, dass man in der OR auch Scripte ausführen kann, ohne die Shell starten zu müssen...

 

[-FuFu-]

die funktion gibt es aber schon länger
kannst dir ja nen schönes script bauen, was alles das ändert, was du sonst per hand machen würdest ^^ denn mich persönlich nervt das ändern der build.prop immer, aber ich hab mir da auch schon was zusammen gebaut, muß es nur mal auf den neusen stand bringen

 

[fipsy]

Nunja, das ist meine bisher erste und einzige Änderung an der build.prop. Gibt es eigentlich irgendeine Zusammenfassung aller Parameter, die man mit der build.prop so einstellen bzw. verändern kann und eine entsprechende Erklärung / Beschreibung?

 

[-FuFu-]

ich glaub nicht, man kann sich das aber zusammen suchen in den diversen Geräteforen ^^
hier mal alle meine zusätlichen änderungen ^^

ro.telephony.call_ring.delay=1500
windowsmgr.max_events_per_sec=160
wifi.supplicant_scan_interval=180

dalvik.vm.startheapsize=4m
ro.HOME_APP_ADJ=1
video.accelerate.hw=1
persist.sys.use_dithering=0 
persist.sys.purgeable_assets=1
pm.sleep_mode=1

media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
ro.mot.buttonlight.timeout=0

debug.sf.hw=1
ro.media.enc.jpeg.quality=100
debug.performance.tuning=1
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4095,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4094,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4093,262140,770880,4096,30643,770880
net.tcp.buffersize.gprs=4094,87380,256960,4096,16384,256960
net.tcp.buffersize.wimax=4094,87380,256960,4096,16384,256960
debug.composition.type=gpu

ro.kernel.android.checkjni=0
ro.kernel.checkjni=0
ro.config.hw_quickpoweron=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.config.nocheckin=1

ro.ril.disable.power.collapse=0
ro.media.dec.jpeg.memcap=10200000 
ro.media.enc.hprof.vid.bps=10200000
debug.sf.nobootanimation=0

in wie weit was dazwischen ist, was beim milestone nicht geht kann ich gerade nicht sagen aber wäre möglich, da es wie gesagt aus vielen Foren zusammen gesucht ist
die ersten 3 werte sind änderungen, der rest zusätzliche einträge, kannst ja googlen und testen ^^

 

[fipsy]

Danke, sehr interessant! Ich glaube, einige Sachen wären auch bei mir von Belang. Werde mich mal damit beschäftigen, wenn ich nichts besseres zu tun habe . Hier gibts ne ganz gute Zusammenfassung mit kurzen Erklärungen: http://forum.xda-developers.com/showthread.php?t=1227269&highlight=TWEAKS

 

[-FuFu-]

daher hatte ich glaub ich auch das ein oder andere ^^
man muß nur eventuell ein paar werte anpassen, da sie nicht unbedingt fürs ms waren, aber man hat wieder nen bisschen was zum testen

 

[fipsy]

die ersten 3 werte sind änderungen, der rest zusätzliche einträge, kannst ja googlen und testen ^^

persist.sys.purgeable_assets=1 ist übrigens auch schon in der Standard build.prop von CM7 so gesetzt. Ist also doppelt gemoppelt ;-)

 

[-FuFu-]

kann ma vorkommen ich muß eh irgendwann man überarbeiten ^^

 

[fipsy]

Hallöchen,

kann vielleicht jemand folgendes Problem bestätigen?

Ich habe die Regelung der Display-Helligkeit auf "automatisch" gestellt und auch einige Stufen manuell angepasst (siehe Screenshot unten). Letztens ist mir aufgefallen, dass hin und wieder einmal nach längerer Betriebszeit des Gerätes die automatische Helligkeitssteuerung versagt: Beim Einschalten des Displays mit dem Ein/Aus-Knopf wird das Display mit korrekter Helligkeit eingeschaltet, aber wenn ich mich danach in eine dunklere (oder hellere) Zone bewege, bleibt die Helligkeit auf dem aktuellen Stand und wird nicht angepasst, wie es eigentlich normalerweise sein sollte. Die angezeigten Sensordaten ändern sich auch nicht, was heißt, dass der Sensor entweder keine Daten mehr liefert, oder dass der Kernel-Treiber einen Fehler hat, der die Sensordaten empfängt. Da beim Einschalten des Displays der gültige Sensorwert einmalig korrekt angezeigt wird, scheint der Sensor wohl Daten zu liefern, aber eben nicht mehr kontinuierlich. Daher tippe ich eher auf einen Fehler im ensprechenden Modul.

Ein Neustart des Android-Systems (hot reboot) bringt auch nichts, nur ein Neustart des Gerätes. Daher tippe ich auf ein Kernel-Problem.

 

[inspire]

Hi.

das gleiche habe ich auch schon beobachtet. mein workaround: helligkeit einmal in einen manuellen und dann wieder in den automatischen modus stellen. habe übrigens die standard-automatik-einstellungen.

inspire

 

[fipsy]

Ah, okay! Das werde ich dann nächstes Mal auch probieren.

Vielleicht kann nadlabak etwas dazu sagen? Ist das Modul für die Helligkeitssteuerung des Displays Open Source? Ich nehme mal an, ja. Dann könnte man den Fehler sicher auch beheben?!

 

[TeCci]

Der Fehler existiert schon ewig, ich glaube sogar schon seit Stock. Auf jedenfall wars unter CM6 auch schon so, was ich als erstes drauf hatte. Ergo ists mir aufgefallen, kurz nachdem ich mich hier registrierte .

Dauert immer ne Weile, bis er auftritt, einmal in der Statusleiste von Automatisch auf deine anderen eingestellten Abstufungen und durch bis Automatisch behebts dann wieder fuer eine Weile.

 

[fipsy]

Na unglaublich! Dann ist mir der Fehler wohl in drei Jahren noch nie aufgefallen! Sowas...

Erstaunlich, dass sich noch nie jemand um die Behebung bemüht hat, oder ist das nicht machbar, weil das Modul, in dem der Fehler liegt, wieder mal Closed Source ist? Also so wie bei battd.

Ganz blöd ist übrigens, dass das Durchklicken der Helligkeitseinstellungen in der Statusleiste, die Einstellung "Display aus" einschließt. Da darf man dann blind versuchen, die richtige Stelle auf dem Display zu treffen, damit es wieder angeht. "Display aus" dürfte bei den Einstellungen gar nicht vorhanden sein. Wozu sollte jemand sein Display wohl dunkel schalten? Leider kann man die Art und Anzahl der Helligkeitsstufen in der Energiesteuerung nicht konfigurieren.

Edit: Oh menno! Erst jetzt habe ich gesehen, dass man bei "Cyanogenmod -> Benutzeroberfläche -> Energiesteuerung -> Schaltflächen" ganz nach unten scrollen kann und dort Einstellungsmöglichkeiten für die Helligkeitsstufen findet. Boah, also DA muss man erstmal drauf kommen!

 

[fipsy]

FuFu: Nochmal ne Frage zu deinen TCP-Buffergrößen:

net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4095,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4094,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4093,262140,770880,4096,30643,770880
net.tcp.buffersize.gprs=4094,87380,256960,4096,16384,256960
net.tcp.buffersize.wimax=4094,87380,256960,4096,16384,256960

Gibt es einen speziellen Grund für die sehr ungewöhnlichen Größen bei Edge? Und gibt es einen Grund dafür, dass einmal 4096 genutzt werden und die anderen Male 4095, 4094 und 4093? Im Netz findet man überwiegend andere Werte.

 

[-FuFu-]

ka, ich hab die werte dafür irgendwo aus einem forum kopiert gehabt
und bei mir ist es mit den werten soweit okay, zumindest hab ich keine größeren hänger oder sowas

 

[fipsy]

Also ich habe jetzt mal die tcp-Werte ausprobiert und musste feststellen, dass sie sich spürbar negativ auf die Geräteleistung auswirken. Besonders bei Apps, die Datenverbindungen nutzen, hakt das Gerät dann immer wieder in sehr kurzen Zeitabständen. Besonders beim Tippen auf der Display-Tastatur macht sich diese Hakelei äußerst unangenehm bemerkbar. Und im Browser konnte ich zudem keine Verbesserung der Leistung feststellen.

Nachdem ich die Werte aus der build.prop wieder gelöscht und das Gerät neu gestartet hatte, lief wieder alles flüssig. Ich kann die Änderungen also nicht empfehlen. Die einzige Änderung, die meiner Ansicht nach wirklich eine spürbare Verbesserung bringt, ist das Erhöhen von windowsmgr.max_events_per_sec. Das macht den Bildlauf wirklich deutlich flüssiger. Bei allen anderen Änderungen habe ich den Eindruck, dass sie mehr Einbildung sind, als eine objektive Verbesserung zu bewirken.

 

[-FuFu-]

ich hab zu 99% ja nur gprs an hsdpa hab ich wegen stromsparen meistens aus, und ich nutz ja nur whatsapp, was im internet ist. aber ich habs auch nie wirklich getestet ^^

ich kopiere eben gern mal sachen die in foren stehen und lass sie drin, wenn ich keine großen verschlechterungen feststelle daher sind es ja auch so viel sachen ^^

 

[fipsy]

Ich benutze fast nur WLAN. Und im WLAN machen sich die tcp-Änderungen definitiv nachteilig bemerkbar.

Was übrigens auf den ersten Blick seltsam erscheint: Wenn WiFi eingeschaltet ist, wird für das WLAN in der Akkustatistik immer ein enorm hoher Energieverbrauch von rund 40-60% der gesamten Akkuleistung angezeigt. Ich habe deshalb bei meinem Test-Handy, das nie benutzt wird und daher i.d.R. rund drei Tage hält, mal WLAN ausgeschaltet. Dann müsste es bei rund 50% Akkuverbrauch des WLAN, der immer angezeigt wird, ja mindestens zwei Tage länger halten. Aber Pustekuchen! Das ist nicht der Fall:

Ob mit oder ohne eingeschaltetes WLAN, das Handy hat immer die selbe Standby-Zeit! Und das zeigt für mich, dass die Akkuverbrauchsanzeige bezüglich des WLANs völligen Mumpitz anzeigt! WLAN verbraucht gar nicht viel Energie! Ich vermute stark, dass in die Verbrauchsanzeige des WLAN auch der Verbrauch von Apps oder anderen Komponenten mit eingerechnet wird, die das WLAN benutzen. Das Ausschalten von WLAN bringt nach meinen Untersuchungen keinerlei Energie-Vorteile.

Ich will mal eine Tabelle aus dem Artikel von Payce zitieren:

Verbraucher             Variable                  Leistung in mW

Deep Sleep Flugmodus                              6
2G Empfang                                        10
3G Empfang                                        14

HG-Beleuchtung          5 (MIUI min)              260
HG-Beleuchtung          30 (dunkel)               299
HG-Beleuchtung          102 (mittel)              389
HG-Beleuchtung          255 (hell)                604

CPU Volllast            250 MHz 30 vsel           400
CPU Volllast            500 MHz 40 vsel           563
CPU Volllast            800 MHz 50 vsel           856
CPU Volllast            1 GHz 62 vsel             1213

Taschenlampe            niedrigste Einstellung    59
BT Scan                                           358
BT StandBy                                        24
GPS StandBy                                       ~ 0
GPS Scan                aktive Suche!             653
Kamera                                            705

WLAN StandBy                                      ~ 0
WLAN down/up                                      1332
EDGE download           voller Empfang            1505
EDGE upload             voller Empfang            1172
HSPDA download          "3 Striche"               2564
HSDPA upload            "3 Striche"               3188

Unterschied weißer Bildschirm zu schwarz          40

Man sieht, dass das WLAN im Standby fast nichts verbraucht und nur im Daten-Betrieb rund 1330 mW. Gleichzeitig sieht man, dass EDGE (also auch GPRS) im Daten-Betrieb beim Download sogar mehr verbraucht als WLAN. Und beim Upload nur unwesentlich weniger als WLAN. Das aber auch nur bei vollem Empfang, den man nicht immer hat. Zu Deutsch: WLAN beim Datenverkehr abzuschalten, wirkt sich grundsätzlich negativ auf die Akkuleistung aus! Insbesondere auch deshalb, weil die Übertragungsraten im WLAN gewaltig viel höher sind, als bei EDGE und die Betriebszeit des WLAN bei gleicher Datenmenge daher viel kürzer ist, als die des GPRS-Moduls. Und das deckt sich auch vollkommen mit meinen persönlichen Beobachtungen.