Android Q从根本上改变了手机上存储的工作方式。在Pie之前的每个版本中，Android的存储都像台式计算机一样工作：您可以使用要读取或写入任何文件的任何应用程序(如果您授予了这样做的权限)。借助Q，Google将推出(并要求)“ 范围存储 ”，这使Android的工作方式更像iPhone，其中存储独立于每个应用程序。应用只能访问自己的文件，如果已卸载，则所有文件都将被删除。

幸运的是，Android Q仍然保留了Android最初对中央文件系统的某些行为。不幸的是，现在用户设置应用程序来访问它很麻烦，并且大大降低了性能和功能。开发人员将不得不对应用程序进行大量重新编码以支持它。

需要常规文件系统访问的应用程序，例如办公套件，图像编辑器或文件管理器，现在将需要使用一个称为“ 存储访问框架 ”(SAF)的Android API 来进行所有文件操作。SAF自Android 5.0 Lollipop以来就已经可用，但是开发人员倾向于除非必要否则不使用它，因为它的API困难且文档记录差，用户体验差，性能差和可靠性差(主要是特定于设备供应商的形式)实施问题)。由于难以过渡到SAF，因此Google决定允许尚未表明支持Android Q的应用程序像往常一样工作，但是当Play商店要求所有应用程序明年支持Q时，情况将有所改变。

SAF最明显的面向用户的更改是授予应用访问存储的体验。为了使应用程序能够访问，它向操作系统发出请求，然后操作系统显示目录选择器屏幕。在此屏幕上，用户选择一个文件夹层次结构的根，该应用程序将在该根目录中读取和写入文件。用户必须对需要访问本地文件的每个应用程序执行此过程，如果需要授予其对外部SD卡的访问权限，则每个应用程序必须执行两次。

Google至少在Q beta 3方面改进了此过程，因为以前的beta版甚至不允许应用程序向用户建议位置，这需要用户做大量工作才能真正找到其设备的主存储。

在SAF下，文件I / O性能会受到一定的影响，但是最突出的问题在于文件目录操作，它比Pie中的传统文件访问速度慢25到50倍。对于文件管理器，这意味着执行搜索和存储使用率计算需要更长的时间。此处提供了带有演示应用程序的错误报告。

更大的性能问题是，某些应用程序必须先将文件复制到其本地“作用域存储”区域，然后才能使用它们。当此类文件的大小为数GB时，例如在视频文件或压缩档案的情况下，这可能会出现问题。许多Android应用程序利用开发人员社区中数量众多的开源Java库，而这些库通常需要直接文件系统访问才能工作。它们不是特定于Android的，需要重写才能与SAF一起使用。更糟糕的是，许多Android自己的内部库将无法使用它，例如程序包管理器或zip API。例如，如果不首先将整个APK复制到其自己的作用域存储区域中，文件管理器甚至将无法显示APK文件的图标(使用标准的Android API)。错误报告。

对于有技术倾向的人们，目前可以使用appops命令通过ADB在每个应用程序的基础上禁用Android Q的“范围存储” 。超级用户无需台式机即可直接在其设备上执行命令。这些命令在文档中被描述为开发人员功能，因此可以随时删除。