最近,有同事向我反馈把Twitter应用的Widget放到我们的Launcher应用上会失败,但是放到AOSP的Launcher3上却能成功。
我和他们一起看了下日志,看到将Twitter的Widget放到Launcher上时会启动Widget自己的配置Activity,然后这个WidgetSettingsActivity很奇葩——他用一个系统的SignatureOrSystem级别权限来保护自己,更奇葩的是他的exported属性居然是false。这存心不让人用嘛。
<activity android:name=".WidgetSettingsActivity"
android:permission=“android.permission.BIND_REMOTEVIEWS”
android:exported="false"
... >
Okay,Twitter不能用的原因算找到了,但是问题又来了——为何Launcher3上成功了?
通过JDWP单步调试Launcher3,发现这货在ActivityManagerService.startActivityLocked()里的callingUid居然是SYSTEM_UID,怪不得这货怎么玩都能够通过鉴权。
在ActivityManager.checkComponentPermission()里会先检查uid是否是ROOT_UID或SYSTEM_UID,如果是的话就直接返回PERMISSION_GRANTED了。所以,exported="false"根本没起作用。
回溯Launcher3的stack trace后,发现这货调AppWidgetHost.startAppWidgetConfigActivityForResult()进来的。这个函数会让AppWidgetService创建一个IntentSender,拿着这个IntentSender去调ActivityManager.startActivityIntentSender(),就这样把AppWidgetService的上下文带过去了。
我们看了下AppWidgetHost.startAppWidgetConfigActivityForResult()的接口注释,发现接口设计者可能没有想到会发生这样的事——这算“强奸”了Twitter的意愿了吧。