TWRP: Eigene Flashbare ZIP macht nicht alles was sie soll

  • 68 Antworten
  • Neuester Beitrag
Diskutiere TWRP: Eigene Flashbare ZIP macht nicht alles was sie soll im Root / Custom-ROMs / Modding für Samsung Galaxy S10 / S10+ / S10E / S10 5G im Bereich Samsung Galaxy S10 / S10+ / S10E / S10 5G Forum.
B

bobwooton

Ambitioniertes Mitglied
Ich hab mir ja schon seit längerem eine flashbare ZIP für TWRP erstellt die nach einer Neuinstallation die Klingeltöne und Benachrichtigungstöne austauscht ( also den Werksmüll löscht und nur meine rein kopiert ) und die hosts Datei austauscht. Das klappt alles auch soweit schon seit meinem S6 vor Jahren.

Nun wollte ich auch die aktive Wallpaper schon von dem Script austauschen lassen. Was im Grunde auch läuft. Soll heißen die Dateien werden rein kopiert und Rechte und Besitzer gesetzt. Nur nach einem Start wird im besten Fall keine Wallpaper angezeigt und im schlechtesten Fall startet Android gar nicht mehr ( oder besser gesagt stürtzt beim Start der UI ab ) bis man im TWRP Terminal die Dateien löscht für den nächsten Start.
Hier mal das Script ( was übersehe ich da das es nicht klappt... der Teil mit der Wallpaper ist im Moment im Script deaktiviert ):

ui_print(" ");
ui_print("-------------------------------------");
ui_print(" ");
ui_print(" personalisation Script 1o.1o.2o2o ");
ui_print(" ");
ui_print("Install hosts, ringtones and notification");
ui_print(" ");
ui_print("-------------------------------------");
sleep(1);
###########################################################
ui_print("- Set busybox up and running ");
package_extract_file("META-INF/com/miui/busybox", "/tmp/busybox");
run_program("/sbin/chmod", "777", "/tmp/busybox");
###########################################################
ui_print ("- Mounting Partitions");
package_extract_file("META-INF/com/miui/mount.sh", "/tmp/mount.sh");
set_perm(0, 0, 0777, "/tmp/mount.sh");
run_program("/tmp/mount.sh", "");
delete("/tmp/mount.sh");
sleep(3);
###########################################################
ui_print("- Delete old files");
run_program("/tmp/busybox", "rm", "-f", "/system/etc/hosts");
run_program("/tmp/busybox", "rm", "-f", "/system_root/system/etc/hosts");
run_program("/tmp/busybox", "rm", "-f", "/system/media/audio/notifications/*");
run_program("/tmp/busybox", "rm", "-f", "/system_root/system/media/audio/notifications/*");
run_program("/tmp/busybox", "rm", "-f", "/system/media/audio/ringtones/*");
run_program("/tmp/busybox", "rm", "-f", "/system_root/system/media/audio/ringtones/*");
delete("/system/etc/hosts");
delete("/system_root/system/etc/hosts");
delete_recursive("/system/media/audio/notifications/");
delete_recursive("/system/media/audio/ringtones/");
delete_recursive("/system_root/system/media/audio/notifications/");
delete_recursive("/system_root/system/media/audio/ringtones/");
sleep(1);
###########################################################
ui_print("- copy hosts");
package_extract_file("hosts", "/system/etc/hosts");
package_extract_file("hosts", "/system_root/system/etc/hosts");
run_program("/sbin/chmod", "644", "/system/etc/hosts");
run_program("/sbin/chmod", "644", "/system_root/system/etc/hosts");
ui_print("- done");
sleep(1);
ui_print("- copy notifications");
package_extract_dir("notifications", "/system/media/audio/notifications");
package_extract_dir("notifications", "/system_root/system/media/audio/notifications");
run_program("/sbin/chmod", "644", "/system/media/audio/notifications/*");
run_program("/sbin/chmod", "644", "/system_root/system/media/audio/notifications/*");
ui_print("- done");
sleep(1);
ui_print("- copy ringtones");
package_extract_dir("ringtones", "/system/media/audio/ringtones");
package_extract_dir("ringtones", "/system_root/system/media/audio/ringtones");
run_program("/sbin/chmod", "644", "/system/media/audio/ringtones/*");
run_program("/sbin/chmod", "644", "/system_root/system/media/audio/ringtones/*");
ui_print("- done");
sleep(1);
###########################################################
#ui_print("- delete wallpaper");
#run_program("/tmp/busybox", "rm", "-rf", "/data/system/users/0/wallpaper*");
#run_program("/tmp/busybox", "rm", "-rf", "/system_root/data/system/users/0/wallpaper*");
#sleep(1);
#ui_print("- Extracting extracting wallpaper");
#package_extract_file("wallpaper.zip", "/tmp/wallpaper.zip");
#run_program("/tmp/busybox", "unzip", "/tmp/wallpaper.zip", "-d", "/data/system/users/0");
#run_program("/tmp/busybox", "unzip", "/tmp/wallpaper.zip", "-d", "/system_root/data/system/users/0");
#run_program("/tmp/busybox", "rm", "-f", "/tmp/wallpaper.zip");
#sleep(1);
#run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper");
#run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper");
#run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chmod", "771", "/data/system/users/0/wallpaper_lock_images");
#run_program("/sbin/chmod", "771", "/system_root/data/system/users/0/wallpaper_lock_images");
#run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper_lock_images/wallpaper_lock");
#run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper_lock_images/wallpaper_lock");
#run_program("/sbin/chown", "system:system", "/data/system/users/0/wallpaper");
#run_program("/sbin/chown", "system:system", "/system_root/data/system/users/0/wallpaper");
#run_program("/sbin/chown", "system:system", "/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chown", "system:system", "/system_root/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chown", "-R", "system:system", "/data/system/users/0/wallpaper_lock_images");
#run_program("/sbin/chown", "-R", "system:system", "/system_root/data/system/users/0/wallpaper_lock_images");
#ui_print("- done");
#sleep(1);
###########################################################
ui_print("- UnMounting filesystem");
run_program("/tmp/busybox", "umount", "/system");
run_program("/tmp/busybox", "umount", "/system_root");
unmount("/system");
unmount("/system_root");
sleep(3);
ui_print("- Done.... Ready to reboot");
ui_print("-------------------------------------");
ui_print(" ");

