VideoPlayer and WfbNgLink take a Context, not an AppCompatActivity

[iflyhere]

VideoPlayer and WfbNgLink both take an AppCompatActivity, but neither uses it as one:

• VideoPlayer passes it to nativeInitialize()
• WfbNgLink uses it for getSystemService()

Both only need a Context. Requiring an AppCompatActivity means neither can be constructed
from a Service, an Application or a test — which is what I hit while moving the link out
of the Activity so it stops being torn down in onPause().

Nothing else changes: every existing caller passes an Activity, which is a Context.

Compile tested for arm64-v8a + armeabi-v7a.

---

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

Accept Context in video and wireless link constructors

✨ Enhancement 🕐 Less than 10 minutes

AI Description

• Removes unnecessary Activity coupling from native video and wireless link wrappers.
• Enables construction from services, applications, activities, and test contexts.
• Preserves existing callers because every Activity is also a Context.

Diagram

graph TD
  C["Context Caller"] --> V["VideoPlayer"] --> N["Native JNI"]
  C --> W["WfbNgLink"] --> U["USB Manager"]
  W --> N

Loading

High-Level Assessment

Using Context directly is the appropriate approach because it represents the actual dependency required by JNI initialization and system-service access. Retaining AppCompatActivity overloads would preserve unnecessary coupling, while forcibly storing the application context could alter context semantics beyond this focused API change.

Files changed (2) +2 / -4

Refactor (2) +2 / -4

VideoPlayer.javaGeneralize VideoPlayer constructor to Context +1/-2

Generalize VideoPlayer constructor to Context

• Replaces the AppCompatActivity constructor parameter with Context and removes the unused AppCompat import. Existing Activity callers remain source-compatible while non-Activity components can now construct the player.

app/videonative/src/main/java/com/openipc/videonative/VideoPlayer.java

WfbNgLink.javaGeneralize WfbNgLink constructor to Context +1/-2

Generalize WfbNgLink constructor to Context

• Replaces the AppCompatActivity constructor requirement with Context and removes the corresponding import. The link can now be owned by services, applications, or tests while retaining USB service and JNI behavior.

app/wfbngrtl8812/src/main/java/com/openipc/wfbngrtl8812/WfbNgLink.java

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

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

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 ↗