奇葩的Twitter和更奇葩的Launcher3

最近，有同事向我反馈把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的意愿了吧。