我正在这篇博文中阅读有关在 Android 系统中使用 Binder 令牌的信息。我看到了与唤醒锁相关的示例,其中令牌用于识别来自同一应用程序的后续请求。
我想问为什么在Android系统UID
中,调用应用程序不足以跟踪应用程序的后续请求?在识别应用程序方面是否需要 Binder 令牌满足 UID 无法满足的要求?
我正在这篇博文中阅读有关在 Android 系统中使用 Binder 令牌的信息。我看到了与唤醒锁相关的示例,其中令牌用于识别来自同一应用程序的后续请求。
我想问为什么在Android系统UID
中,调用应用程序不足以跟踪应用程序的后续请求?在识别应用程序方面是否需要 Binder 令牌满足 UID 无法满足的要求?
Binder 令牌不会以它的方式识别应用程序uid
。令牌是一种能力或票据,这意味着拥有才是最重要的。换句话说,有了一个活页夹令牌,你是谁或什么都无关紧要,而重要的是你是否拥有这个令牌。最后一部分是关键:在 Android 框架中,出于安全原因需要区分许多对象,但它们要么都具有相同的uid
(例如,system_server
进程空间中的对象)和/或uid
不能识别真实的主题(例如,在 Binder RPC 本地端运行的代码)。
与uid
启用功能相关的这种差异不容易实现,甚至无法使用uid
. 您引用的博客文章中有一个很好的例子:
应用程序可以
InputMethodManager
通过调用该hideSoftInputFromWindow(IBinder windowToken, int flags)
方法来请求隐藏软键盘,但必须提供一个窗口令牌作为请求的一部分。如果令牌与属于当前接受输入的窗口的窗口令牌不匹配,InputMethodManager
则将拒绝该请求。这使得恶意应用程序无法强制关闭另一个应用程序打开的软键盘。
在这里使用标记的主要原因是窗口对象不是具有uid
. 当然,它是某个具有 的某个进程的一部分uid
,但无论如何uid
,它不是uid
试图隐藏软键盘的应用程序的一部分。因此,确保请求者拥有当前接受输入的窗口的唯一方法是强制应用程序提供WindowManager
第一次创建窗口时给出的令牌。