[Android] App Messages SLOW on Android 4.2.x

[MichaelMalony]

App messages between pebble watch and Android are significantly slower on Android 4.2.x than on earlier versions of Android.

I created a sample (url below) to reproduce the problem. Here is the flow it follows:

• Open Android app (sets up receiver, but does nothing else)
• Open watch app, it will send a message to Android (contains a byte key/value pair)
• Android app receives message, sends ack, then sends back a message (byte key/value pair).
• Watch app receives message, shows count of messages received, send another message to Android app
• The last two steps repeat indefinitely

On pre 4.2 this is very fast. You can see the count increasing on the watch almost instantly.

On 4.2.x the messages are far slower. It takes anywhere from 1-2 seconds to see the count go up each time.

IMPORTANT: On 4.2.x every once in a while it will run fast (usually after a restart or fresh install), but after a few minutes it will run slow and pretty much remain that way indefinitely.

Sample app (includes pbw, apk, and source):

https://docs.google.com/file/d/0B2PhRn7T41j3UnNOaUhmdExEU1k/edit?usp=sharing

[Mhornyak]

Hi,

Thanks for the report.

When you say 'earlier versions of Android,' do you mean Android 4.2.1? Or Android 4.1 and lower?

thanks, Matt

On Jul 1, 2013, at 5:21 PM, DashCunning notifications@github.com wrote:

App messages between pebble watch and Android are significantly slower on Android 4.2.2 than on earlier versions of Android.

I created a sample (url below) to reproduce the problem. Here is the flow it follows:

Open Android app (sets up receiver, but does nothing else) Open watch app, it will send a message to Android (contains a byte key/value pair) Android app receives message, sends ack, then sends back a message (byte key/value pair). Watch app receives message, shows count of messages received, send another message to Android app The last two steps repeat indefinitely On pre 4.2.2 this is very fast. You can see the count increasing on the watch almost instantly.

On 4.2.2 the messages are far slower. It takes anywhere from 1-2 seconds to see the count go up each time.

IMPORTANT: On 4.2.2 every once in a while it will run fast (usually after a restart or fresh install), but after a few minutes it will run slow and pretty much remain that way indefinitely.

Sample app (includes pbw, apk, and source):

https://docs.google.com/file/d/0B2PhRn7T41j3UnNOaUhmdExEU1k/edit?usp=sharing

— Reply to this email directly or view it on GitHub.

[MichaelMalony]

That's a good question. I'll try and get a 4.2.1 image on one of my devices and test it out. I know it works right on a few different versions of 2.3.x and also 4.1.something. Not sure why I assumed 4.2.2 instead of 4.2.x, been staring at too many version numbers.

[MichaelMalony]

Tested on 4.2.1 and it is definitely a problem on that version as well. I updated the issue accordingly.

[MichaelMalony]

Still a problem with 1.12 firmware / SDK. If you update AppMessageTest.c around line 89, the first line of sendAppMessage(), insert this line:

app_comm_set_sniff_interval(SNIFF_INTERVAL_REDUCED);

The app message will not now run fast for anywhere from 30-60 messages, then it slows down again. Not nearly as bad as with the previous firmware, but it is still an unaccounted for slow down. Not really sure if it requires the messages to be in quick succession or the slow down will happen even when they are spread apart.

[alexd6631]

Hello,

Curiously, setting SNIFF_INTERVAL to REDUCED then NORMAL seems to yields better results than just leaving it to REDUCED, and will give something like 10 seconds of consistent speed boost.

Doing so before each request and after each received message (see snippet below), allow to keep the speed to its maximum for an arbitrary number of successive messages. Can you please try this trick on your apps and report if it worked for you ?

void handle_in_received(DictionaryIterator received, void *context) { ... / Handle incoming message here */ app_comm_set_sniff_interval(SNIFF_INTERVAL_REDUCED); app_comm_set_sniff_interval(SNIFF_INTERVAL_NORMAL); }

[sarfata]

Hi Alex,

