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

[fipsy]

If you've encountered issues while using frequencies solely invented by you, then I'm indeed feeling sorry for you. But... what have you expected?

If this was a known issue I first would have expected any warning that not every frequency is allowed to be used in 10overclock. For the vsel values there are a lot of warnings in this direction, but not for the frequencies. If I'm free to choose every frequency I like I would not expect that there are frequencies that send the device to netherworld . I think for a normal user it's not obvious that this maybe an issue! Especially because everyone posts his own frequencies (e.g. on maemo.org) without saying that there are forbidden ones. And I'm sure that I'm not the only one with this issue. I believe that a lot of drains and frequency stucks belong to this problem.

So I think it's not adequate to put the blame on me!

 

[fipsy]

@fipsy: Könntest du deine oc-Werte mal posten? Mit denen scheint es bis jetzt ja sehr gut zu laufen.

Klar. Unten links die Werte. Zusätzlich erlaubt sind auch 325, 400 und 550 MHz. Definitiv nicht erlaubt sind 150 und 650 MHz. Und auch wenn nadlabak vor zu niedrigen vsel-Werten warnt, so habe ich mit den abgebildeten Werten keinerlei Probleme feststellen können. Es war ausschließlich die Frequenz von 150 MHz schuld an den Akku-Drains und Frequenz-Blockaden und nicht die niedrigen vsel-Werte! Es ist natürlich bei jedem Gerät etwas anders, aber auf den beiden Geräten, die ich hier habe (und die in der Produktion fast ein Jahr auseinander sind), laufen die selben, niedrigen vsel-Werte völlig unproblematisch. Das eine Gerät läuft trotz recht intensiver Nutzung (11 Stunden Uptime) mittlerweile seit über 33 Stunden fehlerfrei und hat trotzdem noch 12% Restkapazität. Bei so einer Nutzung war sonst nach spätestens 18-24 Stunden Schluss. Ich komme jetzt also auch an FuFus Werte ran. Positiv auffällig ist außerdem der nun plötzlich sehr gleichmäßige Abfall der Akku-Restkapazität (rechtes Diagramm). Früher waren da immer massive Sprünge drin.

Eine etwas niedrigere CPU-Spannung mag zwar nicht viel in Bezug auf die Akkuleistung bringen, aber sehr wohl für die Lebensdauer der CPU, da die Elektromigration dadurch erheblich verringert wird.

Die unten aufgeführten Frequenzwerte bewirken bei mir eine relativ gleichmäßige prozentuale Belegung aller Frequenzbereiche, was für mich ein Zeichen ist, dass sie ganz gut gewählt sind.

Um "Lags" bei eingehenden Anrufen zu verhindern (Handy wacht zu langsam aus dem Deep Sleep auf), was hier immer wieder als Fehler berichtet wird, sollte die maximale Frequenz bei ausgeschaltetem Display auf 600 MHz gesetzt werden! 500 MHz reichen nicht aus, wie ich festgestellt habe.

Abschließend geht auch ein großer Dank an Nadlabak für ein sehr gut und zuverlässig funktionierendes CM7 - aber eben nur, wenn man alle Klippen umschifft hat, die zahlreich vorhanden sind. Es fehlt leider an einer guten Dokumentation bzw. wenigstens an einer FAQ bzw. Sammlung der häufigsten Fehlerquellen.

 

[-FuFu-]

dafür ist das Forum ja dann da wir sammeln hier ja alles was an fehlern gefunden wird ^^
wir geben sie zwar nur weiter, wenn jemand einen ähnlichen fehler hat, aber hier wird sich ja gut ausgetauscht ^^

und weil es immer wieder vereinzelne fehler gibt, die nicht jeder reproduzieren kann oder durch nadlabak recht schnell gefixt werden, ist es schwer eine liste aller fehler zu führen.

immerhin haben wir jetzt in langer arbeit den fehler gefunden, den wir die letzten Monate gesucht haben kann also nur noch bergauf gehen ^^

 

[fipsy]

immerhin haben wir jetzt in langer arbeit den fehler gefunden, den wir die letzten Monate gesucht haben kann also nur noch bergauf gehen ^^

