PebbleKit2 messages from watch #11
Description
Hello,
I have some issues with PebbleKit2 communication watch->phone.. From phone->watch everything works well.
But sometimes non-deterministically my messages from Pebble to Phone are not delivered into the ListenerService.
I have debugged the watch app and I see the message is sent from the watch and acked by the Pebble app:
10:24:15] SleepAsPebble.c:372> Action message: 4
[10:24:15] SleepAsPebble.c:655> Data acked successfully.
I see the messge rrived at Pebble app on the Phone:
2026-03-06 10:38:04.780 17501-10189 PebbleProt...:D5:83:90) coredevices.coreapp D sending io.rebble.libpebblecommon.packets.AppMessage$AppMessageACK@fffffff2
2026-03-06 10:38:07.919 17501-10189 PebbleProt...:D5:83:90) coredevices.coreapp D inbound pebble protocol packet: io.rebble.libpebblecommon.packets.AppMessage$AppMessageACK@ffffffef
2026-03-06 10:38:18.211 17501-7431 PebbleProt...:D5:83:90) coredevices.coreapp D inbound pebble protocol packet: io.rebble.libpebblecommon.packets.AppMessage$AppMessageACK@fffffff0
But the override suspend fun onMessageReceived(
watchappUUID: UUID,
data: PebbleDictionary,
watch: WatchIdentifier
): ReceiveResult {
method in my app is not called.
My Pebble app has the comapnion app section in package.json
"companionApp": {
"android": {
"url": "https://play.google.com/store/apps/details?id=com.urbandroid.sleep",
"apps": [
{
"package": "com.urbandroid.sleep"
}
]
}
},
And this is the manifest declaration of the service:
Interestimgly the onStartApp method is called but not onAppStop or onMessageReceived
After some debugging I have also found this error in the logcat:
026-03-06 10:48:35.711 17501-13801 e coredevices.coreapp E Unhandled exception in PebbleKit2 24b0a1e5-f0b1-440d-8e53-8f26688a3f07: All 2 AppMessage channels already claimed
java.lang.IllegalStateException: All 2 AppMessage channels already claimed
which is probbaly the cause of the problem...
I seen that force closing the Pebble app fixes the issue.
Could this be cause by not closing the sender properly? I have improved sender closing handling to always close X seconds after the last successful message. Is this a good approach?
I guess closing the sender just afetr sending the message and creating a new one for each messge is not a good approach - I guess this woudl break the ack mechanism?
The github readme could be a little more specific on how to best handle sender closing IMHO..
Many thanks for all you effort on this!