arcean/meegotouch-applauncherd
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
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.
About
No description, website, or topics provided.
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published