Ja, aber ohne den Einbau des CPU stats kernel modules hätten wir den Fehler sicher niemals gefunden! Ich hatte aufgrund des Energieverbrauchs gegenüber der CPU-Auslastung, wie sie bei Battery Mix angezeigt wurde, ja schon vermutet, dass die CPU irgendwie dauerhaft auf 800 MHz festhängt, aber das war eben nur eine Vermutung von mir und kein Beweis. Ohne CPUStats wäre ich wohl nie auf die Idee mit den verbotenen bzw. unerlaubten Frequenzen in 10overclock gekommen. Vielleicht findet der eine oder andere ja noch eine weitere erlaubte oder verbotene Frequenz. Es wäre gut, wenn man mal eine Tabelle mit solchen Frequenzen anlegen würde!

 

[-FuFu-]

naja, ich denke ein großteil wird die vorgegebenen Werte nutzen und je nach bedarf wohl nur die oberste frequenz anpassen (hab ich anfangs auch nur gemacht)...

unter 2.2.1 (unter cm7 laufen die stats bei mir noch immer nicht -.-) hab ich die meiste nutzung bei 250 und 550 mhz im normalbetrieb (whatsapp, sms und ab und an telen) die oberen frequenzen von 700 und 900 mhz werden nur genutzt, wenn ich im browser was mache oder etwas rumspiele...
man muß sich die einzelnen taktraten relativ gut anpassen, aber auch nicht übertreiben, ich denke ich hab für mich gut werte gefunden (250, 400, 550, 700, 900) und die werden für viele sicher auch ganz okay sein

 

[fipsy]

(unter cm7 laufen die stats bei mir noch immer nicht -.-)

Was ich irgendwie sehr seltsam finde.

hab ich die meiste nutzung bei 250 und 550 mhz im normalbetrieb (whatsapp, sms und ab und an telen) die oberen frequenzen von 700 und 900 mhz werden nur genutzt, wenn ich im browser was mache oder etwas rumspiele...

Nachdem ich festgestellt hatte, dass 250 MHz insgesamt recht viel genutzt wird, habe ich die unterste Frequenz auf 125 MHz reduziert und festgestellt, dass das Gerät dann zu fast 40% bei dieser Frequenz verweilt. Meist ist eben doch nicht wirklich viel zu tun, wenn eine App auf eingehende Daten wartet (z.B. beim Chatten). Und dann reichen auch 125 MHz. Nach den Messdaten von Payce lassen sich bei 125 MHz immerhin nochmal fast 25% Leistung gegenüber 250 MHz einsparen (300 mW bei 125 MHz gegenüber knapp 400 mW bei 250 MHz): https://www.android-hilfe.de/attach...tungsverbraucher-leistung_taktfrequenz_v2.png

Übrigens tauchen die Werte 700 und 800 MHz bei maemo.org in der Liste auch nicht auf, sondern nur 720 und 805 MHz. Warum diese "krummen" Frequenzen gewählt wurden, wird dort leider nicht erklärt.

Der ursprüngliche Beitrag von 02:32 Uhr wurde um 03:07 Uhr ergänzt:

Da mir bei xda developers niemand auf meine freundliche Frage geantwortet hat, wie man die vom Akku an battd gelieferten Kapazitäts-Informationen auslesen kann, frage ich es hier nochmal. Es muss doch irgendjemanden geben, der bereit oder in der Lage ist, was dazu zu sagen?! Laut der nachfolgenden Aussage vom User jusid im xda-Forum muss es ja wohl irgendwie möglich sein, an diese Information zu kommen. Nur wie?

The estimation is based on a battery capacity (requested from the battery itself) and the active current. A stock battery reports 1500 capacity. A 1700mAh Chinese battery, I also have, reports only 1200 capacity

battd stores the last calculated battery percentage and voltage in the /data/battd/cc_data file.

Leider ist der User dort wohl nicht mehr aktiv bzw. existent. Jedenfalls reagiert er nicht mehr

 

[nadlabak]

Da mir bei xda developers niemand auf meine freundliche Frage geantwortet hat, wie man die vom Akku an battd gelieferten Kapazitäts-Informationen auslesen kann, frage ich es hier nochmal. Es muss doch irgendjemanden geben, der bereit oder in der Lage ist, was dazu zu sagen?! Laut der nachfolgenden Aussage vom User jusid im xda-Forum muss es ja wohl irgendwie möglich sein, an diese Information zu kommen. Nur wie?

Leider ist der User dort wohl nicht mehr aktiv bzw. existent. Jedenfalls reagiert er nicht mehr

Most probably, no answers are there simply because no one who read your question so far has any clue.

battd prints that information at the end of this log output sequence (about 3.5s from the main log start):

