[ROM] CyanogenMod 11.0 (Android 4.4.4)

[Jung]

...Bislang habe ich nur von Defy+ (MB526) gelesen, die diesen Fehler haben....

Nur nochmal zur Klarstellung: Ich habe diesen Fehler mit meinem Defy (MB525), allerdings habe ich eine Defy+ SBF (DEFYPLUS_U3_4.5.1-134_DFP-231_CEE_gyari.sbf) benutzt. Welche SBF nutzt Du?

Was ich nicht nachvollziehbar habe, ist, das beim Flashen bzw. beim Entfernen/Einsetzen des Akkus das Phone wieder selbst startet. - Entweder sofort oder nach einigen Sekunden.

Ich würde meinen, das ist der gleiche Bug. Das habe ich auch schon erlebt.

Also liegt hier evtl. auch die Vermutung nahe, dass irgendein diskretes Bauteil ... ein Einschalten provoziert.

Aber spricht nicht dagegen, dass das Auschalten aus TWRP heraus angeblich funktionieren soll? Leider testet man genau das nicht so oft, wie das Abschalten aus CM11 heraus. Diese These wurde ja aufgestellt, leider ist nicht klar wieviele Leute genau dies wie oft mit wie vielen Geräten versucht haben. Vielleicht gibts es ja doch das ein oder andere Defy, was sich auch hier wieder einschaltet. Und solange der Bug #51 nicht einwandfrei nachvollziehbar ist, kann auch quarx sich nicht an einer Lösung versuchen, wie sollte er testen, ob eine Codeveränderung den gewünschten Effekt bringt?! Und solange wird die Problemlösung Kaffeesatzleserei bleiben, vielleicht für immer ;-(.

 

[MB526]

Welche SBF nutzt Du?

