The concept designs are a set of technical documents covering many aspects of the project, written through the history of the project, taking into account the status of the project at that time. These documents cover topics that have been researched but not necessarily implemented in Apertis at the time of writing.

Information in these documents may be outdated, but nonetheless provide important context for the decision making process and overall vision of the project.

Security

This document discusses and details solutions for the security requirements of the Apertis system. Security boundaries and threat model describes the various aspects of the security model, and the threat model for each. Local attacks to obtain private data or damage the system, including those performed by malicious applications that get installed in the device somehow or through exploiting a vulnerable application are covered in Mandatory access control (MAC). It is also the main line of defense against malicious email attachments and web content, and for minimizing the damage that root is able to do are also mainly covered by the MAC infrastructure. [Read More]

Sensors and actuators

This documents possible approaches to designing an API for exposing vehicle sensor information and allowing interaction with actuators to application bundles on an Apertis system. The major considerations with a sensors and actuators API are: Bandwidth and latency of sensor data such as that from parking cameras Enumeration of sensors and actuators Support for multiple vehicles or accessories Support for third-party and OEM accessories and customisations Multiplexing of access to sensors [Read More]

Supported API

The goal of this document is to explain the relevant issues around API (Application Programming Interface) and ABI (Application Binary Interface) stability and to make explicit the APIs and ABIs that can be and will be guaranteed to be available in the platform for application development. It will be explained as well how we are going to deal with situations where certain components break their API/ABI. New releases and API stability Software systems are typically composed of several components with some depending on others. [Read More]

System updates and rollback

This document focuses on the system update mechanism, but also partly addresses applications and how they interact with it. Definitions Base OS The core components of the operating system that are used by almost all Apertis users. Hardware control, resource management, service life cycle monitoring, networking Applications Components that work on top of the base OS and are specific to certain usages. Use cases A variety of use cases for system updates and rollback are given below. [Read More]

Text To Speech

Text To Speech Introduction This documents possible approaches to designing an API for text to speech (TTS) services for an Apertis system in a vehicle. This document proposes an API for the text to speech service in Appendix: A suggested TTS API. This API is not finalised, and is merely a suggestion. It may be refined in future versions of this document, or when implementation is started. The major considerations with a TTS API are: [Read More]

UI customisation

Introduction The goal of this user interface customisation design document is to reduce app development time when porting between variants by abstracting the differences between variants into a UI library. The goal of standardising this process is reduce the amount of code written or changed in customising a variant. It is understood that for system components, code might have to be altered for some requests, but code inside application bundles should remain as similar as possible and work in variant-specific ways automatically. [Read More]

Conditional Access

App-store curators and ISVs often impose technical restrictions on applications (and other content, such as themes) so that they can only be used by a user who has purchased the application, or on a device for which a license has been purchased. This design is intended to address this topic. Assumptions Identification Store account ID For the purposes of this design, we assume that the owner(s) of the vehicle has/have access to at least one store account. [Read More]

Compositor security

The compositor is the component of Apertis that is responsible for drawing application windows and other graphical elements on the screen. In Apertis the compositor runs as the agl-compositor executable from a systemd user unit and launches maynard as desktop manager. This is a thin executable wrapper around the library libweston, which provides the majority of its functionality. In Wayland, the compositor is the display server. Graphical programs arrange for their graphics to be displayed by creating a buffer (a surface) in GPU memory, drawing their text, images etc. [Read More]

Egress filtering

This way to the egress! — attributed to P. T. Barnum An application that handles confidential data might have a security vulnerability that leads to it becoming controlled by an attacker. This design aims to mitigate such attacks. Assumptions We assume that the user has some confidential data (for example the contents of their address book), accessible to a particular application bundle, and that an attacker’s goal is to gain access to that confidential data. [Read More]

Content hand-over

Content handover is when an application is asked by the user to open a file it doesn’t know how to handle or to start a service it is not responsible for providing. For example, a browser just finished downloading an epub file and the user now wants to open it. The browser will ask the system to start the application responsible for dealing with that file. Another example would be a map application in which the user located a destination and now wants to navigate. [Read More]