Android's multiprocess is used to indicate if a component can be hosted in the process space of the application requesting the component. The documentation claims that a request isn't necessarily honored at all times and works only with some permissions.
This is usually requested by application developers willing to have their component execute in other application's process space. This presents a security concern, a third party application without the knowledge of multiprocess could request for a component like starting an activity. The target activity would be created and resumed in the context of the calling process space and ends up having access to memory etc. Android's framework has a permission model to deal with this security concern but sadly isn't well documented. The intention is perhaps to demotivate application developers from using this feature.
The permissions model and this feature is similar to android:process documented here. android:process lets developers specify the process that would end up hosting the component. multiprocess seems more generic by avoiding hard coded process names in the manifest. Nevertheless, both features are controlled by sharedUserId and application signature.
multiprocess is considered only when both the requesting application and owning application share a common user id (android:sharedUserId) and are signed by the same certificate. If not, a new process is forked to host the requested component. The only exception is when both applications share a user id but are signed with different certificates and in this case installation of the second application would fail. Based on this permission model, this is most likely targeted at organizations using same certificate across a portfolio of applications and the upside being performance by hosting all components within a process boundary (avoiding binder IPC etc).
This is usually requested by application developers willing to have their component execute in other application's process space. This presents a security concern, a third party application without the knowledge of multiprocess could request for a component like starting an activity. The target activity would be created and resumed in the context of the calling process space and ends up having access to memory etc. Android's framework has a permission model to deal with this security concern but sadly isn't well documented. The intention is perhaps to demotivate application developers from using this feature.
The permissions model and this feature is similar to android:process documented here. android:process lets developers specify the process that would end up hosting the component. multiprocess seems more generic by avoiding hard coded process names in the manifest. Nevertheless, both features are controlled by sharedUserId and application signature.
multiprocess is considered only when both the requesting application and owning application share a common user id (android:sharedUserId) and are signed by the same certificate. If not, a new process is forked to host the requested component. The only exception is when both applications share a user id but are signed with different certificates and in this case installation of the second application would fail. Based on this permission model, this is most likely targeted at organizations using same certificate across a portfolio of applications and the upside being performance by hosting all components within a process boundary (avoiding binder IPC etc).
No comments:
Post a Comment