We know this is not perfect yet and it's great that you are finding solutions on your own. I just wanted to let you know that changing the sniff interval increases power consumption (during the switching process) and doing it so often will drain the watch battery. We do not recommend sticking with that solution.

thomas Pebble Developer Evangelist

[alexd6631]

Hi Thomas,

Yes obviously it will depend on the application and the kind of reactivity expected by end users. I am aware it is not something to leave always on.

But in the case of an user open an app and perform a few request then close the app, it makes sense to speed the communication during a few seconds (for instance it is the case in Music app), because the overall time spent in the app will be negligible. The pattern that I recommend is setting to REDUCED before sending a request and back to NORMAL after receiving the response. It seems to have an undocumented effect of leaving it fast for a few more seconds, so if another message come in that time, it will be received shortly.

My point was more about understanding the behaviour of sniff interval and exploring the limit of the protocol. Right now the documentation of the functions, is slightly different from how they behave in real life, which I think is confusing for a lot of developers.

Best regards

[follower]

@alexd6631 Please note @sarfata's use of the phrase "(during the switching process)"--the actual process of switching states increases the power consumption regardless of which modes are being switched between. My understanding is that this happens because the Bluetooth hardware has to go into an intermediate higher power state in order to perform the switch (this state has higher power consumption than even REDUCED mode). This means that constantly switching states will actually increase the power consumption in comparison to leaving the state at REDUCED.

This is something we're planning to document more clearly in a future release but I just wanted to reinforce Thomas' advice that constantly switching states will lead to significantly reduced battery charge life and while it may be a workaround to the speed issue it's a costly one in terms of battery charge life.

[alexd6631]

Hello,

Thanks for the clarification about the internals of the "switching process", the current documentation is indeed misleading about that, especially about the intermediate power hungry state.

So when I switch to REDUCED, I will enter into a SWITCHING state for a few seconds (explaining the fast communication observed by many), then will enter the real REDUCED mode (which is a bit but not so faster) than NORMAL ?

I think what most of us want here, is a faster and more consistent REDUCED state than it is right now, because some use cases like phone remotes or image sending can only be achieved by the switching tricks.

My proposal would be, if possible, to have several levels of REDUCED_XXX and let the developer pick the less consuming one that satisfy expected reactivity. Hopefully you'll find an elegant solution to this issue.

Best regards

[rjcase]

Hey there,

The internal API to switch between these different sniff intervals forces the Bluetooth controller to enter an "active" mode---that's the responsive but very power-hungry state you've discovered.

In a future release, we'll add an API to allow third-party apps to cause the Bluetooth controller to enter an active mode for a period of time.

Thanks for your feedback :)

On Tue, Jul 16, 2013 at 11:39 AM, alexd6631 notifications@github.com wrote:

Hello,

Thanks for the clarification about the internals of the "switching process", the current documentation is indeed misleading about that, especially about the intermediate power hungry state.

So when I switch to REDUCED, I will enter into a SWITCHING state for a few seconds (explaining the fast communication observed by many), then will enter the real REDUCED mode (which is a bit but not so faster) than NORMAL ?

I think what most of us want here, is a faster and more consistent REDUCED state than it is right now, because some use cases like phone remotes or image sending can only be achieved by the switching tricks.

My proposal would be, if possible, to have several levels of REDUCED_XXX and let the developer pick the less consuming one that satisfy expected reactivity. Hopefully you'll find an elegant solution to this issue.

Best regards

— Reply to this email directly or view it on GitHub.

[alexd6631]

Great to hear that :)

Reminds me that Android API, by the way : http://developer.android.com/reference/android/os/PowerManager.WakeLock.html#acquire(long)

I think it will be very useful for "request/responses" patterns where you need high performance for a very short time then return back to sleep as soon as possible.

[alexd6631]

Hello,

Just to inform you, that in the new Android 4.3 communications are fast and instant again without having to change the sniff interval.

[natevw]

Could this ticket be related at all to really poor messaging performance I usually see with libpebble? When its repl first connects I get pretty good performance, but it soon goes down to only a message a second or so.

