当前位置：首页 > news >正文

这个binder面试题你会吗？-学员作业

news 2026/6/13 9:22:29

背景：

前些天有学员朋友刚好带回来了一道关于binder相关的面试。当时看着其实感觉也没啥问题，并没啥难度，所以在vip群里也有学员朋友积极的进行回答。

面试题目如下:
有如下一个业务调用场景：
app调用wms接口，wms中处理又会调用到sf进程，请问说出在wms，sf中binder方法中getcalluid是谁？这个callinguid又是在哪设置的?

针对这个面试题大家可能都觉得不难，很多同学都可以答对认为是system_server的uid。

在但是也有同学提出做个实验发现就是uid为system_server，但是pid实际上是0.

所以针对这个getCallingPid到底是多少的问题反而成了最大的争议点。

多个版本验证getCallingPid

针对这个问题已经存在了各种争议，马哥也针对这个问题在不同的版本进行了验证，发现还确实是有差异的。

准备环境：

aosp14，aosp16这两个aosp的版本

打印部分添加：
这里以前些天豆包手机截图接口为案例
frameworks/base/services/core/java/com/android/server/wm/WindowManagerService.java

@OverridepublicvoidcaptureDisplay(intdisplayId,@Nullable ScreenCapture.CaptureArgs captureArgs,ScreenCapture.ScreenCaptureListener listener){//打印callingpid和callinguidSlog.d(TAG,"captureDisplay "+Binder.getCallingUid()+" pid "+Binder.getCallingPid());ScreenCapture.LayerCaptureArgs layerCaptureArgs=getCaptureArgs(displayId,captureArgs);ScreenCapture.captureLayers(layerCaptureArgs,listener);}

在远端SurfaceFlinger中也进行打印
frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp

binder::StatusSurfaceComposerAIDL::captureLayers(constLayerCaptureArgs&args,constsp<IScreenCaptureListener>&captureListener){IPCThreadState*ipc=IPCThreadState::self();constintpid=ipc->getCallingPid();constintuid=ipc->getCallingUid();ALOGE("SurfaceComposerAIDL::captureLayers pid %d uid %d ",pid,uid);mFlinger->captureLayers(args,captureListener);returnbinderStatusFromStatusT(NO_ERROR);}

但是两个aosp版本确实得出不同的结果。
aosp14版本日志：

12-2411:32:38.648341606E SurfaceFlinger: SurfaceComposerAIDL::captureLayers pid515uid1000

aosp16版本日志：

12-2411:40:47.8935181285E SurfaceFlinger: SurfaceComposerAIDL::captureLayers pid0uid100012-2411:40:47.8935181285E SurfaceFlinger: validateScreenshotPermissions pid0uid1000

可以看出确实在aosp16版本显示pid是0，但是对应uid是1000也就是system_server

但是真的aosp16版本都是pid为0吗？明显也不是哈，具体也可以看下面截图：
可以看到其实也是有uid为1000但是pid不是0情况.

前置必学binder驱动相关知识：

那么要解决上面这个疑问就必须学习如下这些前置知识

mCallingPid，mCallingUid是在哪里赋值的呢？
frameworks/native/libs/binder/IPCThreadState.cpp
这里可以看出是在IPCThreadState::executeCommand方法中由内核进行返回的。
所以这块要查到根本原因还是要去binder.c中进行进一步排查。

drivers/android/binder.c

trd->sender_euid=from_kuid(current_user_ns(),t->sender_euid);t_from=binder_get_txn_from(t);if(t_from){structtask_struct*sender=t_from->proc->tsk;trd->sender_pid=task_tgid_nr_ns(sender,task_active_pid_ns(current));trace_android_vh_sync_txn_recvd(thread->task,t_from->task);}else{trd->sender_pid=0;}