> Launchpad > Run with privilege > Three launchpads can be foreseen > (OSP, WRT, Core Native). > Receive all the context (sécurity, environment, ...) from AMD. > Insert the Application at launch in the user context > Manage lib and info caching to speed launch > (preload, pre-link, ...) > Manage App Live cycle > (kill, pause, slowdown, garbage collection) >
Actually managing app lifecycle is the role of AMD. AMD is actually the central daemon who maps process (pid) and app (appId). The only launchpad task you did not mention is monitoring child app process. At least one of the launchpad is the parent of the specific app and it broadcast dbus message when it receives SIGCHILD signal and AMD (mostly) receives termination of the process. Previous developer for AUL (AMD) considered refactoring AMD/launchpad to use cgroup to receive the lifecycle of app process but he did not do it due to schedule issue. (He should have confirmed it from arch review also) Currently there are two active aunchpads, OSP/Core and WRT. OSP and Core app shares a lot in common and I made a conclusion that separating launchapd between OSP and Core does not deserve it. There exist one more launchpad, debug_launchpad and it works only for debugging purpose for OSP app. It is launchpad by sdbd when connected with USB cable and terminated by sdbd. Wrt_launchpad has much more works like calling process pool and Mr. Ming Jin can explain this architecture well.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
