I’ve spend many weeks trying to find the solution to this problem. The closest I got to the all time non stop working application was to create multi package application (also called a hybrid app) that consisted of:
- WEB application written in JS that was a watch face app
- Native service application (no UI) written in C
All apps were targeting Tizen API 2.3.1. This is the crucial part because there were multiple problems with 3.0 API like unexpected application kills by the OS or “too much battery usage” prompts that sometimes also resulted in killing my app. Funny thing about the Tizen OS is that when it kills the watch face app due to too much resource usage, the main screen of the watch is just plain black. Unfortunately targeting API 2.3.1 resulted in not being able to use multiple APIs added after this version.
Next thing I’ve used was device_power_request_lock(POWER_LOCK_CPU, 0); in all the native service apps. I believe that using the older API (2.3.1 instead of 3.0) allowed the application to work much longer without being killed by the system. I think that this is a flaw in this Tizen OS version that I’ve leveraged.
In the WEB app I’ve used ScreenStateChangeListener and timetick events to check if the service app is running. If not -> it was started by the WEB application. For communication between service and the watch face I’ve used preferences listener API. Watch face WEB app was responsible for checking what service is working and what service needs to be woken up or started.
In the end I’ve ended up using 4 native service applications packaged together with the WEB app. Each service app had its own purpose like filesystem, network, monitoring, etc. Multithreaded service apps were really hard to maintain and often crashed for unknown reason.