philips-tv-speicher-voll/diagnostics/phase5/adopted-storage-analysis.md

Adopted USB architecture

Confirmed live layout

• disk:8,0 is a 123.060.879.360-byte adoptable USB disk.
• private:8,2 is mounted ext4 at /mnt/expand/0ca93141-9ebf-42fa-9123-dfb75fff60fc through /dev/block/dm-4; free 114.828.268 KiB. Device-mapper plus vold's private-volume model confirms an encrypted adopted mapping; the exact cipher/key metadata is not readable to shell and remains UNKNOWN.
• The volume is Android PRIVATE, and its UUID is the primary storage UUID. Its media/ directory backs the primary emulated storage through sdcardfs and FUSE at /storage/emulated/0.
• /data remains /dev/block/mmcblk0p37, ext4, 5.089.920 KiB. Therefore a 112-GiB /storage/emulated does not enlarge internal /data.
• The adopted root contains standard app, user, user_de, media, misc directories, but no package code path currently resolves below its app.
• A second disk:8,16 is public VFAT (A5F7-1E0B).

Options for EPG placement

Variant	Classification	Main issues
App patch using an app-private adopted Context	POSSIBLE WITH PATCH; preferred selective experiment	Channels is a system/shared-UID app and must choose a private volume explicitly; boot/unmount fallback, migration and locking required
DB path directly under /mnt/expand/<uuid>/user...	POSSIBLE WITH PATCH, brittle	volume UUID/readiness, sandbox/fscrypt/SELinux paths and OTA compatibility
Bind-mount only EPG DB directory	HIGH-RISK HACK	root/init, vold timing, mount namespace, SELinux, USB loss, recovery
Symlink	NOT PRACTICAL	Android data-directory traversal/SELinux and emulated storage SQLite locking; FUSE target is wrong
init mount unit for EPG	HIGH-RISK HACK	creates early-boot/vold dependency and recovery complexity
Move all Channels appdata	POSSIBLE WITH PLATFORM PATCH, not recommended	boot-critical shared UID consumers, DE/CE split, failures affect TV UI

Never put SQLite on /storage/emulated/FUSE: use the private ext4 view, preserve atomic rename/fsync and fail closed to a small internal DB when USB is absent.

Entire /data on USB

NOT PRACTICAL / unacceptable boot risk. /data is mounted by early init before vold adopts USB; FBE/fscrypt user setup, SELinux labels, zygote, Package Manager and recovery depend on it. USB enumeration/power/UUID failure would prevent a normal boot. Required fstab/init/recovery/format/OTA changes intersect locked AVB and static partitions. The boot log already shows transient zygote failures while the adopted user path was not yet present—evidence that making the whole boot depend on USB would worsen a real ordering edge.

Ranking

1. Keep /data internal and repair EPG/GEL leaks – best reliability/OTA/boot.
2. Selectively place large, reconstructible, non-boot-critical payloads on private adopted ext4 with an internal fallback.
3. Android-supported movement of genuinely movable user apps – low risk but little gain here.
4. Entire /data or bind-mount hacks – worst recovery and boot safety.