[xlight]

this bug still exist on my Galaxy S4 (i9500) Android 4.2.2 will it be solved?

[MichaelMalony]

This was never really resolved. The sniff interval stuff helped some, but you still see a slow down. The biggest annoyance is how much this varies across devices / Android versions. Makes supporting apps a huge pain as it I can't really tell users "Oh, you just happen to being using a device that has horrible communication lag with Pebble. Deal with it."

[sarfata]

I understand your pain here. This is an Android bug though and unfortunately we have not found a lot we can do on the pebble side.

[vongohren]

Has this issue been reconsidered? Im experience slow connection on my 4.4.2 android devices. I have an app which have a long connection time, not a lot of data sending. But when I click the middle button i want to update a state. The slow connection makes the app_message_register_outbox_failed trigger because I dont have time to send the ACK back with the PebbleKit.sendAckToPebble(context, transactionId). It is the first thing I do when I recieve the middel button click. Ref this question: http://forums.getpebble.com/discussion/17876/pebblekit-ack-message-failes-android

[sarfata]

@Snorlock What version of the app are you using? We have rewrote the appmessage layer almost completely in the new beta which is available through our beta channel.

[matejdro]

@sarfata What @Snorlock is describing is bug in Pebble firmware (I've seen reports from iOS people too on forums), where message will sometimes take few seconds to arrive from Pebble to phone and naturally trigger timeout on the Pebble.

[vongohren]

@sarfata im using 2.0.17.1 but does the pebble app have anything to do with the pebble kit One use in android developing? But it is correct what @matejdro explains, that is my troubles and its seems in the pebble firmware. He mentiones that there have been reports on iOS, and there probably is, but we have not experienced that on our own app, so there is a difference.

The most noticable difference is that the iOS doesnt have to write the specific line about sending the ack message, its handled in the pebble_kit layer.

[matejdro]

Just for reference, here is forum thread I was talking about: http://forums.getpebble.com/discussion/11491/appmessage-sending-frequency

(Reports from both Android and iOS are inside)

[sarfata]

Thanks - I posted in this thread to get code that reproduces the problem.

On Android, your app messages are sent to the Pebble app (via an intent) and then the Pebble app delivers them. Please update to the last version of the Pebble app and tell me if you still get those problems. thanks!

[vongohren]

@sarfata is the newest version 2.0.17.1? Because that is the one I have, and I dont experience anything different The code im using is. there are things below received value, but i try to send the ack at once!

private PebbleDataReceiver getPebbleDataReceiver() {
    return new PebbleKit.PebbleDataReceiver(PebbleConstants.SPAREBANK1_UUID) {

        @Override
        public void receiveData(final Context context, final int transactionId, final PebbleDictionary data) {
            PebbleKit.sendAckToPebble(context, transactionId);
            int receivedValue = data.getInteger(1).intValue();

[sarfata]

No. Version 2.1 is available through our beta channel. I should have been more explicit. Here are instructions to get it.

[vongohren]

Thx @sarfata . Iv got it now, it fixes some issues yes, but i still experince the timeout problem. Its much faster though. But when is this version expected to release? I wonder because we have a bug that is on the 2.0.17.1 but have been fixed on the 2.1 version, and I wonder if Im going to spend time on this bug or not.

Its about the int recieved on ackRecieved. It used to send and ack on app termination which was just increasing. But now it seems like you send 255 instead. As well you guys reset the int sent in as recieved instead letting it run uncontrolled up to 255 and start over again.

[sarfata]

I do not have an exact data but it is been in beta for a little while now and you can expect it will not be much longer before we release it.

One thing to note though is that it will be only available to Android 4.3+ when we release it. Support for older versions will take a bit longer to come.

[vongohren]

@sarfata ok, because of this release i either have to wait for it to release or use time to fix the bug mentioned earlier. And that bug is only thing waiting for a release. About android versions, its all good, it just lets me argue why i have to push the versions, which is good.