By GO U

23 Jan 2018 05:17 English 6 Replies

Hi. I'm developing a wearable service app which has infinite while loop for timing-critical job.

Psuedo code of my app is here:

void tickThread(void *data, Ecore_Thread *thread)
{
 while(1){
  doJobs();
  sleep(1);
 }
}

bool service_app_create(void *data)
{
 ecore_thread_run(tickThread, NULL, NULL, NULL);
 return true;
}

However, sometimes, doJobs() is never called or be delayed.

In my guess, Tizen platform seems to kill or halt the thread in the service apps, but I want to get clear answer.

If so, how can I avoid this restriction to develop the timing-critical service app?

P.S. "auto restart" property in the tizen-manifest.xml is true, but I can not certain that it works properly. Does it require partner privilege?

Edited on 23 01, 2018

Responses

6 Replies

Armaan-Ul- Islam

24 Jan 2018 10:39

As far as I Know, Yes.

Tizen Release Note specifies:

Restricting CPU resources for background application processes has been enhanced

Restricting CPU resources for background application processes has been added according to the background categories that are specified in the application manifest.

https://developer.tizen.org/development/tools/download/release-notes/2.4-oct-22-2015

(Check the System FW & Application FW Section)

In tizen-manifest.xml you can specify why your app requires 'not be killed' by adding a Background Category. Hope that may reduce halting/killing.

tizen-manifest.xml > 'Advanced' Tab > Background Category > +

Reply to this post
Mark as answer

GO U

25 Jan 2018 12:07

Thanks, but following points are confusing me.

1. This issue can be reproduced on Tizen 2.3.2(Gear S2) also, So IMHO, new feature of Tizen 2.4 seems not related with this issue. Furthermore, there are no Tizen 2.4 wearable profile!

2. As I said, my target platform version is Tizen 2.3.2, and tizen-manifest.xml file in Tizen 2.3.2 template does not contain "Background Category" property. So unfortunately, I don't think it can help me :(

Ans as I checked the dlog message, APP IS NOT KILLED by platform, but the function "doJobs()" is not called every second in some cases. I tested ecore timer also instead of infinite while loop, but result was same.

It is just my guess, but this issue is reproduced when I was walking and the S Health app counts my step. Can it disturb my service app? I can not understand the cause of this problem at all :(

Reply to this post
Mark as answer

GEUNSOO KIM

25 Jan 2018 05:18

the Tizen platform, especially wearable devices, puts your app into sleep mode after a time period no matter what you do in your app unless your app is foreground and there is user action.

To avoid this you have 2 options.

1. keep on CPU awake all the time. But it will consume battery very fast.

2. If you are using the routine in periodic manner, use alarm to wake your app up. (alarm, not timer. timer routine is not working for this situation..)

But it seems that Samsung don't want for 3rd parties to make these kind of code.. they is gonna adding more restrictions on next version I think..

Reply to this post
Mark as answer

GO U

25 Jan 2018 02:18

Thanks! Now I can understand why it happened. However, I still have some detail questions.

1. Can I ask some tricks for keeping the CPU awake?

2. Purpose of my code is making the noti at every hour. So I think that alarm can be helpful, but I wonder that this action can be restricted to 3rd party developers or not.

3. Can I find some documents about app lifecycle management policy of Tizen platform? My app is switched to the sleep state or restored without explicit reason. It is very chaotic :(

Reply to this post
Mark as answer

GEUNSOO KIM

25 Jan 2018 02:53

1. you an use device_power_request_lock() and device_power_release_lock() API. you need to set privilege "http://tizen.org/privilege/display" to use the APIs.

But not recommended due to the battery consumption.

2. if you are using 1 hour interval then it should be OK to use alarm. on the higher version of Tizen (like 3.0 or 4.0), the minimum interval is going to be 10 minutes, which is there is no restriction yet on 2.3.x. And for the operation of the alarm, you'd better use "APP_CONTROL_OPERATION_MAIN" rather than "APP_CONTROL_OPERATION_DEFAULT". I cannot remember that it is required on native app or not. But in case of web app, "APP_CONTROL_OPERATION_DEFAULT" operation makes restart the app even if the app is already running. And when you use alarm, it will be launched if the app is not running, so you maybe needed to save your app context before your app dead to sync between previous/next instance.

3. Well.. I cannot sure there is any document about it. I acquired this info with trial and error... -_-

good luck.