Update #1

[daddle]

Du brauchst doch nur die apk um zu installieren.. Die odex-file wird automatisch erstellt, spätestens beim nächsten reboot.

 

[retikulum]

Nein, VideoFavorites ist eine System-App. Die ist nicht installierbar, sondern muss sich inkl. der Odex im System/Apps Ordner befinden.
Versuch doch mal, diese zu installieren, dann siehste es.

Ich brauche die Odex mit exakt der SHA1 Checksumme aus dem Update Script. Und das wird wohl nur die sein, die VOR dem Update vorhanden war.

 

[daddle]

Danke für die info; ich denke es ginge mit root auch für system-apps! Werde testen.

Ist denn youtube auch eine system-app? Und Chainfire installiert seine su.apk auch unter /system/app

 

[retikulum]

VideoFavorites ist keine Standalone App, deshalb lässt die sich nicht installieren. Die gehört zu einer anderen App dazu und wird aus dieser aufgerufen.
Das Bekloppte ist halt die Checksummen-Abfrage in der update_script. Ändern kann ich hier leider nix ohne Custom Recovery, wegen Signatur-Check.

Also, wenn mir nochmal jemand die VideoFavorites.odex herzaubern könnte? Bitte diesmal nicht umbenennen, lieber in ne RAR packen. Beim Umbenennen wird bereits die Checksumme anhand des Modified-Datums verändert!

 

[daddle]

Danke für die Erklärung.

Du brauchst also die ...odex von jemand der noch kein Update gemacht hatte, da schon das Update #1 nicht durchläuft? Kann ich leider nicht mehr geben, zwei Tage eher dann wäre es gegangen, hatte eine Woche mit Updates gewartet, aber dann war der Sog der Update-Meldungen zu stark geworden, konnte nicht mehr widerstehen! :blushing:

Hattest du denn was an den files geändert wegen der Streaming Probleme?
Oder von alleine fehlerhaft geworden.

 

[retikulum]

...aber dann war der Sog der Update-Meldungen zu stark geworden, konnte nicht mehr widerstehen! :blushing:

Haha, ja das kommt mir bekannt vor

Ich hatte eigentlich nur sämtliche Apps gefreezed. Warum sich hier die Checksumme dann geändert hat ist mir schleierhaft. Die .apk von Reinhardo hatte funktioniert, evtl. hat er noch die .odex für mich (diesmal nicht umbenannt, sondern besser in eine .rar gepackt)?

Du kannst mir aber gerne testweise mal deine .odex zukommen lassen. Evtl. passt die ja doch (vielleicht wurde ja nix geändert), was ich zwar nicht glaube... aber ein Versuch ists allemal wert...

 

[daddle]

Eintrag in dem mp2 to ota-1-Update in der c:\Lifetab_S8312\mp2-to-ota1.zip\META-INF\com\google\android\updater-script steht:

apply_patch_check("/system/app/VideoFavorites.odex", 

"4ca71e5988fb92afc7938f843a4a3d84b3a4da25", 

"525b2f812f2e8f8396cce58665625a627fdc5142") || 

abort("\"/system/app/VideoFavorites.odex\" has unexpected contents.");
set_progress(0.253402);

Die apk wird mit Update #1 auch gepatcht, aber die störte ja nicht beim Update-Versuch.

In dem ota1-to-ota2-Update in der c:\Lifetab_S8312\ota1-to-ota2.zip\META-INF\com\google\android\updater-script steht:

apply_patch_check("/system/app/VideoFavorites.odex", 

"f7c97bb7f68b2da013170ef9ceb339b16b2eda0b",

"4ca71e5988fb92afc7938f843a4a3d84b3a4da25") ||

abort("\"/system/app/VideoFavorites.odex\" has unexpected contents.");
set_progress(0.221440);

Die Update #1 prüft die Checksum "525b2f....." und die sich ergebende Neue ist "4ca71e....."

Die Update #2 prüft die Checksum "4ca71e....." und die sich ergebende Neue ist "f7c97b......"

Von Update #1 nach #2 wird die odex auch gepatcht, die apk aber nicht noch einmal, und die Checksum für "odex"ändert sich, dann wird dir meine nicht helfen. Bin schon auf Update #2.

Du könntest aber die updater-script in deiner Update #1.zip mit der passenden Checksum editieren, bzw. die Checksum-Prüfungszeilen rausnehmen, dann müsste das Update auch ohne "abort" durchlaufen. Auf die Formatierung achten. Sicherheitshalber in einer kopierten Updater-script arbeiten, dann die originale sichern und mit der editierten in der .zip ersetzen. Pfad dahin hab ich ja mit angegeben. Bei dir hängt doch update #1 oder? daddle

Nachtrag:
Oder du kopierst die nicht "gefreezde" odex von Reinhardo ins System, die war ja vor dem Update #1, daher sicher intakt trotz der Um- und Rückbenennung, löschst die Checksum-Prüfungs-Zeilen, dann bist du etwas sicherer dass die odex intakt ist. Vermute, dass das freezen etwas am Datei-Datums-Eintrag im Header ändert, daher die fehlerhafte Checksum; aber wird durch das Umbenennen dann auch passieren können.

 

[Reinhardo]

@ retikulum,

hier die .odex gepackt, als zip. Anhang anzeigen VideoFavorites.zip

Gruß und viel Erfolg

 

[daddle]

Nach dem reinkopieren könnte schon die Checksum verändert werden; man muss ja auch noch die Eigenschaften für die Datei neu festlegen, die nach dem Kopieren meist auf 666 steht. Mein Tab ist gerade in Gebrauch, werde sie nachher hier noch ergänzen.

VideoFavorites.apk:      UID:   root   GID:  root    -rw-r--r-- (644)

