Is it possible to keep Tizen application alive non stop

Question

recently I’ve started developing for Tizen OS. My application is created only for wearable and only for specific device which is Samsung Gear Sport (Tizen 3.0 on board). Main purpose of this application is to gather complete sensor data over a long period of time. I’m interested in heart rate, and movement sensors in general (gyroscope and accelerometer). Then, this data will be send to cloud server and analysed. Currently I’m considering a WEB application because so far I have found no evidence that WEB API is missing something that exists in native API.

But there is one limitation in Tizen OS that so far I am unable to overcome. My application is put to sleep after a while (10 minutes or so). It is crucial that this app should work in the background for a long time (up to 10 hours). To achieve this, I’ve tried following approaches:

• Normal Tizen app with background-category: data given by this approach is still too fragmented, for example I got 15 minutes holes where no data was recorded at all. Sometimes there were holes even longer than 30 minutes.
• Tizen alarms API: alarms did the job in case of keeping the app alive, but with every alarm, app was brought to the front and this is not an acceptable solution. There is an option to silently wake up the app (using app control), but it does not have any callback, so all alarms would have to be scheduled upfront.
• CPU_AWAKE flag made the system show “this app is using too much energy” popup, and when not answered within 10 minutes or so, system would kill my app nonetheless.
• Web Workers - this one is only for the sake of argument, web workers are put to sleep along with the application
• Data recording: I was hoping for something similar to Apple Health Kit, but instead I got something that is not working for HRM at all. Somehow it works for PRESSURE sensor. Tizen allows to start recording for HRM but nothing is recorded after - NotFoundError: Failed to read recorded data. Any other sensor gives TypeMismatchError.
• Web Service app - this one requires partner-level certification with Samsung, also it’s affected by the background limitations, as the documentation mentions.
• Watch Face approach with “keep always on” flag set to true in device settings. This solution was the best I’ve tried. Watch face app wakes up every minute to change the time and it also receives sensor data. Unfortunately after more testing it turned out that there were couple holes in the data recorded.

About the battery: none of the above was draining the battery to a point where it became unacceptable. So first I’d like to find a solution that will give me all the sensor data I need, as frequently as possible from at least 10 hours, with no holes in it. And after that, if it turns out that this solution is draining too much battery, I will think about how to optimize it.

And now the question: is it possible to keep my application alive for 10+ hours non stop?

Answer 1

If you target the native Service App API 3.0 get the following:

device_power_request_lock(POWER_LOCK_CPU, 0);
sensor_listener_set_option(listener,  SENSOR_OPTION_ALWAYS_ON);
sensor_listener_set_attribute_int(listener, SENSOR_ATTRIBUTE_PAUSE_POLICY, SENSOR_PAUSE_NONE);

And don't forget to set a Background Category (sensor + location if needed) in the Manifest because otherwise Tizen will kill your app after ~ 10 min.

Of course hardly any of this is properly documented...

Answer 2

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.