The situation:
I'm developing an android app for some hardware that has a BlueGiga WT12 bluetooth modem. The hardware device sends 56 byte packets at around 240hz. I'm testing on a Samsung S5 and S8. A fully functional app has already been created for IOS and PC so we know the hardware device works.
I use a separate thread to read in the data and then dispatch it to the main thread.
Issue:
The issue I'm having is when I send the command to the device telling it to start streaming, it starts to stream but very shortly after I start receiving packets at a very slow rate 10-60hz.
After some examination I realized that the device was experiencing a bufferoverflow.
After talking to our hardware guy he said the only real thing that could cause that is something on the phone side not reading fast enough, resulting in the hardware device not wanting to send more packets because it thinks the phone can't receive anymore and then the buffer overflows on the hardware device.
The WT12 has flow control enabled so maybe this is an issue with Android not giving a clear-to-send signal to the WT12. But to my knowledge we don't have access to all of the flow control stuff.
What I've tried:
My first line of attack was to simply remove any code that I thought was slowing down the reads but that seemed to have no effect.
I also tried basically every bluetooth serial terminal app I could get my hands on, all with the same result.
So then I questioned if it was some weird problem relating to the hardware device but after using pc based (bluetooth) serial terminals I had no issues at all on the pc.
The hardware device can also operate over USB as opposed to bluetooth so I tried reading the data from it exactly the same as I had with the bluetooth connection but over USB. Using the USB serial connection I had no issues at all.
My thoughts:
So this leads me to believe the problem must be with the bluetooth modem on the phone side. I was thinking maybe it was a flow control issue as we have flow control enabled on the WT12. Maybe android isn't sending a clear to receive signal?
The problem is to my knowledge the flow control is implemented in the bluetooth stack and we as developers have no control over it if I'm not mistaken?
Other then flow control I don't really have much idea what could be causing the hardware device to not want to send me data.
I've just now been experiencing the same issues with flow control. Then I see that in case of RN4678 BT module, that it's best to disable the flow in the MCU FW and pull the cts pin low on the module. That worked for us.
I have an Android application that has a chat client as one of its features. The chat client uses XMPP based on the Smack library for Android and running Openfire as XMPP server in the background. The connection is established using BOSH The whole XMPP connection handling is implemented as a service to run and listen in the background for incoming messages even if not activity of the app is in the foreground. So far, everything works perfectly fine.
The only problem seems to be the sleep mode. In the emulator (when set to "Stay Awake") or with the phone in use, the XMPP connections is holding and the app can send and receive messages. However, once the phone goes into sleep mode, the XMPP connection breaks down -- I can see it in the Admin Console of the Openfire server that the user is offline. Intuitively, I want to receive messages all the time like, e.g., WhatsApp.
Of course, I've searched online including Stackoverflow, but I couldn't get a definitive answer. Often the use case seems to be that a task has to be performed periodically, say, once every hour. But this doesn't seem to fir in case of a chat client. Since I assume this is a common use case -- after all, there a so many chat apps or apps with chat features out there -- these are my question:
How to I have to change / extend the app that I can receive chat message while the phone is sleeping?
I've stumbled upon WakeLock. Is this the way to go or are these not suitable for my use case?
Since Lollipop, there's also the JobScheduler API which itself uses WakeLock. Any better?
How does, for example, WhatsApp handles this case?
On a side note: I have problems with the sleep mode using the emulator for debugging. When I switch off "Stay Awake" in the emulator, the screen goes black after 1+ min and the XMPP connection breaks. But I somehow have no idea how to wake up / switch the emulator back on once it went black. Android Studio actually tells me at some point that the device or something is gone, and I have to restart the emulator again.
The exact way to resolve this issue is by using push notification.
It is the natural behavior of XMPP connection to get disconnected after the specified idle interval i.e when the device goes to sleep.
Coming to the case of WhatsApp, it also uses the same XMPP and maintains a server which acts as a wrapper class on the messages exchanged. This server checks the message status whether it is delivered or not. If not delivered, it sends a push notification, now at the device end in the push service when a message is received, it checks if the connection is active and is authenticated or not.
If not authenticated, it re-establishes the connection. In this way, the most chat apps manage this timeout exception.
Hope this helps :)
You don't need push notifications, you don't need WakeLocks. Instead simply
Whitelist your app from doze mode
Use a sticky (START_STICKY) background service
Use Smack's ServerPingWithAlarmManager
Act on CONNECTIVY_CHANGED intents send by Android, and use XMPPTCPConnection's instantShutdown() in that case.
I have two devices (Samsung Galaxy Tab 10 running 4.0.4 and Nexus 7 running 4.2.1). My application i am writing uses bindService/unbindService a service written within the same application to handle the constant managing of data regardless of activity state. Emulator/devices connected to the PC with USB debugging enabled work as expected. As soon as i unplug the the devices and try to the run the application stand-alone it doesn't error or exit or anything just doesn't bind so my log-in button doesn't work in my application until the bind is complete. This bind never completes and I have no idea why. Has anyone else experienced this?
I am including this for anyone who may run into this situation in the future. In my situation this was failing because the background service was waiting for a debugger thanks to android.os.waitForDebugger() and it was timing out. One line can screw your world up.. I had completely forgot that was in there.
I have read tons of this same advices about connecting two emulators using telnet. For example this one: Connecting 2 Emulator instances In Android
I've made all as it is said and nothing works. I have got server app on emulator 5554 and client app on emulator 5556. They are using ports 6000 server app and 5000 client app. What I want is to communicate when this two emulators are open - in both ways.
At the beginning server app shows her ip, and in client app user have to write this ip. That is whole configuration.
As in mentioned post was said I've written redir add tcp:5000:6000 but nothing works. Also when I write redir add tcp:6000:5000 nothing happen. Those apps don't hear each other. However if server is on other device than everything works fine.
Maybe it is stupid question but can someone guide me through this, because I don't know what am I doing wrong.
After following these instructions to integrate Adobe AIR with native Android I have a few issues.
I have managed to get a bluetooth connection going in native android, setting up 2 BluetoothSockets which then shows the air app also packaged within the apk. This included air app requires 2 connections to somewhere (normally wifi).
I have it connecting to TestService1 and TestService2, which is then passing the traffic between these services and the BluetoothSockets.
It is a little slow as i have to put Thread.sleep(80) in between reading from bt socket and writing to the AIR app for it to work currently.
My 2 questions are
Is there any way to get the AIR app to know about and access the Bluetooth Sockets created in the Android code rather than having the 2 Services being the middle men?
Is this kind of release (hybrid) allowed in Android Marketplace does anyone know?
Really hoping to find an answer to question 1 as currently my bluetooth server is continously sending data and using the TestService1 and 2 to get this bluetooth data to the AIR app and is causing a 10 seconds lag.
Thanks in advance
These apps are definitely allowed in the Android market.
You should be able to send Bluetooth data immediately over the socket to the AIR app. It doesn't seem like you should need 2 separate services or a sleep. I think your service that is talking to the Bluetooth can also listen on a socket and send data over that socket when it gets it.