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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
---
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.
With `needlefish` release, further changes have been added, including a gRPC
interface, alongside a D-BUs one, as well as using systemd units to start
applications.
# 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, now in deprecated phase.
- [gRPC](https://grpc.io/about): inter-process communication
- [Desktop Entry specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/):
application enumeration and startup, now in deprecated phase, systemd being
the one would list out applications and handling start-up.
AGL also provides reference implementations whenever possible and relevant,
located in the [meta-agl](/04_Developer_Guides/02_AGL_Layers/02_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](/04_Developer_Guides/02_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 used to promote the use of
[D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) as the preferred way
for applications to interact with services. Starting with `needlefish` release
we instead switched to using [gRPC](https://grpc.io) for our system-wide IPC,
with D-Bus being kept to provide functionality to services and application
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](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
The Application Framework used to follow the guidelines of the
[Desktop Entry specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)
for application enumeration and startup, but now instead relies on systemd to
provide that functionality indirectly, 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 startup. It can therefore be considered always available.
`applaunchd` enumerates applications installed on the system and provides a
D-bus (deprecated)/gRPC 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](../02_Application_Startup/).
|
