Schlussdiagnose: Philips 43PUS7394/12 – interne Speicherwarnung

Stand: 2026-08-25. Plattform TPM191E, Firmware TPM191E_R.211.000.103.000, Android TV 12, Kernel 4.9.310-ab4215.

Dies ist die aktuelle Kurzfassung. Die vertrauliche Deep-Forensics-Fassung mit Angriffsflächenanalyse ist nicht Teil der kuratierten Veröffentlichung.

Phase-4-Update: Eine konsistente UID1000-Kopie der EPG-DB schließt die letzte zentrale Lücke. scheduletable hält 3.071.250 vollständig abgelaufene Zeilen; 97,81 % sind älter als 30 Tage. Die Tabelle belegt 1.436,98 MiB, ihre vier Indizes 222,06 MiB; freelist_count=0, auto_vacuum=FULL, integrity_check=ok. Damit ist jahrelang nicht gelöschte Schedule-Historie die bewiesene Hauptursache. Die veröffentlichten Details stehen in phase4/epg-database-forensics.md.

Ergebnis

Die Warnung ist kein Beleg dafür, dass Androids /data-Dateisystem unmittelbar voll ist. Die letzte Momentaufnahme zeigte:

Wert	Ergebnis
`/data` gesamt	5.089.920 KiB = 4,85 GiB
belegt	3.831.944 KiB = 78 %
verfügbar	1.136.840 KiB = 1,084 GiB
Inodes	7 % belegt
Android-Status	`NORMAL`

Philips verwendet jedoch einen eigenen Monitor in der Nähe von 1 GiB freiem /data. Zur 1-GiB-Marke blieben zuletzt nur 88.264 KiB beziehungsweise 86,2 MiB. Normale Schwankungen reichen deshalb aus, die Philips-Warnung wiederholt auszulösen, obwohl Android selbst noch keinen Low-Storage-Zustand meldet.

Eine nach dem späteren Aufwachen sichtbare Philips-Zeile mit rund 762 MB frei misst nicht /data, sondern die separate 1000-MiB-ext4-Partition /data/vendor/user_setting. TvProvider warnt dort erst unter rund 13 % und 10 %; aktuell sind bezogen auf die Rohpartitionsgröße rund 72,7 % frei. Diese zweite Messung ist daher unauffällig und nicht die Ursache der Meldung.

Der klare Hauptverursacher ist eine Philips-EPG-Datenbank:

Verursacher	Größe
`org.droidtv.channels/.../EpgDatabase.db`	1.742.053.376 B = 1,622 GiB
`org.droidtv.gel/.../androidx.work.workdb`	229.453.824 B = 218,824 MiB
sichtbarer Code von 18 aktualisierten System-Apps	686,195 MiB
statbare Basis-ODEX/VDEX dieser Apps	226,381 MiB

Insgesamt sind konservativ 2.830,530 MiB beziehungsweise rund 75–76 % der belegten /data-Kapazität konkret erklärt. Rund 0,88–0,89 GiB bleiben wegen App-Sandbox, DAC und SELinux nicht einzeln aufteilbar; dieser Rest wurde nicht als frei oder unbenutzt behandelt.

EPG-Datenbank: Ursache und offene Größe

Für EpgDatabase.db sind folgende Werte direkt bewiesen:

Seitengröße 4096 Byte;
page_count 425.306;
Dateigröße exakt 425.306 × 4096 = 1.742.053.376 Byte;
nur 358 sichtbare Index-, 195 Now- und 162 Next-Zeilen, aber AUTOINCREMENT-IDs im Millionenbereich;
eine unbeschränkte lesende Schedule-Abfrage war nach mehr als 120 Sekunden noch nicht vollständig und wurde clientseitig abgebrochen.

Die APK-Analyse erklärt einen konkreten Wachstumsmechanismus: Der als Stale-Cleanup benannte Runnable berechnet Grenzwerte und schreibt Logmeldungen, führt aber keine Löschoperation aus. Zusätzlich sind die Zeitkonstanten dort offenbar als Millisekunden statt als die beabsichtigten längeren Intervalle verwendet. Vorhandene echte Zeit-Löschmethoden sind nicht mit diesem globalen Cleanup-Pfad verbunden.

