Guides

Apertis is meant as a very flexible baseline to base a variety of different product and product types. This flexibility not only in the software selection used, but also in the hardware platforms, boards and features. As Apertis aims to cater to a variety of use-cases and hardware platforms (with each platform providing its own balance of performance and features), developers are free to pick the hardware platform that provides the best match to their requirements. [Read More]

The process of getting from source code to an image suitable for loading into a target device with Apertis is a clearly defined multi-step process. The initial step is to build the source and package the resulting artefacts into .deb packages. For the vast majority of packages this is already done and provided by Apertis in the package repositories. This page will not cover this step of the process an will assume all required packages have been successfully built and are available in the package repositories. [Read More]

This guide will explore a number of workflows for retrieving, patching, building and packaging the Apertis kernel. This guide will suggest workflows both utilising the Debian infrastructure on which Apertis is built and a workflow that eschews the Debian infrastructure and thus is usable by third party integrators who may need access to a patched kernel tree for integration, but who’s workflow would make using the Apertis infrastructure difficult. This document is targeted towards development of Apertis and where possible, we would strongly advise using the Apertis SDK image and the Debian tooling provided for it, as this workflow will be more efficient (“option 1” where present). [Read More]

While Apertis is focussed on providing a full infotainment system, including HMI, there are potential use-cases for a much smaller and scaled down variation of Apertis. One such use-case is to use Apertis purely to bridge between the internal car systems and the wider internet, in such a situation Apertis would only be used to run Agents which connect to web and other online services and relay information received from those systems to the other in-car systems. [Read More]

Design Linux PStore and Ramoops modules allow to use memory to pass data from the dying breath of a crashing kernel to its successor. This can be read from Linux after restart, or for hardware using U-Boot directly from the U-Boot command line. PStore PStore is a generic interface to platform dependent persistent storage. Platforms that provide a mechanism to preserve some data across system reboots can register with this driver to provide a generic interface to show records captured in the dying moments. [Read More]

This page describes some general API design principles which are useful to bear in mind when designing APIs (whether those APIs are for C, C++, JavaScript, D-Bus, or something else). Summary API designs must make sense from the point of view of a third-party app developer (start by designing high-level APIs, only add daemons if it is necessary) Interfaces that don’t have to be API should not be API (minimize surface area) Follow GNOME/GObject conventions, so that we get JavaScript bindings automatically Use existing frameworks where we can; if we can’t use them directly, learn from their design Identify privilege boundaries, do not trust less-privileged components, and consider whether some features should be restricted Minimize “surface area” The “SDK API” is intended to remain stable/compatible over time, which means that we are committing to interfaces in the “SDK API” continuing to work in future: third-party code that uses stable Apertis APIs should continue to work in future, without needing changes. [Read More]

Logging debug and informational output from libraries and programs is an open problem, and there are various methods for converting multiple streams of log output into the customary stdout and stderr streams. Below are some suggestions for how to implement logging. However, the most important thing is to ensure that logging is consistent, so that log data can be accessed and searched with a minimum of effort, since that’s what it’s used for. [Read More]

The layout and basic structure of a project’s source directory needs to be done when the project is created. If done well, with thought put into future maintainability and scalability of the build system, little maintenance time will be required on the build system in future. Summary Follow the standard root directory layout so users of the project can find information where they expect. (Root directory layout) Ensure the project and each source code file is clearly licenced. [Read More]

The process for contributing code to Apertis is the same as for many other open source projects: check out the code, make changes locally, then submit them for review and merging. Apertis uses its GitLab instance as a code repository and review tool. This guide assumes good working knowledge of git (see Version control for specific guidelines) and an account with commit rights on GitLab (see Getting commit rights for guidance). [Read More]

Packaging in Apertis is handled through a set of git repositories hosted on GitLab containing the sources for every package. GitLab CI pipelines take care of propagating updates to OBS to build and publish the resulting binaries. For an overview of the broader Apertis workflow see The Apertis Workflow. More detail on the steps required to add and maintain packages can be found in Adding and Updating Components. Repository contents The packaging git repositories follow the DEP-14 Git layout specification. [Read More]