Kingzone K1 - MT6592 5,5" FHD NFC Alu 8MP + 14MP Cams 2GB Ram 16GB Rom dual sim Android 4.3

[Michael_K]

Hab die stock recovery installier, dann über das Menü update geladen, installation läuft automatisch ab.

!!!Achtung: OTA Updates werden dann nicht mehr gehen (da die Prüfsumme der Build.Prop sich ändert, also vorher Backup machen!!!

Hab mal wahllos zwei alte Beiträge (teilweise) hervorgekramt.
Das OTA Update scheint nur mit Stock Recovery zu klappen.
Lt. einem anderen Beitrag von @Ora, den ich jetzt auf die Schnelle aber nicht finde, scheint beim OTA Update auch die Prüfsumme des Boot.img und Recovery.img geprüft zu werden....

 

[Ora]

htt92_wet_jb9

Chinpo:
Bitte schaue mal in Deiner
/system/build.prop nach, wie dieser Eintrag aussieht: ro.product.device = ???

 

[chinpho]

ro.product.device = htt92_wet_jb9

Sowohl device als auch name

Edit:
Außerdem in der build.prop zu finden:

# ro.build.product is obsolete; use
ro.product.device
ro.build.product=htt92_wet_jb9

 

[Ora]

1. Das install Script prüft:

assert(getprop("ro.product.device") == "htt92_wet_jb9" ||
	   getprop("ro.build.product") == "htt92_wet_jb9");

Also sollten in der build.prop entweder:

ro.product.device=htt92_wet_jb9

oder

ro.build.product=htt92_wet_jb9

stehen...

2. oder DEIN aktuelles Recovery kann das Script nicht korrekt abarbeiten (welches nutzt DU?) --> spiele das original zurück....

Eurer boot.img wird auch geprüft!

assert(apply_patch_check("EMMC:boot:5130240:e401e41abb66a9336368e9f200c3adc187e5f030:5130240:2f636db67155548389f337bd1548acb4e1f54c6f"));

---> Falls es zu weiteren Fehlermeldungen käme ---> spiele das Originale boot.img zurück

TIPP: wenn es dann durch ist, öffnet nicht mehr den Boot Loader (Patch boot.img), sondern öffnet den nur bei Bedarf temporär (MTK Droidtool).

 

[gsmfrank]

Habe gestern mein Kingzone K1 Turbo erhalten, und leider heute schon, durch blindwütiges copy pasten in die Build.Prop, und trotz tauschen dieser gegen den inhalt des originals, mehreren factory resets, dalvik und cache wipes,installation von CWM, und factory resets des selben, kann ich jetzt nur noch flashen...verstehe das aber irgendwie noch nicht so richtig (nexus 7 war da leichter)...ein bisschen verstehe ich schon von dem prozess, aber ich wäre echt froh, wenn ich eine Möglichkeit finde es wieder her zu stellen, mit eurer Hilfe...danke im vorraus!

Wenn überhaupt, bitte was ist das für ein Satz?
Sorry

 

[Zorbas]

1. Das install Script prüft:

assert(getprop("ro.product.device") == "htt92_wet_jb9" ||
	   getprop("ro.build.product") == "htt92_wet_jb9");

Also sollten in der build.prop entweder:

oder

stehen...

2. oder DEIN aktuelles Recovery kann das Script nicht korrekt abarbeiten (welches nutzt DU?) --> spiele das original zurück....

Eurer boot.img wird auch geprüft!

assert(apply_patch_check("EMMC:boot:5130240:e401e41abb66a9336368e9f200c3adc187e5f030:5130240:2f636db67155548389f337bd1548acb4e1f54c6f"));

---> Falls es zu weiteren Fehlermeldungen käme ---> spiele das Originale boot.img zurück

TIPP: wenn es dann durch ist, öffnet nicht mehr den Boot Loader (Patch boot.img), sondern öffnet den nur bei Bedarf temporär (MTK Droidtool).

Hallo Ora,

heißt das, das ich den Hinweis:

# ro.build.product is obsolete; use
ro.product.device
ro.build.product=htt92_wet_jb9

löschen kann und dann noch kontrolliere, ob der Eintrag

("ro.build.product") == "htt92_wet_jb9

richtig drin ist und Ihn ggf. ergänze und berichtige ?? Sorry für die "Newbie Frage" aber ich fang ja erst an.................. ;-)))

