[ROM][Gingerbread] ezGingerbread / GINGERBREAD-DS-Alpha by ezterry (Android 2.3)

[DiSa]

Der Hauptunterschied zwischen EZGingerbread und ADS_Magpie liegt aktuell in der Möglichkeit die Permissions der installierten Applikationen zu ändern. Weiterhin gibt es noch ein paar zusätzliche Einstellmöglichkeiten bzgl. ZRam und VM-Size. Der Rest ist ähnlich / identisch, da in der Regel kurz nachdem ein neues Feature in EZGingerbread eingeführt wird, dieses in ADS_Magpie gemerged wird und umgekehrt.

 

[DiSa]

...Aufgrund der kernel.org Probleme steht der Merge auf Android 2.3.7 noch aus.

Der Merge mit 2.3.7 ist nun erfolgt. Ein neues ADS_Magpie Release steht seit heute zur Verfügung. Zusätzlich gibt es viele weitere Änderungen, deshalb sollten sich vor Installation das Changelog und die Requirements genau durchgelesen werden.

AndDiSa's ADS_Magpie Gingerbread (Android 2.3.7) for G1 / HTC Dream / HTC Magic

 

[hosl]

Hallo,

Was mich an den neueren Versionen stört ist das automatische Herunterfahren des Handy bei Akkuanzeige 0.
Kann man das irgendwie abschalten? Ich habe nämlich das Gefühl dass bei mir die Anzeige manchmal zu früh auf 0 geht.

Danke,

 

[norbert]

Das ist doch normal, daß das OS bei Akku=0 automatisch runterfährt. Das war schon so bei Android 1.1

aber vielleicht einfach den Akku mal neu kalibrieren.

 

[hosl]

Das ist doch normal, daß das OS bei Akku=0 automatisch runterfährt. Das war schon so bei Android 1.1

aber vielleicht einfach den Akku mal neu kalibrieren.

Der Akku ist neu. Ich bilde mir ein dass bei meinem alten (kaputten) Akku und einer früheren Version von COS-DS das Handy nicht automatisch bei 0 heruntergefahren ist. Da es bei neuer Versionen doch der Fall war, dachte ich es lag am Kernel. Vielleicht habe ich mich aber auch einfach getäuscht.

 

[norbert]

ich denke du täuscht dich. "wird runtergefahren" kenn ich jetzt seit fast 3 Jahren, wenn der Akku leer wird.

Warum sollte das System bei anstehendem Energienotstand auch unbedingt aufrecht bleiben und riskieren, daß Anwenderdaten beschädigt werden?

Falls der Akku ein Nachbau ist, kann es natürlich leicht sein, daß er zu früh 0 anzeigt

 

[hosl]

ich denke du täuscht dich. "wird runtergefahren" kenn ich jetzt seit fast 3 Jahren, wenn der Akku leer wird.

Warum sollte das System bei anstehendem Energienotstand auch unbedingt aufrecht bleiben und riskieren, daß Anwenderdaten beschädigt werden?

Falls der Akku ein Nachbau ist, kann es natürlich leicht sein, daß er zu früh 0 anzeigt

War der Original Akku, aber quasi tot nach 2 Jahren. Vielleicht ist er auch bei 1% stehen geblieben, jedenfalls hat auch die Battery Reset Funktion und "Kalibrierung" nichts gebracht um eine realistische Anzeige zu erhalten.

Noch was zum aktuellen AndDiSa 2.3.7:
Bei mir blinkt die LED bei einem verpassten Anruf nicht. Ist das gewollt? Kann man das irgendwo einschalten bzw. vielleicht sogar die Farbe einstellen (ohne extra App)? Wenn nein, welche App wäre die richtige dafür?

 

[DiSa]

Das Problem mit der LED habe ich auch schon festgestellt, aber bisher leider auch noch keine Lösung
Ich vermute, dass es evtl. sogar nur etwas mit den Einstellungen zu tun hat, aber dass müsste man mal ein wenig genauer untersuchen.

 

[DiSa]

Kurze Ergänzung zu meiner letzten Mail: Im "original" Android gibt es diese Funktion nicht. Somit bleibt nur die Installation einer zusätzlichen App (z.B. Missed Calls) aus dem Market.

 

[DiSa]

