Phase-3-Speicherreparatur

Stand: 2026-08-25. Jede Änderung wird vor Ausführung ergänzt.

Ausgangslage

/data: 5.089.920 KiB gesamt, 3.832.668 KiB benutzt, 1.136.116 KiB frei, 78 %.
GEL androidx.work.workdb: 229.453.824 Byte plus 524.288-Byte-WAL und 32.768-Byte-SHM.
Die DB liegt unter /data/user/0/org.droidtv.gel/no_backup/; Androids regulärer App-Backup- Mechanismus schließt dieses Verzeichnis absichtlich aus.
org.droidtv.gel hat ALLOW_BACKUP und ALLOW_CLEAR_USER_DATA.
Die normale Actions-DB ist nur 20.480 Byte groß. Der Actions-Satz ist nach bestätigter Philips-Leerkonfiguration leer; alle Phase-3-Testdateien sind entfernt.
Live belegt sind mehrminütige Unique-Work-Graphtraversierungen, dauerhafte lineare Aufarbeitung alter BGM-Status-WorkSpecs und massive Verzögerung neuer GEL-Intents. Die WorkDB ist daher nicht nur groß, sondern funktional pathologisch.

Reparaturstufe 1 – normale GEL-Daten sichern, vor Ausführung

Hypothese: Ein Android-Full-Backup von org.droidtv.gel sichert die wiederherstellbaren normalen App-Daten (Preferences, files/, Actions-DB), während der explizit nicht backupfähige WorkManager-Schedulerzustand ausgeschlossen bleibt. Nach erfolgreicher Sicherung kann genau dieser ephemere Zustand neu aufgebaut werden.

Aktionen:

am force-stop org.droidtv.gel, um Service, DB-Writes und die laufende Work-Kette für eine konsistente Sicherung anzuhalten.
adb backup -f diagnostics/phase3/gel-normal-data-before-clear.ab -noapk -noobb -noshared org.droidtv.gel; Bestätigung am Fernseher ohne Passwort.
Nur ein Archiv mit gültigem ANDROID BACKUP-Header und mindestens einem Tar-Eintrag mit App-Nutzdaten gilt als Erfolg. Vorher erfolgt kein pm clear.

Mögliche Nebenwirkungen: GEL und der gemeinsame candeebug-Prozess werden beendet; Systemereignisse können ihn wieder starten. Während der Backup- Bestätigung erscheint kurz eine System-UI. Die Sicherung schreibt nur auf den PC; die App-Daten werden gelesen, nicht geändert.

Rückkehrweg: Vor einer Bereinigung ist kein Datenrollback nötig; GEL kann durch einen normalen Service-/Eventstart wieder anlaufen. Die Backup-Datei kann später mit adb restore (erneute UI-Bestätigung) zurückgespielt werden.

Ergebnis des Sicherungsversuchs

am force-stop org.droidtv.gel wurde ausgeführt. Der gemeinsame Prozess org.droidtv.candeebug wurde durch eine andere UID-1000-Komponente wieder gestartet, GEL selbst blieb jedoch stopped=true; ein GEL-Service lief nicht.
Die Backup-Bestätigung wurde am Fernseher angenommen und der ADB-Befehl ordnungsgemäß beendet.
Das erzeugte Archiv diagnostics/phase3/gel-normal-data-before-clear.ab ist nur 47 Byte groß. Es enthält den Header ANDROID BACKUP, Kompression zlib, danach aber ein leeres Tar-Archiv: keine einzige GEL-Datei wurde gesichert.
Manifest und PackageManager bestätigen zwar allowBackup=true, aber GEL läuft als Shared-/Core-UID android.uid.system / UID 1000, besitzt keinen deklarierten backupAgent und erscheint nicht unter den Teilnehmern von dumpsys backup. Das ist die belastbare Laufzeiterklärung für das leere Archiv; die genaue interne Eligibility-Regel ist daraus nur als sehr wahrscheinliche Framework-Inferenz abgeleitet.
Unabhängig davon liegt die 229-MiB-WorkDB unter no_backup/ und wäre auch bei einem funktionierenden normalen App-Backup absichtlich ausgeschlossen.

