Hello,
In the case where we would agree to use a single Launching point (AMD),
I would propose to share the tasks following this model.
All the operation related to the context of an App Launch are regrouped
in AMD
AMD
Run with privilege
Gather environment information for each logged user
(a PAM module could be a good entry point for initial env.
collection)
Serve launch request
(by name, ID, Mime type, ...)
Ask user for choice when multi application can serve the request.
Verify if Launch is authorised for the user (profile) in
current context
(car in movement, battery status, data roaming, ....)
Subcontract the launch to a specialised launcher (launchpad)
per App type
(OSP, WRT, Core native)
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)
I see several values in that model:
- it's not a complete change from Tizen 2, moving smoothly should be
possible.
- it does allow for resource optimisation
- single user mode is not made more complex
- activating a second user does not induce a large resource call.
- securisation via SMACK is simple
- moving to a stronger App containment in the future would be quite
simple
- adding later a policy manager which would control App Launch and
live cycle is well contained.
- Adding a hook from window manager to favour App in foreground is
well contained.
Thanks in advance for your feedback.
--
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