I/BATTD   ( 1137): SBCM_GLUE ****BRT SUCCESS****
I/BATTD   ( 1137): BM_BATT_DATA: status valid
I/BATTD   ( 1137): BM_BATT_DATA: uid valid
I/BATTD   ( 1137): BM_BATT_DATA: family_code = 137
I/BATTD   ( 1137): BM_BATT_DATA: uid_lsb = 0
I/BATTD   ( 1137): BM_BATT_DATA: uid_msb = 80
I/BATTD   ( 1137): BM_BATT_DATA: page_2_checksum = 0
I/BATTD   ( 1137): BM_BATT_DATA: page_3_checksum = 0
I/BATTD   ( 1137): BM_BATT_DATA: cpyrght_vld = 1
I/BATTD   ( 1137): SBCM CORE convert_rom_data: bcap= 1390, raw= 0x8b
I/BATTD   ( 1137): BATTD_SetBattCapacity BATT CAP = 182199
I/BATTD   ( 1137): SBCM_GLUE BATT CAP = 1390

Motorola's BP6X battery has it's minimal capacity declared as 1390 mAh...

As mentioned before, the battd daemon is available only as a proprietary binary, no source. No one knows what exactly is being done inside.
There's not very big probability that someone will spend the necessary lot of time needed for disassembly, learning, understanding and reverse engineering its code these days anymore.

 

[fipsy]

Ich habe noch eine unerlaubte Frequenz gefunden: Auf Overclocking - maemo.org wiki werden 805 MHz als Frequenz angegeben. Wenn ich bei meinem Gerät 805 MHz einstelle, gerät es in eine Endlos-Bootschleife: Kurz nach der PIN-Eingabe wird das Display schwarz und dann startet das Gerät neu. Egal welchen vsel-Wert ich bei 805 MHz benutze. Also das selbe Problem wie bei 650 MHz. Es ist schon recht seltsam, dass auf maemo.org solche unerlaubten Frequenzen empfohlen werden. Ich finde die ganze Sache eh sehr seltsam. Kann vielleicht jemand mal testhalber diesen Fehler reproduzieren?! Wäre echt nett!

 

[nadlabak]

I'm not sure where the 805 MHz maemo OPP comes from, but I've enabled the 800 MHz (used officially by TI on OMAP3440 as 'OMAP3430 Turbo mode') to be the default on Milestone and there seem to be no issues so far.
https://github.com/nadlabak/kernel/commit/2448751f4051287bec4af1dfe6cec5deb0060b63
https://github.com/nadlabak/kernel/commit/c7f3998165b1989041843577a3f2475296083602

 

[fipsy]

battd prints that information at the end of this log output sequence (about 3.5s from the main log start):

THANK YOU VERY MUCH! This was the thing I exactly needed!

I already thought I could find it in the logfiles but so far I always used the app "aLogcat" and this seems not to read the whole system logfile from the beginning. I don't know how long the standard size for the system logfile is. Maybe these events have already been deleted when booting has finished.

I now activated event logging to /cache/logger and examined the logfile on the pc with an external editor. There I found the sections I needed.

Thanks a lot for your friendly assistance!

I needed this information just to prove what capacity the battery reports. I have some compatible batteries that provide wrong values and wanted to report this error to the manufacturer. Here I wrote something about this issue: https://www.android-hilfe.de/forum/...58/ersatzakku.10433-page-20.html#post-5382159. battd is okay. I also think no one wants to address this piece of software anymore.

Der ursprüngliche Beitrag von 01:20 Uhr wurde um 01:29 Uhr ergänzt:

I'm not sure where the 805 MHz maemo OPP comes from, but I've enabled the 800 MHz (used officially by TI on OMAP3440 as 'OMAP3430 Turbo mode') to be the default on Milestone and there seem to be no issues so far.
https://github.com/nadlabak/kernel/commit/2448751f4051287bec4af1dfe6cec5deb0060b63
https://github.com/nadlabak/kernel/commit/c7f3998165b1989041843577a3f2475296083602

I also used the 800 MHz for months and had no problems with it. But 805 immediately crashes. Just tested it on both devices. I really think that it has to do with the (probably 16 bit) frequency dividers that cause problems at certain frequencies.

 

[hellfire]

@fispy: Sobald mein Handy wieder funktioniert werde ich die "forbidden frequencies" mal testen.

 

[-FuFu-]

ich komm kaum zu testen bis heute besuch da gehabt ^^ und da kann man nicht am Handy rumfummeln

