企业官网建设流程全解析

做安卓开发这么久，存储这块一直是新手容易栽跟头的地方。尤其是涉及存储卡的文件操作，坑比想象中多得多。这一篇专门把存储卡相关的文件读写逻辑拆开揉碎，从底层路径到实际代码，再到权限适配，一次性讲明白。不管你是刚接触安卓基础，还是正在做文件管理类App，这部分内容都值得仔细过一遍。

1. 安卓存储体系先搞清楚：内部存储与存储卡不是一回事

1.1 内部存储与外部存储的划分逻辑

很多初学者刚接触安卓时，会把“内部存储”理解成手机自带内存，把“存储卡”理解成用户自己插的TF卡或SD卡。这个理解大方向没错，但在安卓系统的术语体系里，这组概念有着相对固定的定义和分工。

在Android的官方文档里，内部存储（Internal Storage）是每个应用私有的目录，系统会为每个应用分配专属空间，其他应用没有权限直接读取。这个区域对应的路径通常是/data/data/包名/或者/data/user/0/包名/。应用卸载时，这个目录会被系统自动清理干净。

外部存储（External Storage）则是一个相对更大的共享存储区域，它可能是手机内置的一整块分区（比如/storage/emulated/0），也可能是用户后来插入的物理SD卡（比如/storage/XXXX-XXXX）。外部存储不是应用私有的，所有应用在获得授权后都可以访问其中的公共文件。

这里要特别强调一个历史因素。早期的安卓设备确实存在独立的物理SD卡插槽，当时“外部存储”基本上就等于“存储卡”。后来很多手机取消独立SD卡槽，改用了内置大容量存储，但系统仍然沿用了“外部存储”这个称呼。所以现在很多机型上所谓的“外部存储”，其实是一块物理上位于机身内部的模拟SD卡分区。

1.2 外部存储的挂载点与路径演进

外部存储的路径在安卓版本演进中经历过几次比较大的变化，理解这个演进过程对写兼容性代码至关重要。

最早的Android 1.x到2.x时代，外部存储的路径是/sdcard，代码里可以通过Environment.getExternalStorageDirectory()拿到。到了Android 3.0左右，系统引入了多用户支持，路径变成了/storage/sdcard0，后来又演变为/storage/emulated/0这种带用户编号的格式。Android 4.2之后，多用户机制越来越成熟，每个用户都有自己独立的/storage/emulated/N目录，其中0代表第一个用户（也就是设备主人）。

到了Android 6.0，系统引入Adoptable Storage（可采纳存储）概念，物理SD卡可以被格式化为内部存储的一部分，挂载路径就不固定了。到了Android 10，分区存储（Scoped Storage）机制开始强制推行，直接通过File路径访问外部存储公共目录的方式受到严格限制。Android 11继续强化了这套规则，Android 13又对媒体文件权限做了更细粒度的拆分。

可以整理成一张表格来对照：

1.3 开发中为什么要关注存储卡与内置存储的区别

如果只是写一个简单的Demo，随便在/sdcard下建个文件夹就能跑通读写。但一旦涉及真实项目，就不得不考虑用户手机的实际环境。我遇到过不少用户反馈“App数据丢失了”，查到最后发现是不同厂商ROM的路径适配问题。

某些国产ROM会把物理SD卡挂载在/storage/XXXX-XXXX这样的路径下，而Environment.getExternalStorageDirectory()指向的是机身内置存储。如果代码里写死了/sdcard/MyApp，那么在插了SD卡且SD卡被设置为默认存储的设备上，文件可能被写入机身存储而不是用户期望的SD卡。这也是为什么官方一直强调不要硬编码路径，而是要通过系统API去获取真实路径。

2. 存储卡文件操作的基础API与设计思路

2.1 核心API体系：File、Environment与StorageManager

在Android中操作存储卡文件，最基础的工具类就是java.io.File，配合android.os.Environment来获取存储位置。这套组合拳几乎覆盖了所有常规文件操作：创建、写入、读取、重命名、删除、遍历。

Environment类的几个关键方法需要理解透彻：

这里我建议把getExternalStoragePublicDirectory和getExternalFilesDir放在一起对比理解。前者是公共目录，所有应用都能读写，但Android 10之后需要申请权限；后者是应用专属目录，不需要任何权限即可访问，而且卸载应用时系统会一并清理，类似内部存储的扩展版。

