老哥，这种情况我太熟了！谷歌TV应用的DPad审核真的有点“吹毛求疵”，但其实都是咱们本地测试容易忽略的细节。我帮好几个开发者踩过这些坑，给你梳理下必查的点：

1. 先搞定焦点可见性——审核人员的第一判断依据 #

• 很多时候咱们本地测试觉得焦点没问题，但审核人员可能因为焦点样式太淡、和背景融合，直接判定“看不到焦点移动”。
• 强制要求所有可交互控件（按钮、列表项、菜单选项）都有高对比度的焦点高亮样式：
  • 给控件加android:focusable="true"，用android:background指定一个明显的焦点状态drawable（比如深色边框、高亮底色）。
  • 测试时把设备/模拟器亮度拉到最高，模拟审核人员的测试环境，确保任何场景下焦点都能一眼识别。

2. 覆盖所有边缘场景的导航——别漏冷门路径 #

• 本地测试常忽略这些场景：弹窗/对话框的焦点、页面跳转后的初始焦点、侧边栏/底部导航的切换、空状态页面的导航。
• 举个例子：弹出权限对话框时，DPad能不能直接聚焦到“允许”按钮？从列表页进入详情页后，焦点是不是自动落在返回按钮或第一个可交互控件上？
• 严格执行纯DPad测试流程：全程不用鼠标/触屏，走完所有用户可能的操作路径，把任何焦点卡住、无法移动的点记下来修复。

3. 滚动列表的焦点逻辑——RecyclerView最容易出问题 #

• 如果用了RecyclerView或ListView，要确保：
  • DPad上下键能流畅滚动列表，焦点不会突然跳到列表外。
  • 列表项内如果有多个可交互控件（比如按钮+文本），左右键能在内部正常切换，不会跳出列表项。
  • 可以给RecyclerView设置android:descendantFocusability="beforeDescendants"，避免焦点被子控件抢走导致列表无法滚动。

4. 检查Manifest的TV特性声明——别踩声明坑 #

• 确认AndroidManifest.xml里的TV相关声明完全正确：

  <!-- 声明不需要触屏，TV设备大多没有 -->
  <uses-feature android:name="android.hardware.touchscreen" android:required="false" />
  <!-- 必须声明Leanback支持，这是TV应用的核心特性 -->
  <uses-feature android:name="android.software.leanback" android:required="true" />
  

• 别错误声明强制要求触屏，这会直接影响审核的兼容性判断。

5. 用官方工具跑自动化测试——揪出隐藏问题 #

• 用Android Studio自带的**TV Compatibility Test Suite (CTS)**跑一遍，它能检测出很多手动测试漏掉的问题：比如焦点陷阱、无法到达的控件、导航逻辑错误等。
• 操作步骤：连接TV设备/AVD → 打开Android Studio → 点击Run → 选择Android TV Compatibility Tests，根据测试报告修复问题。

6. 申诉时拿实锤——别空口说白话 #

• 如果排查后还是被驳回，申诉时一定要提供详细的测试证据：
  • 列出你测试过的设备型号（包括官方AVD的具体版本，比如Android 14 TV AVD）。
  • 附上焦点移动的视频或截图，展示每个菜单、页面的完整DPad导航流程。
  • 说明你已经修复的问题，比如优化了焦点样式、修复了列表焦点跳脱的bug等。

内容的提问来源于stack exchange，提问作者ausgeorge