docs/06_Component_Documentation/Application_Framework/01_Introduction.md

   1 ---
   2 title: Introduction
   3 ---
   4
   5 # Foreword
   6
   7 AGL has worked at providing the components of an application framework for many
   8 years. However, the implementation used up until the `lamprey` release was retired
   9 starting with the `marlin` release, and replaced with a redesigned one.
  10 However, this new implementation does not aim to be a 1:1 replacement, and as such
  11 it does not provide all of the features of the previous framework. Some of those
  12 will be added back over time, while others have been discarded in favor of more
  13 modern and/or widely-used alternatives.
  14
  15 With the `needlefish` release, further evolution of the replacement framework included:
  16
  17 - Using [gRPC IPC](https://grpc.io/about) for the application launcher API.
  18   The interim D-Bus based API was deprecated at this time, and removed in the
  19   `pike` release.
  20 - Using only systemd unit metadata in the application launcher instead of using
  21   [Desktop Entry specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)
  22   to list applications, and relying entirely on systemd for the application
  23   lifecycle, rather than spawning them directly.
  24
  25 # Introduction
  26
  27 With a goal of being the provider of an integrated solution to build up on, it
  28 is useful for AGL to define a reliable and well-specified method for managing
  29 the deployment and integration of applications and services, as well as the way
  30 they can interact with the rest of the system.
  31
  32 This is achieved by providing a common set of rules and components, known as
  33 the application framework. By documenting those rules, application developers can
  34 have a good understanding of the requirements for creating and packaging applications
  35 targeting AGL-based systems that leverage the upstream application framework components.
  36 Likewise, system developers and integrators have a clear path for including such
  37 applications in AGL-based products.
  38
  39 The application framework's scope extends to the following areas:
  40
  41 - system services integration and lifecycle management
  42 - user-level application lifecycle management
  43 - inter-process communication
  44
  45 In order to be as simple as possible and avoid any unneeded custom
  46 implementation, the application framework relies mainly on third-party
  47 technologies and/or software components. They include:
  48
  49 - [systemd](https://www.freedesktop.org/wiki/Software/systemd/): system
  50   services and user session services management
  51
  52 - [gRPC](https://grpc.io/about): inter-process communication, new recommmended
  53   system-wide IPC, which should be used instead of D-Bus.
  54
  55 Note that while there are many open source software projects in the desktop Linux
  56 space using [D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) for inter-process
  57 communication, AGL has decided to avoid using it for new development projects for the
  58 following reasons:
  59
  60 - It has proven challenging in the past to manage dependencies between and the
  61   start-up of system and per-user D-Bus services in AGL.
  62 - Managing the security of D-Bus APIs involves the use of PolicyKit, which is
  63   somewhat heavyweight and not widely understood. As well, providing D-Bus
  64   access to applications running inside containers or other sandbox schemes can
  65   be significantly more complicated than e.g. using gRPC with authorization token
  66   access control.
  67 - D-Bus is not widely used in application development ecosystems outside of desktop
  68   Linux. This matters when engaging with application developers in newer ecosystems
  69   such as web applications or Flutter.
  70
  71 AGL also provides reference implementations whenever possible and relevant,
  72 located in the [meta-agl](../../04_Developer_Guides/02_AGL_Layers/02_meta_agl.md)
  73 layer under `meta-app-framework`. At the moment, the application framework
  74 contains two such components:
  75
  76 - `agl-session`: `systemd` unit files for user sessions management
  77 - `applaunchd`: application launcher service
  78
  79 # Service Management
  80
  81 Both system and user services are managed by `systemd`, which provides a number
  82 of important features, such as dependency management or service monitoring:
  83 when starting a service, `systemd` will ensure any other units this service
  84 depends on are available, and otherwise start those dependencies. Similarly,
  85 `systemd` can automatically restart a crashed service, ensuring minimal
  86 downtime.
  87
  88 `systemd` also provides an efficient first layer of security through its
  89 [sandboxing](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing)
  90 and other security-related options.
  91
  92 It is also well integrated with D-Bus and can be used for a more fine-grained
  93 control over D-Bus activated services.  By delegating the actual service start-up
  94 to `systemd`, developers can take advantage of its advanced features, allowing
  95 for improved reliability and security.
  96
  97 Each service should be represented by a `systemd` unit file installed to the
  98 appropriate location. More details can be obtained from the [Creating a New
  99 Service](../../04_Developer_Guides/03_Creating_a_New_Service.md) document.
 100
 101 # User Session Management
 102
 103 Similarly, user sessions and the services they rely on are also managed by
 104 `systemd`.  Prior to the `pike` release, AGL used a user session for the
 105 `agl-driver` user for the running of user facing applications, including the
 106 compositor. This has been replaced with using system units that use the
 107 `User` directive. The reason for this is two-fold:
 108
 109 - Several useful systemd sandboxing features are unavailable to user session
 110   units, or would require the use of unprivileged namespace mounting.  The
 111   latter is not necessarily available in vendor BSP kernels, and the security
 112   characteristics of it are still a matter of some debate.
 113 - Encoding dependencies between user session and system units is sometimes
 114   not straightforward or impossible.
 115
 116 # Inter-process Communication
 117
 118 In order to provide a language-independent, "standard", IPC mechanism and avoid
 119 the need for maintaining custom bindings for each programming language to be
 120 used on top of AGL, the application framework previously promoted the use of
 121 [D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) as the preferred way
 122 for applications to interact with services. Starting with `needlefish` release,
 123 this has changed to recommending [gRPC](https://grpc.io) for our system-wide IPC,
 124 with D-Bus being kept to provide functionality to services and applications
 125 which haven't transitioned yet to using gRPC.
 126
 127 Most services already included in AGL provide one or several D-Bus interfaces,
 128 and can therefore interact with D-Bus capable applications and services
 129 without requiring any additional component. Those services include, among
 130 others:
 131
 132 - [ConnMan](https://git.kernel.org/pub/scm/network/connman/connman.git/):
 133   network connectivity
 134
 135 - [BlueZ](http://www.bluez.org/): Bluetooth connectivity
 136
 137 - [oFono](https://git.kernel.org/pub/scm/network/ofono/ofono.git): telephony
 138   and modem management
 139
 140 - [GeoClue](https://gitlab.freedesktop.org/geoclue/geoclue/-/wikis/home):
 141   geolocation
 142
 143 Similarly, ongoing work involves expanding various services to expose a
 144 gRPC interface.
 145
 146 # Application Launcher Service
 147
 148 The Application Framework used to follow the guidelines of the [Desktop Entry
 149 specification](https://www.freedesktop.org/wiki/Specifications/desktop-entry-spec/)
 150 for application enumeration and start-up, but with the `needlefish` release
 151 instead it relies on systemd to provide that functionality, indirectly, by
 152 using the `applaunchd` application.
 153
 154 As no simple reference implementation exists for this part of the
 155 specification, AGL provides an application launcher service named `applaunchd`.
 156 This service is part of the default user session, and as such is automatically
 157 started on session start-up. It can therefore be considered always available.
 158
 159 `applaunchd` enumerates applications installed on the system and provides a
 160 gRPC interface for services and applications to:
 161
 162 - query the list of available applications
 163 - request the start-up of a specific application
 164 - be notified when applications are started or terminated