Title: Build 620 regression — Litchi Pilot holds RC/SDK connection after close, blocking other apps (DJI Fly) from connecting; also observed uncommanded gimbal deflection and drift mid-flight in Free/Manual mode. NOT present in builds 595/605.
Aircraft: DJI Mini 3 (standard, non-Pro)
Controller: RC-N1
Phone/OS: Xiaomi Redmi Note 13 Pro 5G, Android 16
App: Litchi Pilot 1.0.0_BETA-dji (Build 620)
Regression: Confirmed absent in builds 595 and 605. Only appeared after updating to 620.
Flight mode used: Free/Manual (direct VirtualStick control via RC sticks) — no waypoint mission was active at the time of the in-flight incident.
PART 1 — In-flight incident (uncommanded gimbal + drift)
Pre-flight/troubleshooting steps performed before this session (to rule out user error):
Phone rebooted before switching apps
No app set as default USB handler — manually selected “just once” each time a connection prompt appeared
Battery fully charged, aircraft in good physical condition, sensors clean (confirmed via normal DJI Fly operation before and after)
Sequence:
Opened DJI Fly, closed it, rebooted phone
Opened Litchi Pilot — aircraft did not connect
Rebooted phone, opened DJI Fly — flew normally, no issues, landed
Rebooted phone, opened Litchi Pilot again — this time connected successfully, took off in Free/Manual mode
At approximately 2m horizontal distance from pilot and 2.5m altitude, with no manual input or programmed action, the gimbal moved on its own to an extreme position: pitch near max positive limit (tilted almost fully upward) combined with simultaneous roll deflection to the right (viewed from the front, facing the aircraft). The aircraft also drifted laterally to one side without stick input.
Landed the aircraft immediately upon observing the anomaly.
Rebooted phone, opened DJI Fly — flew normally.
On final manual approach (no RTH — RTH is never used; always cancelled and landed manually), at approximately 1.5m altitude, with a fully charged battery, the aircraft began an uncommanded descent. Pilot had to actively hold the left stick up to counteract it. No low-battery warning, no sensor error, and no RTH was displayed or active at this time.
Confounding variable / transparency note: This flight took place with 3 other drones operating simultaneously in the same area. RF interference or channel congestion cannot be ruled out as a contributing factor to the gimbal/drift anomaly specifically, and is noted here for full transparency. This variable does not apply to Part 2 below.
PART 2 — Post-flight ground reproduction (isolated, no RF interference, solo testing at home)
Used QuickTransfer normally to download flight footage from the aircraft — worked correctly.
QuickTransfer exited on its own unexpectedly (unprompted).
Re-entered QuickTransfer mode, downloaded additional videos successfully.
Exited QuickTransfer, rebooted phone.
Opened Litchi Pilot — it connected to the aircraft.
Rebooted phone again, opened DJI Fly to continue downloading footage — aircraft did not connect to the RC.
Power-cycled both aircraft and RC — still no connection via DJI Fly.
Opened Litchi Pilot, then went to Android Settings > Apps > Litchi Pilot > Force Stop.
Opened DJI Fly — aircraft connected to the RC immediately and worked perfectly.
Confirmed that neither third-party app killers nor clearing the app cache resolve this — only Force Stop via Android system settings released whatever Litchi Pilot was holding.
Uninstalled Litchi Pilot entirely. Repeated the DJI Fly connection test twice more — connected correctly both times, no issues.
This reproduction was performed alone, at home, with no other drones/RCs/RF sources present, ruling out interference as a factor here. Note the RC-N1 relies entirely on the phone for display and app execution, meaning both Litchi Pilot and DJI Fly share the exact same USB port/cable/phone — reinforcing the USB accessory handle hypothesis below.
Root cause hypothesis
Initially suspected the new “Resume interrupted waypoint flight” feature (introduced in build 620) as the cause of a persistent background service. This has been ruled out — the connection-lock issue was reproduced while flying in Free/Manual mode, with no waypoint mission active, and no resume-state to track.
This points instead to a more fundamental issue in how Litchi Pilot build 620 acquires and releases its DJI MSDK product connection / USB accessory handle. The connection appears to remain held at the OS/process level regardless of flight mode used, and is only released via Force Stop (Android Settings) or full uninstall — not by normal app closure, backgrounding, third-party app killers, or cache clearing.
Additional note for dev team: Android 16 introduces stricter background/foreground service execution limits compared to earlier Android versions. Given that builds 595 and 605 did not exhibit this issue, it’s worth checking whether Litchi Pilot’s connection-handling service is being killed, restricted, or left in an inconsistent state specifically under Android 16’s new background execution rules — which could produce exactly the “connection held but app appears closed” behavior described above.
Summary of impact
This is not a cosmetic or connectivity-only bug. While Litchi Pilot held an active connection in Free/Manual mode, the aircraft exhibited uncommanded behavior it should never perform: gimbal snapping to an extreme, non-programmed position (pitch near max positive + simultaneous roll to the right) and uncommanded lateral drift, at low altitude (2–2.5m) and close proximity to the pilot (2m). This is a flight-safety concern, not a UX inconvenience.
Separately, the improperly released connection caused a completely unrelated app (DJI Fly) to fail to connect to the same aircraft, on a different occasion, with no other apps or RF sources involved. Standard remedies (app switcher close, third-party app killer, cache clearing, power-cycling aircraft and RC) did not resolve this — only Force Stop via Android Settings or uninstalling Litchi Pilot did.
In short: Litchi Pilot build 620 both caused unsafe, uncommanded aircraft behavior mid-flight, and left a persistent connection state that broke a separate, unrelated app’s ability to control the same aircraft. Neither issue was present in builds 595 or 605.
Question for the dev team: What changed in build 620 regarding MSDK connection lifecycle management or VirtualStick session handling that could explain (a) a connection/handle not being released on normal app close under Android 16, and (b) stale/uncommanded gimbal and movement values being sent to the aircraft during an active Free/Manual session?
I want delete this post!. Thanks You
Just to be clear. Did you want this entire thread to be deleted?
Ya no quiero eliminarla. Solo comentar que volví a usar la versión 607. Y todo funciona ok. Gracias