Foreword¶

AGL has worked at providing the components of an application framework for many years. However, the implementation used up until the lamprey release was retired starting with the marlin release, and replaced with a redesigned one. However, this new implementation does not aim to be a 1:1 replacement, and as such it does not provide all of the features of the previous framework. Some of those will be added back over time, while others have been discarded in favor of more modern and/or widely-used alternatives.

With the needlefish release, further evolution of the replacement framework included:

• Using gRPC IPC for the application launcher API. The interim D-Bus based API was deprecated at this time, and removed in the pike release.
• Using only systemd unit metadata in the application launcher instead of using Desktop Entry specification to list applications, and relying entirely on systemd for the application lifecycle, rather than spawning them directly.

Introduction¶

With a goal of being the provider of an integrated solution to build up on, it is useful for AGL to define a reliable and well-specified method for managing the deployment and integration of applications and services, as well as the way they can interact with the rest of the system.

This is achieved by providing a common set of rules and components, known as the application framework. By documenting those rules, application developers can have a good understanding of the requirements for creating and packaging applications targeting AGL-based systems that leverage the upstream application framework components. Likewise, system developers and integrators have a clear path for including such applications in AGL-based products.

The application framework's scope extends to the following areas:

• system services integration and lifecycle management
• user-level application lifecycle management
• inter-process communication

In order to be as simple as possible and avoid any unneeded custom implementation, the application framework relies mainly on third-party technologies and/or software components. They include:

• systemd: system services and user session services management

• gRPC: inter-process communication, new recommmended system-wide IPC, which should be used instead of D-Bus.

Note that while there are many open source software projects in the desktop Linux space using D-Bus for inter-process communication, AGL has decided to avoid using it for new development projects for the following reasons:

• It has proven challenging in the past to manage dependencies between and the start-up of system and per-user D-Bus services in AGL.
• Managing the security of D-Bus APIs involves the use of PolicyKit, which is somewhat heavyweight and not widely understood. As well, providing D-Bus access to applications running inside containers or other sandbox schemes can be significantly more complicated than e.g. using gRPC with authorization token access control.
• D-Bus is not widely used in application development ecosystems outside of desktop Linux. This matters when engaging with application developers in newer ecosystems such as web applications or Flutter.

AGL also provides reference implementations whenever possible and relevant, located in the meta-agl layer under meta-app-framework. At the moment, the application framework contains two such components:

• agl-session: systemd unit files for user sessions management
• applaunchd: application launcher service

Service Management¶

Both system and user services are managed by systemd, which provides a number of important features, such as dependency management or service monitoring: when starting a service, systemd will ensure any other units this service depends on are available, and otherwise start those dependencies. Similarly, systemd can automatically restart a crashed service, ensuring minimal downtime.

systemd also provides an efficient first layer of security through its sandboxing and other security-related options.

It is also well integrated with D-Bus and can be used for a more fine-grained control over D-Bus activated services. By delegating the actual service start-up to systemd, developers can take advantage of its advanced features, allowing for improved reliability and security.

Each service should be represented by a systemd unit file installed to the appropriate location. More details can be obtained from the Creating a New Service document.

User Session Management¶

Similarly, user sessions and the services they rely on are also managed by systemd. Prior to the pike release, AGL used a user session for the agl-driver user for the running of user facing applications, including the compositor. This has been replaced with using system units that use the User directive. The reason for this is two-fold:

• Several useful systemd sandboxing features are unavailable to user session units, or would require the use of unprivileged namespace mounting. The latter is not necessarily available in vendor BSP kernels, and the security characteristics of it are still a matter of some debate.
• Encoding dependencies between user session and system units is sometimes not straightforward or impossible.

Inter-process Communication¶

In order to provide a language-independent, "standard", IPC mechanism and avoid the need for maintaining custom bindings for each programming language to be used on top of AGL, the application framework previously promoted the use of D-Bus as the preferred way for applications to interact with services. Starting with needlefish release, this has changed to recommending gRPC for our system-wide IPC, with D-Bus being kept to provide functionality to services and applications which haven't transitioned yet to using gRPC.

Most services already included in AGL provide one or several D-Bus interfaces, and can therefore interact with D-Bus capable applications and services without requiring any additional component. Those services include, among others:

• ConnMan: network connectivity

• BlueZ: Bluetooth connectivity

• oFono: telephony and modem management

• GeoClue: geolocation

Similarly, ongoing work involves expanding various services to expose a gRPC interface.

Application Launcher Service¶

The Application Framework used to follow the guidelines of the Desktop Entry specification for application enumeration and start-up, but with the needlefish release instead it relies on systemd to provide that functionality, indirectly, by using the applaunchd application.

As no simple reference implementation exists for this part of the specification, AGL provides an application launcher service named applaunchd. This service is part of the default user session, and as such is automatically started on session start-up. It can therefore be considered always available.

applaunchd enumerates applications installed on the system and provides a gRPC interface for services and applications to:

• query the list of available applications
• request the start-up of a specific application
• be notified when applications are started or terminated