Philips' interne rebuilddb-Pfade sind ebenfalls kein physischer Datenbank-Neuaufbau. Sie löschen beziehungsweise synchronisieren Zeilen in derselben Datei und rufen weder VACUUM noch einen Dateiersatz auf.

Wichtig ist die Grenze der Aussage: freelist_count, der persistierte auto_vacuum-Headerwert und die Seitennutzung der großen Schedule-/FVP- Tabellen sind nicht zugänglich. AOSP baut Plattform-SQLite langjährig mit SQLITE_DEFAULT_AUTOVACUUM=1 (FULL); da die Philips-App keinen anderen Modus setzt, ist FULL eine starke Inferenz, aber kein Gerätebeweis. Deshalb ist eine sehr große Freelist nicht als Hauptursache bewiesen. Die Datei kann zu wesentlichen Teilen aus noch lebenden Schedule-Daten, freien Seiten und/oder interner Fragmentierung bestehen. Der tatsächlich rückgewinnbare Platz ist derzeit nicht seriös bezifferbar.

GEL-WorkManager-Datenbank

GELs androidx.work.workdb ist rund 2.155-mal größer als typische WorkManager-Datenbanken auf demselben Gerät. Die APK erzeugt wiederholt GEL_WORK mit APPEND_OR_REPLACE; eine lang gewachsene Work-Kette ist daher sehr wahrscheinlich. Die Hauptdatei hat 4096-Byte-Seiten und 56.019 Seiten; der Live-Stand umfasst wegen aktivem WAL 56.020 Seiten. WAL und SHM belegen zusammen nur 0,531 MiB und erklären den Ausreißer nicht. Tabellen- und Freelist-Anteile bleiben ohne autorisierten Owner-Zugriff unbekannt.

Adoptierter Speicher

Das adoptierte 112-GiB-Volume ist korrekt gemountet und praktisch leer. Die 18 Pakete unter /data/app sind jedoch ausnahmslos Updates von System-Apps; auch Channels und GEL sind Systempakete. Android verschiebt solche Pakete und ihre privaten Daten nicht auf das adoptierte Volume. Der große freie USB-Speicher kann die beiden Datenbanken daher nicht automatisch aufnehmen.

Ein Philips-spezifischer mFreeSize 0-Fehler für öffentliche/adoptierte Volumes ist in Logs vorhanden. Androids eigener StorageManager misst diese Volumes korrekt. Ein Einfluss des Fehlers auf einzelne Philips-Oberflächen ist plausibel, aber er erklärt weder die reale /data-Belegung noch ist er als Auslöser des hier dekompilierten Warnpfads bewiesen.

eMMC-Gesundheit

Philips hat beim Boot beide eMMC-Life-Time-Felder als 0x0a/0x0a ermittelt, protokolliert und in persist.odm.tpv.sys.emmc_lifetime gespeichert. Nach der von KIOXIA mit JEDEC-Genehmigung wiedergegebenen Tabelle bedeutet 0x0a für beide Felder die grobe Klasse 90–100 % der geschätzten Lebensdauer verbraucht. Das ist keine exakte Restlebensdauer und beweist keinen gegenwärtigen I/O- Fehler.

PRE_EOL_INFO beschreibt getrennt den Verbrauch reservierter Ersatzblöcke. Eine spätere rein lesende Eventlog-Abfrage hat diesen Wert unabhängig von der Philips-Property sichtbar gemacht: storaged_emmc_info: [emmc 5.1,1,10,10]. Die installierte Tagdefinition ordnet die Felder als Version, EOL, Lifetime A und Lifetime B zu. Damit sind eMMC 5.1, PRE_EOL_INFO=0x01 (Normal) und A/B 0x0a/0x0a für diesen Boot bestätigt. Nur der direkte Rohdump sowie CID, CSD, Hersteller und Modell bleiben auf diesem Production-Build durch SELinux gesperrt. storaged wurde beim zusätzlichen Lesen des EXT_CSD-Debugfs-Knotens als UID 0 durch SELinux abgewiesen; Root allein wäre daher weiterhin keine vollständige Zugriffs- oder Reparaturlösung.

