Probleme/Lösungen für Geräte mit Root/CWM etc. beim OTA Update 175.xxx/176.xxx

[Micha1965]

Hallo,
Also bei meinem One ging die Inastallation erst nach Stock-Recovery und deinstall Framework + Module, vielleicht versuchste das mal.

Micha

 

[karlsberg]

Genau, außerdem wurde hier schon vermutet das eventuell Framework + Module die Ursache sein könnten.
Und wenn das Änderungen in der build.prob zu Folge hat wird es eh schwierig. Am besten mit Tool zurück auf Stock.

Kleine Anmerkung am Rande, liest hier eigentlich jemand Threads durch, bevor Fragen gestellt werden. Ist ja nicht so das dieser sehr unübersichtlich wäre.

Gesendet von meinem Nexus 7 2013 mit der Android-Hilfe.de App

 

[Hardy32]

Bei mir ging das Update nachdem ich wieder die Stock Recovery drauf hatte und die App "Demo.apk" wieder aus meinem Backup wiederhergestellt hatte. Hatte sie beim entfernen der Crapware entsorgt.

Ansonsten : Root, Xposed inkl. Gravity Box und unlocked Bootloader haben nicht gestört beim Update.

VG
Hardy

Gesendet von meinem GT-P3100 mit der Android-Hilfe.de App

 

[GeoLudes]

So, ich gebe auch mal ein Update, schließlich hab ich das hier ja losgetreten:

Ich habe alle möglichen Varianten ausprobiert, habe Xposed und Adaway runtergeschmissen, alle Recoverys getestet, Cache geleert, etc. aber das manuelle Update über die Recovery hat nicht funktioniert. Wie ein paar Posts weiter oben schon geschrieben hat mir wohl irgendeine App die Build.prop verändert, was zum Abbruch des Updatevorgangs geführt hat. Leider konnte ich nicht nachvollziehen, welche App das war.

Nachdem ich dann heute morgen versehentlich (im Halbschlaf, ich Idiot) das Updateangebot angenommen hatte (ja, es poppte tatsächlich auf einmal auf...) habe ich mich in einem Bootloop wiedergefunden. Dann war ich auch wach *g* und habe (gezwungenermaßen) das MotoG komplett zurückgesetzt. 1000Dank für die batch-Datei von Xain....

Fazit: Drei Fotos und meinen Spielstand bei HillClimb-Racing hab ich verloren *neeeeeeiiin* , aber jetzt is mein System wieder sauber und das Update hat auch funktioniert. Eine Lösung für das Problem mit der veränderten build.prop kann ich aber leider nicht anbieten.

MfG
GL

 

[karlsberg]

@Hardy32: Es gibt hier aber auch Leute die das Problem trotz Stock-Recovery haben bzw. hatten. Bei mit war auch das Stock-Recovery
der erste Schritt, hätte der nicht funktioniert hätte ich komplett neu geflasht. Wenn man gerne mit dem Gerät herum experimentiert muss man wohl damit rechnen es ab und zu neu aufzusetzen. Man kann sich ja gegen den Verlust von Daten entsprechend absichern.
Gesendet von meinem Nexus 7 2013 mit der Android-Hilfe.de App

 

[zwerg77]

Kann bitte jemand mit Root, bei dem das 176er Update funktioniert hat, seine build.prop hochladen. Nehme auch gerne eine 175er build.prop. Bei mir bleibt das Update - auch nach einem Factory Reset - immer hängen, daher würde ich gerne ein Diff meiner build.prop mit einer funktionierenden machen.

 

[Hardy32]

@Karlsberg : Ich wollte ja auch nicht behaupten die Lösung schlechthin gefunden zu haben

Hier meine Build.prop gerootet und 176er Version

Musste sie zippen, sonst konnte ich sie nicht hochladen.

VG
Hardy

 

[karlsberg]

