The config_maxUiWidth=0 override never took effect from /vendor/overlay:
static RRO precedence is decided by partition order before priority, so
the product-partition TvFrameworkOverlay (1920) always won and silently
re-capped the UI to 1920x1080 on 4K displays. Moving our overlay to the
product partition lets its priority 10 beat TvFrameworkOverlay's 0, so
the cap is disabled and the UI renders at the display's native
resolution. Users can select a lower mode in Settings if needed.
The root cause of the oversized/clipped UI is TvFrameworkOverlay's
config_maxUiWidth=1280 in the values-tvdpi resource bucket. With
PRODUCT_AAPT_PREF_CONFIG=tvdpi, the device resolves this bucket and
the 1280px cap is enforced, limiting the logical display to 1280x720
(which SurfaceFlinger then upscales to 1920x1080).
The Raspberry Pi 5 ATV build (KonstaKANG) uses PRODUCT_AAPT_PREF_CONFIG=xhdpi
and has no display sizing issues, because values-xhdpi has
config_maxUiWidth=1920 (no effective cap on 1080p displays).
Also adds a values-xhdpi/config.xml overlay with config_maxUiWidth=0 as
defense-in-depth, matching the existing values-tvdpi override.
Copyright (C) 2026 Brendan Szymanski <hello@bscubed.dev>