Neuer Build von Terry: 20111107-1: GINGERBREAD-DS-Gamma-20111107-1.zip
(md5: f57ebc7ccd0819e0536407d066f02c6b)
Note: Gamma release (beta+1): Kernel update to v1.5.2 w/ patches for time skew, updates to android 2.3.7, wifi lease fix, add pt_BR to language set, various framework patches fixes speedups from CM7, KSM (Kernel SamePage Merging) support to dalvik-vm with supporting kernels (eg: ezgb-2636) MMS Time display and MDPI icon from CM7, compress xbin and move various libs to a compressed xlib, compact (pngcrush + zip -9 resources.arsc) apks, superuser 3.0.6, Odex framework (shrinks the framework jars, and moves the framework dalvik-cache into system) EzGbExtras also now has options for KSM, Incoming Call TouchUI CompCache chooser, ntpd background service for better time sync. Security fixes based off digitalgardian certs, Settings no long has compcache (moved to EzGb Extras)

Ausserdem gibt es von AndDiSa eine neue Version auf dem gleichen Stand + zusaätzliche Features (z.B. App-Permissions, ...) AndDiSa's ADS_Magpie Gingerbread (Android 2.3.7) for G1 / HTC Dream / HTC Magic

 

[Technoolli]

Hi Leute die neue Version:

ADS_Magpie Gingerbread (Android 2.3.7)

Changelog

07.11.2011: ADS_magpie-20111107-signed.zip md5sum: 1aea4cf2a1978e15a494a93b9f7ae590

• sync / merge with latest changes from Terry
• new kernel (v1.5.2)
• cacerts update
• ntpd option to synchronize time with a ntp server
• some bugfixes
• odex framework to save space on /data, better optimization
• Install Notes:As with version from 18.10.2011 its important to wipe dalvik cache (and ideally the cache partition), backup, then install when you come from an older version, i.e. <18.10.2011.

Rennt echt klasse, kann Ich nur empfehlen. Die lasse ich erstmal drauf

 

[DiSa]

Hi Leute die neue Version:

ADS_Magpie Gingerbread (Android 2.3.7)

Changelog

07.11.2011: ADS_magpie-20111107-signed.zip md5sum: 1aea4cf2a1978e15a494a93b9f7ae590

• sync / merge with latest changes from Terry
• new kernel (v1.5.2)
• cacerts update
• ntpd option to synchronize time with a ntp server
• some bugfixes
• odex framework to save space on /data, better optimization
• Install Notes:As with version from 18.10.2011 its important to wipe dalvik cache (and ideally the cache partition), backup, then install when you come from an older version, i.e. <18.10.2011.

Rennt echt klasse, kann Ich nur empfehlen. Die lasse ich erstmal drauf

Ich weiss zwar nicht, warum Du das ROM noch einmal auf einem anderen Server und unter einer anderen URL bereitstellst, aber ansonsten kann ich Dir niur zustimmen
P.S.: Die Original-URL ist übrigens "http://bit.ly/ADS_Magpie" einfach, oder?

 

[hgmichna]

[Hier ist ein kleiner Artikel, den ich schon geschrieben hatte, bevor ich diesen Thread wiederfand, daher wiederholt er ein paar hier schon beschriebene Punkte.]

Ich hatte noch zwei HTC Magic 32B Handys hier, deren Android-Version schon relativ alt war, und habe mit den drei letzten Versionen von ezGingerbread experimentiert: GINGERBREAD-DS-Beta-20110716.zip, GINGERBREAD-DS-Beta-20110828.zip und GINGERBREAD-DS-Gamma-20111107-1.zip

Da Gingerbread für das HTC Magic 32B eigentlich zu groß ist, braucht man fast zwingend einen Swapfile, sonst laufen große Programme teilweise gar nicht mehr oder nicht ohne Störungen. Selbstverständlich ist das Magic dann erst recht langsam. Ab und zu beschwert sich Android, dass ein Programm nicht antwortet, und fragt, ob man warten möchte. Man sollte in solchen Fällen erst einmal warten. Das ist der Preis, den man für das modernisierte Betriebssystem auf dem alten Handy zahlt.

Mit der Version 20110716 von ezGingerbread hatte ich regelmäßig Probleme, hautpsächlich Force Close bei Programmen. Aber seit der letzten Version sind diese Fehler völlig verschwunden. Ich kann das Handy z.B. problemlos zum Navigieren mit Google Maps benutzen und sogar---in Zeitlupe---Angry Birds spielen.