Im verfügbaren Bugreport-/Logfenster wurden keine echten MMC-, Block-I/O-, EXT4-, JBD2-, ENOSPC- oder Read-only-Remount-Fehler gefunden. Weil dmesg, PStore, EXT4-Fehlerzähler und ein OEM-Board-Dump fehlen, ist das ein begrenzter Nichtfund und kein Gesundheitszertifikat.

Quellen: KIOXIA Wear Leveling, KIOXIA Bad Block Management, AOSP EXT_CSD-Auswertung, AOSP SQLite-Buildoptionen und SQLite VACUUM.

Bewertung möglicher Maßnahmen – nichts davon ausgeführt

Option	Bewertung
Philips-dokumentierter, geordneter EPG-Dateirebuild	technisch größter gezielter Hebel und voraussichtlich schreibärmer als `VACUUM`; wurde aber weder als UI-/Supportweg gefunden noch auf Nebenwirkungen verifiziert
internes `rebuilddb` / `rebuilddbonnewchannellist`	kein bestätigter Dateirebuild; Speichergewinn abhängig vom unbekannten Auto-Vacuum und mit EPG-/Verknüpfungsrisiken
manuelles Löschen von `EpgDatabase.db`	nicht vertretbar bei laufendem Provider, offenen FDs und unbekannten Labels/Abhängigkeiten
`VACUUM`	vermeiden: hohe Schreiblast; kann bis zu ungefähr eine zusätzliche DB-Größe benötigen, während nur rund 1,1 GiB frei sind
`pm clear org.droidtv.channels`	zu grob; löscht das gesamte Paketprofil und kann Spiegel/Einstellungen betreffen
Werksreset/Firmware-Flash	unverhältnismäßig, schreibintensiv und ohne Beleg für dauerhafte Fehlerbehebung
adoptierter Speicher	für die bestehenden Systempaketdaten kein gangbarer Hebel

Die risikoärmste Folgerung lautet daher weiterhin: keine spontane Mutation. Sinnvoll wäre ein von Philips/TPV ausdrücklich dokumentierter Ablauf, der den Channels-Prozess geordnet schließt, nur die EPG-Datenbank konsistent neu erzeugt, Sender/Favoriten/Timer schützt und die Nebenwirkungen benennt. Eine solche Prozedur wurde in der Firmware und den vorhandenen Supportartefakten nicht gefunden.

Standby-Nachprüfung

Der während der Analyse beobachtete Aus-Zustand war kein Absturz und kein Neustart. Nach dem manuellen Einschalten lief die Uptime weiter. Die Logs belegen power off by auto power down, den Übergang nach POWER_STATE_SEMI_STANDBY mit detail=SWITCH_OFF_TIMER und später das Aufwachen per WAKE_REASON_WAKE_KEY. Die Kontrollmessung danach blieb bei 78 % /data-Belegung und Android-Status NORMAL. Im erhaltenen aktuellen Logfenster trat nach dem Aufwachen kein MEMORY_CRITICAL, CLEANUP_APPS oder Android-Low-/Full-Storage-Ereignis auf.

Nachvollziehbarkeit und Sicherheit

Am Fernseher wurden keine Dateien gelöscht oder verändert, keine Einstellungen oder Pakete geändert und kein Reboot, Recovery-, Flash-, Root- oder Reparaturvorgang ausgeführt. Lange Provider-Leseabfragen wurden nur auf dem PC abgebrochen. Transparenz-Ausnahme: Das vom Auftrag ausdrücklich verlangte dumpsys diskstats meldete selbst einen [512B Data Write]-Latenztest; dieser Android-Test wurde danach nicht wiederholt.

Detailberichte:

Rohbefehle, private Zustandsdaten sowie Privilegien-/SELinux-Berichte sind aus dieser Veröffentlichung ausgeschlossen.

10 KiB Raw Blame History Unescape Escape