Status: BACKUP GATE NICHT ERFÜLLT. Kein pm clear ausgeführt. Das 47-Byte-Archiv bleibt als Beleg erhalten, darf aber nicht als Wiederherstellungspunkt behandelt werden.

Reparaturstufe 2 – ausdrücklich freigegeben

Das ursprüngliche Backup-/Restore-Konzept ist auf diesem Build nicht realisierbar. Ein Package-Daten-Reset würde die pathologische WorkDB sicher entfernen, zugleich aber auch kleine normale GEL-Daten, für die jetzt kein dateibasierter Rückkehrweg existiert. Bestätigt risikomindernd sind: die Actions-Liste ist leer, die Philips-Konfiguration wird beim App-Start wieder vom kanonischen Dienst bezogen, das System-APK bleibt unverändert und Daten anderer Packages werden nicht gelöscht. Unbekannt bleiben einzelne GEL- Preferences bzw. sonstige interne Dateien.

Der Eigentümer hat am 2026-08-25 den Verlust unbekannter kleiner GEL- Preferences/private Appdaten ausdrücklich akzeptiert und exakt pm clear --user 0 org.droidtv.gel freigegeben.

Unmittelbarer BEFORE-Snapshot

/data: 5.089.920 KiB gesamt, 3.836.812 KiB benutzt, 1.131.972 KiB frei, 78 %.
GEL: installiertes System-APK Version 7.2.0.56, UID/sharedUser 1000 / android.uid.system, stopped=true, Datenpfad /data/user/0/org.droidtv.gel.
Kein laufender GEL-Service. Der gemeinsame Prozess org.droidtv.candeebug, PID 23775, läuft als UID system in u:r:system_app:s0; er verwendet seine eigene Package-Datenbank, nicht die gestoppte GEL-WorkDB.
Letzter exakt gemessener WorkDB-Zustand vor dem Stop: 229.453.824 Byte Hauptdatei + 524.288 Byte WAL + 32.768 Byte SHM.
JobScheduler-Historie bestätigt für GEL 62 Pending-/60 Active-Ereignisse und fortlaufende erfolgreiche Jobs mit Nummern bis mindestens 257839; aktuell ist nach dem Force-Stop keine GEL-Queue aktiv.
WorkSpec-/Dependency-Zeilenzahlen bleiben UNKNOWN; die Datenbank ist für ADB shell weder direkt lesbar noch durch einen offenen GEL-Prozess abfragbar.

Vorab dokumentierte Aktion

Hypothese: Der Package-Reset entfernt den 229-MiB-WorkManager-Zustand und die historische serielle Queue. Die System-App rekonstruiert anschließend einen kleinen sauberen Zustand aus der kanonischen Philips-Konfiguration.

Aktion: ausschließlich pm clear --user 0 org.droidtv.gel.

Erwartung: Success, rund 219 MiB mehr freier /data-Platz, kein Eingriff in APK/Firmware/andere Packages.

Nebenwirkung: alle privaten User-0-Daten von GEL werden gelöscht; ein dateibasierter Restore ist wegen des nachweislich leeren ADB-Backups nicht möglich.

Rückkehrweg: GEL-System-APK bleibt vorhanden; normale Neuinitialisierung und erneuter Abruf der Philips-Konfiguration. Kein Restore des bewusst verworfenen Schedulergraphs.

Unmittelbares Ergebnis

pm clear --user 0 org.droidtv.gel antwortete exakt Success.
/data unmittelbar danach: 3.611.820 KiB benutzt, 1.356.964 KiB frei, 73 %.
Speichergewinn: 224.992 KiB = 219,72 MiB = 0,2146 GiB.
Die zuletzt gemessenen WorkManager-Dateien erklären 224.620 KiB davon. Die Differenz von nur 372 KiB ist eine Obergrenze aus sonstigen GEL-Daten plus Dateisystem-/Messschwankungen. Der Reset traf damit praktisch exakt den identifizierten WorkManager-Verbraucher.
GEL blieb zunächst stopped=true; kein GEL-Service und kein GEL-Prozess. org.droidtv.candeebug wurde für seine eigene CollectionService-Nutzung als neuer PID 26108 wieder gestartet.
JobScheduler protokollierte Can't cancel all jobs for system uid. Das ist kein Clear-Fehler, sondern eine Schutzschranke gegen das pauschale Löschen sämtlicher Jobs der Shared-UID 1000. Der Package-Clear selbst war erfolgreich, es gab keine aktuelle GEL-Pending-/Active-Queue; die angezeigten 62/60-Werte sind historische Statistik.
Nach 30 Sekunden erfolgte kein automatischer GEL-Lifecycle-Start. Deshalb wird einmalig der bereits verstandene normale Produktpfad DAC_START_GEL an GatheringService verwendet.

