Android Question UDP network issue with Android 5.0.2 and higher

[JS Hart]

I have an app that communicates with Windows PCs using UDP packets. It has been working successfully for over a year on Android devices that are 5.0 and earlier. Then I discovered that newer Androids running later versions than 5.0 did not work correctly anymore. The first problem was that button views were always on top. After looking at the forum here, I followed the advice and re-coded to make the buttons not visible in addition to using the "bringtofront" method.

This seems to work okay... but then I discovered a bigger problem: the UDP_PacketArrived event never triggers when using Android 5.0.2 or later. I can run the exact same code on Android 5.0 and everything works great; both using debug and using release as well as without any B4A bridge connection. I check to make sure that the UDPSock.IsInitialized=true, I know the udp packet is being sent on the port from the Windows PC... but the UDP_PacketArrived never triggers -- but only when using Android 5.0.2 or higher.

Is there some network behavior that changed? Permissions needed? Ports blocked (all my port numbers are at the very high end: 65535 and down to 63487... could that be a problem? Is it a security issue in the SSL layer of the newer Android OS?

I can post code, but like I said it works fine under Android 5.0 and earlier.

Thanks,
J. S. Hart

 

[wes58]

I have been using UDP communication between Microchip PIC32 (server) and my application for a number of years. Now I am on Andorid 5.1.1 and don't have any problem.

 

[Erel]

After looking at the forum here, I followed the advice and re-coded to make the buttons not visible in addition to using the "bringtofront" method

This is not the correct advice. Correct advice: Make your app compatible with Android 5.0 devices

It works fine here tested with a device running Android 6.
I've used this code:

Sub Process_Globals
   Private udp As UDPSocket
End Sub

Sub Globals

End Sub

Sub Activity_Create(FirstTime As Boolean)
   If FirstTime Then
     udp.Initialize("udp", 12345, 8192)
   End If
End Sub

Sub udp_PacketArrived (Packet As UDPPacket)
   Log(Packet)
End Sub

 

[JS Hart]

Thanks Erel, I'll go over it again and see what I did wrong.

 

[JS Hart]

As expected, you're correct. I added "SetApplicationAttribute(android:theme, "@android:style/Theme.Holo")" to the manifest. And while I was at it, I updated my Android SDK with all the new versions, and "Presto" everything works like it was designed.

Thanks Erel.

 

[JS Hart]

Just to close the loop on these issues in case any one else goes down this path:

The initial problem I described was first discovered when I installed my app on a newer Motorola device that was running Android 5.1.1. I later found the same undesirable behaviors also appeared on Motorola devices with Android 5.0.2 installed. My main testing and development platform is a Galaxy S5, running Android 5.0, and I could not duplicate the issues on it. So ultimately, I found it necessary to acquire an inexpensive Motorola device that could upgrade to 5.0.2. I chose a Moto E2, and presto, the issues were manifested on it. Now I could work on solutions.

The first issue was the "buttons always on top" display formatting issue. I first went down the wrong road of changing the way the screens were drawn to compensate, but Erel corrected me and (strongly) suggested the change to the manifest as described above. This worked and was much simpler. Very good advice.

The second issue however was not immediately obvious and also not related to the formatting issue. The issue was that I was not receiving the UDP messages on the newer Android devices. After a good bit of research, I found that (as Erel said) UDP packets were in fact still working just fine on the newer Android versions, but what was not working specifically on the Motorola devices was the ability to receive broadcast UDP messages. I didn't expect this. I thought a message was a message. But no, it seems that some devices filter out broadcast messages and only allow receipt of messages specific to the receiving device.

The solution to this problem is also (thankfully) found on this forum, and that is that you must specifically allow multicast messages. Here's one link to that problem and it's solution.

So in the end, there were two problems that appeared at the same time but required two separate solutions. And both were found on this forum.

Thanks to one and all.