0

I'm working on a Control Extension for Sony SmartWatch 2 that needs to update a TextView every second on the SW2 Display.

It happens that if I've my Smartphone connected via USB or when USB disconnected if I've my Smartphone screen active, the Control Extension works as expected on SmartWatch 2.

But soon my SmartPhone screen idles, the control extension stops the regular TextView updates. First starts breaking and eventually get stuck. The Extension is not closed by the Host Application and the SW2 continues well paired with the Smartphone. In fact if I touch the display, the Extension appears to recover state for some moments with a few TextView updates, but rapidly breaks and get stuck again.

Meanwhile, if I turn ON my Smartphone screen, the control extension recovers the state and resume the normal TextView updates.

It seems that when the smartphone idles it stops to send the regular bluetooth messages to the SW2. I've tried many solutions to avoid this behaviour, even set the keepRunningWhenConnected to true. But the behaviour is allways the same.

Is anyone also having this problem or have a clue for the solution?

Thanks :)

xetiro
  • 112
  • 4
  • So you have an activity on the phone too? It sounds like that's being stopped. You should not rely on that being around. Do you think you are? – weston Jan 02 '14 at 20:04
  • I'm only using one Preference Activity that could be launched through the SmartConnect app. – xetiro Jan 02 '14 at 20:49

2 Answers2

1

What model of phone are you using?

If it is indeed that the bluetooth connection is not persisting then you could try the following possible solutions:

  1. Is there a setting on the phone to keep bluetooth on even when going into idle?
  2. You could set the phone to not go into idle while your app is running, of course this is not ideal as it will cause battery drain.
mldeveloper
  • 2,253
  • 1
  • 13
  • 14
  • I'm using a Galaxy Note I (GT-N7000) with Android 4.1.2 by Samsung. But isn't supposed the Host Application keep the bluetooth connection between Phone and Smartwatch 2? This should be transparent for programmers since its the paradigm of use of the SmartWatch 2 in the first place. – xetiro Jan 02 '14 at 20:32
  • If this is the problem, other smartwatch apps would be affected just as much. @xetiro are they? – weston Jan 03 '14 at 08:37
0

Ok. After testing and testing several solutions (AlarmManager, BluetoothAdapter, etc...) I came to following conclusion:

Its not the Bluetooth connection that is lost, otherwise the SmartWatch 2 would lost connection with the Smartphone, and that never happens. In fact is the Phone CPU that is lost by the ControlExtension, because when the Smartphone idles the CPU also idles. By loosing the Phone CPU the ControlExtension cannot process the "sendText(...)" call and this means that the corresponding upper call "sendHostApp(...)" that uses the Bluetooth messages its also never called, that's why the TextView is not updated on the SmartWatch 2.

Also I think that when I touch the SmartWatch 2 screen, this triggers an hardware interruption that wake up the Phone CPU for short seconds to answer to the SmartWatch 2 Touch Event and thats why when I touch the SW2 screen the TextView is updated a few times before get stuck again.

This works fine for static Control Extension applications that only display static content and/or replies to the user (touch, swipe, etc...) events. But its a complete disaster for Control Extensions applications that need to be doing some processing regardless the user direct interaction.

I never though in this terms because I though that it was the job of the SmartConnect Host Application to guarantee Phone CPU to the Control Extensions.

So the solution for some apps could be using an AlartManager in order to schedule wake up calls to do some processing. For other apps the solution could be the PowerManger and use a wakelock.aquire()/wakelock.release().

xetiro
  • 112
  • 4
  • So do other smartwatch apps have the problem? Try a game, where the screen is updated a lot. – weston Jan 03 '14 at 08:39