Android's shared user id (android:sharedUserId) is a way for different applications to share the same user id for permissions, which lets them access their data and host their components in other process space. By declaring a new sharedUserId in the manifest, a new user id is creating during installation and is ready to be used by other applications provided they are signed with the same certificate and one such use is to update android:process of an application component to host it in other process space.
However, if the applications don't share a user id and aren't signed with the same certificate, a new process is launched with the same name as in android:process and this new process automatically shares userId with the requested application.
If the applications share user id and and aren't signed by the same certificate, the installation of the apk would fail.
If the applications share user id and are signed by the same certification, then requested process indeed hosts the component. There is an exception to this in latest version of android supporting global and application private process. This is documented here.
If they don't share a user id and are signed by the same certificate, a new process is launched with the same name as in android:process and the new process shares userid with the requested application.
However, there is one exception to the final rule in case of settings.apk and stk.apk. They don't share a user id but are signed with the same system certificate and yet requested settings's component is hosted in com.android.phone process.
Stk
However, if the applications don't share a user id and aren't signed with the same certificate, a new process is launched with the same name as in android:process and this new process automatically shares userId with the requested application.
If the applications share user id and and aren't signed by the same certificate, the installation of the apk would fail.
If the applications share user id and are signed by the same certification, then requested process indeed hosts the component. There is an exception to this in latest version of android supporting global and application private process. This is documented here.
If they don't share a user id and are signed by the same certificate, a new process is launched with the same name as in android:process and the new process shares userid with the requested application.
However, there is one exception to the final rule in case of settings.apk and stk.apk. They don't share a user id but are signed with the same system certificate and yet requested settings's component is hosted in com.android.phone process.
Stk
xmlns:androidprv="http://schemas.android.com/apk/prv/res/android"
package="com.android.stk"
android:sharedUserId="android.uid.phone">
...
...
...
android:label="@string/app_name"
android:clearTaskOnLaunch="true"
android:process="com.android.phone">
Settings
package="com.android.settings"
coreApp="true"
android:sharedUserId="android.uid.system">
android:label="@string/sim_lock_settings"
android:theme="@android:style/Theme.Holo.DialogWhenLarge"
android:process="com.android.phone">
No comments:
Post a Comment