Daher halte ich das für eine gute Gelegenheit, das HTC Magic 32B, das in Deutschland von Vodafone verkauft wurde, noch einmal aufzuwerten und entweder selbst noch eine Weile weiterzubenutzen oder es als Geschenk an jemanden mit geringeren Anforderungen oder einen Smartphone-Neuling zu verwenden.

Technische Daten
Model number: Gingerbread on Sapphire
Android version: 2.3.7
Baseband version: 62.50SJ.20.17U_2.22.28.25
Kernel version: 2.6.36.4-s3-ezgb-v1.5.2 ezterry@zack #1
Mod version: ezGingerbread-gamma.20111107-1
Build number: full_sapphire-userdebug 2.3.7 GINGERBREAD eng.

Swapfile in Partition swap, nach dem Flashen von ezGingerbread erstellt mit: SwapScriptv2.1.1-signed.zip
Größe: 32 MB
swappiness: 0

Anmerkungen: Ich habe mit verschiedenen Swapfile-Größen experimentiert und gefunden, dass größere Swapfiles zu sehr langen Wartezeiten führen. Weil Android wegen seiner ungewöhnlichen Speicherverwaltung nicht gut mit einem Swapfile zusammenarbeitet, muss man die Größe eng begrenzen und die swappiness auf den niedrigstmöglichen Wert von Null einstellen. Das Ziel ist, dass Android möglichst nur dann swappt, wenn es unvermeidlich ist, um größere Programme zu laden und auszuführen. Ansonsten ist das Swapping für Android absolut unerwünscht, weil es alles nur viel langsamer macht.

Das hier verwendete Radio benötigt den dafür angepassten Kernel, der aber im ezGingerbread-Update-ZIP-File schon enthalten ist, und auch ein angepasstes HBOOT: hboot0013d-signed.zip

Weiterhin verwendet wurden: gapps-mdpi-gb-20110709_S.zip, radio_update_2.22.28.25_S.zip, ohsaka-super-wipe.zip, gprs_patch_S.zip, splash1_HTC_Magic.nb0

Zum ursprünglichen Rooten wurde supposedly_EngineeringSPL_2.53.707.2_-_sappimg.zip verwendet.

 

[DiSa]

Als Gapps für ezGingerbread sollten eigentlich gapps-mdpi-gb-20110709_S.zipverwendet werden, da seit Ende Juli ein spezielles Security-Feature aktiviert ist und die Gapps mit einem besonderen Key signiert sein müssen.

 

[hgmichna]

Vielen Dank für die Korrektur! gapps-mdpi-gb-20110709_S.zip habe ich auch benutzt. Es war ein Versehen. Ich habe das jetzt in meinem Kommentar berichtigt, falls jemand nur den liest.

 

[DiSa]

Noch eine kurze Anmerkung: Swap macht *nur* für das Magic Sinn, da hier der +15MB Trick nicht funktioniert, für das G1 sind +15MB in Verbindung mit Compcache/ZRAM der bessere Weg.

 

[hgmichna]

Ich habe zwar keine Tests gemacht, aber die CompCache-Idee erscheint mir auf den ersten Blick ziemlich fragwürdig, so, als ob ich meiner Frau die Diamanten klaue und sie ihr dann wieder verkaufe. Hinzu kommt noch, dass nicht alles gut komprimierbar ist, und wenn nicht, dann nützt Compcache so gut wie gar nichts.

Ich würde so aus dem Hut heraus annehmen, dass ein ganz normaler Linux-Swapfile seinen Zweck durchaus erfüllt, mindestens so gut wie Compcache, und genau das beobachte ich ja auch. Compcache könnte vielleicht bei solchen Handys besser funktionieren, die ein sehr schnelles RAM haben. Das Magic benutzt aber meines Wissens auch nur Flash-Speicher als RAM, der kaum oder gar nicht schneller ist als die anderen Flash-Speicherbereiche. Deswegen dürfte Compcache hier nicht besonders flott laufen.