VideoFavorites.odex:     UID:   root   GID:  root    -rw-r--r-- (644)

Die Eigenschaften lassen sich am einfachsten mit Total Commander (Play Store) überprüfen und einstellen: langer Touch auf Datei - >
Eigenschaften wählen. Ist übersichtlicher für Nicht-Linux-User als im ES-3-Datei-Manager!

 

[retikulum]

Ich mache alles über die Shell (Linux-Power-User :-D ) . Aber danke. Ich nutze auch den ES File Explorer statt dem Total Commander, aber ist auch wurscht.

Ich teste und berichte.

Danke Reinhardo und daddle für die Mühen bisher!

Ich teste gerade auch ein bis zwei Möglichkeiten eine neue Recovery drauzubügeln. Wünscht mir Glück....

 

[daddle]

Ich wünsche Dir viel Glück!

Der Hinweis auf den TC war ja auch für Alle; konnte nicht wissen dass du LX-User bist.

Ein Hinweis noch: Habe gesehen dass in der Update.zip unter SEC_VER die Einträge geändert wurden:

Habe in dem Update #2 gesehen dass auch uboot jetzt auf secure gestellt wurde, in Update #1 stand nur in SEC_VER:

BOOTIMG = 1
RECOVERY = 1
ANDROID = 1

in Update #2:
BOOTIMG = 1
RECOVERY = 1
ANDROID = 1
UBOOT = 1

Weiss nicht ob dieser Eintrag SEC_VER diese Werte mit dem Updaten einstellt, und ob vorher beim nicht upgedateten Tab alles noch auf 0 stand; oder ob diese Werte nur ausgelesen werden, was dann bedeuten würde das zumindest mit Update #1 UBOOT auf secure gestellt wurde, was dann Up #2 am SEC_VER Eintrag prüft/erkennt.

So oder so, sei froh dass du noch kein Update gemacht hast.

 

[retikulum]

Du könntest aber die updater-script in deiner Update #1.zip mit der passenden Checksum editieren, bzw. die Checksum-Prüfungszeilen rausnehmen, dann müsste das Update auch ohne "abort" durchlaufen. Auf die Formatierung achten. Sicherheitshalber in einer kopierten Updater-script arbeiten, dann die originale sichern und mit der editierten in der .zip ersetzen. Pfad dahin hab ich ja mit angegeben. Bei dir hängt doch update #1 oder? daddle

Das hatte ich komplett übersehen

Dazu muss ich sagen: NÖÖ, das wird nicht funktionieren. Die Updates sind signiert und diese Signatur kann nur per Custom Recovery umgangen werden. Trotzdem danke.

P.S.: die VideoFavorites.odex von Reinhardo funktioniert leider wie befürchtet nicht, da dort auch das Update #1 dazwischen kam. Mist. Ich würde ne originale Stock ROM benötigen....

 

[daddle]

Erstens fragt das Update die release keys ab. Zweitens macht es den einzelnen Dateien Check; wenn du da die einzelnen "apply patch check" und die "apply patch und extract"-Zeilen für die fehlenden apk und odex-files löschst, läuft das Update durch. Habe es selber schon so mit Erfolg gemacht. Warum nicht ausprobieren?
Verstehe aber nicht wieso du mit root in der /system überhaupt etwas löschst, das weiss man als Linux-Freak, dass danach ein Update hängen bleiben muss.

Du kannst aber auch von jemandem der entweder noch nicht das Update #1 gemacht oder auch von einem der bereits Update #1 geflasht hat, die gelöschten apk- und odex-files schicken lassen und an die passende Stelle (in /system/app/ od. /system/priv-app/) reinkopieren, dann sollte das Update auf jeden Fall durchlaufen.
Man kann ja das gleiche Update mehrfach einspielen, daher können die nach Update #1 bereits gepatchten Dateien nicht stören. Haben etliche auch beim Update #2 so gemacht und bereits gepatchte Update #2 - Dateien genommen, und das Update #2 lief sauber durch. daddle

 

[retikulum]

Erstens fragt das Update die release keys ab. Zweitens macht es den einzelnen Dateien Check; wenn du da die einzelnen "apply patch check" und die "apply patch und extract"-Zeilen für die fehlenden apk und odex-files löschst, läuft das Update durch. Habe es selber schon so mit Erfolg gemacht. Warum nicht ausprobieren?
Verstehe aber nicht wieso du mit root in der /system überhaupt etwas löschst, das weiss man als Linux-Freak, dass danach ein Update hängen bleiben muss.

1. Denkst du wirklich, ich hätte das nicht schon ausprobiert? :-D . Ich kann dir gerne die Logs zuschicken. Hast du es an diesem Tab getestet? Am Format des Speicherns sollte es eigentlich auch nicht liegen. Mit nano und auch vi mal probiert, um hier Fehler auszuschließen.

Nunja, ich kann mich auch nicht mehr dran erinnern, diese gelöscht zu haben. Aber wer ist schon feherfrei in seiner Gier? ^^

P.S.: Geschriebenes kann manchmal böser rüber kommen, als es gemeint ist :-D . Nix für ungut, falls das Gefühl auftauchen sollte

 

[daddle]

Alles gut. Will dir ja nur endlich dein Update #1 bescheren!
Also als gebrickt zur Überprüfung einschicken, wird automatisch die Auslieferversion von Medion geflasht!

 

[retikulum]

Ich glaub, das ist das Beste was ich machen kann :-D

Mercy nochmal ;-)

Der ursprüngliche Beitrag von 17:00 Uhr wurde um 18:38 Uhr ergänzt:

So, nach Recovery hab ich dann das Script editiert und per Recovery unsigniert installiert...mein Update #1 ist endlich da :-D