I’ll try a different question. Does anyone use QGC on an Android phone? A Google Pixel? I’m have trouble with what appears to be outgoing packets from QGC to the flight controller being blocked by the OS. I’m on a Pixel 11 Fold w/Android 17.
Yes…i have a QGC v5.0.8 on a Herelink GCS running Android version 9. QGC v5.0.8 desktop(windows) version also has the same issue of not detecting Mavlink packets . I have to open QGC windows desktop v4.4.2 first to detect mavlink packets and then close and then open QGC v5.0.8 ( windows desktop) to ensure it detects the drone automatically on start !! 
My problem is the opposite direction. QGC receives the UDP packets from the aircraft, but can’t send anything to the aircraft. I suspect that this is an Android version issue with newer versions locking things down more. I’m hoping to figure out how to work past the “security” (if that is what issue) so that it works properly.
I’m using various Android devices, but no Pixel.
Will have to try over coming days if there are any communication issues.
Since aircraft → QGC traffic is working but QGC → aircraft is not, I’d try to separate the Android/network layer from QGC before assuming Android 17 is blocking it.
One useful test would be to capture traffic on the aircraft/network side while sending a simple command from QGC.
I’d check:
- whether QGC actually emits an outbound UDP datagram
- destination IP and UDP port
- source port used by QGC
- whether the return destination was learned from the incoming MAVLink endpoint
- whether the packet reaches the Wi-Fi interface/network but not the aircraft
That gives a fairly clean boundary:
QGC command → UDP send → Android/network interface → Wi-Fi network → aircraft
If no packet leaves the Pixel, the investigation stays on the QGC/Android side. If it does leave but never reaches the aircraft, I’d look at routing/AP isolation/firewall behaviour instead.
If you can capture a short packet trace while sending one command, that would probably narrow this down quickly.
My Android 15 device is working / communicating as expected.
…but I am aware that later versions of Android lock things down even more, as you have already mentioned.
We made some progress on this in another post, linked below. I don’t know why this only manifests on recent versions of Android and not older versions and not on Linux with multiple WiFi interfaces. The problem appears to be routing, not some sort of firewalling. App permissions around routing could be a factor. I’m not an Android developer. With the WiFi connected to the dead-end (not internet connected) ELRS backpack and mobile data connected to the internet, the default interface is the mobile data link. It appears that the out-going UDP packets attempt to go that way. I have not traced them, but on advice I tried turning off the mobile data connection. With that default interface down, UDP routed out the WiFi correctly and QGC is fully functional. …except that it can’t pull imagery or terrain data from the internet. Once QGC is synchronized with the FC, the mobile data can be turned on. Now UDP sends fail again, but QGC can pull data from the internet. Once that is done, turn mobile data off again. This is a major PITA, but it seems to point in the direction of the problem and gives me a poor solution to survive for now.
That is a very useful A/B result. The mobile-data toggle gives you a much stronger boundary than the original “Android may be blocking UDP” hypothesis.
Based on what you observed:
mobile data ON → outbound MAVLink fails
mobile data OFF → Wi-Fi path works and QGC is fully functional
mobile data ON again → outbound MAVLink fails again
that makes route/interface selection a much stronger candidate than generic firewalling.
I would still avoid concluding that the UDP packets definitely leave through cellular until it is observed directly, but the next test can now be very focused.
If possible, capture one identical QGC command in two conditions:
A — mobile data OFF, command succeeds
B — mobile data ON, command fails
Then compare the destination IP/port and whether the datagram appears on the ELRS/Wi-Fi side in each case.
If A produces the expected Wi-Fi packet and B produces no corresponding packet on that interface, you have a small reproducible test case that could be much more useful to QGC/Android developers than the original symptom description.
It may also be worth recording the Pixel/Android version, QGC version, Wi-Fi network properties and whether Android reports that Wi-Fi network as having internet connectivity.
The workaround is awkward, but it has given you a very useful experimental control.