@Hardy32: War auch nicht als Kritik gedacht sondern sollte eine reine Feststellung sein.

@zwerg77: gib mal bitte Rückmeldung ob das mit der build.prop was gebracht hat.

 

[Hardy32]

@Karlsberg : so kam es auch an

@zwerg77: Würde mich auch interessieren

 

[zwerg77]

@Hardy32: Vielen Dank fürs hochladen.

Leider habe ich aber nichts gefunden, was mich schlauer macht. Die einzigen Unterschiede sind die logischen Unterschiede zwischen 175 und 176 (IDs, Datum, Uhrzeit etc.). Und die 176er hat eine zusätzliche Radio Build Prop (persist.radio.relay_oprt_change=1).

Nachdem alle Versuche fehlgeschlagen sind (Xposed deinstalliert, alle Recoverys probiert,...), werde mir also wohl die 174er flashen müssen und dann die zwei Updates einspielen.

 

[JayJay21]

Ich habe bei mir das Update als ZIP über die recovery geflasht, hat einwandfrei funktioniert.

 

[zwerg77]

Habe ich auch versucht, bekomme aber bei allen Methoden immer die gleiche Fehlermeldung:

"\system\build.prop" has unexpected contents.
Installation aborted.

 

[J.S. Fontanelli]

Ich habe bei mir das Update als ZIP über die recovery geflasht, hat einwandfrei funktioniert.

Hab ich jetzt auch mal mit CWM probiert. Update schlägt fehl mit der Meldung: Das Update wäre für "falcon_umts" und ich hätte ein "xt1034". In der build.prop steht aber korrekt "xt1032".

 

[karlsberg]

@Hardy32: Vielen Dank fürs hochladen.
Nachdem alle Versuche fehlgeschlagen sind (Xposed deinstalliert, alle Recoverys probiert,...), werde mir also wohl die 174er flashen müssen und dann die zwei Updates einspielen.

Ich glaube das Tool von Xian flasht sogar bereits die 175er. Scheint aber momentan die einzig wirksame Methode zu sein. Zumindest bei vielen die hier aufschlagen.

Gesendet von meinem Nexus 7 2013 mit der Android-Hilfe.de App

 

[bhf]

Ich biete hier eine build.prop eines unmodifizierten Systems mit installiertem 176'er Update. Ist allerdings die franz. Version, also eher nicht von großem Nutzen für die meisten hier.

Aus Kompatibilitätsgründen habe ich ein .txt dranhängen müssen.

 

[GeoLudes]

Moinmoin,

ich versuche mich mal an einer kleinen Zusammenfassung, da ich gerne den ersten Post im Thread aktualisieren würde.

Bislang gibt es 4 unterschiedliche Wege, das Update erfolgreich zu installieren, ohne einen Factory-Reset zu machen:

1. Es gibt User, bei denen das Update trotz root und exposedfm über die Recovery problemlos zu flashen war (z.B. Stefan1893, JayJay21 ?).
2. Es gibt User, bei denen eine andere Recovery nötig war (karlsberg mit stock, Spikie mit philztoch und mar.co mit cwm)
3. Es gibt User, die auf Stock recovery zurück mussten, und die XposedFM-Module zusätzlich deaktivieren mussten (Micha1965)
4. Hardy32 hat die Demo.apk wiederhergestellt, danach ging es trotz root, xposedfm etc.

Wenn von diesen Möglichkleiten keine zum Erfolg führt, muss man Android komplett neu flashen (howto gibts hier: Klick ).
Das ist bislang immer dann der Fall (korrigiert mich bitte, wenn ich hier falsch liege), wenn:

