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