Architecture

Packages automatically generate debug symbol packages at build time, the packages have the package name extension -dbgsym. Infrastructure To be able to benefit from dbgsym packages, the infrastructure must be ready for them, the requirements are: reprepro: must support dbgsym since 4.17.0 debhelper: with dbgsym support since 9.20160114 dpkg-dev: support for dbgsym since 1.18.2~ When building packages with those tools, automatic debug symbols will be generated for all built packages. [Read More]

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]

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]

This page describes design patterns that can be used for inter-process communication, particularly between applications and background services 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]

Apertis uses Wayland as protocol for graphics servers, which provides a very mature and much simpler architecture than X11. The architecture is explained in Wayland compositors, however, since Wayland is just a core protocol, with some extensions defined in Wayland Protocols several different implementation can be found. Currently Apertis uses agl-compositor, an AGL project to provide a simple compositor targeted to the automotive industry based on libweston, while older releases ship mildenhall-compositor which is a Mutter based compositor. [Read More]

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]

Flatpak is a sandboxed Linux application package manager, allowing individual applications to maintain a degree of isolation from the host system and libraries. This document describes Flatpak’s core architecture and trade-offs, with a focus on the embedded use case. Core Concepts Applications packaged via Flatpak are run in a sandboxed environment that is independent from the host system, i.e. the rootfs that they see is not the host’s and will have an independent set of libraries. [Read More]