Guides

The Apertis Toolchain provides a build environment to build Apertis for a foreign architecture from an operating system that is not Apertis. The toolchain is intended for cross-compilation, targeting architectures that don’t match the CPU architecture of the build host (for instance, building ARM64 binaries from a Intel-based host). Currently Apertis provides toolchain for two architectures : 32 bits ARM (armhf) 64 bits ARM (AArch64) It is meant to be used by teams that want to keep their development tools such as their preferred editor. [Read More]

The guide will explain the process of modifying and packaging a custom kernel to be used within Apertis. Apertis is provided with a number of pre-built kernels, however it is likely that these may not suit your purpose: The kernels don’t have the support for your SoC enabled You wish to enable some specific drivers that aren’t enabled in the standard build You have out-of-tree board support or drivers that you need to add You wish to incorporate more drivers directly into the kernel rather than loading them as modules In order to meet your project goals, it may be necessary to create a project specific kernel package for use in your project. [Read More]

With the 18.03 release of Apertis, a new set of images have appeared. Apertis is now delivered in two variants: apt images and OSTree images. OSTree provides Apertis with an atomic update solution, which is able to work in containers and flash-specific file systems like UBIFS. OSTree uses an efficient mechanism to package updates, thus resulting in small downloads. The standard images are a debian derivative. The OSTree images are prefixed apertis_ostree. [Read More]

Apertis provides tools, pre-installed in the Apertis SDK, for the purpose of downloading and interacting with sysroots. These tools are pre-installed in the Apertis SDK. The SDK images shipped by Apertis are meant to be run in VirtualBox. They provide a common, reproducible environment to build both platform packages and application-bundles for Apertis. The tool provides general manual pages so you can get command information by using man ade on the SDK. [Read More]

This document aims to explain how to develop on devices running the reference Apertis images. Which image to choose The APT-based fixedfunction and hmi images are the ones providing all the flexibility needed for development, letting developers install and remove packages, and otherwise customize the rootfs. The OSTree-based images are tailored as a reference for product deployments: their constraints make installing and removing packages impossible, and the more care must be taken to get write access to the rootfs managed by OSTree. [Read More]

Apertis is moving to a WebView widget and browser based on WebKit2GTK+. The purpose of this migration is to take advantage of the new WebKit2 multi-process architecture, adopt a port that is upstream and that is based on a more future-proof toolkit. Packages for testing and using the API The engine is available in Apertis on the webkit2gtk source package. To test it on a development or SDK image, install the webkit2gtk-testing package and run /usr/bin/GtkClutterLauncher. [Read More]

Git is used for version control for all Apertis projects. This page assumes good working knowledge of git; some introductory material is available here, and a git cheatsheet is here. Summary Make atomic, revertable commits. (Guidelines for making commits) Include full reasoning in commit messages, plus links to relevant bug reports or specifications. (Guidelines for making commits) Keep large changes, such as renames, in separate commits. (Guidelines for making commits) Merge changes from feature branches by rebasing. [Read More]

There are a few anti-patterns to consider when accessing the filesystem. This article assumes knowledge of the standard GFile, GInputStream and GOutputStream APIs. Summary Always use asynchronous I/O for file access. Always use appropriate functions to construct file names and paths. Validate file paths to ensure expected results before using them. Use AppArmor profiles to enforce constraints on file access. Asynchronous I/O All I/O should be performed asynchronously. That is, without blocking the GLib main context. [Read More]

GSettings is a GLib API for storing persistent application settings (but not large amounts of data or user documents). It is the successor to GConf, and is similar in use to the Windows Registry. GSettings is used by Apertis for application preferences and configuration data. Its main advantages over databases or configuration files are its support for structured data (using GVariant), and its fast reads. It has good integration with GObject, with powerful features such as binding to object properties with g_settings_bind(). [Read More]

GObject introspection (abbreviated ‘GIR’) is the system which Apertis uses to extract APIs from C code and produces binary type libraries which can be used by non-C language bindings, and other tools, to introspect or wrap the original C libraries. It uses a system of annotations in documentation comments in the C code to expose extra information about the APIs which is not machine readable from the code itself. It should be enabled for all public APIs: so all libraries. [Read More]