diff --git a/overlay/AndroidTvOpiOverlay/Android.bp b/overlay/AndroidTvOpiOverlay/Android.bp
index 3f02f9c..18aaa41 100644
--- a/overlay/AndroidTvOpiOverlay/Android.bp
+++ b/overlay/AndroidTvOpiOverlay/Android.bp
@@ -3,9 +3,15 @@
 //
 // SPDX-License-Identifier: Apache-2.0
 
+// This overlay MUST live on the product partition: it overrides resources that
+// TvFrameworkOverlay (a product-partition RRO from device/google/atv) also
+// overrides, and static RRO precedence is decided by partition order first
+// (system < vendor < odm < oem < product < system_ext) and android:priority
+// second. From /vendor/overlay our entries always lose to TvFrameworkOverlay
+// regardless of priority; on /product our priority 10 beats its priority 0.
 runtime_resource_overlay {
     name: "AndroidTvOpiOverlay",
     resource_dirs: ["res"],
     sdk_version: "current",
-    vendor: true,
+    product_specific: true,
 }
diff --git a/overlay/AndroidTvOpiOverlay/res/values-xhdpi/config.xml b/overlay/AndroidTvOpiOverlay/res/values-xhdpi/config.xml
index 73b9322..0989af4 100644
--- a/overlay/AndroidTvOpiOverlay/res/values-xhdpi/config.xml
+++ b/overlay/AndroidTvOpiOverlay/res/values-xhdpi/config.xml
@@ -16,9 +16,23 @@
 -->
 
 <resources>
-    <!-- Override TvFrameworkOverlay's config_maxUiWidth value in the values-xhdpi
-         bucket, which this device now resolves via PRODUCT_AAPT_PREF_CONFIG=xhdpi
-         (matching the RPi5 ATV approach). Our RRO priority 10 beats their priority
-         0, so 0 (disabled cap) wins. -->
+    <!-- Disable TvFrameworkOverlay's config_maxUiWidth cap so the UI renders at
+         the display's native resolution (e.g. true 4K UI on a 4K TV); the user
+         can drop to a lower mode in Settings -> Display & Sound -> Resolution if
+         performance demands it.
+
+         Why this exact shape is required (all verified on hardware 2026-07-16):
+         - PRODUCT_AAPT_PREF_CONFIG strips all other density buckets from every
+           overlay APK at build time, so both TvFrameworkOverlay and this overlay
+           ship only their values/ and values-xhdpi entries. Adding more buckets
+           here is pointless; this bucket (plus values/) is the whole contest.
+         - The runtime density (ro.sf.lcd_density=240) always resolves the xhdpi
+           bucket, so this entry is the one that wins or loses.
+         - Both overlays define the same bucket, so config specificity ties and
+           precedence decides — which is partition order FIRST, android:priority
+           second. This overlay must therefore be product_specific (see
+           Android.bp); from /vendor it always loses to the product-partition
+           TvFrameworkOverlay (1920) no matter the priority, which silently
+           re-caps the UI to 1920x1080 on 4K displays. -->
     <integer name="config_maxUiWidth">0</integer>
 </resources>
diff --git a/overlay/AndroidTvOpiOverlay/res/values/config.xml b/overlay/AndroidTvOpiOverlay/res/values/config.xml
index f8ab1ca..280b5af 100644
--- a/overlay/AndroidTvOpiOverlay/res/values/config.xml
+++ b/overlay/AndroidTvOpiOverlay/res/values/config.xml
@@ -51,12 +51,12 @@
     <!-- Maximum width, in pixels, to restrain the UI layer-stack to; height and
          density are scaled to match, then SurfaceFlinger upscales to the panel.
          The stock Android TV framework overlay (TvFrameworkOverlay) sets this to
-         1280 in its values-tvdpi bucket, which this device resolves. That caps a
-         native 1920x1080 panel to a 1280x720 @ 320dpi logical display, making the
-         whole UI render oversized (SurfaceFlinger scales 720p -> 1080p) and making
-         the Settings "Resolution" picker a no-op (the layer stack is capped
-         regardless of the scanout mode). 0 disables the cap so the UI renders at
-         the panel's native resolution. -->
+         1920 (values/ and values-xhdpi buckets survive PRODUCT_AAPT_PREF_CONFIG
+         stripping), which scales a 4K display down to a 1920x1080 logical UI.
+         0 disables the cap so the UI renders at the display's native resolution.
+         The density-qualified values-xhdpi entry (see values-xhdpi/config.xml) is
+         the one that actually decides the contest at runtime; this unqualified
+         entry is kept as a fallback for density configs with no xhdpi match. -->
     <integer name="config_maxUiWidth">0</integer>
 
 </resources>