Das Problem bei Android ist, dass es viel Speicher nimmt, wenn es ihn kriegen kann, und da das Swapping für Android transparent ist, nimmt es ihn anscheinend nur allzu bereitwillig an. swappiness = 0 scheint da etwas zu helfen, löst aber das Problem auch nicht gänzlich. Jedenfalls beobachte ich, dass bei größeren Swapfiles, z.B. 128 MB, Android streckenweise extrem langsam wird. Ich verstehe nicht ganz, warum das so ist, denn eigentlich sollte Linux ja die tatsächlich gebrauchten Pages (den working set) im RAM halten. Jedenfalls gibt es da irgendwo ein Problem, das ich nur dadurch in Grenzen halten kann, dass ich die Swap-Partition klein mache, also 32 MB.

Mit dieser Lösung kann man allerdings meines Erachtens ganz zufrieden sein. Natürlich wird das Magic langsamer, aber alle Programme laufen sonst einwandfrei, mit einem gelegentlichen Warten-Button, den Android dazwischenwirft, wenn es einmal gar zu lange dauert. Gefällt mir sehr gut und ist eigentlich fast unglaublich in diesem kleinen, alten, RAM-schwachen, aber immer noch sehr elegant aussehenden Handy.

Noch eine kurze Anmerkung: Swap macht *nur* für das Magic Sinn, da hier der +15MB Trick nicht funktioniert, für das G1 sind +15MB in Verbindung mit Compcache/ZRAM der bessere Weg.

Funktioniert Compcache wirklich nicht im Magic? Wieso denn nicht? Abgesehen davon, dass es nicht gerade schnell ist, müsste es den verfügbaren virtuellen RAM schon etwas vergrößern.

 

[DiSa]

Also ich glaube ich muss etwas ausholen:
1) Du solltest RAM und internen Speicher nicht verwechseln. Der +15MB "Trick" bringt auf dem G1 15 MB mehr RAM (nicht internen Speicher), d.h. anstelle von 97MB stehen ca. 112MB zur Verfügung. Dieser Speicher wird zum großen Teil vom Radio "geklaut", dem nämlich recht großzügig RAM zugeordnet wird, der gar nicht verwendet wird.
2) Swapfiles / Swap-Partitionen werden im internen (Flash-)Speicher oder auf SD-Karte angelegt, allerdings ist der Zugriff auf Flash-Speicher um Größenordnungen (10-100 mal) langsamer als der Zugriff auf RAM.
3) Compcache macht sich diesen Fakt zu nutze. Hinzu kommt, dass sich Daten / Programme, im Regelfall recht gut (>= 2:1) komprimieren lassen. Mit ca. 16MB Compcache und dem "15MB Trick" stehen auf dem G1 ca. 128 MB RAM für laufende Programme und Daten zur Verfügung (96MB RAM + 32 MB Swap im RAM bei angenommenem Kompressionsverhältnis von 2:1), allerdings muss auch hier der Speicher wie beim Einsatz von Swap-Space immer hin und her kopiert und auch komprimiert/dekomprimiert werden. Trotzdem ist in der Regel Compcache um einiges schneller als Swap und man braucht außerdem keine Angst hinsichtlich der begrenzten Flash-Zyklen von Flash-Speicher zu haben.

Beim Magic sieht es nicht so gut aus, da hier nur die 97MB RAM zur Verfügung stehen. Würde man hier ebenfalls 16MB Compcache anlegen, so hätte man immer noch nur ca. 113 MB (81MB + 32 MB Swap im RAM), was immer noch erst dem real zur Verfügung stehenden Speicher des G1 mit 15MB-Trick entspricht.

Wenn Du nun Swap mit Swappiness 0 auf SD-Karte anlegst (egal ob Swapfile oder Swappartition), so hoffst Du darauf, dass Android einige Teile der Laufenden Programme / Daten nicht benötigt und auf Swap auslagert und dann hoffendlich nie wieder anfasst. Das mag für einen Teil der Daten sogar funktionieren, wenn dann aber das OS die ausgelagerten Teile doch braucht, dann "steht" das OS quasi, da der Zugriff auf den Swap recht lange dauert und alles erst wieder in das reale RAM kopiert werden muss. Aus diesem Grund ist Swap am Anfang auch noch recht schnell, nach einiger Zeit muss man das Phone allerdings re-booten, da es zu träge geworden und der Swap-Space komplett "aufgeräumt" werden muss.

Ich hoffe, ich konnte ein wenig zur Aufklärung des Sachverhalts beitragen.

 

