Log the ids of attached usb devices, and make wirelessInfo() safe

[iflyhere]

The problem

"No compatible wifi adapter found." is a common report, and the one piece of information
needed to act on it — the adapter's vendor and product id — cannot be obtained by the person
reporting it.

There is no way around the app for this. On some devices sysfs is not readable by the shell
(Horizon OS for one), and dumpsys usb does not list host devices there either:

$ adb shell 'cat /sys/bus/usb/devices/*/idVendor'      # nothing
$ adb shell 'dumpsys usb | grep -i UsbDevice'          # nothing

The app enumerates the devices and matches them against usb_device_filter.xml, and then
throws that away.

The change

getAttachedAdapters() logs every attached device with its ids, manufacturer and product
name, and whether the filter matched:

usb devices attached: 1
  /dev/bus/usb/001/002  0BDA:8812  Realtek 802.11n NIC  -> supported

or, for something not in the list:

  /dev/bus/usb/001/003  2357:012D  TP-Link Archer T3U  -> NOT in usb_device_filter.xml

which turns "it does not work" into a line that can go straight into a filter entry.
Relevant to the standing adapter requests: #82, #91, #93, #105.

Also in here

wirelessInfo() is reached from exactly this code path and is a landmine: it is static and
reads a static WifiManager field that only VideoActivity.initializeUI() ever assigns.
WfbLinkManager.refreshAdapters() calls it from the "no adapter" branch, so any other host
of WfbLinkManager — or this one before onCreate has got that far — gets

NullPointerException: WifiManager.getConnectionInfo() on a null object reference
    at VideoActivity.wirelessInfo(VideoActivity.java:183)
    at WfbLinkManager.refreshAdapters(WfbLinkManager.java:174)

It now takes a Context, fetches the service itself and null checks both the manager and the
WifiInfo. The static field is gone, so it cannot come back through a different entry point.

Note

On master this NPE is latent — VideoActivity is the only host of WfbLinkManager and it
does assign the field. It is a real crash as soon as anything else hosts it, which is how I
ran into it.

Compile tested for arm64-v8a + armeabi-v7a; the logging verified on a Quest 3.

---

Part of a series of independent fixes found while building an immersive (OpenXR) mode on a
Quest 3, each standalone and mergeable in any order:

• Add a low latency decoder option and actually apply the MediaCodec keys #113 — apply the MediaCodec low-latency keys, behind a new switch
• Render the main video on a SurfaceView unless object detection needs the TextureView #114 — SurfaceView for the main video unless object detection needs the TextureView
• Fix: DVR recording leaks one heap buffer per frame #115 — DVR leaked one heap buffer per recorded frame
• Harden the USB adapter lifecycle #116 — USB adapter lifecycle, including an ANR from an unbounded join on the main thread
• Keep the activity alive across configuration changes #117 — keep the activity alive across configuration changes
• Log the ids of attached usb devices, and make wirelessInfo() safe #118 — log the ids of attached usb devices, and make wirelessInfo() safe
• VideoPlayer and WfbNgLink take a Context, not an AppCompatActivity #119 — VideoPlayer / WfbNgLink take a Context
• Bound how long the packet queue holds a frame back #120 — bound how long the packet queue holds a frame back

#113 and #116 are now confirmed on hardware (Quest 3, Horizon OS, Android 14).

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Log USB device IDs and make Wi-Fi lookup null-safe

🐞 Bug fix ✨ Enhancement 🕐 10-20 Minutes

AI Description

• Logs attached USB identifiers, metadata, and adapter-filter support status.
• Resolves Wi-Fi information through context with null-safe Android service handling.

Diagram

graph TD
  A["USB Manager"] --> B["Enumerate Devices"] --> C{"Filter Match"}
  C -->|Yes| D["Log Supported"] --> E["Adapter Map"] --> F["Refresh Adapters"]
  C -->|No| G["Log Unsupported"]
  F -->|No adapters| H["Safe Wireless Info"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Dedicated network information provider

• ➕ Decouples WfbLinkManager from VideoActivity
• ➕ Allows service behavior to be unit tested or mocked
• ➕ Supports additional WfbLinkManager hosts cleanly
• ➖ Adds an abstraction for a single current call site
• ➖ Broadens the scope of this focused fix

2. User-facing USB diagnostics

• ➕ Makes identifiers accessible without collecting application logs
• ➕ Could streamline adapter-support reports from end users
• ➖ Requires new UI, localization, and support workflows
• ➖ Exposes hardware details beyond the existing diagnostic channel

Recommendation: The PR's focused logging and context-based lookup are appropriate for a low-risk fix and should be retained. If WfbLinkManager gains additional hosts, move wireless address resolution from VideoActivity into an injectable network-information provider; a user-facing diagnostics screen is better treated as a separate enhancement.

Files changed (2) +36 / -6

Enhancement (1) +15 / -2

WfbLinkManager.javaLog attached USB metadata and adapter support status +15/-2

Log attached USB metadata and adapter support status

• Logs the attached USB device count plus each device's path, vendor/product IDs, names, and filter-match status. The no-adapter flow now passes its context into the null-safe wirelessInfo lookup.

app/src/main/java/com/openipc/pixelpilot/WfbLinkManager.java

Bug fix (1) +21 / -4

VideoActivity.javaMake wireless information lookup context-scoped and null-safe +21/-4

Make wireless information lookup context-scoped and null-safe

• Removes the activity-initialized static WifiManager field. wirelessInfo now obtains WifiManager from the application context, handles unavailable manager or connection information, and continues returning null when no IPv4 address exists.

app/src/main/java/com/openipc/pixelpilot/VideoActivity.java

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (1) 📜 Skill insights (0)

1. 2357:0115 remains unsupported 📎 Requirement gap ≡ Correctness

Description

The new enumeration path only logs that devices absent from usb_device_filter.xml are unsupported;
it does not recognize TP-Link Archer T4U v3.2 VID 2357 / PID 0115. The adapter is therefore
excluded before driver startup, violating the required T4U v3.2 support.

Code

app/src/main/java/com/openipc/pixelpilot/WfbLinkManager.java[125]

+                    allowed ? "supported" : "NOT in usb_device_filter.xml"));

Evidence

Rules 1 and 3 require functional TP-Link Archer T4U v3.2 support, with Rule 1 specifically
identifying VID 2357 and PID 0115. The current filter contains other 2357 products but not PID
0115; getAttachedAdapters() consequently labels the device as absent from the filter and
excludes it before adapter startup.

Support TP-Link Archer T4U v3.2 with RTL8812BU
Support TP-Link Archer T4U v3.2
app/src/main/res/xml/usb_device_filter.xml[13-23]
app/src/main/java/com/openipc/pixelpilot/WfbLinkManager.java[111-131]
app/src/main/java/com/openipc/pixelpilot/WfbLinkManager.java[167-172]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
TP-Link Archer T4U v3.2 with VID `2357` and PID `0115` remains absent from the supported-device filter and is excluded from adapter startup.

## Issue Context
The logging change helps diagnose an unsupported device but does not satisfy the requirement for functional RTL8812BU support. Confirm that the native driver path supports RTL8812BU before adding the USB filter entry, and add or integrate the required driver support if it does not.

## Fix Focus Areas
- app/src/main/res/xml/usb_device_filter.xml[13-23]
- app/src/main/java/com/openipc/pixelpilot/WfbLinkManager.java[111-131]
- app/wfbngrtl8812/src/main/cpp/WfbngLink.cpp[119-134]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Tickets: 🎫 RTL 8812BU Support 🎫 Addition of archer t2u 🎫 Support Archer T4U v3.2

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