Subject: SHIELD TV Pro (mdarcy) — USB device mode lost after factory reset; remote-only fleet, enabling nvidia,safe_mode_adb
We operate a fleet of SHIELD TV Pro (2019, mdarcy) devices in a datacenter, connected to Linux hosts over USB Type-A to Type-A for automated testing. The convertible port is configured in device mode with USB debugging enabled.
We have no physical access to these devices. They are racked in a remote datacenter and administered entirely over adb from the attached host. There is no remote, no controller, and no console. If a device drops off USB, we cannot recover it without raising a remote-hands request, which takes days and does not scale across a fleet.
After running adb shell cmd testharness enable (which performs a factory reset), the device does not return on adb, and recovery has required an on-site engineer every time.
What we observe on the first boot after the reset:
Test harness mode restores our adb key correctly and adb connects normally. Approximately 9 seconds later, at BOOT_COMPLETED:
ShieldMtpActivity: start to initialize USB settings on boot complete.
HwBinder: getting vendor.nvidia.hardware.convertibleport@1.0::IConvertiblePort/default
ConvertiblePortServiceImpl::readConvPortMode is called.
ShieldMtpActivity: Found extcon path </sys/class/extcon/extcon0> for name: virtual_id
ConvertiblePortServiceImpl::writeConvPortMode is called.
The USB link is lost immediately afterwards. Host-side dmesg shows the device re-enumerating from idProduct b42b to b42a, then usb2-port1: Cannot enable. Maybe the USB cable is bad? repeating until the kernel abandons the port. It does not return.
We also confirmed the device is otherwise alive but unreachable: no HDMI signal on our capture card, and no response on the network. Every remote path into the device is closed simultaneously.
Our reading of ShieldMtpActivity.BootReceiver is that the port mode resolved to host on this boot, and that the host branch calls setPortMode, which writes the extcon node and sets Settings.Global.adb_enabled = 0.
Questions:
What determines the convertible port mode on the first boot after a factory reset? On a healthy device in our fleet, persist.vendor.convertible.usb.mode is not set at all, yet the port remains in device mode and adb works — so an unset property does not by itself appear to cause this. We would like to understand what readConvPortMode returns when the property is absent.
The boot receiver skips the port reconfiguration entirely if /proc/device-tree/chosen/nvidia,safe_mode_adb is present. Is there a supported way to enable this on production devices, or a build or DTB variant that ships with it set? Given that we cannot reach these devices physically, this appears to be exactly the deployment scenario it was intended for.
Is there a supported way to wipe user data on these devices that preserves USB device mode and adb access, for fleets without physical access?
Environment: SHIELD TV Pro 2019 (mdarcy), ro.build.fingerprint:, Android 11 / SHIELD Experience Full logcat and host kernel logs available on request.