Vorab: normale GEL-Neuinitialisierung

Aktion: Expliziter Start von org.droidtv.gel/.gathering.GatheringService mit org.droidtv.tv.intent.action.DAC_START_GEL.

Erwartung: neuer kleiner WorkManager-Zustand, GELWorker-Ausführung, kanonischer Konfigurationsabruf und stabiler Service.

Nebenwirkung: normale neue GEL-Appdaten/WorkDB und ein legitimer GEL_WORK-Eintrag.

Rückkehrweg: Bei Crashloop am force-stop org.droidtv.gel; keine weitere Datenlöschung.

Ergebnis der Neuinitialisierung

Service-Start von ADB shell wurde akzeptiert; GEL läuft im gemeinsamen Prozess PID 26108, UID 1000, u:r:system_app:s0.
GELWorker für DAC_START_GEL startete sofort und endete mit SUCCESS.
GEL forderte die kanonische Konfiguration an; ConfigLoader meldete No actions found in Config. Die neue Actions-DB ist 20.480 Byte groß und SELECT uuid FROM Actions blieb leer.
Neue WorkDB unmittelbar danach: 4.096 Byte; WAL 206.032 Byte; SHM 32.768 Byte, zusammen 242.896 Byte = 237,20 KiB.
Gegenüber 229.453.824 + 524.288 + 32.768 Byte vorher ist der private WorkManager-Dateisatz um rund 219,49 MiB kleiner.
Keine Connection-Waiter, keine SQLite-Exception und keine Crashloop. Ein legitimer GEL-Job/Alarm wurde neu angelegt; die historische serielle Kette ist nicht zurückgekehrt.

Bewertung: GEL-WorkManager-Pathologie BEREINIGT / VALIDATED LIVE.

Mehrminütige Stabilitätsbeobachtung

WorkDB-Hauptdatei nach mehreren Alarmzyklen: 102.400 Byte; SHM 32.768 Byte; WAL 461.472 Byte. Kein annähernd lineares Wachstum in Richtung des alten 219-MiB-Zustands.
GATHERING_ALARM_INTENT lief im 60-Sekunden-Takt jeweils sofort und mit Worker result SUCCESS; kein serieller Rückstau.
Keine GEL-Crashloop, ANR, SQLiteException, SQLiteDiskIOException oder malformed-Meldung im Beobachtungsfenster.
/data blieb bei 73 % und rund 1.356.336 KiB frei.
ADB erreichbar; WLAN-Netz 100 CONNECTED/VALIDATED. Channels-, EPGData-, PlayTV-, MediaTek-TVInput- und GEL/candeebug-Prozesse liefen.

Zur quantitativen Bestätigung des kleinen Work-Satzes wird der bereits verstandene AndroidX DiagnosticsReceiver genau einmal aufgerufen. Er erzeugt selbst einen kleinen, prune-fähigen Diagnose-WorkSpec, liest anschließend nur WorkManager-Metadaten und endet regulär mit SUCCESS.

Ergebnis: Der Diagnoseworker listete elf abgeschlossene GEL_WORK-Zeilen, alle SUCCEEDED. Running enthielt nur den Diagnoseworker selbst, der unmittelbar SUCCESS meldete. WorkSpec-Zahl im sichtbaren aktuellen Fenster damit 12 einschließlich Diagnose-Work; die exakte gesamte Tabellenzeilenzahl und Dependency-Zahl bleiben ohne sqlite3 UNKNOWN. Entscheidend ist, dass keine Pending-/Running-Altkette mehr vorhanden war und die DB klein/stabil blieb.

10 KiB Raw Blame History Unescape Escape