Vor gut einem Monat habe ich über meine Probleme mit meinem Android G1 Handy bei der Anrufannahme berichtet. Das Problem ist wohl, dass alle Prozesse gleich behandelt werden (und dass das Ding total laaahm ist), auch der Telefonprozess und der Klingeltonprozess. Meine damals gezeigten Einstellungen waren noch nicht ganz so optimal. Zum Teil standen sich die Prozesse dann gegenseitig im weg zum Teil liegt das Problem aber nicht nur bei den Prioritäten.

Ich habe jetzt einen guten Monat weiter experimentiert und möchte nun meine Erkenntnisse und Ergebnisse mit euch teilen.
Wie gesagt: Ich versuche das Problem mit der App phonePrioritizer von jinx10000, gefunden im xda-developers forum, zu lösen. Die App führt alle 30 Minuten ein Skript aus. Das Skript setzt die Prioritäten einiger Prozesse höher oder niedriger als normal. -20 ist die höchste Prio, 20 die Niedrigste.
Hier mein aktuelles Skript:

Man kann natürlich so viel priorisieren wie man will. Der größte Flaschenhals bleibt die Hardware. 528 mobile MHz und zusammen gehackte 107 MB Arbeitsspeicher. Darin tummeln sich, dank Apps2SD, ziemlich viele, zum Teil nachinstallierte, Hintergrundprozesse. Der Telfonprozess ist zum Glück speicherresistent und wird nicht abgeschossen.
Damit kommen wir zur ersten Teil meines Lösungsweges: Swappen. Ja, toll, das kann ein gerootetes Telefon. Normalerweise werden bei zu wenig freiem RAM Programme aufgefordert den Zustand zu speichern und werden abgeschossen, später wenn das Programm wieder in den Vordergrund kommt, wird der Zustand wiederhergestellt - klingt langsam. Beim Swappen werden stattdessen nicht benötigte Speicherbereiche (also Apps) vom RAM in die Swappartion (oder -file) verschoben und nicht abgeschossen. Dafür wird ein wenig auf der SD-Karte rumgeschrieben. Ich habe den Kampf auf mich genommen und eine schnelle Class 6 SD-Karte besorgt, auch wieder wochenlang mit swappiness und anderen Settings rumgemacht. Bringt alles nichts. Das Telefon wurde noch langsamer bis hin zur totalen Entropie. Weg damit - Zustand wiederherstellen ist bei mir schneller.
Zum Prozessor (und gleichzeitig meiner ersten Modifikation der Skript.txt). Von 528 MHz werden normalerweise nur 245-384 genutzt. Um das aufzubohren benutze ich SetCPU for Root Users von Michael Huang. Das Programm bietet sogenannte Profiles. Ich nutze Normal 128-524 MHz und bei Sleep/Standby 128-245 MHz um Strom zu sparen. Früher hatte ich 128-128 - reden wir nicht drüber. Jetzt kommen die Prios ins Spiel: Telefon- und Klingelton-Prozess sind mit der Prio -18 die Platzhirsche, wenn die in Gange sind, geht nix Anderes mehr. Genau, nichts Anderes, auch nicht SetCPU, was ja eigentlich, wenn der Anruf das Display aktiviert, feststellen müsste, dass das Telefon nun an ist und volle Power braucht. -18 hin oder her, bei lahmen 245 MHz nützt das dem Telefonprozess auch nichts. Also: SetCPU-Prio auch -18.

Die meisten anderen Prois habe ich so gelassen wie es im xda-Forum steht. gapps (Market, GMail Speicher...) Prio 5 leuchtet ein, dass sind Hintergrundprozesse, die selten benötigt werden. Wenn z.B. GMail mit dem Speicher kommuniziert, wartet es ja auf dessen Antwort und macht deshalb in dem Moment keine Prozessorasche, es bleibt also CPU-Zeit für den Provider übrig, auch wenn der nur die Prio 5 hat.
Telefon, klar, -18, volle Power. Aber jetzt eine Änderung von mir, die, auch wenn ich es nicht gedacht hätte, was gebracht hat: Mediaserver nur die Prio -16. Anscheinend ist das G1, bei wenn die auch Prio -18 ist, so damit beschäftigt den Klingelton abzuspielen, dass keine CPU-Zeit mehr dafür übrig bleibt im Adressbuch nachzuschauen, wer hinter der Telefonnummer steckt. Man hört also das Klingeln, kann aber wieder nicht richtig abnehmen oder sieht nicht wer anruft. -16 klappt da eindeutig besser.
Den Launcher/Homeapp mit Prio -16 find ich etwas flüssiger beim Arbeiten, steht glaube ich auch so im Original. Ich benutze DxTop, wer die normale App benutzt, muss deren Prozess eintragen.
Die htc.music und android.music Prios habe ich nicht angetastet, stand so bei xda.
Dann hab ich noch meine Softwaretastatur eingetragen, die HTC-IME. Genau wie bei der Homeapp. Wenn sie offen ist, soll genau diese App die meiste CPU-Zeit bekommen.
Mein nächstes Expriment seht ihr in den letzten Zeilen: Weitere Hintergrundprozesse mit einer niedrigen Priorität von 5 laufen lassen. Die Probanden sind: Locale, Wapdroid und Batteryleft.
Um die Prozessnamen herauszufinden benutze ich den OSMonitor von eolwral. Im Terminal "ps" tut's natürlich auch. Ich kann aber schneller über das Icon den richtigen Prozess finden. Dass ich faul und dumm bin kommt auch noch dazu.

Zum Testen benutze ich den Terminal Emulator von HelloAndroid.com. Man kann das Skript nämlich einfach mit "sh /sdcard/phonePrioritizer/script.txt" ausführen. (als root natürlich) So muss man keine 30 Minuten warten und kann Fehler erkennen. Das Skript hat keine Ausgabe - alles in Ordnung, keine Tippfehler.


Kommentar hinzufügen