mirror of https://github.com/cutefishos/appmotor
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
73 lines
3.4 KiB
Plaintext
73 lines
3.4 KiB
Plaintext
What is applauncherd?
|
|
==============================
|
|
|
|
Applauncherd is a daemon that helps to launch applications faster by
|
|
preloading dynamically linked libraries and caching stuff (MComponentCache). It also saves memory, because all launched
|
|
applications share certain resources.
|
|
|
|
Applauncherd also provides support for a splash screen and fast single
|
|
instance launches.
|
|
|
|
Some technical details are explained below.
|
|
|
|
Install applauncherd-doc for the Doxygen-based user documentation.
|
|
See INSTALL on how to build applauncherd and the documentation.
|
|
|
|
Technical overview
|
|
==============================
|
|
|
|
The applauncherd daemon is started by UpStart as part of XSession, that
|
|
is, at the same level as the desktop (MeeGo Touch homescreen).
|
|
Applauncherd forks the will-be-application process, "booster", before
|
|
knowing which application is going to be launched next. There can be
|
|
different kinds of boosters optimized for different kinds of
|
|
applications, e.g. Qt, Meego Touch, QML.
|
|
|
|
In the current architecture boosters are loaded as plugins. Applauncherd
|
|
searches for plugin libraries in /usr/lib/applaucherd/lib*booster.so and
|
|
forks a new process for each booster to wait for launch commands from the
|
|
user.
|
|
|
|
The user uses the launcher always through a special invoker program. The
|
|
invoker (/usr/bin/invoker) tells booster process to load an application
|
|
binary via a socket connection.
|
|
|
|
The application to be launched via applauncherd should be compiled as a
|
|
shared library or a position independent executable (-pie) and it should
|
|
always export main(). There's also a "booster" for all applications to
|
|
be used with the splash screen. In that case exec() is used.
|
|
|
|
Technical details
|
|
==============================
|
|
|
|
Before loading, booster process changes its security credentials so that
|
|
the code in the application binary will be executed with the correct credentials. Loading the binary is done with dlopen(), and therefore the
|
|
application needs to be compiled and linked as a shared library or a
|
|
position independent executable. The booster process also sets the
|
|
environment variables. Finally, it finds the main function in the
|
|
application binary with dlsym() and calls the main() with the command
|
|
line arguments given by the invoker.
|
|
|
|
The launcher itself is a library that is loaded by a small C-program (/usr/bin/applauncherd.bin). Idea behind this is to avoid linking the
|
|
launcher binary to any libraries. This allows us to fully control how
|
|
(with which flags) the preloaded libraries are opened with dlopen().
|
|
|
|
Aegis platform security is used to protect the socket connection between
|
|
invoker and launcher. Currently this works only on the target device. It
|
|
is automatically disabled by the build scripts when compiling on x86.
|
|
|
|
Each application type (currently Qt and MeeGo Touch) has its own booster
|
|
process. When booster launches the application by calling the "main()"
|
|
function, applauncherd will create new booster process of that type.
|
|
|
|
Booster processes do some initializations that cannot be shared among
|
|
other processes and therefore have to be done after forking. This allows,
|
|
for instance, instantiating a MeeGo Touch application before knowing the
|
|
name of the application. Then the booster process waits for a connection
|
|
from the invoker with the information about which application should be
|
|
launched.
|
|
|
|
With MeeGo Touch booster it's possible to fetch certain objects from a cache. This will significantly reduce the startup time of an application.
|
|
|
|
|