ooo benutzt für sein MB525 (#5887)

Ich benutze beim "Back To Stock" für ein MB525 als SBF "Android 2.2.2 Blur_Version.34.177.3.MB525.Retail.en.DE" (Froyo)

 

[Jung]

Schade, auf die SBF kann ich leider nicht zurück.

 

[ooo]

@Jung
Vielleicht kennst du das schon:

SBF-files Defy and Defy+ STOCK ROMS, bootloa… | Motorola Defy | XDA Forums

Dort kannst du herausfinden, ob nicht doch ein Downgrade machbar ist.

TWRP-Ausschalten und "reguläres" Ausschalten sollten die identische Funktion ansprechen (dann wäre es ein Software Bug im ROM, ja). - Vorausgesetzt, es werden von der Software physikalisch die identischen Register, Speicherzellen, OP-codes benutzt. - Am Schluss ist es ja immer Ladung oder Nicht-Ladung von Hardware. - Anders gesagt: Wenn man eine (ältere) ROM findet, die (auf dem identischen Phone) das Phone aus lässt, dann kann man von einem Software-Bug in der ROM ausgehen. - Das Dumme daran ist, dass man dafür jede Menge Zeit bräuchte (evtl. 200++ Nightlies zurück in die Vergangenheit?).

Schade, auf die SBF kann ich leider nicht zurück.

_____

@JamesM , @MB526
Merci

 

[vps]

Ich probier das Programm mal aus. Obwohl ich in letzter Zeit kaum Probleme mit dem RIL-Bug hatte, eher mit der erfoderlichen PIN-Eingabe nach schlechtem Empfang.

Beim Stromverbrauch helfen solche Tools meiner Erfahrung nicht, zumindest nicht mir. Ich habe das Defy schon ganze Tage zu 99% im Flugmodus betrieben.

Immer noch das ROM vom 23-Aug, auto-data funktioniert ganz gut und scheint (obwohl ich das nicht gedacht hätte) auch ein wenig bei mir die Laufzeit zu verlängern. Ich hatte schon mal etwas mehr als 2 Tage Laufzeit ohne Nachladen

Allerdings habe ich nun öfter als früher den Fall, daß ich die PIN eingeben muß. Vermutlich durch den Fall, daß er bei schlechtem Empfang die Datenverbindung kurz einschalten möchte. Tagsüber im Firmengebäude ist der Empfang halt gruselig.

 

[Pizzapeter]

Hallo Defy Freunde , ist ja viel los hier.

Könnte außerdem jemand mit diesem Problem einmal folgendes versuchen: Nach dem sich das Defy abgeschaltet hat, den Power-Knopf kurz drücken (so als wenn man das Defy im Normalbetrieb aufwecken wollte). Dann bitte wieder warten, ob es sich dennoch einschaltet. Wirre Fehler erzeugen wirre Ideen.

Das mach ich öfter, weil ich schalte mein Handy jeden Abend aus, und probiere oft später ob es aus oder wieder an ist. Auch danach geht es manchmal wieder an...

Edit:
Was ich nicht nachvollziehbar habe, ist, dass beim Flashen bzw. beim Entfernen/Einsetzen des Akkus das Phone wieder selbst startet. - Entweder sofort oder nach einigen Sekunden. - Also liegt hier evtl. auch die Vermutung nahe, dass irgendein diskretes Bauteil ("müder" Kondensator, statische Aufladung, Kriech-Spannung), dafür sorgt, dass es hier zu einem Effekt kommt, der ein Einschalten provoziert. - Das wäre dann die (altersschwache oder qualitativ minderwertige) Hardware als Verursacher. - Wir sprechen hier ja auch von bis zu fast 4 Jahre alten Geräten, die nicht Endanwender-konform benutzt wurden (hunderte Flash-Vorgänge etc.). - Das kann Quarx dann auch nicht mehr abfangen ...

Etwas ääähnliches hatte ich auch schon mal geschrieben, ich glaubte auch schon eine Tendenz zu sehen, das der Bug hauptsächlich auftritt, wenn die Accuspannung besonders hoch oder besonders niedrig ist... kann ich leider auch nicht wirklich bestätigen.

Aber spricht nicht dagegen, dass das Auschalten aus TWRP heraus angeblich funktionieren soll? Leider testet man genau das nicht so oft, wie das Abschalten aus CM11 heraus. Diese These wurde ja aufgestellt, leider ist nicht klar wieviele Leute genau dies wie oft mit wie vielen Geräten versucht haben. Vielleicht gibts es ja doch das ein oder andere Defy, was sich auch hier wieder einschaltet. Und solange der Bug #51 nicht einwandfrei nachvollziehbar ist, kann auch quarx sich nicht an einer Lösung versuchen, wie sollte er testen, ob eine Codeveränderung den gewünschten Effekt bringt?! Und solange wird die Problemlösung Kaffeesatzleserei bleiben, vielleicht für immer ;-(.

Das es sich nach einem TWRP ausschalten nicht wieder einschaltet, mag sein, allerdings wenn ich es ein 2tes mal, normal ausschalte dann bleibt es meistens auch aus...
Ich habe mir das alles nicht genau gemerkt... weil es meistens spät ist..

Gibt es eigentlich einen Weg, aus dem eingeschaltetem Betrieb direkt ins TWRP zu kommen? Damit wäre es einfacher zu testen.....

 

[MB526]

Ein Beispiel beim Rom flashen mit beiden Telefonen: alles war identisch von Stock und Root sbf Dateien bis Rom. Auf dem MB525 (grüne Linse) wollte es einfach nicht funktionieren, auf dem MB526 ging das wie von allein. Habe das echt mehrmals versucht, mit allem was meine "Trickkiste" her gab, nix zu machen. Eine Version zurück ging ohne Probleme, aber das Aktuelle, keine Chance, immer der selbe Fehler, Installation abgebrochen.

Von daher denke ich schon das die Komponenten Hardware und sbf zwei Wichtige Bausteine beim flashen sind, wenn nicht sogar die mit am Wichtigsten.

Es ist schon lange her, da wollte man mir nicht wirklich glauben oder Gehör schenken wo ich mehrmals bei Problemen sagte, es kommt auch auf die sbf an. Da reagierte man nicht so Glaubhaft drauf...Waren meine ich die Mehrheit mit einem Defy+ (bin da aber nicht mehr sicher).
Auch habe ich immer schon ohne SIM und ohne SD Karte die SBF aufgespielt, dann eine frisch formatierte Karte genommen mit nur dem nötigstem drauf zum flashen.

Habe mir überlegt, ob es wohl angebracht wäre einmal die Wichtigsten Dinge über sbf zu welchem Telefon ins Wiki zu bringen? Wenn Cua der Meinung ist, das passt da rein, dann schreibe ich das einmal in Ruhe zusammen. Finde es für Anfänger recht schwierig durch zu steigen welche sbf den nun die Richtige ist und dann diese auf Anhieb zu finden. Und wenn man die Geschichte nicht weiß mit dem Downgrade wobei da wo was nicht mehr geht, dann bleibt mitunter schon einmal der Bildschirm schwarz.
Auch das Problem mit der Kamera hatten wir ja auch schon bei manchen und bei Anderen wieder überhaupt nicht, denke das liegt evtl. auch schon viel an der sbf und BL 4 aufwärts und ob rote oder grüne Linse. Das ist jetzt rein Spekulativ, also nicht drauf fest nageln.

Das mit dem Wiki und sbf wird dann eine Übersicht als Verlinkung mit Textpassagen zu Themen die es hier und bei XDA schon gibt, wo man das passende findet zu dem jeweiligem Telefon.
Dazu oder vorab ein paar Grundlegende Dinge die man beachten sollte, laß mir dann dann noch etwas dazu einfallen.

Es gibt hier einen, der ein Downgrade geschafft hat von 2.3.6 auf 2.3.4 zurück, aber ob das stimmt weiß ich nicht, der hat hier nur einmal geschrieben. Auch gibt es bei XDA eine BL6 sbf Froyo die ein Downgarde möglich machen soll. Habe es probiert, ging nicht, habe dabei einen Fehler gemacht oder schon vorher hat mein Schulenglisch versagt und ich habe das Thema falsch verstanden, kann auch sein.

Ein wenig noch zum leidigen Akkuverbrauch. Habe die letzten Tage zig auf andere Versionen geflasht, von WajkIUI Multilang 3.1.2.7, Motorola defy bl7 sbf all in one, Miui v4 hwa multilingual for Defy Plus, MIUI_GB_Defy+ bis zu einfachen MIUI, hör mir bloß auf, die Akkufresser hoch 100. Klar, ist ja ein wenig bekannt mit dem Akku, aber das war schlimm. Habe auch den Battery Fix für GB Kernel installiert, aber das hat bei keiner Rom was gebracht.
Ob das jetzt am MB525 gelegen hat und beim MB526 nicht passiert wäre, will ich gar nicht mehr wissen, beim Defy kommt nur noch was rauf von Quarx ab CM11 weil es einfach sehr gut funktioniert.

 

[JamesM]

Habe mir überlegt, ob es wohl angebracht wäre einmal die Wichtigsten Dinge über sbf zu welchem Telefon ins Wiki zu bringen

Super Idee.
Habe erst letzt Woche mit diesem Problem gekämpft und einen ganzen Tag benötigt, um mir alles zusammen zu suchen. Dank Eurer Hilfe hab ich dann das Defy wieder zum laufen gebracht!

 

[dmasu]

Zur 23.09.:
Könnt Ihr Videos abspielen oder bekommt Ihr auch eine Fehlermeldung?

Bug #51:
Ich muss mich korrigieren: Habe erst seit Anfang Juni KitKat auf dem Defy und beobachte den Bug bewusst seit Anfang August. Ich bin mir aber sicher, dass es von Anfang an dieses Wiederanschalten bei mir gab. Was sich mit den Meldungen auf XDA auch deckt. Bis Januar hatte ich noch nicht mal gerootet und von da ab CM10 auf dem Defy und niemals diesen Bug gehabt.

Wie beschrieben teste ich eine neue Nightly mit kurzen Ausschaltphasen von weniger als 1h und bisher trat der Bug dann spätestens in der dritten Ausschaltphase auf. Wenn ich das Defy "verlässlich" ausschalten will, mache ich das über TWRP. Seit Anfang August ist mir bei wöchentlich mindestens zweimal Ausschalten über TWRP kein Mal das Defy von alleine wieder angegangen. Um sicher zu gehen, teste ich gerade das TWRP-Ausschalten ebenfalls mit kurzen Ausschaltphasen. Ich werde berichten.

Ich überlege derzeit anschliessend zurück auf Stock-ROM zu gehen, um dort auf den Bug zu testen. Anschliessend dann mit den CM11 ROMs langsam in die Vergangenheit zurück zu gehen, in Monatsschritten, um damit die ROM mit der entscheidenden Änderung zeitlich einzugrenzen und schliesslich zu finden. Ich schrecke aber noch etwas vor dem Aufwand zurück. Ich hab nur das eine Handy - muss gut geplant werden.

@MB526: Wiki-Eintrag

 

[0815Genie]

Hallo an alle!

Mit diesem Beitrag möchte ich mich vor allem bei den großartigen Bemühungen aller Devs bedanken. Diese gehen in erster Linie Quarx und Blechd0se aber auch an alle beteiligten CM Devs und Supporter!

Ich beobachte den Thread schon seit einem halben Jahr und gestern habe ich das Upgrade von CM7 auf CM11 gewagt und gewonnen Alles funktioniert soweit super, aber langsam, hier kommt mein Bericht:

Im April hatte ich ebenfalls versucht das Upgrade auf CM11 auszuführen, scheiterte aber am Bug "Einrichtungsassistent crasht". Ohne Homescreen kein Programm, ohne Programm ... na ihr wisst schon. Nach 8 Stunden harten versuchens hatte ich immerhin im Morgengrauen wieder ein funktionierendes CM7.

Damit mein Handeln nachvollzogen werden kann:
Zuerst habe ich (nach dem Backup, das ist der nullte Schritt) TWRP 2.6.3.0 geflasht.
Nach einem Neustart in TWRP gebootet, WIPE, dann cm-11-20140923-nightly-mb526 und sofort gapps-kk-20140918-minimal-x-edition-signed hinterher geflasht.
Neustart und das System ließ sich mit dem Einrichtungsassistent einrichten. Nach wenigen Minuten war ich schon wieder online.

Dies sind meine Erfahrungen, vor allem im Vergleich zu CM7:
+ Alle gewünschten Funktionen sind erreichbar. Bisher konnte ich noch keinen Bug feststellen, und ich habe wirklich schon fast alles probiert, was ich probieren konnte
+ Im Vergleich zu CM7: WLAN ist stabiler, Youtube und Tagesschau waren vorher (bei mir) unbenutzbar
+ CM7 Browser ist gern abgestürzt, ist hier noch nicht passiert
+ Android 4.4.4 ist vom 19.06.2014, das haben selbst brandaktuelle Modelle aus dem Laden nicht unbedingt.

Das klingt doch echt super, oder!? Neutral:
o Batterieverbrauch kann ich nicht beurteilen, scheint aber ok zu sein
o Performance im Programm ist gleichbleibend

Ok, und was ist nicht so toll:
- Wechsel zwischen Screens bzw. Programmen dauert ca 1-2 Sekunden, wenn es noch nicht geladen wurde, dann noch länger. Das war vorher deutlich schneller.

Gesamturteil:
Erfolgreich! (soweit ich das sagen kann)

Viele Grüße

 

[Fight4Music]

Ich war mal so frei und hab die MMS/APN Diskussion in einen eigenen Thread ausgegliedert. Der Thread dazu befindet sich hier: https://www.android-hilfe.de/forum/...la-defy.577/mms-apn-einstellungen.614556.html

Bei Fragen/Kritik/Anregungen bitte einfach per PN an mich wenden - so können wir auch außerhalb dieses Threads Probleme gemeinsam aus der Welt schaffen.

-> Startpost angepasst:
- Problemwiki eingebunden.
- Neuer Unterpunkt unter Probleme/Bugs/Todo mit Verweis auf die ausgegliederten Probleme mit Lösungen. --> Vorteil: Es muss nicht der Verlauf der letzten 3 Wochen gelesen werden, um ein Problem/Lösung zu verstehen. Es reicht nun ein Blick in den Startpost und dem zugehörigen Verweis.

Im nächsten Schritt werde ich noch die SDBoot Beiträge zusammenfassen und ausgliedern, da es sich zur Zeit um ein experimentelles Feature handelt, ähnlich wie beim 3er Kernel.

Ich hoffe auf diesem Wege euch alle zufriedenstellen zu können

 

[Pizzapeter]

Zur 23.09.:
Könnt Ihr Videos abspielen oder bekommt Ihr auch eine Fehlermeldung?

Bug #51:
Ich muss mich korrigieren: Habe erst seit Anfang Juni KitKat auf dem Defy und beobachte den Bug bewusst seit Anfang August. Ich bin mir aber sicher, dass es von Anfang an dieses Wiederanschalten bei mir gab. Was sich mit den Meldungen auf XDA auch deckt. Bis Januar hatte ich noch nicht mal gerootet und von da ab CM10 auf dem Defy und niemals diesen Bug gehabt.

Wie beschrieben teste ich eine neue Nightly mit kurzen Ausschaltphasen von weniger als 1h und bisher trat der Bug dann spätestens in der dritten Ausschaltphase auf. Wenn ich das Defy "verlässlich" ausschalten will, mache ich das über TWRP. Seit Anfang August ist mir bei wöchentlich mindestens zweimal Ausschalten über TWRP kein Mal das Defy von alleine wieder angegangen. Um sicher zu gehen, teste ich gerade das TWRP-Ausschalten ebenfalls mit kurzen Ausschaltphasen. Ich werde berichten.

Ich überlege derzeit anschliessend zurück auf Stock-ROM zu gehen, um dort auf den Bug zu testen. Anschliessend dann mit den CM11 ROMs langsam in die Vergangenheit zurück zu gehen, in Monatsschritten, um damit die ROM mit der entscheidenden Änderung zeitlich einzugrenzen und schliesslich zu finden. Ich schrecke aber noch etwas vor dem Aufwand zurück. Ich hab nur das eine Handy - muss gut geplant werden.

@MB526: Wiki-Eintrag

Hab mir jetzt auch die "23.9" installiert, habe noch ein altes Video, das kann ich abspielen... Neues Video gemacht, kann nicht abgespielt werden

Bug51, auch noch da... ich werde auch mal eine kleine Testreihe machen:

Handy ausschalten - warten, schaltet sich wieder ein - ins TWRP Booten, Power off - Hoffen, das es ausbleibt.

Handy ausschalten - warten, schaltet sich wieder ein - normal Booten lassen, wieder ausschalten - schauen, ob es auch aus bleibt.

Beide Varianten erstmal je 5x so als ersten Anhaltspunkt.

 

[ooo]

Passt auf, dass ihr keine Server (SSH) mit der aktuellen Nightly 2014-09-23 (und älteren) mit Verbindung aus dem Internet laufen habt, die die bash shell benutzen, da diese ebenfalls vom ShellShock exploit betroffen ist. AFWall+ dürfte dies standard-mäßig ohnehin unterbinden, wenn diese korrekt eingestellt ist.

Quelle:
Angriffe auf ShellShock-Lücke häufen sich | heise Security

Die alternative Android-ROM CyanogenMod hat ebenfalls Updates veröffentlicht, im Gegensatz zu den meisten Android-Versionen wie den Images von Google ist dort nämlich Bash mit installiert. Andere Android-Systeme nutzen eine puritanischere Shell und sind damit nicht angreifbar. Auch das von manchen Nutzern nachinstallierte Busybox ist nicht betroffen.

Im offiziellen CyanogenMod ist dies bereits gefixt, aber der Build Bot von Quarx produziert ja seit ein paar Tagen keine neue Nightly.

 

[ooo]

Ich habe mir inzwischen den jüngsten Source-Code der bash Shell 4.3 geholt und alle 26 Patches integriert. - Dann habe ich mir diese gepatchte Release unter Linux für Android kompiliert und die benötigten Libraries statisch dazugebunden, so dass das Programm nicht auf die Libraries der Nightly angewiesen ist (deswegen ist die neue bash auch größer).

Nach Tests kann ich sagen, dass die Sicherheitslücke bei mir auf dem Phone nicht mehr existiert.

Wer möchte, kann die bash (V.4.3.26) auf seinem Gerät austauschen, bis eine neue Nightly existiert, die eine gepatchte reguläre bash beinhaltet.

Das geht so:

• Download der bash.zip hier im Posting (Dateianhang)
• Auspacken (die zip-Datei enthält die neue Datei "bash")
• Mit CM Filemanager als root das Verzeichnis /system/xbin/ öffnen
• Dann dort (alte) bash in bash.original umbenennen (und evtl. die Berechtigung "X" wegnehmen, um die ungewollte Ausführung zu verhindern)
• Jetzt die neue heruntergeladene Datei bash von der SD Card in das Verzeichnis /system/xbin/ kopieren
• In den Dateieigenschaften unter Berechtigungen "Besitzer" auf "00000 - root" und "Gruppe" auf "02000 - shell" setzen und unten
• bei "Besitzer" R W X anhaken,
• bei "Gruppe" R und X anhaken,
• bei "Andere" R und X anhaken
• Jetzt hat man diese Sicherheitslücke geschlossen

Quelle: Angriffe auf ShellShock-Lücke häufen sich
_

 

[fairdroid]

Hallo @ooo!

Ich habe bei der originalen bash-Datei als Besitzer "0-root" und für die Gruppe "2000-shell".
Du schreibst, dass man die neue Datei auf "00000 - root" setzen soll - Besitzer und Gruppe.
Warum soll man das tun, also die Eigentümer anders setzen als bei der originalen bash-Datei?
Oder übersehe ich da was und das hat auch was mit dem Beseitigen des Bashbugs zu tun?

Ansonsten: Danke für dieses Engagement!!!

 

[ooo]

Wenn es bei dir (euch) in der originalen bash Datei so ist

• Besitzer = root (00000)
• Gruppe = Shell (02000)

dann bitte genau so beibehalten.

Bei mir war es (evtl. aufgrund von vielen Versuchen) beides root (00000).
Ich hab's oben im Posting korrigiert.

Merci für's Aufpassen.

Hallo @ooo

Ich habe bei der originalen bash-Datei als Besitzer 0-root und als Gruppe 2000-shell.
Du schreibst, dass man die neue Datei auf 00000 - root setzen soll - Besitzer und Gruppe.
Warum soll man das tun, also die Eigentümer anders setzen als die originale bash-Datei?
Oder übersehe ich da was?

Ansonsten: Danke für dieses Engagement!!!

Der ursprüngliche Beitrag von 13:43 Uhr wurde um 14:16 Uhr ergänzt:

Nachtrag:

Sollte jemand in der Interims-bash einige Befehle, das Prompt (mit Hostname und Pfad) und die Farben "vermissen", kann er das mit folgender Eingabe in der aktiven Shell korrigieren:

(Zwischen dem Punkt "." und dem Slash "/" ist ein Leerzeichen.)

. /system/etc/bash/bashrc

Die Liste der dann wieder zur Verfügung stehenden Befehle kann man auflisten mit

alias

 

[King1791094]

Also die Rom hackt extrem seit der m8 Version... Wird immer schlimmer

 

[King1791094]

Ich meine das es sich oft aufhängt und laagt...nicht flüssig läuft.

 

[dmasu]

@king1791094 :

Ich bin mit den Monatsversionen von CM auch nicht so vertraut - M8, war das im Juni oder Juli? Sind wir nicht schon bei M11?

Wenn Du Hilfe erwartest muss Du noch etwas genauer werden: Welche Nightly verwendest Du, ab welcher Nightly meinst Du traten die Probleme auf usw. Welches Defy hast Du eigentlich, oder bist Du gar im falschen Thread gelandet?

Tatsächlich werden hier die neuen Nightlies, wenn sie laufen, eigentlich immer mit: "Läuft gefüllt viel flüssiger" oder "Akkulaufzeit auch wieder eine Spur besser" kommentiert. Was ich auch nicht alles so recht glauben mag, aber ist wohl immer das "Beste Persil aller Zeiten" ;-)

 

[Pizzapeter]

Passt auf, dass ihr keine Server (SSH) mit der aktuellen Nightly 2014-09-23 (und älteren) mit Verbindung aus dem Internet laufen habt, die die bash shell benutzen, da diese ebenfalls vom ShellShock exploit betroffen ist. AFWall+ dürfte dies standard-mäßig ohnehin unterbinden, wenn diese korrekt eingestellt ist.

Da ich eh gerade nicht genau weiß, worum es dabei geht meine AFWall+ verhindert dies? Das heißt, wenn sie richtig eingestellt ist? Habe teils deine verlinkten Einstellungen benutzt.

Zu "23.9":
Hab mal irgendwo was über "Video abspielen geht nicht" gelesen, habs nicht wiedergefunden, weiß wer wo das war?
Mit GPS stimmt auch was nicht, ich dachte dies wäre gelöst... alerdings weiß ich auch noch nicht ob es was mit Net.Osmand zu tun hat... oder XPrivacy... aber dazu gibt es ja verlinkte Hilfe, ist das noch aktuell?