werd aber mal schauen, das ich die Tage mal etwas zeit finde, da ich eh noch das ein oder andere testen wollte, besonders wegen dem stats modul, was hier noch immer nicht läuft -.- aber immerhin zeigt er mit den deepsleep anteil an

 

[fipsy]

ich komm kaum zu testen bis heute besuch da gehabt ^^ und da kann man nicht am Handy rumfummeln

Es gibt Leute, die fummeln an allem möglichen rum, wenn sie zu Besuch sind.

aber immerhin zeigt er mit den deepsleep anteil an

Mühsam ernährt sich das Eichhörnchen...

 

[MOMaTriX]

Hi,

ich hab mal 2 fragen:
zum einen wo finde ich nochmal die einstellung für die zeit die vergehen muss zwischen zwei anschlägen auf der tastatur damit der aus z.b. ss ein ß macht. ich meine das konnte ich bei einer früher build in einem menu einstellen, finde es aber zum verrecken nicht mehr in der neuen f build.

zum anderen:
ich hatte die e build drauf und hab f einfach drübergeflasht, seitdem zeigt er mir unter akkuverbraucht das android-os mit 60-70% immer an. ruhezustand hat meist nur so 10-20% allerdings hat sich die akkulaufzeit nicht verschlechtert sondern hält immernoch ca 3 tage. ist des normal? kommt das von dem cpustats im hintergrund oder wovon?

 

[fipsy]

zum einen wo finde ich nochmal die einstellung für die zeit die vergehen muss zwischen zwei anschlägen auf der tastatur

Geräteeinstellungen -> Intervall für mehrfachen Tastendruck

ich hatte die e build drauf und hab f einfach drübergeflasht, seitdem zeigt er mir unter akkuverbraucht das android-os mit 60-70% immer an. ruhezustand hat meist nur so 10-20%

Ist das nicht gut so? Nur 10% Akkuverbrauch im Ruhezustand ist doch super! Der Ruhezustand sollte ja auch kaum Akkuleistung verbrauchen. Dass das System 60-70% verbraucht ist relativ viel, aber wenn du nix groß mit deinem Handy gemacht hast, ist es auch wieder halbwegs normal. Einen Punkt "Android-OS" gibts bei mir bei der Akkustatistik aber gar nicht!? Wo kommt der denn bei dir her? Kannst du mal einen Screenshot posten?

sondern hält immernoch ca 3 tage. ist des normal?

Wenn der Akku gut in Schuss ist und das Handy nur ungenutzt in der Ecke rumliegt, ja.

 

[MOMaTriX]

Ist das nicht gut so? Nur 10% Akkuverbrauch im Ruhezustand ist doch super! Der Ruhezustand sollte ja auch kaum Akkuleistung verbrauchen. Dass das System 60-70% verbraucht ist relativ viel, aber wenn du nix groß mit deinem Handy gemacht hast, ist es auch wieder halbwegs normal. Einen Punkt "Android-OS" gibts bei mir bei der Akkustatistik aber gar nicht!? Wo kommt der denn bei dir her? Kannst du mal einen Screenshot posten?

Naja früher hatte ich immer Ruhezustand mit 60% und mobilfunk standby auch so hoch ungefähr, der rest waren dann nur kleine anwendungen die ich halt benutzt habe. ich hatte es jetzt die zeit mehr oder weniger nur rumliegen ja bzw hatte es in der hosentasche dabei.
unter android OS hab ich dann cpu insgesamt mit 1h 12m 46s und infos zu gesendete und empfange daten.
ich meine auch das ich das vor dem update nicht hatte, bin mir aber nicht ganz sicher. aufjedenfall war da ruhezustand und mobilfunkstandby wesentlich höher.

Wenn der Akku gut in Schuss ist und das Handy nur ungenutzt in der Ecke rumliegt, ja.

hehe die frage war eigentlich auf das problem mit dem android os bezogen und nicht wegen dem akku das der wert noch gut ist weiß ich auch, lese hier ja genug mit

 

[fipsy]

Naja früher hatte ich immer Ruhezustand mit 60% und mobilfunk standby auch so hoch ungefähr, der rest waren dann nur kleine anwendungen die ich halt benutzt habe.

