Closed JiriBilek closed 1 year ago
Indeed, this lines are probably crap https://github.com/hannesa2/paho.mqtt.android/blob/a66af7316e4b7c34591c8f3af0b8598ccdc48292/basicSample/src/main/java/paho/mqtt/java/example/PahoExampleActivity.java#L151-L157
Anyway, I assume this is the main reason https://developer.android.com/about/versions/oreo/background.html Here is the discussion https://github.com/eclipse/paho.mqtt.android/issues/281
I would love when someone would implement a solution with https://developer.android.com/reference/android/app/job/JobScheduler.html . I would approve immediate
Thanks for the reply. I didn't have an idea of the changes from Android 8 on. It seems to me now that we can forget about long time TCP connections and about a reliable and instant MQTT transfer as well :(
Yes, this is the biggest problem in this library. Maybe I will fix it in the next few days, but I promise nothing
There is no reason to give up that early. You can switch back to
targetSdkVersion 24
then I expect to work properly.
But with this you can't publish to Google play store anymore
The thing is how to test it in Espresso test this background service behavior ?
@JiriBilek Your have to help me.
I following your connection String serverUri = "tcp://broker.hivemq.com:1883";
Does this works for you, or is it my network connection ? (I'm on vacation, and maybe the port it locked in my hotel)
In your example, I had to add to the manifest more privileges to be able to connect:
<!-- Permissions the Application Requires -->
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.WAKE_LOCK" />
In your example,
It's the example, not mine 😉 I just try to keep this library alive.
Please see https://github.com/hannesa2/paho.mqtt.android/pull/84 This solves only the init crash. And yes there are too less permission, and unfortunately it's doesn't show any error when it's missing 👎
I tried the example on Android 5.1 and it lost the connection as well.
I try to reproduce it, but till now I failed.
This looks not that bad.
How does it looks like on your side ?
It looks the same. Between "The Connection was list" and "Reconnected" is losing the data from the broker.
The last line is confusing - failed connection because already connected. Weird.
I use QoS 0 as I my intention is to know about the event asap. I am monitoring a beehive (bumblebees, actually).
my intention is to know about the event asap
It has the touch of https://github.com/eclipse/paho.mqtt.android/issues/281#issue-291927771 Solution 1 with forground services
You battery will be empty sooner, but everything has a price
Anyway I tried to introduce a test to capture the error case with #98 and #96 and to be honest I need help here to first have 1 #reproduce able issue, then (only after this) I can look for a 2 #solution.
For a better understanding it comes with screenshots of test case
I'm stuck on 1 #reproduce able issue. You are warmly welcome to jump into this.
Yes, I read the comment about foreground services. It may solve my problem. It'll take me time as I must study the android services first. Until now, I took the paho.mqtt library as such and have not studied the internals in it.
As to the tests, I want to help but I don't understand what should I do.
As to the tests, I want to help but I don't understand what should I do.
I need to know, how to reproduce it.
Btw, the BasicDemo can send a message, but never receive it. -wtf-
Between "The Connection was list" and "Reconnected" is losing the data from the broker.
Did you changed the qos
(quality of service) ? Maybe it helps.
Btw, when you do your changes in a branch of your fork, I could at least follow what you did
Ok, I must leave now but in the afternoon I'll fork the repo and play with the qos.
I forked the repo, made necessary changes (https://github.com/JiriBilek/paho.mqtt.android/commit/8eda6aea6bf91fa81b3243b4c0c435fdf7c5d857) and run it. It run without losing the connection for 30 minutes while the phone was connected to the usb for the whole time. Shortly after disconnecting the usb cable, it lost the connection.
Still Android 5.1.
Edit: I realized that with the USB power, my old app runs fine and holds the connection like a charm. Next, I'll try the same on Android 10.
Edit2: I checked out the AwakeTest and run it. As long as the phone was connected to the PC (and charging), it held the connection. After plugging out, the connection was lost.
Can my app receive the MQTT message even if the screen is turned off or my app is not the foreground app, with this library? The "basic sample" seems to be working, but that was with my app in the foreground with the screen on. My app would not be very useful if I have to keep the screen on and my app as the foreground app to receive the MQTT message.
If it is possible, would you add another simple sample project to show the incoming message in the system notification when the app is not the foreground app or the screen is turned off?
Without foreground service, you could give https://github.com/hannesa2/paho.mqtt.android/releases/tag/3.4.0-beta5 a try.
I uses Workmanager
to avoid to keep device always on.
This issue has been automatically marked as stale because it has not had recent activity. Please comment here if it is still valid so that we can reprioritize. Thank you!
Closing this. Please reopen if you believe it should be addressed. Thank you for your contribution.
Hi, I tried the basicSample application in hope it would not lose the connection to the mqtt broker as my app using the original service did. Unfortunately, I am losing the connection as well.
The changes I made to the sample:
serverUri = tcp://broker.hivemq.com:1883
I tried the app in the emulator and it works fine. On the phone (Motorola with Android 11) after the screen goes black, ca 90 seconds later, it loses the connection:
It does not matter if I'm connected to Wifi or Mobile data.
Is there anything I can do to fix it? Thanks.
Edit: the 90 seconds I mentioned may be misleading, I currently observed virtually any time between reconnecting and losing the connection.