Yes, you're right that the device will not sleep.
Consider using Job scheduler API or Alarm API for periodic job in background.
It will allow the device to sleep and wake up based on the schedule.
-----Original Message-----
From: Application-dev <application-dev-boun...@lists.tizen.org> On Behalf Of
Luzian Scherrer
Sent: Thursday, December 3, 2020 10:37 PM
To: application-dev@lists.tizen.org
Subject: [Tizen Application-dev] Periodic deterministic execution time without
requiring a power lock
Hello Tizen Developer Community,
I'm working on a Tizen Native API app for wearables and I would like to get
some advice.
The project consists of a service that is constantly running in background. It
is listening and sending bluetooth data (using bt_adapter_le_start_scan() and
bt_adapter_le_start_advertising_new() running constantly) and is periodically
sending a few KB of data to a server using HTTPS. I call the latter a heartbeat
because it is also used to determine from a centralised server if the device is
still operational (battery ok, connection ok, etc).
In order to have a deterministic heartbeat I use the following logic:
device_power_request_lock(POWER_LOCK_CPU, 0);
ecore_init()
ecore_timer_add(201, ecore_tick_wrapper, NULL);
...
Eina_Bool ecore_tick_wrapper(void *data) {
tick();
return ECORE_CALLBACK_RENEW;
}
...
The tick() function determines if a heartbeat is required by checking the last
time is has been able to send one. Currently that is set to 10 minutes.
This is all working very well and reliably. On the recent Galaxy Watches that
are running in standalone mode (ie no phone paired) and transmitting data via
WiFi I get around 20 to 25 hours of battery lifetime using that method. The
problem arises when I run the software on LTE models. On the LTE models,
battery lifetime drops drastically down to only 10 hours using the very same
logic. To my current understanding this is because the device is not going into
sleep mode.
I am currently thinking about the following strategies:
A) Omitting the device_power_request_lock(POWER_LOCK_CPU, 0) with the downside
of not having a deterministic tick() anymore. It is not required to happen
exactly every X seconds, but I need to be certain that it happens at least at
interval Y. Y should not be lower than one hour.
B) Bind the tick() to some kind of event/callback that is happening
periodically, preferably at a time when the device is awake and ready to send
network data anyway.
C) Instead of triggering the tick() on the devices, use the Push API to trigger
it from the server. The downside of this is that it requires a more complex
infrastructure.
My question is: which approach would you recommend? Is it one of the three
mentioned above or are there other good strategies for this problem? Or am I
following the wrong lead because the bluetooth scanning and advertising
prevents the sleep mode anyway?
Thank you very much!
-Luzian
_______________________________________________
Application-dev mailing list
Application-dev@lists.tizen.org
https://protect2.fireeye.com/v1/url?k=56243804-09bf0108-5625b34b-000babff3563-eee3e6050d2ed1da&q=1&e=bfa7c9c1-820a-4fa3-ae44-d0dcbb9fd69c&u=https%3A%2F%2Flists.tizen.org%2Flistinfo%2Fapplication-dev
_______________________________________________
Application-dev mailing list
Application-dev@lists.tizen.org
https://lists.tizen.org/listinfo/application-dev
