Binder getCallingUid and Intent constructor

797 views
Skip to first unread message

Sboogie

unread,
Aug 23, 2011, 3:47:18 AM8/23/11
to android-platform
Hello!

First, I'm sorry for potential double posting, I posted this first to
the android-dev group, but I think that was the wrong list..

Now to my question:
I am doing some AOSP system development for a university project and I
want to to "tag" Intents created within a function of service
component with the UID of the remote caller app who bound/called to
the service. My straightforward solution was to extend the Intent
class with a new private integer which is set with
Binder.getCallingUid in the constructors of the Intent. However, I
encountered strange behavior:

When calling Binder.getCallingUid in the function of the service, it
correctly returns the UID of the caller app. But when using
Binder.getCallingUid in the Intent constructor (called in this service
function), Binder.getCallingUid returns the UID of the service's app.

The stack dump looks like:
W/System.err( 668): java.lang.Throwable: stack dump
W/System.err( 668): at java.lang.Thread.dumpStack(Thread.java:612)
W/System.err( 668): at android.content.Intent.<init>(Intent.java:
2668)
W/System.err( 668): at com.test.app.RemoteService
$1.sendData(RemoteService.java:46)
W/System.err( 668): at com.test.app.IRemoteService
$Stub.onTransact(IRemoteService.java:54)
W/System.err( 668): at android.os.Binder.execTransact(Binder.java:
288)
W/System.err( 668): at dalvik.system.NativeStart.run(NativeMethod)

So, it seems there is no IPC going on when calling the Intent
constructor, so I wonder why the return value of Binder.getCallingUid
changes between sendData(RemoteService.java:46) and (Intent.java:
2668)?!

Thanks and cheers,
- Sven

Dianne Hackborn

unread,
Aug 24, 2011, 1:48:27 AM8/24/11
to android-...@googlegroups.com
Binder.getCallingUid() returns the UID of the caller when processing an incoming Binder IPC.  The value that is returned will vary depending on whether you are in the context of dispatching an incoming IPC or something else.

Also, code will often call Binder.clearCallingIdentity() to clear the calling information after it has verified it so that further operations are considered to be coming from the current uid.

Process.myUid() returns the uid of the current 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.

Sven Bugiel

unread,
Aug 24, 2011, 4:07:45 AM8/24/11
to android-...@googlegroups.com
Hello Dianne!

Thanks for your reply! Indeed, the Intent constructor was called within
a function of a remote service stub, thus it returns the caller UID as
you said. Even in the constructor of the Intent class. I just found out,
that I did the very stupid beginner's error to not include the new int
variable of Intents (to which I write the value Binder.getCallingUid()
in the constructor) into the writeToParcel/readFromParcel functions and
thus it naturally never shows up at the receiving end of the Intent...
Now everything works as expected :)

> <mailto:android-...@googlegroups.com>.


> To unsubscribe from this group, send email to
> android-platfo...@googlegroups.com

> <mailto:android-platform%2Bunsu...@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 <mailto: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.
>

Reply all
Reply to author
Forward
0 new messages