Concept Designs

As a platform, Apertis needs a vibrant ecosystem to thrive, and one of the foundations of such ecosystem is being friendly to application developers and product teams. Product teams and application developers are more likely to choose Apertis if it offers flows for building, shipping, and updating applications that are convenient, cheap, and that require low maintenance. To reach that goal, a key guideline is to closely align to upstream solutions that address those needs and integrate them into Apertis, to provide to application authors a framework that is made of proven, stable, complete, and well documented components. [Read More]

Immutable root filesystems have several security and maintainability advantages, and avoiding changes to them increases the value of testing as the system under test would closely match the production setup. This is fundamental for setups that don’t have the ability to install packages at runtime, like OSTree-based deployments, but it’s largely beneficial for package based setups as well. To achieve that, tests should then ship their own dependencies in a self-contained way and not rely on package installation at runtime. [Read More]

This document describes the goals and the approaches for automating the management of the infrastructure used by Apertis. It will focus in particular on release branching since the new release flow implies that Apertis will need to go through that process two or three times more than in the past on each quarter. Goals Data-driven Separating the description of the desired infrastructure state from the tools to apply it nicely separates the two concerns: in most cases the tools won’t need to be updated during branching, only the desired infrastructure state changes. [Read More]

Apertis is a mature platform that is compatible with modern and flexible solutions for software distribution and software update. This document describes user-driven and operator-driven use cases, explores the challenges of each use case to extract requirements, and finally propose building blocks for software distribution and software update. Terminology Application and services Application and services are loosely defined terms that indicate single functional entities from the perspective of end users. However each application may be composed of more than one component: [Read More]

This document extends the higher-level Applications and Security design documents to go into more detail about the permissions framework. Applications can perform many functions on a variety of user data. They may access interfaces that read data (such as contacts, network state, or the users location), write data, or perform actions that can cost the user money (like sending SMS). As an example, the Android operating system has a comprehensive manifest that govern access to a wide array of functionality. [Read More]

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]

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]

Requirements 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 a user service that starts during device startup a user service that is started on-demand Desktop environments provide metadata about these programs so that they can be launched. [Read More]

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. The Apertis Application Bundle Specification describes the files that can appear in an application bundle and are expected to remain supported long-term. [Read More]

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]