Hi Tencik, Der patch check in der updater-script aus der Updater.zip #1 fragt ob der Schlüssel aus der dritten Zeile passt, bevor er den patch freigibt patch check aus update #1: assert(apply_patch_check("/system/framework/core.odex", "ba642c8ee2fe289a4e9b94df03a1c366af453164", "c7e4cb1d48d26850390f8b59b71b5d156c264f44")); dieser, "c7e4cb1d48d26850390f8b59b71b5d156c264f44", in deiner Fehlermeldung angegebener Schlüssel ist der Schlüssel für /system/framework/core.odex aus der Auslieferversion, also der in der update.zip #1 abgefragt wird. Dieser wird in der update.zip #2 nicht gelistet und abgefragt; hier listet die Fehlermeldung vmtl. den vorgefundenen Schlüssel "c7e4cb1d48d26850390f8b59b71b5d156c264f44" einfach mit auf. und nach dem Patch ist der neue Schlüsselwert nach dem Update #1 eigentlich: "ba642c8ee2fe289a4e9b94df03a1c366af453164" Das Update zwei fragt die Schlüsselwerte so ab: assert(apply_patch_check("/system/framework/core.odex" "42a696b90eea6ba12d977248bd15ade50c672a0b", "ba642c8ee2fe289a4e9b94df03a1c366af453164")); Das Update #2 sucht jetzt den neuen Schlüssel (nach dem Patch aus Update #1), aus der dritten Zeile "ba642c8ee2fe289a4e9b94df03a1c366af453164" patcht, und der neue Schlüsselwert nach Update #2 lautet dann: "42a696b90eea6ba12d977248bd15ade50c672a0b" Deine Fehlermeldung zeigt aber den Schlüssel der Auslieferversion: "c7e4cb1d48d26850390f8b59b71b5d156c264f44", wahrscheinlich den, den der patch check vorfindet (oder es wurde erneut Update #1 benutzt), Interessant ist dass es auch einen zweiten, neuen u. anderen Schlüsselwert anzeigt: "b4b2651ed45d7562b71d9c19771fe2a8bef2b3f2" der weder in Update #2 noch in Update #1 angegeben wird. Hattest du vielleicht Xposed installiert? Habe den Eindruck da ist irgend etwas ziemlich durcheinander, wenn der patch check den neuen Schlüsselwert ausgibt. Es sieht auch so aus als ob evtl. statt Update #2 versehentlich wieder Update #1 gestartet wurde? Sonst erklärt sich mir nicht dass das Update den Schlüsselwert aus der Auslieferversion angeben kann, ausser der Sicherheitscheck gibt den vorhandenen Schlüsselwert aus wenn er den erwarteten Wert im Check nicht findet; denn nach dem ausgeführtem Update #1 müsste dieser ja ""ba642c8ee2fe289a4e9b94df03a1c366af453164" sein. (Wenn Update #1 korrekt gelaufen war) Und in Update #2, ich wiederhole mich, ist der Sicherheitscheck-Schlüsselwert "c7e4cb1d48d26850390f8b59b71b5d156c264f44" nicht enthalten. Wie das sein kann weiss ich nicht, Bin kein Experte, im Gegenteil, mir fallen nur scheinbare logische Brüche im Ablauf auf. Da müssen wir @TheDoctor M fragen, der dies in seiner Antwort ein paar Posts weiter oben bereits in seinem PS-Nachtrag als Möglichkeit angedeutet hatte. daddle
... Mehr anzeigen