1. Das Update über Einstellungen/Über das Telefon/Systemupdates gestartet wurde und man sich in einem Bootloop wiederfindet (ist mir passiert)
2. Das Update über die Recovery in einer Fehlermeldung endet, die (vermutlich) auf eine beschädigte build.prop zurückzuführen ist, wobei entweder eine falsche Androidversion als Grund angegeben wird ("Package expects build fingerprint of motorola/falcon/retde/falcon_umts:4.4.2/KLB20.9-1.10-1.9.1/1:user/release-keys or motorola/falcon/retde/falcon_umts:4.4.2/KLB20.9-1.10-1.24-1.1/1:user/release-keys this device has: motorola/falcon_retgb/falcon_umts:4.3")
   oder
3. eine falsche Geräteversion angenommen wird (J.S. Fontanelli:"Das Update wäre für "falcon_umts" und ich hätte ein "xt1034". In der build.prop steht aber korrekt "xt1032".")

Eine allgemeine Lösung ergibt sich daraus bislang nicht. Schade, ich hatte gehofft, anderen betroffenen usern mit dem Thread hier eine Neuinstallation ersparen zu können.

Wer weiter experimentieren möchte:
Hier ist eine Build.prop (gerootet und 176er Version) von Hardy32
und
hier eine 176er build.prop von einem unmodifizierten 176er mit installiertem update von bhf, allerdings als franz. Version


Habe ich etwas vergessen?
MfG
GL

 

[karlsberg]

Schöne Zusammenfassung! Mir ist nur aufgefallen das du von einem 'Factory-Reset' schreibst. Es ist aber eigentlich ein komplett neues Aufsetzen (Flashen) der Stock Firmware. Ein Factory-Reset würde in dem Fall nicht helfen.
Aber du hast recht, eine generelle Vorgehensweise scheint es derzeit nicht zu geben.

Gesendet von meinem Nexus 7 2013 mit der Android-Hilfe.de App

 

[GeoLudes]

Schöne Zusammenfassung! Mir ist nur aufgefallen das du von einem 'Factory-Reset' schreibst. Es ist aber eigentlich ein komplett neues Aufsetzen (Flashen) der Stock Firmware. Ein Factory-Reset würde in dem Fall nicht helfen.
Aber du hast recht, eine generelle Vorgehensweise scheint es derzeit nicht zu geben.

Gesendet von meinem Nexus 7 2013 mit der Android-Hilfe.de App

Danke, hast völlig recht.
Habs abgeändert.

 

[deja-vue]

hallo leute,

habe heute auch ewig probiert und am ende doch hinbekommen. hatte mir selbst ein bein gestellt, mit titanium backup. und zwar hatte ich alle vorinstallierten motorola apps deaktiviert. dadurch hat das system nicht nach den update gesucht bzw. konnte es nicht finden.
nachdem ich dienste und mein telefon neugestartet hatte, fand er sofort das 175er update. konnte es problemlos installieren. anschließend fand er sofort das 176er update. konnte es ebenfalls problemlos installieren. root ist erhalten geblieben.

system:
MG 8GB
stockrom
stockrecovery
bootloader offen
root


hoffe es hilft dem einen oder anderen!

grüße

 

[myVoodoo]

Ich habe das 16 GB Moto G und mich schon fleissig mit beschäftigt.

Derzeit ist das Blur_Version.175.44.1.falcon_umts.Retail.en.DE drauf. Ich verwende CWM (CWM6046-MotoG44) als Recovery. Das Handy ist gerootet mit SuperSU.

Jetzt habe ich den Thread hier vollständig durchgelesen und möchte deshalb, bevor ich das automatische Update von Motorola installiere auf das Stockrom updaten um die Boot Schleife zu umgehen.

Ich habe das mit mfastboot flash recovery recovery.img gemacht. Ich bin mir sicher, dass es die img ist, die ich verwendet habe um auf 175 zu flashen. Allerdings funktioniert es nicht. Es kommt immer das Bild von einem kaputten Androiden, wenn ich in den Recovery möchte.

Habe jetzt erstmal wieder CWM drauf. Wie bekomme ich denn nun das Stockrom drauf? Kann mir jemand weiterhelfen?