Android系统应用蓝牙分享文件失败的分析解决方法

一、前言

在最近开发蓝牙功能时，发现一个有意思的现象：Android系统签名应用进行蓝牙文件分享会失败，而普通应用却完全正常。这个问题在AML方案上确实存在，按道理安卓原生流程应该也有，但RK方案就没遇到——很可能是在某个环节做了特殊处理。这里就把分析过程和解决方案梳理一下。

二、分析解决

1、主要日志

先看报错日志，这里是关键线索：

07-02 22:57:31.376   937  2839 W UriGrantsManagerService: For security reasons, the system cannot issue a Uri permission grant to content://com.mobisystems.office.RemoteFiles/YXNzZXRzOi8vc2FtcGxlcy9HZXR0aW5nX1N0YXJ0ZWQucGRm/0 [user 0]; use startActivityAsCaller() instead
07-02 22:57:31.379   937  2839 W Bundle  : Key android.intent.extra.STREAM expected ArrayList but value was of a different type.  The default value  was returned.
07-02 22:57:31.380   937  2839 W Bundle  : Attempt to cast generated internal exception:
07-02 22:57:31.380   937  2839 W Bundle  : ja va.lang.ClassCastException: Cannot cast android.net.Uri$StringUri to ja va.util.ArrayList

07-02 22:57:31.380   937  2839 W UriGrantsManagerService: For security reasons, the system cannot issue a Uri permission grant to content://com.mobisystems.office.RemoteFiles/YXNzZXRzOi8vc2FtcGxlcy9HZXR0aW5nX1N0YXJ0ZWQucGRm/0 [user 0]; use startActivityAsCaller() instead
07-02 22:57:31.384   937  2839 V GrammaticalInflectionUtils: AttributionSource: AttributionSource { uid = 1002, packageName = null, attributionTag = null, token = android.os.Binder@8d82233, deviceId = 0, next = null } does not ha ve READ_SYSTEM_GRAMMATICAL_GENDER permission.
07-02 22:57:31.385   937  2839 W OptProp : Cannot read opt property android.window.PROPERTY_COMPAT_ALLOW_RESIZEABLE_ACTIVITY_OVERRIDES
07-02 22:57:31.385   937  2839 W OptProp : Cannot read opt property android.window.PROPERTY_COMPAT_ALLOW_MIN_ASPECT_RATIO_OVERRIDE

从日志看，很容易误以为是权限问题——比如“does not ha ve READ_SYSTEM_GRAMMATICAL_GENDER permission”这句。但实际尝试添加权限后，问题依然存在，而且应用本身是系统签名，权限理应足够大。

2、具体分析日志

真正的关键，其实是下面这段：

UriGrantsManagerService: For security reasons, the system cannot issue a Uri permission grant to content://com.mobisystems.office.RemoteFiles/YXNzZXRzOi8vc2FtcGxlcy9HZXR0aW5nX1N0YXJ0ZWQucGRm/0 [user 0]; use startActivityAsCaller() instead

定位到源码 frameworks/base/services/core/ja va/com/android/server/uri/UriGrantsManagerService.ja va，核心逻辑如下：

    private int checkGrantUriPermissionUnlocked(int callingUid, String targetPkg, GrantUri grantUri,
            int modeFlags, int lastTargetUid) {
        // ... 省略部分代码
        final int callingAppId = UserHandle.getAppId(callingUid);
        if ((callingAppId == SYSTEM_UID) || (callingAppId == ROOT_UID)) {
            if ("com.android.settings.files".equals(grantUri.uri.getAuthority())
                    || "com.android.settings.module_licenses".equals(grantUri.uri.getAuthority())
                    || "com.mobisystems.office.RemoteFiles".equals(grantUri.uri.getAuthority())
                    || "com.skg.filemanager.provider".equals(grantUri.uri.getAuthority())
                    || "com.debug.fastpass.fileprovider".equals(grantUri.uri.getAuthority())) {
                // 白名单——这些是豁免的
            } else {
                Slog.w(TAG, "For security reasons, the system cannot issue a Uri permission"
                        + " grant to " + grantUri + "; use startActivityAsCaller() instead");
                return -1;
            }
        }
        // ...

代码注释已经写得很清楚：如果调用者UID是系统或Root，且目标URI不在白名单内，就会直接返回-1并报错。这是出于安全考虑——系统签名应用权限太大，如果随意授权临时URI，可能会被恶意利用。

蓝牙分享、某些投屏场景，恰恰需要临时URI来控制文件访问，所以系统应用就被卡住了。解决方案也很直接：把需要授权的URI源加入白名单。比如上面代码中的 com.debug.fastpass.fileprovider 或 com.mobisystems.office.RemoteFiles，就是从报错信息中提取出来的。

如果不想逐个添加，也可以直接把 (callingAppId == SYSTEM_UID) || 这个判断去掉，让所有系统应用都通过——但需要留意，这样可能会影响EDLA认证。

至于RK方案为什么没这个问题？从代码看，它并没有修改 UriGrantsManagerService.ja va，很可能是在流程的前面或后面做了其他处理，这里就不展开了。

三、其他

1、小结

根本原因：Android Framework在 UriGrantsManagerService 中做了安全校验，限制了系统签名应用使用临时URI。适配修改这个文件，加入目标URI的白名单，就能解决问题。

2、普通应用蓝牙文件分享知识

Android蓝牙文件分享的实现，其实有一套成熟方案。通过蓝牙技术，可以在设备间快速传输图片、音频、文档等文件。本文基于实际项目经验，总结了单文件分享、多文件批量分享、权限配置、关键API使用及常见问题解决。如果感兴趣，可以查阅相关专题。