Hmmm!!! Jetzt bin ich echt irritiert. Deine Akku-Statistik nach Android-OS und Apps aufgeschlüsselt hatte ich früher auch mal. Aber das war noch unter Eclair oder Froyo. Meine Akkustatistik unter CM7.2.4f sieht erheblich magerer aus. Da gibts keine Apps und kein Android-OS (siehe unten). Jetzt wäre die Frage, woran es liegt, dass deine Statistik so ganz anders ist als meine. Eine Konfigurationsmöglichkeit für die Akku-Statistik gibt es meines Wissens nicht. Ich habe die App "Battery Mix" laufen. Dort gibt es auch eine detaillierte Statistik, aber das Android-System selbst zeigt mir keine solche an. Sehr seltsam!

Wenn die Statistik sich schon so unterschiedlich auf verschiedenen Geräten verhält, würde ich sie mal mit großer Vorsicht genießen und vorerst keine Aussagen über ihren Nutzen treffen wollen. Vielleicht kann nadlabak ja auch was dazu sagen?!

Tschö, Volker

 

[hellfire]

Also ich bin der Meinung dass die Akkuverbrauchs-Anzeige nicht wirklich zuverlässig funktioniert. Da werden auch nur einige Apps angezeigt die genutzt wurden, WhatsApp oder so taucht zum Beispiel gar nicht auf, genau so wie BatteryMix.

So sieht es bei mir aus:

edit: @fipsy: Könntest du noch mal erklären wie genau man die 10overclock-Datei über die OR löscht? Dann würde ich die "forbidden Frequencies" ausprobieren.

edit2: Ich hab jetzt mal die Datei für das reboot-Log erstellt. Die Datei müsste dann doch theoretisch auch in den system/etc/init.d Ordner mit entsprechenden Rechten oder? Allerdings habe ich in dem /system Ordner schon 175,5MB von 175,6MB belegt und ich kann die Datei nicht darein verschieben, obwohl die nur 52B groß ist. Bekomme dann immer die Meldung "cp:write error: No space left on device".

Ich habe schon mehrere System-Apps aus der CM7 Datei gelöscht (.apk und odex), allerdings sind die odex-Dateien immer noch unter system/app zu finden. Kann ich die ohne Bedenken löschen? Dann sollte ich ja genug Speicherplatz im /system Ordner haben.

 

[fipsy]

Hmmm! Wieso habt ihr nur alle dort "Android OS" stehen und ich nicht?! Ich mein, ich finde das ja gar nicht schlecht, dass es bei mir nicht dort steht, weil es eh keine Aussagekraft hat und die Genauigkeit der Statistik verschlechtert. Trotzdem würde ich echt gern den Grund dafür wissen. Zumal bei mir auch bisher niemals irgendeine App dort aufgetaucht ist.

Ich habe übrigens gelesen, dass in der Statistik nur Apps auftauchen, die mehr als 2% verbraucht haben. Das erklärt vielleicht, warum manche dort nicht vorhanden sind. Es erklärt allerdings nicht, warum bei mir auch keine Apps dort auftauchen, die mehr als 2% verbraucht haben.

edit: @fipsy: Könntest du noch mal erklären wie genau man die 10overclock-Datei über die OR löscht? Dann würde ich die "forbidden Frequencies" ausprobieren.

Mein Vorschlag: Lass die 10overclock unangetastet und schiebe dem System die neue Frequenz manuell unter, indem du im Terminal Emulator z.B. eingibst:

su
echo "4 650000000 56" > /proc/overclock/mpu_opps

Dann wird die neue Frequenz mit dem Index 4 in der Liste sofort aktiviert und nach dem Booten ist wieder alles beim Alten. Du musst allerdings den richtigen Index wählen, so dass die Frequenzen in der Liste immer kontinuierlich aufsteigend sind. Du musst dann natürlich auch noch ein bisschen mit dem Gerät arbeiten, um den Crash zu provozieren, weil die "falsche" Frequenz ja auch erstmal genutzt werden muss.

Ich hab jetzt mal die Datei für das reboot-Log erstellt. Die Datei müsste dann doch theoretisch auch in den system/etc/init.d Ordner mit entsprechenden Rechten oder?

Wenn das Script auf die SD-Karte schreiben soll, darf es nicht nach init.d, weil zu dem Zeitpunkt, zu dem die init.d-Scripte ausgeführt werden, die SD-Karte noch nicht zuverlässig gemountet ist. Die einzige Möglichkeit, Scripte, die auf die SD-Karte zugreifen sollen, zuverlässig beim Booten auszuführen, ist die Nutzung eines Script Managers (z.B. der App SManager)! Auch wegen deines mangelnden Speicherplatzes empfiehlt sich diese Lösung, weil du das Script dann auch einfach auf die SD-Karte kopieren kannst.

