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 :)
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().