[hgmichna]

Danke für die interessanten Details!

Ist denn im HTC Magic der RAM tatsächlich wesentlich schneller als der interne (Flash-) Speicher? Ich meine, irgendwo gelesen zu haben, dass in diesen älteren Handys der RAM auch nur Flash-Speicher ist und daher wenig oder gar nicht schneller als z.B. die SD-Karte. Das könnte aber auch eine Fehlinformation gewesen sein.

Für die Entscheidung, wie man den knappen RAM-Speicher beim Magic erweitern kann, spielt das aber wohl kaum eine Rolle, weil hier praktisch nur der Swapfile in Frage kommt.

Meine Beobachtung ist ein wenig anders als du beschreibst und stimmt auch mit der Theorie überein. Mit swappiness = 0 sollte Linux so wenig wie möglich Swap-Speicher verwenden, was auch meiner Absicht entspricht. Idealerweise benutzt es den Swap-Speicher erst, wenn Programme geladen werden, die ohne Swapping nicht mehr in den Speicher passen.

Allerdings wird es dann den einmal zugeordneten Swap-Speicher weiter verwenden, auch wenn die Programme geschlossen und aus dem Speicher geräumt werden.

Linux arbeitet aber so, dass es Speicherseiten bei Bedarf aus dem Swap-Space in den RAM lädt und dafür andere Seiten auslagert. Im Idealfall, und der wird auch in Android normalerweise immer wieder erreicht, befinden sich alle Speicherseiten, die tatsächlich für das laufende Programm gleichzeitig benötigt werden (der working set), im RAM, und das jeweilige Programm läuft mit voller Geschwindigkeit. Dasselbe gilt auch für mehrere gleichzeitig laufende Programme.

Wenn man dann ein anderes Programm lädt, tritt oft vorübergehend wieder der Problemfall ein, dass Linux Seiten zwischen RAM und Swapspace hin- und herschieben muss. Dann wird das Handy langsam, und man muss warten. Wenn diese Phase vorbei ist, befindet sich der neue working set im RAM, und das Handy läuft wieder mit voller Geschwindigkeit.

Dieses Umlagern von Speicherseiten tritt auch auf, wenn man in einem Programm eine Funktion aufruft, deren Programmseiten gerade ausgelagert waren. Auch dann wird das Handy vorübergehend langsam, während die benötigten Seiten ins RAM geladen werden und andere, die am längsten nicht gebraucht wurden, statt dessen ausgelagert werden.

Theoretisch gibt es auch den Fall, dass der working set größer ist als der RAM. Dann wäre das Handy anhaltend sehr langsam. Das habe ich aber noch nie beobachtet. Anscheinend reicht der RAM beim HTC Magic 32B für den normalen working set so gut wie immer aus, jedenfalls, wenn man es vermeidet, zu viele Programme gleichzeitig laufen zu lassen.

Ich kann daher und auch aus der praktischen Beobachtung nicht bestätigen, dass es nützlich ist, das Handy neu zu booten. Meines Erachtens ist das nie notwendig, und ich tue es auch nie.

 

[DiSa]

Soweit liegen unsere Ansätze und Verständnisse ja gar nicht auseinander. Sie unterscheiden sich bloß im Detail.

Was das RAM angeht, ja, das Magic und G1 haben dedizierten RAM-Speicher (192 MB), hiervon wird allerdings Standardmäßig 64MB für den Radio-Prozessor reserviert und ca. 30MB für die Camera.

Ja, bei Swappiness 0 wird wird versucht möglichst nur realen Speicher zu verwenden, es wird erst dann Swap verwendet, wenn kein realer Speicher mehr frei ist, aber auch kein Programm beendet werden kann um Speicher freizugeben. Wenn ein Programm / Teile des Programms ausgelagert wurden, so müssen sie danach immer wieder hin und her kopiert werden. Insbesondere, wenn z.B. Teile des Launchers ausgelagert sind, merkt man dass deutlich. Wird ein Programm komplett beendet, so wird auch der ausgelagerte Bereich im Swap wieder freigegeben, Swap garantiert nicht, dass ein Programm von Android nicht beendet wird, es ändert nur die Wahrscheinlichkeit, dass es beendet wird. Das hängt aber sehr stark von den verwendeten Programmen ab.