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.
Apertis audio management was previously built around PulseAudio but with the move to the Flatpak-based application framework PipeWire offers a better match for the use-cases below. Compared to PulseAudio, PipeWire natively supports containerized applications and keeps policy management separate from the core routing system, making it much easier to tailor for specific products.
Applications can use PipeWire through its native API, as the final layer to access sound features. This does not mean that applications have to deal directly with PipeWire: applications can still make use of their preferred sound APIs as intermediate layers for manipulating audio streams, with support being available for the PulseAudio API, for GStreamer or for the ALSA API.
[Read More]
Web portal caching
The purpose of this document is to evaluate the available strategies to implement a custom, single-purpose browser restricted to a single portal website that hosts several HTML/JS applications.
The portal and the visited applications should be available even if no Internet connection is available.
If a connection to the Internet is available, the locally-stored contents should be refreshed.
Locally-stored copies should be used to speed up loading even when the connection to the Internet is available.
[Read More]
Application entry points
Requirements Flatpak application bundles may contain application entry points, which are any of these things:
a graphical program that would normally appear in a menu a graphical program that would not normally appear in a menu, but can be launched in some other way, for example as a content-type handler Desktop environments provide metadata about these programs so that they can be launched.
At least the following use-cases exist:
It must be possible to translate the name into multiple languages, with a default (international English) name used for languages where there is no specific translation.
[Read More]
Application layout
Application bundles in the Apertis system may require several categories of storage, and to be able to write correct AppArmor profiles, we need to be able to restrict each of those categories of storage to a known directory.
This document is intended to update and partially supersede discussions of storage locations in theapplications andsystem updates and rollback design documents.
This document describes and provides rationale for the layout of and file types within an application bundle, suggested future directions, and details of functionality that is not necessarily long-term stable.
[Read More]
Application bundle metadata
This document extends the Apertis Applications concept design to cover metadata about application bundles (app-bundles).
Terminology and concepts See the Apertis glossary for background information on terminology. Apertis-specific jargon terms used in this document are hyperlinked to that glossary.
Use cases These use-cases are not exhaustive: we anticipate that other uses will be found for per-application-bundle metadata. At the time of writing, this document concentrates on use-cases associated with assigning priorities to requests from an app-bundle to a platform service.
[Read More]
Hard keys
Definition Hardkeys: Also known as Hardware keys; Any controls in the car system connected to the Head unit. Examples of hardkeys are volume controls, fixed function buttons (back, forward, home screen, play pause), rotary controls etc.
Traditionally hardkeys referred only to physical controls (e.g. switches, rotary dails etc), hence hardware keys. But current systems are far more flexible and due to that this design can also refer to software buttons rendered by the system UI outside of the applications control or touch sensitive areas with software controlled functionality.
[Read More]
Applications
This document is intended to give a high-level overview of application handling by Apertis. Topics handled include the storage of applications and related data on the device, how they’re integrated into the system, and how the system manages them at run-time. Topics related to the development of applications are covered by several other designs.
Unfortunately, the term “application” has seen a lot of misuse in recent times. While many mobile devices have an “application store” that distributes “application packages”, what is actually in one of those packages may not fit any sensible definition of an application – as an example, on the Nokia N9 one can download a package from the application store that adds MSN Messenger capabilities to the existing chat application.
[Read More]
Connectivity
Network management is the task of managing the access to networks. In other words, deciding when and through which means to connect to the internet. In an IVI context this task is affected by several conflicting requirements. Connectivity may be spotty at times, with tunnels, high speed causing WiFi networks to come and go quickly, low cell phone signal strength, and so on. On the other hand, potentially good connectivity while parked, since the user might have high quality WiFi at the office and at home.
[Read More]
Contacts
This document outlines our design for address book contacts within the Apertis system. It describes the many sources the system can draw upon for the user’s contacts, how it will manage those contacts, which components will be necessary, and what work will be needed in the middleware space to enable these features.
Contacts are representations of people that contain some details about that person. These details are often directly actionable: phone numbers can be called, street addresses may be used as destinations for the navigation system.
[Read More]
Debug and logging
This documents several approaches to debugging components of an Apertis system, either during development, or in the field. This includes debugging tools for reproducing and analysing problems; and logging systems for gathering data about problems and about system behaviour.
The major considerations with a debugging and logging system are:
Reproducibility: Many of the hardest problems to diagnose are ones which are hard to reproduce. A set of debugging tools should make it easy to reproduce problems, and certainly should not make the problems disappear when being debugged.
[Read More]