android:process for applications having different sharedUserId

[Ubuntu guy]

Hello,

I found this documentation in
http://developer.android.com/guide/topics/manifest/application-element.html#proc,
for android:process option of <application>

"you can arrange for components of both applications to run in the
same process — but only if the two applications also share a user ID
and be signed with the same certificate."


However, i'm looking at these applications, (they have different
shared uids)

Phone.apk

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.phone"
android:sharedUserId="android.uid.phone"
android:sharedUserLabel="@string/dialerIconLabel"
>

Settings.apk


<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.settings"
android:sharedUserId="android.uid.system">

Nevertheless, settings app's activity (MultiSimSettings) is created in
com.android.phone.

<activity android:name="MultiSimSettings"
android:label="@string/multi_sim_settings_title"
android:process="com.android.phone"
android:clearTaskOnLaunch="true">

Shouldn't this have failed?

[Dianne Hackborn]

Actually that settings UI is implemented in the phone app, and that is why it runs in that process.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Ubuntu guy]

Hello Dianne, my question (as to why a component is allowed to be
hosted in a process having a different UID) was more generic. I just
used the settings application as an example.
A malicious app could request for an activity to be run as a part of
com.android.phone (despite having a different UID) and could access
null pointer in its onCreate and bring down com.android.phone, isn't
it?

From the documentation of android:process, looks like the
installation of the app should fail but the current implementation of
PackageManagerService doesn't seem to be doing that.

On Aug 27, 5:51 pm, Dianne Hackborn <hack...@android.com> wrote:
> Actually that settings UI is implemented in the phone app, and that is why
> it runs in that process.
>
>
>
>
>
>
>
>
>
> On Fri, Aug 26, 2011 at 5:41 PM, Ubuntu guy <sam_...@yahoo.co.in> wrote:
> > Hello,
>
> >  I found this documentation in
>

> >http://developer.android.com/guide/topics/manifest/application-elemen...
> > ,

> hack...@android.com

[Dianne Hackborn]

My point is that what you are saying is happening is not actually happening.  That part of the settings UI is implemented in the phone app, so it runs in the phone app process.  This concern you have doesn't exist.

hac...@android.com

[Ubuntu guy]

But i just have a sample app which brings down com.android.phone.
The app requests all of its component to be run in com.android.phone
and in one of the activity triggers a fault.
Yes, the default inbuilt apps might not be a concern but how about
market apps?

When you say "concern doesn't exist", do you mean a strict review of
apps before they are published in market?

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.test.helloandroid"
android:versionCode="1"
android:versionName="1.0">
<uses-sdk android:minSdkVersion="10" />

<application android:icon="@drawable/icon" android:label="@string/
app_name"
android:process="com.android.phone">
<activity android:name=".HelloAndroidActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category
android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

<activity android:name=".SecondActivity"
android:label="@string/app_name"
android:allowTaskReparenting="true">
</activity>
...
...
...

[John Vidler]

From your first post: "...and be signed with the same certificate."

Thus, unless you have the same certificate as another application, market or system, you cannot do what you are proposing.

- John.

[Dianne Hackborn]

Unless you are signed with the same cert as the other app *and* using android:sharedUserId, you can't run in its process.

Given that you aren't even using android:sharedUserId in the manifest you posted, I can absolutely say you are not running in the phone process.  So you said you want to run in a process with the same name, but you have a different uid, so you can't run in the existing process and a new one of that name will be created for your uid.  If you look with "ps" you will see two processes with that name, one yours, one the phone app.

hac...@android.com

[Ubuntu guy]

>> I can absolutely say you are not running in the phone process. So
>> you said you want to run in a process with the same name

Thanks Dianne, i didn't notice that. :-)

>> Unless you are signed with the same cert as the other app *and* using
>> android:sharedUserId, you can't run in its process.

That clarifies the policy for third party apps.
Nevertheless, the policy doesn't apply to in-built system apps
( settings and phone as described in my first post).
Although they have same signature, they don't share a user id.
Not that i'm questioning the implementation but for me, this seems to
violate
"all apps are equal" policy of android.

[Dianne Hackborn]

On Wed, Aug 31, 2011 at 12:01 AM, Ubuntu guy <sam...@yahoo.co.in> wrote:

  That clarifies the policy for third party apps.

Nevertheless, the policy doesn't apply to in-built system apps
( settings and phone as described in my first post).
Although they have same signature, they don't share a user id.
Not that i'm questioning the implementation but for me, this seems to
violate
"all apps are equal" policy of android.

The settings app runs as the system uid, which has additional ability -- the system itself by its nature has code running in every app, so it can well run code in other apps.

--
Dianne Hackborn
Android framework engineer

hac...@android.com

[Gagan Singh]

Hi,

I am unable to get repo.

repo init -u git://gitorious.org/rowboat/manifest.git -m rowboat-gingerbread.xml

Error:

IOError: [Errno 2] No such file or directory: '/mnt/data/rowboat-Gingerbread/.repo/manifests/.git/HEAD'

 

Any advice for resolution.

 

Regards,

Gagan

[Ubuntu guy]

Ah, i see. It makes sense. Thanks.
Just tried changing SharedUserId of settings.apk and Package manager
indeed ignores it.

On Aug 31, 9:32 am, Dianne Hackborn <hack...@android.com> wrote:

> On Wed, Aug 31, 2011 at 12:01 AM, Ubuntu guy <sam_...@yahoo.co.in> wrote:
> >   That clarifies the policy for third party apps.
> > Nevertheless, the policy doesn't apply to in-built system apps
> > ( settings and phone as described in my first post).
> > Although they have same signature, they don't share a user id.
> > Not that i'm questioning the implementation but for me, this seems to
> > violate
> > "all apps are equal" policy of android.
>
> The settings app runs as the system uid, which has additional ability -- the
> system itself by its nature has code running in every app, so it can well
> run code in other apps.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com