Danke Rolf

 

[Ora]

Nein, ich würde weder die build.prop noch das Script im zip bearbeiten.

Nur falls es tatsächlich so: in der build steht:

# ro.build.product is obsolete; use
ro.product.device
ro.build.product=htt92_wet_jb9

und nicht so:

# ro.build.product is obsolete; use ro.product.device
ro.build.product=htt92_wet_jb9

Also ich meine den Zeilenumschlag oben. Der darf nicht sein, denn dann wäre der zurück gelesene Wert leer.


Es ist NICHT angeraten die build.prop ohne einen geeignete app zu bearbeiten und auch dann nur mit höchster Konzentration. Eine fehlerhafte build.prop bringt das Phone ins Jenseits.

Ich denke eher es liegt an einem ungeeigneten Recovery auf Deinem Phone. Hast Du das geändert?

 

[AndyL]

Hat einer mal das originale Recovery.img?

 

[klassisch]

Bin nur etwas erstaunt, dass es recht genau auf der Ladestation liegen muss. Einen cm zu weit rechts oder links läd es schon nicht mehr....

versuche es einmal mit einem Ladepad mit drei Spulen . Die sind deutlich positionstoleranter.




Gesendet von meinem K1 turbo mit Tapatalk

 

[Zorbas]

[/QUOTE] Ich denke eher es liegt an einem ungeeigneten Recovery auf Deinem Phone. Hast Du das geändert?[/QUOTE]

Hallo Ora,

Nein, bis auf das Root mit "eroot" und einem Gps-Fix habe ich nichts geändert. Somit müsste nach meinem geringen Wissen eigentlich alles aussehen wie im Original.

Ändern würde ICH das über den entsprechenden TextEditor im "Rootexplorer".

Sorry, das die Antwort so lange gedauert hat, aber ich habe gerade Besuch aus Paris und da sind wir viel unterwegs.

Danke für die Hilfe

 

[Ora]

@Zorbas : dann hast Du ja auch noch die original boot.img und das mitgelieferte Recovery drauf?
Dann stelle mal DEINE /system/build.prop als download hier rein (zip).

 

[Poppeye]

Ich wäre dankbar für eine original recovery.img, damit ich das Update einspielen kann. Beim Booten versucht das Update-Script, das Update mittels recovery-Modus zu installieren und das schlägt bei mir fehl, weil TWRP den Parameter nicht unterstützt.

Übrigens... TWRP: Die 2.7.0.0-Versionen sind untereinander nicht kompatibel. Ich hatte mit der von SevenMax Backups erstellt und konnte diese mit der TWRP-Version in ALTF4's deodexed ROM nicht mehr finden...

 

[Ora]

@Poppeye : habe zwar das Handy nicht, aber einen Needrom Account

Das dürfte das default recovery sein...

Und noch einen Hinweis an ALLE... vor und nach dem OTA einfach mal meinen TIPP0 im MTK DRoidttool Thema anschauen. Sicherung ohne Root... hilft zukünftigen Ärger zu ersparen.

 

[Poppeye]

Vielen Dank, mit dem Original-Recovery startet auch das Update.

Interessanterweise checkt das Script nach dem Vorhandensein des Weather3DWidgets. Diese app hatte ich bereits eingefroren/entfernt, da sie hohen Akku-Verbrauch erzeugte. Ein Schuft, wer jetzt denkt, dass da im Hintergrund ständig Daten fliessen, evtl. sogar vielleicht nicht einmal Wetterdaten... Ein Update dieses Widgets ist aber für mich entbehrlich, genauso wie dessen Funktion. Daher hat das Script auch abgebrochen und ich konnte die Fehlermeldungen analysieren.

