Hello Ian,
Thanks for the response. Please see my feedback below:
from what you've said, if API level 16 is used, then shouldn't the current approach work, as the documentation says that it will be inexact starting in API level 19?
>> There are two different API levels involved here; the one in Paho Android service and the one in final APK.
Since Paho Android service gets used as JAR in another APK, apparently the run time API level is based on the API level of the APK. Previously I was using API level 19 in my APK and this caused the AlarmManager set API to be inexact. Once I changed the API level of my APK to 16, the AlarmManager now works as expected.
1) Would supporting API level 19 bring additional benefits? Would it mean that API level 16 was not supported and that it would not run on older Android versions?
>> I don't know of any other benefits by moving to API level 19. If we change to setWindow API, then it will not work on API level 16 because this API was added in 19.
2) there hasn't been a plan because until you mentioned it I didn't realize it was a problem! It would be great if you could try a fix and see that it works. I'm all for you helping out (check the contribution guidelines
http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.java.git/about/), but I want to check that this is the right approach.
>> I have already tried the fix and it is working as expected. When using setWindow API, I set the window length to 40% of keepalive value. Since MQTT allows 50% buffer time, there is no more connection drops.
This issue is more common on Wi-Fi only devices, which tend to sleep for long periods. Moreover, when this issues happens, the broker disconnect at 1.5 times keepalive internal. At that time, the client gets notified and can reconnect. Therefore, on Wi-Fi only devices, you would see frequent connects and disconnects especially for lower values of keepalive (<10 minutes).
Once I made the change, the issue disappeared completely.
Based on above observations, it may be better to keep things as it is for now. As long as final APK uses API level 16, there should be no issues.
If there are other reasons to migrate to higher level API, this task can be bundled at that point.
Regards,
Kamaljeet
Date: Sun, 8 Mar 2015 20:44:11 -0700
From: icraggs@xxxxxxxxxxxxxxxxxxxxxxx
To: paho-dev@xxxxxxxxxxx
Subject: Re: [paho-dev] AlarmManager accuracy
Hi,
from what you've said, if API level 16 is used, then shouldn't the
current approach work, as the documentation says that it will be
inexact starting in API level 19?
1) Would supporting API level 19 bring additional benefits? Would
it mean that API level 16 was not supported and that it would not
run on older Android versions?
2) there hasn't been a plan because until you mentioned it I didn't
realize it was a problem! It would be great if you could try a fix
and see that it works. I'm all for you helping out (check the
contribution guidelines
http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.java.git/about/),
but I want to check that this is the right approach.
Ian
On 03/05/2015 09:11 AM, Kamaljeet
wrote:
Hello,
I am using Paho MQTT Android service on a Kitkat device. I
noticed that sometimes AlarmManager notification does not
happen and this leads to disconnection. After searching the
reason for this, I found this note in the Android
documentation:
Beginning in API 19, the
trigger time passed to this method is treated as inexact:
the alarm will not be delivered before this time, but may
be deferred and delivered some time later. The OS will use
this policy in order to "batch" alarms together across the
entire system, minimizing the number of times the device
needs to "wake up" and minimizing battery use.
There are two alternates to solve this issue; either use
setExact or setWindow function to schedule the alarm. In order
to use either of these functions, the minimum API needed is
19.
When compiling Paho Java and Android service based on Maven
commands mentioned below, it always uses API 16:
My questions:
1) Is there a plan to support API 19 or later for the Paho
Android service?
2) Is there a plan to change the AlarmManager call from set
to setWindow? I will be happy to help with this task.
Thanks
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev