summaryrefslogtreecommitdiffstats
path: root/docs/4_Developer_Guides/1_Application_Framework/1_Introduction.md
blob: 957858a5fb0eaa28c2302c8f487798f802a42474 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
---
title: Introduction
---

# Foreword

The AGL Application Framework is nothing new. However, the implementation used up until
the `lamprey` release has been retired starting with the `marlin` release and replaced
by a redesigned Application Framework one. However, this new implementation isn't a 1:1
replacement, and as such it doesn't provide all of the features of the previous
Application Framework. Some of those will be added back over time, others have been
discarded in favor of more modern and/or widely-used alternatives.

# Introduction

As a provider of an integrated solution to build up on, AGL needs 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 ensuring conformity to those rules, application developers
can have a good understanding of the requirements for creating and packaging
applications targeting AGL-based systems. 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 session management, including user-level applications and services lifecycle
  management
- inter-process communication

In order to be as simple as possible and avoid any unneded custom implementation, the
Application Framework relies mainly on third-party technologies and/or software
components, most of those being maintained under the
[freedesktop.org](https://www.freedesktop.org) umbrella. Those include:


- [systemd](https://www.freedesktop.org/wiki/Software/systemd/): system services and user session services management


- [D-Bus](https://www.freedesktop.org/wiki/Software/dbus/): inter-process communication


- [Desktop Entry specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/):
  application enumeration and startup

AGL also provides reference implementations whenever possible and relevant, located in
the [meta-agl](/3_Developer_Guides/6_AGL_Layers/2_meta-agl/) layer under `meta-app-framework`. At the
moment, the Application Framework contains 2 such components:

- `agl-session`: `systemd` unit files for user sessions management

- `applaunchd`: application launcher service

# Services 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](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#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 startup to `systemd`,
developers can take advantage of some 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](/3_Developer_Guides/2_Creating_a_New_Service/)
document.

# User session management

Similarly, user sessions and the services they rely on are also managed by `systemd`.

AGL provides 2 `systemd` units:


1\. `agl-session@.service` is a template system service for managing user sessions; it
takes a username or UID as a parameter, creating a session for the desired user.
Instanciating this service can be achieved by enabling `agl-session@USER.service`, for
example by executing the following command on a running system:

```
$ systemctl enable agl-session@USER.service
```

By default, AGL enables this service as `agl-session@agl-driver.service`, running as
user `agl-driver`.

*Note: while you can create sessions for as many users as needed, only one instance of
`agl-session@.service` is allowed per user.*


2\. `agl-session.target` is a user target for managing user services and their
dependencies. It is started by `agl-session@.service`.

By default, `agl-compositor` is part of this target. It is therefore automatically
started for user `agl-driver`.

Any other service needed as part of the user session should similarly depend on this
target by appending the following lines to their unit file:

```
[Install]
WantedBy=agl-session.target
```

# Inter-process communication

In order to provide a "standard", language-independent IPC mechanism and avoid the need
for maintaining custom bindings for each programming language to be used on top of AGL,
the Application Framework promotes the use of [D-Bus](https://www.freedesktop.org/wiki/Software/dbus/)
as the preferred way for applications to interact with services.

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](https://git.kernel.org/pub/scm/network/connman/connman.git/): network connectivity

- [BlueZ](http://www.bluez.org/): Bluetooth connectivity

- [oFono](https://git.kernel.org/pub/scm/network/ofono/ofono.git): telephony and modem
  management

- [GeoClue](https://gitlab.freedesktop.org/geoclue/geoclue/-/wikis/home): geolocation

# Application launcher service

As mentioned above, the Application Framework follows the guidelines of the
[Desktop Entry specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)
for application enumeration and startup.

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 startup. It can
therefore be considered always available.

`applaunchd` enumerates applications installed on the system and provides a D-bus
interface for services and applications to:
- query the list of available applications
- request the startup and/or activation of a specific application
- be notified when applications are started or terminated

`applaunchd` is described with more details in [the following document](../2_Application_Startup/).