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:


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:

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:

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:

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:

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:

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:

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: