CutefishOS app startup speed optimizer.
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.
 
 
 
 
 
Simo Piiroinen 833b551af1 [mapplauncerd] Sandboxed application boosters. JB#53844 OMP#JOLLA-43
When booster is executing in sandbox as an applicatiom booster, it
needs to verify that command line received from invoker matches
Exec line in application desktop file, application launch is allowed,
and permissions granted are as was expected at the time of booster
launch.

Provide booster-generic@.service that can be used for instantiating
sandboxed application boosters.

D-Bus ipc with sailjaild is modified version of similar code in
sailjailclient. The biggest difference is that this version uses
private connection via libdbus to avoid leaving stray dbus connections
or threads behind when transferring control to application code
without use of exec*() functions.

Remove cap_sys_ptrace from booster executable as makes it impossible
to run the booster within a no-new-privs sandbox.

Fix socket passing from booster instance to booster daemon so that it
works also when invoker is running in different namespace than booster
instance (invoker pid might be unresolvable).

Replace ad-hoc booster argument parsing with getopt_long().

Fix issues with argv handling: using const pointers for non-const
data, passing data by reference between objects that might have
different lifespans and never releasing the dynamically allocated
arrays.

Fix issues with env passing: duplicating invoker env at booster
side as-is can lead to problems like loss of customg session
bus socket address that has been set up by firejail.

If booster bumps into command read problems, bailout immediately
instead of relying on out-of sequence data possibly triggering
exit due to unknown commands.

As an enabler for sharing code between invoker (written in c) and
daemon (written in c++), modify Logger class used by c++ code so
that it is just a wrapper for logging functionality used by invoker.

Signed-off-by: Simo Piiroinen <simo.piiroinen@jolla.com>
4 years ago
doc [mapplauncherd] Remove splash support. 12 years ago
rpm [mapplauncerd] Sandboxed application boosters. JB#53844 OMP#JOLLA-43 4 years ago
scripts [mapplauncherd] Fixes MER#1916 7 years ago
src [mapplauncerd] Sandboxed application boosters. JB#53844 OMP#JOLLA-43 4 years ago
.gitignore Remove mbooster 13 years ago
CMakeLists.txt Respect GNUInstallDirs 5 years ago
COPYING.LESSER Changes: First public release 16 years ago
README [mapplauncerd] Sandboxed application boosters. JB#53844 OMP#JOLLA-43 4 years ago

README

What is applauncherd?
==============================

Applauncherd is a daemon that helps to launch applications faster by
preloading dynamically linked libraries and caching stuff.
It also saves memory, because all launched applications share certain resources.

Applauncherd also provides support for 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.

Building
==============================

    BUILD_TESTS=1 ./configure
    make
    make doc
    make install

Technical overview
==============================

Booster daemons (written using the provided library) are started as part of the
user session. The booster is responsible for forking the will-be-application
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 or QML.

In the current architecture boosters are implemented as seperate processes,
using the provided support library. Each booster process waits for launch
commands.

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.
In that case exec() is used.

Technical details
==============================

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.

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 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. 

Contributors
==============================

People who have contributed to mapplauncherd:

Robin Burchell
John Brooks
Thomas Perl

People who have contributed to meegotouch-applauncherd:

Olli Leppänen
Jussi Lind
Juha Lintula
Pertti Kellomäki
Antti Kervinen
Nimika Keshri
Alexey Shilov
Oskari Timperi

Some parts of the code is based on the maemo-launcher by:

Guillem Jover
Michael Natterer