Update: Schaue mir das Update gerade auf dem PC an. Da wird im Systemverzeichnis so ziemlich alles gepatcht, was nicht niet- und nagelfest ist. Leider sind das alles binäre diff-patches, da kann man sehr schwer sehen, was passiert.

 

[Ora]

Das freut mich, dass ich auch ohne im Besitz des Handys zu sein, Euch helfen konnte.... und immer schön sichern TIPP0

 

[chinpho]

Lässt sich die standard_recovery.zip nicht auch einfach über CWM Recovery installieren? Also im Sinne von "Installiere Update.zip"
Das wäre ja schön einfach

 

[Michael_K]

versuche es einmal mit einem Ladepad mit drei Spulen . Die sind deutlich positionstoleranter.

Gesendet von meinem K1 turbo mit Tapatalk

Danke für den Tipp. Aber wie erkenne ich ein Pad mit mehreren Ladespulen ? Ich hab bisher zwei (Billig)Pads aus der Bucht, und beide sind gleich empfindlich in Bezug auf exaktes Auflegen des Phones.[DOUBLEPOST=1408192677,1408192520][/DOUBLEPOST]

Lässt sich die standard_recovery.zip nicht auch einfach über CWM Recovery installieren? Also im Sinne von "Installiere Update.zip"
Das wäre ja schön einfach

Originales Recovery.img mit MobileUncleTools installieren ? Also die *.ZIP erst entpacken?

 

[Ora]

Lässt sich die standard_recovery.zip nicht auch einfach über CWM Recovery installieren? Also im Sinne von "Installiere Update.zip"

Im Grunde genommen "ja".
-- mit mobileUncle
-- mit MTK Droidtool (und root)
-- mit dem SP Flashtool

 

[Poppeye]

Wer Schwierigkeiten mit dem Update hat, kann ja mal - auf eigene Gefahr, nur mit MTKDroid Backup - die Datei auf der SD-Karte \system_update\META-INF\com\google\android\updater-script so anpassen, dass die checks für die Dateien entfernt werden, die man selbst geändert hat. Also z.B. die Zeilen 122/123 löschen

assert(apply_patch_check("/system/build.prop", "d1d4ab3c21a4db6ce1d0bff00c25ef8640c1c19d", "c7d940ea38106cb24fd6158b986b738cba9230f2"));
set_progress(0.466848);

Build.prop ist allerdings ein schlechtes Beispiel, denn ein diff-Patch funktioniert nur, wenn sich das Script an bekanntem Datei-Inhalt entlanghangeln kann, um Einfügungen und Löschungen vorzunehmen. Wer seine build.prop modifiziert hat, bekommt bei Anwendung des Patches evtl. Schwierigkeiten. Auch ist build.prop Kandidat Nr. 1, um sein Handy unbrauchbar zu machen.

Wer allerdings apps entfernt hat, kann die entsprechenden checks "assert(apply_patch_check" löschen, sollte dann aber auch die entsprechende Patch-Zeile "assert(apply_patch" löschen, damit uns nicht vielleicht das bekannte Universum um die Ohren fliegt.

Ich weise nochmals daraufhin, das ist eine Aufgabe höchsten Schwierigkeitsgrades und sollte nur mit Backup und entsprechendem Wissen durchgeführt werden. Ich bin nicht für Bricks verantwortlich!

Wenn das gesamte system_update Verzeichnis gezippt wird, sollte man es übrigens dann auch per CWM/TWRP flashen können (system_update darf in der zip kein eigenes Unterverzeichnis sein).

 

[Ora]

Es ist NICHT angeraten die build.prop ohne einen geeignete app zu bearbeiten und auch dann nur mit höchster Konzentration. Eine fehlerhafte build.prop bringt das Phone ins Jenseits.

Ich weise nochmals daraufhin, das ist eine Aufgabe höchsten Schwierigkeitsgrades und sollte nur mit Backup und entsprechendem Wissen durchgeführt werden. Ich bin nicht für Bricks verantwortlich!

Gute Hersteller signieren das update.zip... da kann man nichts mehr manipulieren