在 MediaPlayer 中打开 content://media/external/[...] 需要 READ_EXTERNAL_STORAGE 权限吗？

Question

我正在我的应用程序中播放警报声。在大多数设备上，这可以完美运行。一些用户描述没有声音播放。这似乎主要影响三星和华为设备。这是失败的一个最小示例：

alarmUri = RingtoneManager.getActualDefaultRingtoneUri(this, RingtoneManager.TYPE_ALARM);
try {
            if(!mediaPlayer.isPlaying()) {
                mediaPlayer.setDataSource(this, alarmUri);   
                AudioManager audioManager = (AudioManager) this.getSystemService(Context.AUDIO_SERVICE);
                mediaPlayer.setAudioStreamType(audioManager.STREAM_ALARM);
                mediaPlayer.setLooping(true);
                mediaPlayer.prepare();
                mediaPlayer.start();
            }
        } catch(Exception e) {                
                Log.d(logtag,"Exception: " + e);
        }

对于受影响的用户，会抛出以下异常：

异常 java.io.IOException: setDataSource failed.: 状态=0x80000000

这似乎只有在 alarmURI 看起来像这样时才会发生：content://media/external/audio/media/11，即它驻留在外部存储中。当alarmURI 看到这个content://media/internal/audio/media/40 时，我从未见过它发生过。

如果我使用的 Uri 包含 /external/ 部分，我是否需要 READ_EXTERNAL_STORAGE 权限才能播放声音？还是我错过了其他东西？通常，如果权限是问题，我希望抛出一个 SecurityException 。

/e：我可以在我的设备上重现该错误。这是更详细的错误报告：

异常 java.lang.SecurityException: Permission Denial: 读取 com.android.providers.media.MediaProvider URI content://media/external/audio/media 来自 pid=27158, uid=10177 需要 android.permission.READ_EXTERNAL_STORAGE，或 grantUriPermission()

Answer 1

通常情况下，我会期待 SecurityException

您没有收到 SecurityException，因为您的代码在访问 Linux 文件系统（操作系统级别）权限时失败，而不是 Android 框架权限。对于您从 API 收到的RuntimeExceptions（例如 SecurityException）没有严格的保证，这就是为什么它们首先被称为“未经检查的异常”。

如果我使用的 Uri 包含 /external/ 部分，我是否需要 READ_EXTERNAL_STORAGE 权限才能播放声音？

切勿使用外部提供的 Uri 的内容在代码中做出任何决定。只需将它们视为不透明的字符串即可。

这似乎只有在 alarmURI 看起来像这样时才会发生......，即它驻留在外部存储中。当alarmURI 看起来这个时，我从未见过它发生...

您在发布 Uri 以进行故障排除时是正确的，但了解 Uri 的来源也很有帮助。现代版本的 Android 使用 dynamic Uri permission model。即：您对 Uri 的访问级别可能会有所不同，具体取决于 Uri 来自何处以及调用者是否已将 FLAG_GRANT_READ_URI_PERMISSION 添加到 Intent（或调用 Context#grantUriPermission 以获得相同结果），以及您是否已调用 Context#takePersistableUriPermission使用 Uri 接收 Intent。

是的，您可能需要READ_EXTERNAL_STORAGE 权限。 Android 使用 FUSE 或类似的供应商特定 API 来根据调用应用程序的权限调整外部存储的可见操作系统级权限：当您的应用程序具有权限时，外部文件看起来是可读的（File#isReadable 返回 true em>），如果没有，外部文件看起来无法访问（File#isReadable 返回 false）。当然，这应该只与文件相关，但是如果调用者给你一个file:// Uri 怎么办？此外，Uri 后面的 ContentProvider 可能会在给您文件描述符之前检查您是否拥有 READ_EXTERNAL_STORAGE 权限（这很愚蠢，但肯定有可能）。

此外，最好自己打开 Uri 并向播放器提供流/文件描述符而不是 Uri。大多数 Linux 安全检查^* 在您打开文件描述符时发生。为了实现可预测的行为，您应该在自己的代码中打开 Uri 并尽可能多地进行错误处理，包括从远程 ContentProvider 捕获 RuntimeException。

为什么会出现这个问题？可能有多种原因，但可能是其中之一：

1. 有罪设备上的 MediaStorage ContentProvider 存在漏洞（制造商可以并且经常使用自定义漏洞版本替换系统 ContentProvider）
2. 有罪设备上的 MediaPlayer 实现存在错误
3. 有罪设备的 SELinux 权限存在缺陷（过多限制对文件的访问）
4. 您的代码接收 Uris，将它们存储在某处，但不调用 takePersistableUriPermission，因此您的访问在应用重启后失效。

如果没有异常堆栈跟踪，就很难诊断出确切的问题。无论哪种方式，如果上述建议没有帮助，除了使用不同的 API 播放声音文件和/或强制用户在不使用 Android MediaProvider 的情况下选择警报声音之外，您几乎无能为力。

---

^*除了一些 SELinux 检查，但你真的无能为力