This section provides documentation covering the implementation goals and strategies taken to enable features or functionality in Apertis.

For more detailed guidance on implementing or using specific functionality, please refer to the guides.

Structure of an Apertis application

This documentation is written against version 16.12 of Apertis. This guide describes creating an agent using the Canterbury legacy application framework. This framework is deprecated and therefore not recommended for new development. The application generated by the wizard is a set of resources installed as a single unit. It is referred to as a bundle. The app bundle can include open source / proprietary libraries, agents and GUI programs. [Read More]

Platform APIs and Services

Apertis follows an app-centric architecture. This means that the development is more vertical and not layered as in automotive domain. This reduces dependency and leads to less time to market. SDK is designed to make app development fast and easy while maintaining backward compatibility. The system gets upgraded periodically; however the applications should not be affected. This is achieved by writing apps against SDK APIs. The SDK APIs are ensured to maintained backward compatibility. [Read More]

Boot Process

Apertis has a fairly typical Linux boot process: A platform specific bootloader performs initial low-level configuration of the system The Linux kernel performs higher level configuration and creates a standardised environment The kernel passes execution to the user space which enables services based on the functionality provided by the kernel and sets up the system to accept user input Critical sequences during startup The phases during startup generally proceed from most- to least-critical. [Read More]

Data sharing

This page describes design patterns that can be used for inter-process communication, particularly between applications and agents in the same or different app-bundles. We consider a situation in which one or more consumers receive information from one or more providers; we refer to the consumer and provider together as peers. Use cases Points of interest should use one of these patterns Sharing could use one of these patterns Global search (see ConceptDesigns) currently carries out the equivalent of interface discovery by reading the manifest directly, but other than that it is similar to Query-based access via D-Bus Selecting an initiator The first design question is which peer should initiate the connection (the initiator) and which one should not (the responder). [Read More]

Power Loss Robustness

In order to test that Apertis is capable of handling power loss, the tests from from GLib test suite to ensure that the robustness features built into these libraries can be verified to be working. GLib/GIO The GIO library within GLib is the standard way to do file handling, I/O, etc. It also has a set of functional tests for all the features provided by the library. Out of these, the subset of GIO tests that deal with local I/O have been integrated into the image testing. [Read More]

Multimedia Buffering

Various improvements to both Gstreamer and clutter-gst 3.0 have been incorporated in Apertis and upstream. Multimedia buffering strategies For playback of network streams typically some buffering has to be used to ensure playback without any pauses, stuttering or other glitches. Broadly speaking two types of buffering strategies are used, both of which serve slightly different use-cases: Stream buffering Progressive buffering Progressive buffering Progressive buffering (download buffering in the clutter API) is the buffering strategy most people are used to from e. [Read More]