Ich habe schon mehrere System-Apps aus der CM7 Datei gelöscht (.apk und odex), allerdings sind die odex-Dateien immer noch unter system/app zu finden. Kann ich die ohne Bedenken löschen? Dann sollte ich ja genug Speicherplatz im /system Ordner haben.

Ups, ich hoffe du weißt, was du löschst . Ich wäre da eher vorsichtig. Bei mir sind auf der System-Partition immer so 2,6 MB frei. Und das, obwohl ich nichts aus dem CM7 Paket gelöscht habe und auch alle gapps installiert habe. Vermutlich liegt bei dir irgendwo in /system einiger Schrott rum, der da nicht sein müsste. Manchmal ist es z.B. eine durch Adblocker oder Security Software aufgeblähte /system/etc/hosts Datei von 1-2 MB (inklusive Backup). Hast du mal in der OpenRecovery Konsole ein "wipe system" gemacht, bevor du CM7 installiert hast? Dann wird wirklich die gesamte System-Partition platt gebügelt. Aber Achtung: Wenn du eine /system/etc/custom_backup_list.txt hast, ist diese dann natürlich auch weg und ebenso alle darin referenzierten Dateien. Das ist zu beachten. Aber die meisten haben ja keine custom_backup_list. Ansonsten kann durch "wipe system" nix schlimmes passieren.

 

[hellfire]

Mein Vorschlag: Lass die 10overclock unangetastet und schiebe dem System die neue Frequenz manuell unter, indem du im Terminal Emulator z.B. eingibst:

su
echo "4 650000000 56" > /proc/overclock/mpu_opps

Also im Moment sieht es bei mir so aus:

800
600
500
350
250

Das heißt in diesem Fall wäre das auch der Index 4, richtig?

Wenn das Script auf die SD-Karte schreiben soll, darf es nicht nach init.d, weil zu dem Zeitpunkt, zu dem die init.d-Scripte ausgeführt werden, die SD-Karte noch nicht zuverlässig gemountet ist. Die einzige Möglichkeit, Scripte, die auf die SD-Karte zugreifen sollen, zuverlässig beim Booten auszuführen, ist die Nutzung eines Script Managers (z.B. der App SManager)! Auch wegen deines mangelnden Speicherplatzes empfiehlt sich diese Lösung, weil du das Script dann auch einfach auf die SD-Karte kopieren kannst

Alles klar, werde ich mal ausprobieren.

Ups, ich hoffe du weißt, was du löschst . Ich wäre da eher vorsichtig. Bei mir sind auf der System-Partition immer so 2,6 MB frei. Und das, obwohl ich nichts aus dem CM7 Paket gelöscht habe und auch alle gapps installiert habe. Vermutlich liegt bei dir irgendwo in /system einiger Schrott rum, der da nicht sein müsste. Manchmal ist es z.B. eine durch Adblocker oder Security Software aufgeblähte /system/etc/hosts Datei von 1-2 MB (inklusive Backup). Hast du mal in der OpenRecovery Konsole ein "wipe system" gemacht, bevor du CM7 installiert hast? Dann wird wirklich die gesamte System-Partition platt gebügelt. Aber Achtung: Wenn du eine /system/etc/custom_backup_list.txt hast, ist diese dann natürlich auch weg und ebenso alle darin referenzierten Dateien. Das ist zu beachten. Aber die meisten haben ja keine custom_backup_list. Ansonsten kann durch "wipe system" nix schlimmes passieren.

Ich hab Apps aus dem CM7 Paket gelöscht (sowas wie Browser, Filemanager und Live Wallpapers) und aus den gapps (Talk oder diese Car-App). Da scheint bei mir einiges an überflüssigen Dateien vorhanden zu sein. Also du meinst ich sollte mal ein "wipe system" durchführen? Und danach dann noch mal CM7 flashen und die gapps? Bleiben die Einstellungen von CM7 dann erhalten?

Danke für die ausführliche Antwort.

edit: Okay, ich hatte letztens die Google Tastatur von Android 4 mit Swype-Funktion über Apply Update in der OR installiert, die bei mir aber nicht funktioniert hat (Ich denke man braucht Android 4 dafür). Habe die .apk jetzt mal gelöscht, die war immerhin 10MB groß.