In der "wallpaper.zip" liegen :
/wallpaper_lock_images/wallpaper_lock
/wallpaper_info.xml
/wallpaper


Obwohl Besitzer/Gruppe und Rechte der Dateien genau so gesetzt sind wie es Android selber auch macht scheint es nicht drauf zugreifen zu können. Einen neuen Lockscreenhintergrund kann Android z.b. nämlich erst dann wieder selber abspeichern wenn ich den reinkopierten Ordner "wallpaper_lock_images" per Hand vorher lösche und das System ihn dann selber neu anlegt.
 
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Viel einfacher wäre es, wenn du das recovery.log hochladen würdest. ;-)

Hast du im originalen Script die Shell deklariert (#!/bin/sh)?
 
B

bobwooton

Ambitioniertes Mitglied
Wie geschrieben das Problem liegt ja nicht am flashen selber ( weswegen die recovery.log nix bringt ) denn genau wie oben im Script bei den Klingeltönen und der hosts macht das Script auch bei den Wallpaperdateien alles so wie es das Script machen soll. Die Klingeltöne, Benachrichtigungstöne kann ich dann auch normal nutzen und auch die hosts Datei wird geladen ( und Werbung gefiltert ). Die Dateien werden alle ins System kopiert und Rechte und Gruppe und Besitzer auch richtig gesetzt. Nur die Wallpaper macht Probleme. Sowohl vorm ersten Start nach dem flashen stimmen die Dateieigenschaften der reinkopierten Wallpaperdateien ( im Terminal von TWRP überprüft ) als auch wenn das System gestartet ist kann man im Terminal unter Android sehen das die Dateien von den Rechten und Besitzer und Gruppe eigentlich nicht von den von Android selber angelegten abweichen.
Aber trotzdem scheint das System nicht auf die Dateien zugreifen zu können. Die "wallpaper" und "wallpaper_info.xml" muss man dann erst wieder löschen bevor Android es schaft ohne Absturz wieder hoch zu fahren. Und die wallpaper des Lockscreen kann Android auch nicht anzeigen. Und auch nicht neu setzen ehe man den entsprechenden Ordner und wallpaper löscht.

Hier mal die Zip :
 

Anhänge

  • Archiv.zip
    4,9 MB Aufrufe: 2
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
bobwooton schrieb:
im Terminal von TWRP überprüft
Wenn das gecheckt wurde, ok. Dann bringt das recovery.log wirklich nichts.

Ist Magisk installiert? Im Anhang ist ein Modul, das dir ein Bootlog anfertigt und permanent während des Bootens dmesg und logcat ausliest. Das wird dann unter /data/local/boot gespeichert und kann jederzeit angesehen werden, sobald du irgendwie und irgendwann Zugriff hast.
Beitrag automatisch zusammengefügt:

Damit wäre der Fehler auszulesen.
 

Anhänge

  • Log_Catcher-v17(17)_patched.zip
    5,9 KB Aufrufe: 1
Zuletzt bearbeitet:
B

bobwooton

Ambitioniertes Mitglied
Im Anhang die Logfiles:
 

Anhänge

  • logfiles.zip
    101,6 KB Aufrufe: 1
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Sind die Logs von einem Bootvorgang, der zu einem Absturz geführt hat?
Diese Abstürze äussern sich in Form eines Bootloops oder woran erkennst du sie?
 
B

bobwooton

Ambitioniertes Mitglied
Logs sind von einem booten mit Absturz. Es wird bis zum Launcher gebootet. Der stürzt dann ab und es kommt zum reboot u.s.w. . Löscht man dann im twrp die geflashten Dateien:
wallpaper
wallpaper_info.xml
wallpaper_backup_info.xml

startet Android wieder normal ( mit einem standard Hintergrund ) . Dann kann man einen neuen Hintergrund setzen was auch klappt bis auf den Lockscreen. Um den neu setzen zu können muss man auch wallpaper_locl_images löschen was zeigt das Android irgendwie keinen Zugriff auf die geflashten Dateien zu haben scheint.

Im Anhang noch mal 3 Bilder die zeigen das die Rechte aber eigendlich mit den Originaldateien übereinstimmen. Das erste Bild mit funktionierenden wallpaper Dateien und das zweite Bild nach dem flashen mit den geflashten Dateien die nicht laufen:
 

Anhänge

Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
bobwooton schrieb:
Es wird bis zum Launcher gebootet
Dann bringen die Logs nämlich nichts, weil sie nur als Bootlog angelegt werden und mit dem Start der Bootanimation enden.

Die Rechte sind auch korrekt gesetzt. Es scheint soweit alles ok zu sein. Habe es auch bei mir manuell versucht. Also die Dateien aus dem Verzeichnis kopiert, Wallpaper geändert, Dateien wieder eingefügt und manuell die Rechte gesetzt. Nach einem Neustart wurde das Wallpaper dadurch korrekt geändert.
Aber bevor wir hier nur Vermutungen anstellen, wäre mir ein Log lieber. Das bringt uns direkt zur Ursache.

Ich habe das Script im Modul angepasst, damit es quasi unendlich weiterläuft. Damit sollte der Fehler dann aufgezeichnet werden und zu sehen sein.
 

Anhänge

  • Log_Catcher.zip
    11,1 KB Aufrufe: 2
Zuletzt bearbeitet:
B

bobwooton

Ambitioniertes Mitglied
So hier die Logs von einem Booten mit Absturz nach dem flashen :
Beitrag automatisch zusammengefügt:

Was auch auffällig ist.... wenn er dann mit Absturz bootet und man dann in twrp nach dem ersten Absturz die Wallpaperdateien löscht damit er wieder normal bootet... ist aber durch den Absturz auch jedes mal der WLan-Schlüssel gelöscht beim original Launcher. Wenn NovaLauncher läuft hat man 3 Abstürze in der bootloop Zeit bis der WLanschlüssel weg ist und man ihn neu eingeben muss.
 

Anhänge

  • Archiv.zip
    631,4 KB Aufrufe: 1
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Was so ein Hintergrund alles anrichten kann... 😂 Schau mal, ob du dieses Log finden kannst: /cache/recovery/rescueparty_log
Die sog. Rescue Party löscht dein WLAN-Passwort, bzw. das komplette Interface wlan0.

Also für mich sieht das so aus, als wäre die "wallpaper_info.xml" fehlerhaft. Die SystemUI kann das Bild nicht laden und startet den Request immer wieder neu. Währenddessen versucht der Service Wallpaper die Daten zu laden, schafft es aber nicht und requestet wiederum neue Daten. Tja, so geht das halt ca. 30 mal, bis dein System crasht, v.a. aufgrund von Rescue Party.

Ist das wallpaper_info.xml den passend zu dem verwendeten Bild?
Beitrag automatisch zusammengefügt:

Die Rechte sind alle ok und das Sysrem hat vollen Zugruff und findet alles. Aber der Inhalt der Dateien scheint nicht zu passen.
 
Zuletzt bearbeitet:
B

bobwooton

Ambitioniertes Mitglied
Die wallpaper_info.xml ist passend zu dem Hintergrund. Hab ich auch schon dran gedacht und ein paar mal eben alles zur Wallpaper gelöscht und dann eine neue Wallpaper gesetzt und jeweils die laufenden Dateien in die wallpaper.zip gepackt.

Gegen eine nicht passende wallpaper_info.xml spricht ja auch das wenn man im laufenden System eine andere Wallpaper einstellt und dann die Dateien ins Verzeichnis kopiert und Rechte und Besitzer richtig setzt und neu startet das es dann geht.
Und eben auch das das System auch nicht auf das geflashte wallpaper_lock_images zugreifen kann. Denn das muss man auch erst per Hand löschen bevor man wieder eine neue Lockscreenwallpaper setzen kann.

Oben in der ZIP hatte ich ja das flashen des Lockscreen schon raus genommen aber im Anhang ist die so wie ich sie verwende wo auch der Lockscreen mit geflasht wird. Und da hat man den Effekt das wenn man die anderen geflashten wallpaper Dateien löscht und das geflashte Verzeichnis mit der Lockscreenwallpaper noch im Verzeichnis belässt man wieder ins System booten kann. Wenn man dann nur die Wallpapers löscht im Lockscreenordner und den Ordner aber so belässt wie geflasht kann das System keine neue Lockscreenwallpaper setzen. Man muss auch erst den leeren Ordner löschen das das System ihn neu anlegt. Dann kann man wieder eine Lockscreenwallpaper setzen. Deswegen muss es irgendwie an irgendwelchen rechten hapern bei den geflashten Dateien.

Aber woran da bin ich mit meinem Latein am Ende.
Denn kurz zusammen gefasst..... kopiert man sie im laufenden System per Hand rein und setzt alle Rechte geht es.
Lässt man es in TWRP flashen und alle Rechte setzen klappt es nicht.
Obwohl es die selben Dateien sind und man die selben Rechte ( 600 ) und Besitzer ( system:system ) setzt.

In /cache/recovery liegen übrigends nur "last_log" und "last_log.gz".
 

Anhänge

  • Archiv.zip
    5,2 MB Aufrufe: 0
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Obwohl es sehr abwägig wäre, könntest du die SELinux-Kontexte mit ls -Z vergleichen. Aber sonst fällt mir dazu auch nichts mehr ein.
 
B

bobwooton

Ambitioniertes Mitglied
Um es noch mal etwas verständlicher zu machen. Lässt man mal die normale Wallpaper in Ruhe sondern flasht nur die für den Lockscreen. Also in der wallpaper.zip nur :
/wallpaper_lock_images/wallpaper_lock
/wallpaper_lock_images/wallpaper_lock_orig


und im Script entsprechend dafür nur:
###########################################################
ui_print("- delete wallpaper");
run_program("/tmp/busybox", "rm", "-rf", "/data/system/users/0/wallpaper_lock_images");
run_program("/tmp/busybox", "rm", "-rf", "/system_root/data/system/users/0/wallpaper_lock_images");
delete("/data/system/users/0/wallpaper_lock_images");
delete("/system_root/data/system/users/0/wallpaper_lock_images");
sleep(1);
ui_print("- extracting wallpaper");
package_extract_file("wallpaper.zip", "/tmp/wallpaper.zip");
run_program("/tmp/busybox", "unzip", "/tmp/wallpaper.zip", "-d", "/data/system/users/0");
run_program("/tmp/busybox", "unzip", "/tmp/wallpaper.zip", "-d", "/system_root/data/system/users/0");
run_program("/tmp/busybox", "rm", "-f", "/tmp/wallpaper.zip");
sleep(1);
#run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper");
#run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper");
#run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper_backup_info.xml");
#run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper_backup_info.xml");
#run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper_info.xml");
run_program("/sbin/chmod", "771", "/data/system/users/0/wallpaper_lock_images");
run_program("/sbin/chmod", "771", "/system_root/data/system/users/0/wallpaper_lock_images");
run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper_lock_images/wallpaper_lock");
run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper_lock_images/wallpaper_lock");
run_program("/sbin/chmod", "600", "/data/system/users/0/wallpaper_lock_images/wallpaper_lock_orig");
run_program("/sbin/chmod", "600", "/system_root/data/system/users/0/wallpaper_lock_images/wallpaper_lock_orig");
#run_program("/sbin/chown", "system:system", "/data/system/users/0/wallpaper");
#run_program("/sbin/chown", "system:system", "/system_root/data/system/users/0/wallpaper");
#run_program("/sbin/chown", "system:system", "/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chown", "system:system", "/system_root/data/system/users/0/wallpaper_info.xml");
#run_program("/sbin/chown", "system:system", "/data/system/users/0/wallpaper_backup_info.xml");
#run_program("/sbin/chown", "system:system", "/system_root/data/system/users/0/wallpaper_backup_info.xml");
run_program("/sbin/chown", "-R", "system:system", "/data/system/users/0/wallpaper_lock_images");
run_program("/sbin/chown", "-R", "system:system", "/system_root/data/system/users/0/wallpaper_lock_images");
ui_print("- done");
sleep(1);
###########################################################


Startet Android normal nur dann eben ohne Lockscreenwallpaper. Dann kann man im System
auch beliebig die Wallpaper ändern nur es gelingt nicht die Lockscreenwallpaper zu ändern bevor
man nicht den vom flashen angelegten Ordner "wallpaper_lock_images" löscht so das Android ihn selber neu anlegen kann um darin den Lockscreen zu speichern. Daran sieht man das Android irgendwelche Rechte an den geflashten Dateien/Ordner fehlen.
Beitrag automatisch zusammengefügt:

BOotnoOB schrieb:
@bobwooton Obwohl es sehr abwägig wäre, könntest du die SELinux-Kontexte mit ls -Z vergleichen. Aber sonst fällt mir dazu auch nichts mehr ein.
@BOotnoOB Da gäbe es Unterschiede. Die ersten beiden Bilder die laufenden Lockscreenwallpapers und das 3. und 4. Bild die geflashten nicht laufenden. Aus "users_system_data_file" im Original wird bei dem geflashten nicht laufenden Ordner "wallpaper_lock_images" zum Beispiel "unlabeled" .

Da ich bei "setfiles" nicht so ganz durchblicke wie wäre die genaue Commandline um z.b. den SELinux Kontext
nach den Bildern z.b. für die Datei "wallpaper_lock" oder den Ordner "wallpaper_lock_images" richtig zu setzen ?
 

Anhänge

Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Aha! Um die Kontexte zu ändern, nimmst du:
Code:
chcon u:object_r:users_system_data_file:s0 wallpaper_lock_images
 
B

bobwooton

Ambitioniertes Mitglied
Ja hatte es schon gefunden. Und das wird es sein. Hab mal bei den laufenden Lockscreens gerade den Kontext geändert und schon laufen sie nicht mehr. Werde es also jetzt andersrum probieren und beim flashen die Kontexte richtig setzen und mal sehen was passiert. Hatte es mit "chcon -h test wallpaper_lock_images" bewußt falsch gesetzt und nach dem nächsten Neustart waren dann die Lockscreens nicht mehr nutzbar fürs System.
 
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Hat's geklappt?
 
B

bobwooton

Ambitioniertes Mitglied
Im Prinzip scheint es die Lösung zu sein. Wenn ich bei den nicht laufenden Wallpaperdateien im Terminal unter Android die Kontexte Setze sind die Dateien nach dem nächsten Neustart nutzbar.
In der Praxis scheitert es aber noch an den richtigen Parametern. Denn chcon in der Busybox oder auch das chcon
im System von Android selber will noch Parameter für den Aufruf so das es per Script im Moment noch mangels der richtigen Parameter scheitert. Denn nur :

run_program("/tmp/busybox", "chcon", "u:object_r:users_system_data_file:s0", "/system_root/data/system/users/0/wallpaper_lock_images");
run_program("/tmp/busybox", "chcon", "u:object_r:users_system_data_file:s0", "/data/system/users/0/wallpaper_lock_images");
run_program("/tmp/busybox", "chcon", "u:object_r:wallpaper_file:s0", "/system_root/data/system/users/0/wallpaper_lock_images/wallpaper_lock");
run_program("/tmp/busybox", "chcon", "u:object_r:wallpaper_file:s0", "/data/system/users/0/wallpaper_lock_images/wallpaper_lock");
run_program("/tmp/busybox", "chcon", "u:object_r:wallpaper_file:s0", "/system_root/data/system/users/0/wallpaper_lock_images/wallpaper_lock_orig");
run_program("/tmp/busybox", "chcon", "u:object_r:wallpaper_file:s0", "/data/system/users/0/wallpaper_lock_images/wallpaper_lock_orig");


Im Script ( ohne extra Parameter ) werden die Kontexte nicht geändert. Das chcon in meinem Terminal unterm laufenden Android da geht es wie von dir gesagt ohne Parameter. chcon von Android selber ( also z.b. im Terminal unter twrp ) oder der busybox geht es nicht ohne Parameterangabe.
 
Zuletzt bearbeitet:
BOotnoOB

BOotnoOB

Guru
@bobwooton Was genau meinst mit Parametern?
 
BOotnoOB

BOotnoOB

Guru
@bobwooton Müsste es nicht mit
Code:
run_program("/tmp/busybox", "chcon", "u:object_r:users_data_system_file:s0", "wallpaper_lock_images");
funktionieren?
 
Ähnliche Themen - TWRP: Eigene Flashbare ZIP macht nicht alles was sie soll Antworten Datum
2
11
8