Test Data Reporting

Background Testing is a fundamental part of the project, but it is not so useful unless it goes along with an accurate and convenient model to report the results of such a testing. Receiving notifications on time about critical issues, easily checking tests results, or analyzing tests trends among different images versions are some of the examples of test reporting that helps to keep a project in a good state through its different phases of development. [Read More]

Test Data Storage

Background Testing is a core part of the project, and different test data is required to optimise the testing process. Currently the project does not have a functional and well defined place for storage of the different types of test data, which creates many issues across the testing processes. The goal of this document is to define a single storage place for all the test data and build on top it the foundation for accurate test data processing and reporting. [Read More]

Build infrastructure on Intel x86-64

Build infrastructure on Intel x86-64 Introduction The current Apertis infrastructure is largely made of hosts based on the Intel x86-64 architecture, often using virtualized machines. The only exceptions are: OBS workers used to build packages natively for the ARM 32 bit and ARM 64 bit architectures LAVA workers, which match the reference hardware platforms While LAVA workers are by nature meant to be hosted separatedly from the rest of the infrastructure and are handled via geographically distributed LAVA dispatchers, the constraint on the OBS workers is problematic for adopters that want to host a downstream Apertis infrastructure. [Read More]

Infrastructure maintenance automation

Infrastructure maintenance automation Introduction 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 infratructure 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]

Permissions

Permissions Introduction 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]

List design

List design The goal of this list design document is to establish an appropriate architecture and API design for the list widgets in the Apertis platform. Historically, the roller widget has provided a list widget on a cylinder with no conceptual beginning or end and is manipulated naturally by the user. For non-cylindrical lists there was a separate widget with a different API and different usage. The goal is to consolidate list operations into a base class and be able to use the same simple API to use both cylindrical lists and non-cylindrical lists. [Read More]

Audio management

Audio management Introduction 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. [Read More]

Web portal caching

Web portal caching Introduction 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

Application entry points 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 layout

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. 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]