再看StorageManager，这个类提供更底层的存储设备信息查询能力，比如getStorageVolumes()可以获取所有存储卷的列表，getVolumeList()在老版本中用来获取挂载点集合。在需要同时遍历机身存储和物理SD卡的场景下，StorageManager是不可或缺的工具。

一个很典型的场景：用户插了一张SD卡，App需要扫描SD卡里所有的图片文件。这时不能只盯着getExternalStorageDirectory()返回的路径，还得用StorageManager遍历出所有存储卷，再逐个检查挂载状态、读写权限，才能正确路由到一个可用的路径上。

2.2 检查存储卡状态的正确姿势

在动手操作文件之前，一定要先检查存储卡是否存在、是否可读写。很多人忽略这一步，结果在无SD卡的设备上盲目执行写操作，导致空指针或者IOException。

检查状态的代码模板大致如下：

String state = Environment.getExternalStorageState(); if (Environment.MEDIA_MOUNTED.equals(state)) { // 可以读写 } else if (Environment.MEDIA_MOUNTED_READ_ONLY.equals(state)) { // 只能读，不能写 } else { // 其他状态，包括未插入、正在格式化、损坏等 }

为什么非要检查状态？因为外部存储是可插拔的，它不像内部存储那样“随时都在”。用户可能在应用运行期间拔出SD卡，系统会发送ACTION_MEDIA_REMOVED等广播，应用应该有相应的状态感知和异常处理机制。

一个常规的做法是在Activity或Service中注册BroadcastReceiver监听存储设备状态变化，收到卸载、挂载的广播后，刷新界面上的存储状态提示，避免用户在一张已经拔掉的卡上执行文件操作。

2.3 文件操作的历史包袱与设计教训

早期安卓对文件操作几乎是“放任”状态，应用只要申请了WRITE_EXTERNAL_STORAGE权限，就可以随意在公共目录下创建文件夹、修改文件。这种宽松模式带来了很严重的体验问题：很多App卸载后仍然留下大量垃圾文件，公共目录变得又乱又杂。

Android 10之后分区存储全面推行，核心设计理念就是“各人自扫门前雪”。普通应用想读写公共目录下的文件，要么通过MediaStore插入到媒体数据库，要么通过ACTION_OPEN_DOCUMENT、ACTION_CREATE_DOCUMENT调起系统文件选择器，由用户亲自授权。应用自己的数据则推荐放到getExternalFilesDir()目录下。

对开发者来说，越早适应这套规则，后面适配新版本就越轻松。我自己在维护老项目时就踩过坑：旧代码里大面积使用getExternalStoragePublicDirectory直接读写文件，升级到Android 10之后一大片接口突然不能用了，只能连夜重构成MediaStore方案。这种事经历过一次就会长记性。

3. 完整实操：存储卡文件的写入、读取与遍历

3.1 环境准备：配置目标版本与权限

在开始写文件操作代码前，先把项目的build.gradle配置和权限声明弄到位。现代安卓开发基本都基于AndroidX，所以先确保compileSdk至少是33，targetSdk根据实际测试机型综合决定。

权限声明在AndroidManifest.xml中完成：

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="29" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

为什么把WRITE_EXTERNAL_STORAGE的maxSdkVersion设为29？因为Android 10（API 29）之后，分区存储规则生效，这个权限在Android 10及以上版本中已经无法授权完整的外部存储写权限。Android 11以后废除了这个权限的申请效果（除非应用被授予了ALL_FILES_ACCESS_PERMISSION或属于特殊类型），所以我用了maxSdkVersion="29"来限定这个权限只对Android 10以下系统生效。

Android 13之后，媒体文件权限被拆成三个独立的运行时权限：READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO。如果目标版本是33+，需要在运行时按需申请这些权限。

3.2 在公共目录创建和写入文件

这里演示一个经典的业务场景：把一份测试报告保存到公共下载目录，文件名带时间戳，避免重复。

// 获取公共下载目录路径 File publicDir = Environment.getExternalStoragePublicDirectory( Environment.DIRECTORY_DOWNLOADS); if (!publicDir.exists()) { publicDir.mkdirs(); } String timeStamp = String.valueOf(System.currentTimeMillis()); File reportFile = new File(publicDir, "test_report_" + timeStamp + ".txt"); try (FileOutputStream fos = new FileOutputStream(reportFile)) { String content = "安卓存储卡文件操作测试\n写入时间：" + new Date().toString(); fos.write(content.getBytes(StandardCharsets.UTF_8)); fos.flush(); } catch (IOException e) { e.printStackTrace(); }

这段代码的运行前提是targetSdk低于29或者已经在Android 10以下设备上获得了存储权限。如果是Android 11及以上，直接用绝对路径创建文件大概率会抛FileNotFoundException或EACCES错误。这不是代码写错了，而是系统机制变了。

关于编码要特别提醒一句：写文件之前明确指定字符集编码，不要依赖FileOutputStream的默认编码转换。否则在不同区域设置的手机上，文件内容可能变成乱码。我这里用了StandardCharsets.UTF_8，这是跨平台最稳妥的选择。

3.3 在应用专属外部目录中操作文件

前面已经提过，getExternalFilesDir()获取的是应用专属外部目录，这个目录不需要申请存储权限就可以访问，而且目录结构非常清晰。

// 获取应用专属外部目录下的files子目录 File appExternalDir = context.getExternalFilesDir(null); File subDir = new File(appExternalDir, "my_data"); if (!subDir.exists()) { subDir.mkdirs(); } File dataFile = new File(subDir, "config.json");

这种场景特别适合保存用户数据、缓存文件、日志文件。好处很多：卸载应用时系统会自动删除这些文件，不用操心里面残留垃圾；不需要向用户申请存储权限，隐私合规上压力小；目录结构自带包名标识，在文件管理器中很容易识别。

在Android 11及以上版本里，getExternalFilesDir()几乎是普通应用在公共存储区域做文件操作的唯一“正规军”路径。官方对应用专属目录的访问没有任何限制，从Android 10到Android 13都是如此。

3.4 遍历文件列表与筛选特定文件

读取存储卡上的文件列表，最直接的方法是使用File.listFiles()。这方法返回该目录下所有文件与子目录的File数组。

File[] files = publicDir.listFiles(); if (files != null) { for (File file : files) { if (file.isFile()) { String name = file.getName(); long size = file.length(); long lastModified = file.lastModified(); Log.d("TAG", "文件: " + name + ", 大小: " + size + ", 修改时间: " + lastModified); } } }

需要筛选指定类型文件时，可以传入FileFilter接口：

File[] txtFiles = publicDir.listFiles(pathname -> pathname.isFile() && pathname.getName().endsWith(".txt"));

FileFilter是一个函数式接口，使用Lambda表达式可以写得很简洁。这种筛选方式比遍历后手动判断要干净得多。

还有一个容易忽略的点：listFiles()返回的数组顺序是随机的，和文件系统内部的分区布局有关。如果需要对列表排序，可以这样处理：

if (files != null) { Arrays.sort(files, (a, b) -> Long.compare(b.lastModified(), a.lastModified())); }

这代码把文件按修改时间倒序排列，最新的文件排在前面，很符合日志文件、下载文件管理的常见需求。

3.5 读取文件内容与处理大文件

读取一个文本文件，用BufferedReader按行读取是比较稳妥的方式：

try (BufferedReader reader = new BufferedReader(new InputStreamReader( new FileInputStream(dataFile), StandardCharsets.UTF_8))) { String line; StringBuilder content = new StringBuilder(); while ((line = reader.readLine()) != null) { content.append(line).append("\n"); } String result = content.toString(); } catch (IOException e) { e.printStackTrace(); }

这里有几个细节值得注意。InputStreamReader的第二个参数指定UTF-8编码，避免系统默认编码不一致导致的乱码问题。然后用StringBuilder而非String拼接收取每一行，因为在循环里不断拼接String会产生大量对象，影响性能。如果文件很大（比如几十MB），就不要一次性全部读入内存，改成逐行处理的方式更稳妥。

对于二进制文件，比如图片、音频、APK安装包，就不能用字符流了，必须用FileInputStream配合字节数组分块读取：

try (FileInputStream fis = new FileInputStream(file)) { byte[] buffer = new byte[8 * 1024]; int length; ByteArrayOutputStream bos = new ByteArrayOutputStream(); while ((length = fis.read(buffer)) != -1) { bos.write(buffer, 0, length); } byte[] fileBytes = bos.toByteArray(); }

字节流和字符流的区别，我用一句话概括：字符流处理的是人能看懂的文字，字节流处理的是机器视角下的0和1。选错流类型，轻则内存浪费，重则数据损坏。

3.6 删除、重命名与移动文件

文件删除使用File.delete()或者File.deleteOnExit()。两者区别在于delete()是立即删除，返回值表示是否删除成功；deleteOnExit()是注册到JVM退出时删除，通常用于删除临时文件。

boolean deleted = dataFile.delete(); if (deleted) { Log.d("TAG", "删除成功"); } else { Log.d("TAG", "删除失败"); }

重命名操作使用File.renameTo(File dest)：

File oldFile = new File(subDir, "old_config.json"); File newFile = new File(subDir, "new_config.json"); boolean renamed = oldFile.renameTo(newFile);

要注意的是，renameTo是跨文件系统不安全的。如果原文件和目标文件不在同一个存储卷上（比如从机身存储移动到SD卡），renameTo很可能返回false。这种情况下需要自己实现拷贝+删除的逻辑：

boolean moveFile(File src, File dst) { try (InputStream is = new FileInputStream(src); OutputStream os = new FileOutputStream(dst)) { byte[] buffer = new byte[8 * 1024]; int length; while ((length = is.read(buffer)) != -1) { os.write(buffer, 0, length); } return src.delete(); } catch (IOException e) { e.printStackTrace(); return false; } }

这种移动方式的本质是先把数据读出来，再写到新位置，最后删除原文件。在操作大文件时可能会比较慢，但胜在跨文件系统也能正常工作。

4. 权限处理：从运行时权限到Android 13的细粒度授权

4.1 运行时权限的申请流程

Android 6.0之后，存储权限属于危险权限，除了在AndroidManifest.xml中声明，还需要在运行时动态申请。

运行时权限申请通用的代码模板如下：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { if (checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { requestPermissions( new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, REQUEST_CODE_WRITE_STORAGE); } }

用户响应权限弹窗后，结果会回调到onRequestPermissionsResult：

@Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { super.onRequestPermissionsResult(requestCode, permissions, grantResults); if (requestCode == REQUEST_CODE_WRITE_STORAGE) { if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { // 权限已授予，可以执行写操作 } else { // 用户拒绝权限，需要引导用户手动开启 } } }

这里有一个容易被忽略的小细节：Android 11（API 30）及以上，如果应用targetSdk是30以上，WRITE_EXTERNAL_STORAGE这个权限实际上已经不能生效了。它会被系统直接忽略，就算用户点了授权，应用也拿到不到真正的写入能力。这导致不少开发者困惑：“明明申请了权限，写入公共目录还是失败”。新版系统的正确做法是使用MediaStore或者系统文件选择器，而不是去申请WRITE_EXTERNAL_STORAGE。

4.2 Android 10以后分区存储适配要点

分区存储机制推出后，普通应用访问外部存储公共目录的方式发生了根本性变化。总结下来，现在有四种合法的访问途径：

第一种是访问应用专属目录，也就是getExternalFilesDir()对应的目录，不需要任何权限。第二种是使用MediaStoreAPI写媒体文件，这是把图片、视频、音频插入到系统媒体库的标准方式。第三种是使用系统文件选择器，通过Intent.ACTION_OPEN_DOCUMENT或者ACTION_CREATE_DOCUMENT来让用户选择文件，之后通过返回的Uri来读写。第四种是申请MANAGE_EXTERNAL_STORAGE权限，这是一个特殊权限，需要在设置界面单独开启，Google Play上架审核对这个权限的申请审查非常严格。

用MediaStore在公共下载目录创建文件的示例：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { ContentValues values = new ContentValues(); values.put(MediaStore.Downloads.DISPLAY_NAME, "test_" + System.currentTimeMillis() + ".txt"); values.put(MediaStore.Downloads.MIME_TYPE, "text/plain"); values.put(MediaStore.Downloads.RELATIVE_PATH, Environment.DIRECTORY_DOWNLOADS + "/MyApp"); Uri externalUri = MediaStore.Downloads.EXTERNAL_CONTENT_URI; getContentResolver().insert(externalUri, values); }

这段代码执行后，系统会自动在公共下载目录的MyApp子目录下为应用创建一个空文件，并且该文件的真实路径对当前应用来说是不可见的（但系统会自动授权给它）。接下来再通过OutputStream写入内容：

Uri resultUri = getContentResolver().insert(externalUri, values); if (resultUri != null) { try (OutputStream os = getContentResolver().openOutputStream(resultUri)) { os.write("文件内容".getBytes(StandardCharsets.UTF_8)); } }

用MediaStore的好处是绕开了复杂的路径权限问题，系统直接把Uri授权给了应用，不需要用户在文件选择器里额外点选。坏处是只适合媒体类文件，通用文件的类型覆盖不完整。

4.3 Android 13新增的媒体权限适配

Android 13（API 33）在媒体权限上做了一次重要拆分。系统不再要求读写都申请同一个存储权限，而是按媒体类型细分。

新版权限在AndroidManifest.xml中的声明如下：

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" /> <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />

运行时申请和普通危险权限类似：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { if (checkSelfPermission(Manifest.permission.READ_MEDIA_IMAGES) != PackageManager.PERMISSION_GRANTED) { requestPermissions( new String[]{ Manifest.permission.READ_MEDIA_IMAGES, Manifest.permission.READ_MEDIA_VIDEO, Manifest.permission.READ_MEDIA_AUDIO }, REQUEST_CODE_MEDIA_PERMISSIONS); } }

这里要特别强调兼容性处理。在Android 13以下的设备上，READ_MEDIA_IMAGES这些权限根本不存在，如果用checkSelfPermission检查它们会永远返回PERMISSION_DENIED。正确做法是先判断设备API level，再根据系统版本分为两条申请线路。Android 13及以上申请媒体细分权限，Android 12及以下申请传统存储权限。

5. 常见问题与排查技巧实录

5.1 文件写入成功但MediaStore刷新不出来

这个问题的经典场景是：使用MediaStore插入一张图片，数据库里能查到记录，但系统相册立即刷新时看不到。

我排查过很多次，最常见的原因是ContentValues中缺少了必要的字段，比如DATE_ADDED、DATE_MODIFIED、SIZE等。虽然在测试设备上系统可能宽容处理，但在某些厂商ROM上，这些字段缺失会导致媒体扫描器不识别文件。

解决方法是手动补全关键信息：

values.put(MediaStore.Images.Media.DATE_ADDED, System.currentTimeMillis() / 1000); values.put(MediaStore.Images.Media.DATE_MODIFIED, System.currentTimeMillis() / 1000); values.put(MediaStore.Images.Media.SIZE, file.length());

另一个原因是写入数据后没有正确关闭输出流。如果OutputStream没有关闭，数据可能还在缓冲区中，媒体扫描器读到的文件内容是不完整的，自然无法生成缩略图。所以务必用try-with-resources或者在finally中关闭流。

5.2 路径明明存在但File.exists()返回false

这种情况多出现在使用传统File方式访问公共目录时。表面上路径字符串看起来是合法的，但分区存储机制在底层已经拦截了应用对公共目录的文件访问权限。即便File.exists()返回true，后续的open操作也失败。

一次典型的报错现场像这样：

java.io.FileNotFoundException: /storage/emulated/0/Download/test.txt: open failed: EACCES (Permission denied)

排查思路是先确认设备系统版本和App targetSdk版本。如果是Android 10及以上，且targetSdk也是30以上，那么唯一正确的解决方案是重构为MediaStore或SAF方案，不要试图继续用绝对路径绕过。

有时候开发者在测试机上为了方便会开启“ADB通过错误权限检查”或者开启“所有文件访问权限”，这样写代码时一切正常，一旦发布到用户手机上就各种问题。所以在发布前务必在一台严格受控的、未开启任何开发者便利开关的设备上回归测试存储功能。

5.3 不同厂商ROM下路径差异引发的坑

国内厂商ROM的存储路径定制非常活跃，不同品牌、不同机型之间的外部存储挂载点差异很大。统一返回/storage/emulated/0还算好，但一旦涉及物理SD卡，路径就会变成/storage/XXXX-XXXX这种以字母数字组合命名的卷标。

写代码时千万不要写死SD卡路径，也不要只依赖Environment.getExternalStorageDirectory()。建议用StorageManager获取所有存储卷：

StorageManager storageManager = (StorageManager) getSystemService(STORAGE_SERVICE); List<StorageVolume> storageVolumes = storageManager.getStorageVolumes(); for (StorageVolume volume : storageVolumes) { File volumeDir = volume.getDirectory(); if (volumeDir != null && volumeDir.exists() && volumeDir.canRead()) { if (Environment.MEDIA_MOUNTED.equals(volume.getState())) { // 这个卷可用 } } }

getStorageVolumes()方法支持API 24+，老版本系统可以用getVolumeList()结合反射处理。如果项目最低版本要求不高，建议直接把minSdk提到24以上，省去很多兼容烦恼。

5.4 Android 11上使用SAF创建文件时遇到“无法完成此操作”提示

SAF（Storage Access Framework）是分区存储背景下访问公共文件的重要途径。用ACTION_CREATE_DOCUMENT调起系统保存对话框时，用户可以自行选择保存位置，并在确认后返回一个Uri，应用通过ContentResolver操作该Uri。

但不少开发者反映，在Android 11设备上，从系统文件选择器返回后，尝试openOutputStream时报错“Permission denied”甚至弹出“无法完成此操作，因为必须跳过某些项目”之类的提示。这通常是因为应用拿到的Uri没有持久化权限。

正确做法是调用takePersistableUriPermission保存Uri的授权状态：

int flags = Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION; try { getContentResolver().takePersistableUriPermission(uri, flags); } catch (SecurityException e) { e.printStackTrace(); }

这个步骤在onActivityResult中、确认拿到了合法的返回Uri后执行。如果不执行，Uri授权只对当前进程实例有效，App一旦被杀或重启，再次使用这个Uri就会权限丢失。

5.5 使用getExternalFilesDir后卸载应用仍有残留

getExternalFilesDir()目录在Android官方文档中明确指出会在应用卸载时被系统清理，但实际操作中确实存在部分场景清理不及时的情况。比如某些手机开启了“自动备份到云”，应用卸载后云备份的残留文件还在。另外，如果用户把外置SD卡设置为应用专属存储，在卸载时个别ROM也会出现清理不干净的现象。

对我来说最稳妥的做法是双保险：应用内提供数据导出功能，让用户主动把重要数据备份到公共目录或者云端；同时在onDestroy阶段主动清理无用的临时文件，不把清理工作全部交给系统。

6. 工具选型与调试验收总结

6.1 推荐的调试命令与工具积累

真机调试存储相关功能时，adb命令是很重要的辅助工具。我平时用的最多的几个命令：

# 查看当前存储挂载情况 adb shell df # 查看外部存储目录结构 adb shell ls -l /storage/emulated/0/ # 查看应用专属目录权限 adb shell run-as 包名 ls -l /data/data/包名/files # 查看运行时权限授予情况 adb shell dumpsys package 包名 | grep -i permission

前面两个命令可以直接确认文件到底有没有被创建、创建在哪个路径下。run-as在调试内部存储时很有用，但仅对debug版本有效。dumpsys package可以查看运行时权限状态，排查权限遗漏时很好用。

还有adb shell content query系列命令，可以查询媒体库条目：

adb shell content query --uri content://media/external/downloads

这个命令可以确认MediaStore插入操作到底有没有生成数据，非常直观。

6.2 测试覆盖建议

建议至少准备三类测试环境。第一类是一台Android 8或9系统的老设备，用来验证传统存储权限流程是否正常。第二类是一台Android 10或11设备，验证分区存储下的MediaStore和getExternalFilesDir流程。第三类是一台Android 13以上设备，验证READ_MEDIA_IMAGES等细分权限的申请与使用链路。

如果条件允许，再准备一台插了物理SD卡的机型，专门测试StorageManager多存储卷兼容逻辑。这样才能保证App在不同的存储环境下都有稳定表现，不至于出现在某个特定设备上存储功能崩溃的问题。存储卡文件操作看起来是Android基础中的基础，但实际涉及的系统机制和适配细节非常深，把基础打牢，后面做文件管理器、相册应用、下载管理这类项目时会顺手得多。