Legato application sandboxes are chroot jails, where each application has its own unique user ID, group ID, and root directory. Files are bound into the chroot jail using bind mounts.
Access control for files is done using the underlying POSIX access control mechanisms, based on users and permissions.
See Sandboxes
Legato provides string manipulation functions that support UTF-8 encoding.
For now, at least, other Internationalization and localization features are left up to application developers.
Peripheral device power management is generally taken care of by the device drivers and the operating system. For example, if a device is not in use, the driver will automatically keep that device in its lowest power state.
Of course, application behaviour drives power consumption. If application code is using a peripheral device when it doesn't really need to, then power will be wasted. Power is also wasted if application code is running busy-wait loops or periodically polling for events. Instead, applications should register call-back functions to be triggered when events occur. This way application code will only run when an event occurs, rather than waking up to check for events that haven't happened. Every CPU cycle uses power, so when a power-sensitive application is woken up, it should execute as few instructions as possible before going back to sleep.
When all threads are sleeping, the operating system will reduce the CPU power state and/or memory automatically. When an event handler function returns back to the Legato event loop, it puts the thread to sleep (unless there is another event waiting). If your thread is not running the Legato event loop, to put your thread to sleep when it's not working, block your thread on poll(), select(), read(), write(), recv(), etc.
Periodic timers will wake your application up and consume power. To save power when using a periodic timer, make the timer period as long possible. Longer timer periods allow the operating system to go into deeper sleep states.
Factory calibration is different than configuration. Factory calibration settings are generally set at the factory and do not change thereafter. These settings can be read by software in the field, but cannot be written. Furthermore, even if all configuration settings are deleted and restored to defaults, the calibration data will remain untouched.
Calibration data can be accessed through the Configuration Data API, but it is not possible to write to that data unless the device is in a special "Calibration Mode".
Calibration data appears in a special branch of the configuration data tree.
Copyright (C) Sierra Wireless, Inc. 2014. Use of this work is subject to license.