简介：面向需要在Android应用中实现OTG外接U盘读写功能的移动开发者，这份资源围绕动态权限申请与反射调用系统私有API两大难点，提供了从权限声明、运行时请求到反射获取U盘路径、执行文件读写的完整实现方案，并覆盖Android 6.0及以上版本的外部存储适配思路。资源包共110个文件，以xml配置与布局、java与kt源码、gradle构建脚本、png图片资源及jar依赖为主，整体约518KB，结构清晰紧凑，适合具备Android基础、希望深入外部存储与USB OTG开发的进阶读者。目前已有1356人学习下载。通过学习可理解Android外部存储架构与权限模型，掌握MediaScannerConnection私有字段反射技巧及VolumeInfo挂载点识别方法，同时获得U盘读写异常处理、兼容性评估与系统版本演进方面的排错思路，可直接用于项目开发中的功能落地与代码调试，并有效规避私有API随版本变更带来的兼容风险。
1. U盘在Android上为什么难读：先从OTG挂载聊起
把U盘插到Android手机上，通知栏没反应，文件管理器里找不到盘符——这是我做文件管理类App时被问得最多的问题。很多开发者以为系统有公开API能直接拿到U盘路径，实际跑起来才发现Android根本没把U盘的挂载路径暴露给普通应用，路径藏在系统内部，要反射或者扫描mount表才能捞出来。下面从OTG挂载原理入手，把反射获取U盘路径的方案、读写权限处理、厂商差异和验证方法一次性拆完。适合做文件管理器、离线数据采集、固件升级模块的开发者，新手能跟着跑通，熟手可以直接抄参数和踩坑记录。
2. 反射获取U盘路径：原理、选型与核心代码
2.1 StorageManager与挂载点：先搞清楚数据从哪来
OTG U盘插入后，Android的vold进程会检测到新磁盘，按磁盘序列号分配一个挂载点。这个挂载点在AOSP原生系统里一般长这样：/storage/XXXX-XXXX，其中XXXX-XXXX是U盘分区的序列号或者UUID。但到了各家ROM手里，挂载点就五花八门了，/storage/usbotg、/mnt/media_rw/XXXX-XXXX、/mnt/usbhost、/storage/udisk都出现过。
U盘路径不是固定写死的，所以不能硬编码。系统内部由StorageManager维护一份已挂载卷的列表，其中每个卷对应一个StorageVolume对象，对象里有路径、是否可移除、是否主存储等信息。问题是，getPath()和isRemovable()这些方法在Android里被打了@hide标记，普通SDK里根本看不到，只能反射调用。
2.2 核心反射方法：双版本兼容写法
我一般会封装一个独立的工具类，把反射逻辑集中在一个方法里。下面这份代码可以直接复制进工程跑，不需要额外依赖。
public class UdiskPathHelper { public static String getUdiskPath(Context context) { String udiskPath = null; try { StorageManager sm = (StorageManager) context.getSystemService(Context.STORAGE_SERVICE); // Android 7.0 以下用 getVolumeList，以上部分ROM改成 getStorageVolumes Method method = null; try { method = StorageManager.class.getMethod("getStorageVolumes"); } catch (NoSuchMethodException e) { method = StorageManager.class.getMethod("getVolumeList"); } Object[] volumes = (Object[]) method.invoke(sm); if (volumes == null) { return null; } for (Object volume : volumes) { // StorageVolume 的 getPath / isRemovable 都是隐藏方法 Method getPath = volume.getClass().getMethod("getPath"); Method isRemovable = volume.getClass().getMethod("isRemovable"); String path = (String) getPath.invoke(volume); boolean removable = (Boolean) isRemovable.invoke(volume); if (removable && path != null && !path.isEmpty()) { // 过滤掉内置存储的 emulated 路径和用户目录 if (!path.startsWith("/storage/emulated") && !path.startsWith("/mnt/user")) { udiskPath = path; break; } } } } catch (Exception e) { Log.w("UdiskPathHelper", "reflect getUdiskPath failed: " + e.getMessage()); } return udiskPath; } }这段代码有两个关键点。第一，先尝试getStorageVolumes()，拿不到再退回getVolumeList()，顺序不能反，因为不少国产ROM虽然保留了旧方法，但返回值类型被改动过，直接用旧方法会抛ClassCastException。第二，isRemovable()返回true的卷不一定全是U盘，有些平板的TF卡也被标记为可移除，所以过滤条件里加了一层路径判断，避免把内置存储的镜像目录当成U盘。
反射返回的路径可能是/storage/AAAA-AAAA这种随机目录，也可能是/mnt/media_rw/BBBB-BBBB。前者是系统对外暴露的挂载点，普通应用有权限读；后者是vold的私有挂载路径，部分机型上直接File操作会Permission denied。所以拿到路径后不要急着返回，先做一层可读性校验。
2.3 为什么不用StorageManager的公开API
Android 7.0之后Google在StorageManager里加了getStorageVolumes()，表面上是公开API了，但这个公开只对系统应用和签名应用友好。普通应用调用时，很多厂商的ROM重新实现了StorageManager，方法签名看起来一样，返回的StorageVolume里getPath()却不再返回真实挂载点，而是返回一个应用沙箱路径，比如/storage/emulated/0/Android/obb。这类问题没有规律，同一套代码在一台机器上正常，换一台机器就拿到假路径，属于典型的黑匣子行为。
还有一个常见选型是SAF（Storage Access Framework），也就是ACTION_OPEN_DOCUMENT_TREE让用户授权。它的缺点是每一级目录都需要用户手动操作，自动化程度太低，而且拿到的是DocumentFile，不是真实的/storage/udisk路径，后面做MediaScanner扫库、跨进程共享文件都不方便。所以我的选型结论是：反射优先，mount表扫描兜底，SAF只在反射和扫描都失败时才用。
需要注意，反射方案拿到的路径是挂载点，不是物理分区，只有系统挂载完成之后才能安全访问，插上就读会拿到空目录。
3. 拿到路径之后：权限、复制与全盘扫描
3.1 USB Host与运行时权限：缺一个就白干
反射拿到路径只是第一步，权限不到位，路径就是一张废纸。AndroidManifest里有两个东西必须声明：USB Host功能声明和存储权限。
<uses-feature android:name="android.hardware.usb.host" android:required="true" /> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />uses-feature的作用是告诉系统这个App需要USB Host能力，有些设备厂商会据此在插U盘时给App弹USB授权框。如果不声明，插U盘时系统可能根本不给弹窗，反射出来的路径存在，但你读目录时永远返回空。
存储权限在Android 6.0及以上需要运行时申请，不能在Manifest里写完就完事。代码里要按标准流程走：
if (Build.VERSION.SDK_INT >= 23) { if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(this, new String[]{ Manifest.permission.READ_EXTERNAL_STORAGE, Manifest.permission.WRITE_EXTERNAL_STORAGE }, 1001); } }这里有一个血泪经验：WRITE_EXTERNAL_STORAGE在Android 6.0以上不能随便在requestPermissions里不声明就请求，部分ROM会直接拒绝授权，导致App崩溃。所以权限请求数组里要么两个都写，要么只请求READ，写操作通过File路径直接做。
3.2 从路径到文件列表：前缀过滤与根目录验证
拿到路径之后，第一步是列出U盘根目录下的文件。这里最大的坑是过滤条件不对，把内置存储当成U盘扫了一遍。我习惯把候选挂载点集中在一个数组里，逐个验证，确定哪个路径真正可用再往下走。
private File getUdiskRoot() { String[] candidates = new String[]{ UdiskPathHelper.getUdiskPath(context), // 反射结果 "/storage/usbotg", // 旧系统常见挂载点 "/mnt/media_rw", // vold私有路径，部分平板可用 "/storage/udisk" // 某品牌定制路径 }; for (String path : candidates) { if (path == null) continue; File file = new File(path); if (file.exists() && file.canRead() && file.isDirectory()) { // 再次排除内置存储 if (path.startsWith("/storage/") && !path.startsWith("/storage/emulated")) { return file; } } } return null; }这段代码里canRead()和isDirectory()是双保险。canRead()过滤掉那些反射拿到了路径但实际上没有权限的目录；isDirectory()过滤掉系统虚拟文件节点。注意/mnt/media_rw在部分机型上是个目录，但canRead()返回false，说明普通应用根本进不去，这时候就不要再试图listFiles()了，继续往下走候选路径。
3.3 复制文件到应用私有目录：FileChannel断点保护
U盘读写最常见的场景是把U盘里的数据文件复制到App私有目录，比如固件包、采集数据、离线地图。直接InputStream.read()逐个字节读会有两个问题：一是大文件撑爆堆内存，二是没有持久化记录，复制到一半失败要重新开始。
我一般用FileChannel做文件复制。它底层基于mmap，不经过Java堆，复制一个2GB的文件都不会OOM。
public static boolean copyFile(File src, File dst) throws IOException { try (FileInputStream in = new FileInputStream(src); FileOutputStream out = new FileOutputStream(dst); FileChannel inChannel = in.getChannel(); FileChannel outChannel = out.getChannel()) { // transferFrom 一次能传的最大长度受限于通道实现 outChannel.transferFrom(inChannel, 0, inChannel.size()); return true; } }参数上有一个容易翻车的点：transferFrom一次只能传Integer.MAX_VALUE个字节，也就是约2GB，超过这个数要循环分段传。代码里先取inChannel.size()，然后判断是否大于2GB，大于就按2GB一段循环。另外注意FAT32文件系统单文件上限是4GB，如果U盘格式是FAT32，复制超过4GB的文件会直接报“Invalid argument”，这不是程序问题，是文件系统限制，需要在UI层提前提示用户。
复制完成后不要立刻认为数据落盘了，建议再校验一遍目标文件的大小和源文件大小一致。这个习惯帮你避开不少玄学丢数据问题。
4. 实战排查：挂载延迟、路径失效与厂商差异
4.1 插入U盘后广播没来
现象：在Activity里注册了UsbManager.ACTION_USB_DEVICE_ATTACHED广播，插入U盘后有的机型能收到，有的机型完全没反应。
原因：部分ROM把USB设备广播和U盘挂载广播分成了两个事件，ACTION_USB_DEVICE_ATTACHED只代表USB层检测到设备，不代表vold已经完成挂载。另外，如果你在Manifest里没声明uses-feature，系统可能不把U盘当成host设备处理，广播自然不发。
解决：广播接收只作为UI提示，不作为启动读操作的时机。我在onResume()里做一个轮询——先把挂载点拉一遍，能读到目录就更新UI，读不到就等下一次onResume()再试。这个轮询逻辑比依赖广播可靠得多。
4.2 路径拿到了但File读取为空
现象：反射返回/storage/XXXX-XXXX，new File(path).listFiles()返回null或空数组。
原因：最典型的是速度太快，U盘刚插入，vold还在识别分区表、挂载文件系统，路径已经出现在StorageManager卷列表里，但目录尚未真正准备好。还有一种情况是拿到的路径其实是内部存储的镜像，前面isRemovable()过滤没生效。
解决：在反射工具类里对返回路径做一次File.canRead()校验，不通过就继续循环下一个候选路径。如果所有候选路径都不行，等待500毫秒后重试，最多重试5次。重试逻辑不要写死循环，否则在无U盘状态下会白白耗电。
4.3 某品牌手机上拿到的路径不可写
现象：在A厂商机器上读写U盘一切正常，换到B厂商机器后，反射出来的路径能读文件，但一写就报Permission denied。
原因：厂商把U盘挂载到了/mnt/media_rw/下的私有目录，这个目录对三方应用没有任何写权限。反射调用getPath()拿到的是/mnt/media_rw/XXXX-XXXX，而普通应用能读的公共挂载点应该是/storage/XXXX-XXXX，两个路径指向同一个物理分区，但权限完全不同。
解决：反射拿到路径后，做一次前缀重写——把/mnt/media_rw自动替换成/storage，如果替换后的路径存在且可写，就用替换后的路径。另外，写入前先执行一次File.canWrite()，失败就直接提示用户检查U盘是否处于只读状态，不要等到写入中途才报错。
4.4 中文文件名乱码与非法字符
现象：U盘里有一个测试报告.txt，listFiles()列出来变成一串乱码，或者列出来正常但File.getName()直接抛异常。
原因：FAT32文件系统默认使用GBK/CP936编码存储文件名，而Android的Java层默认按UTF-8解码，两边对不上就乱码。同时，/、\、:这些字符在FAT32里是非法字符，如果U盘是用Windows创建的，个别文件名可能带了非法字符，Java在new File时就会爆出FileNotFoundException。
解决：读取文件名时先用new String(name.getBytes("ISO-8859-1"), "GBK")做一次转码尝试，发现乱码再按UTF-8解码。创建新文件时，应用层强制限制文件名只允许数字、字母、_和-，从源头上避免非法字符问题。
4.5 反复插拔后路径变化
现象：同一个U盘，第一次插入路径是/storage/AAAA-AAAA，拔掉重插后变成/storage/BBBB-BBBB，之前保存的路径全部失效。
原因：Android按磁盘分区序列号分配挂载点，这个序列号在每次挂载时可能重新生成，尤其是一些量产U盘，序列号不固定，导致路径漂移。
解决：不要在任何配置文件、SharedPreferences里持久化U盘路径。每次进入页面时都重新反射扫描一遍，扫描结果只保存在内存变量里。如果App里多个页面都需要U盘路径，用一个单例持有最新值，插拔事件触发时刷新单例。
5. 进阶技巧：热插拔监听、容量获取与多U盘兼容
5.1 热插拔监听：不只靠广播
前面提到过只靠广播不靠谱，但不能完全不用。正确的做法是广播监听USB设备attach/detach事件，同时监听挂载完成事件。注册Receiver的代码很简单：
IntentFilter filter = new IntentFilter(); filter.addAction(UsbManager.ACTION_USB_DEVICE_ATTACHED); filter.addAction(UsbManager.ACTION_USB_DEVICE_DETACHED); filter.addAction("android.hardware.usb.action.USB_STORAGE_MOUNTED"); filter.addAction("android.hardware.usb.action.USB_STORAGE_UNMOUNTED"); context.registerReceiver(usbReceiver, filter);USB_STORAGE_MOUNTED是Android早期版本里用的action，现在很多ROM不发了，但加进filter里不影响。Receiver在onReceive里不能直接做耗时操作，比如listFiles()大目录扫描，要交给Handler线程。正确时序是：收到attach事件后等待500ms，再主动拉一次getUdiskPath()并校验canRead()，这一套流程基本覆盖了99%的机型。
5.2 获取U盘总容量与剩余空间
U盘读写前先查容量，可以在UI上提前拦截“空间不足”。Android里查文件系统容量用StatFs，参数是挂载点路径。
StatFs stat = new StatFs(udiskPath); long blockSize = stat.getBlockSizeLong(); long totalBlocks = stat.getBlockCountLong(); long availableBlocks = stat.getAvailableBlocksLong(); long totalBytes = blockSize * totalBlocks; long freeBytes = blockSize * availableBlocks;getAvailableBlocksLong()和getFreeBlocksLong()的区别很容易忽略：前者返回的是非root用户可用的块数，后者返回的是文件系统剩余块数。普通应用读写U盘时应该用getAvailableBlocksLong()，否则会在系统保留块上栽跟头，明明显示还有空间但写入失败。Android 6.0以下没有Long方法，只能用getBlockCount()乘getBlockSize()，注意int溢出问题，超过2GB的计算要用long强制转换。
5.3 多U盘同时接入怎么处理
OTG Hub接入多个U盘时，StorageManager卷列表里会同时出现多个可移除卷。我的实现里getUdiskPath()在找到第一个可移除卷后就break了，这在一个U盘的场景下没问题，多U盘就会漏。
处理方式是遍历时不去重，把所有可移除且路径可读的卷全部收集到一个List里，用路径作为唯一标识。同时监听ACTION_USB_DEVICE_DETACHED，将对应路径从List中按前缀匹配移除。为什么按前缀匹配而不是精确匹配？因为宿主机对hub下的每个U盘分配的路径前缀不同，但同一个U盘拔掉时广播携带的设备节点经常和List里存的路径对不上，这一步属于兜底匹配。
多U盘场景下，写入目标要明确给用户选择，不能默认往第一个盘写。我一般会弹一个选择框列出所有U盘路径和剩余容量，用户选完再执行复制动作，避免数据写到错误的盘上。
6. 验证方法：一个自检脚本与最终兜底方案
每次在真机上调U盘功能，先别写业务代码，把下面的自检清单过一遍。这张表是我在项目中沉淀下来的固定动作，能过滤掉百分之九十五的“代码没跑但功能失灵”问题。
| 检查项 | 操作方式 | 通过标准 |
|---|---|---|
| 挂载点存在 | adb shell dumpsys mount | grep udisk | 输出里能看到/media_rw或/storage/路径 |
| 路径可读 | App日志打印getUdiskPath()返回值 | 打印值非null且canRead()为true |
| 路径可写 | App日志打印root.canWrite() | 返回true，false则检查U盘写保护开关 |
| 权限已授权 | 系统设置应用权限页 | 存储权限为“允许” |
| 卷列表过滤 | 打印所有StorageVolume的path | 只出现真实U盘路径，无内置存储 |
我在工程里放了一个静态自检方法，每次联调前先跑一遍：
public static boolean checkUdiskReady(Context context) { String path = UdiskPathHelper.getUdiskPath(context); Log.i("udisk-check", "mount point = " + path); if (path == null) { return false; } File root = new File(path); return root.isDirectory() && root.canRead() && root.canWrite(); }这个方法返回false时不要急着改业务代码，按顺序排查：先看dumpsys mount里有没有挂载记录，没有说明U盘没被系统识别；有记录但getUdiskPath()返回null，说明反射逻辑要适配；返回了路径但canRead()为false，那是权限或挂载点私有路径问题。
最终兜底方案是SAF。如果反射和mount表扫描都失败，我会调用ACTION_OPEN_DOCUMENT_TREE让用户手动选U盘目录，拿到DocumentFile后通过getDocumentFile()继续后续读写。这套方案虽然自动化程度低，但胜在稳定，适合做功能上线前的最后一道防线。
从那以后，我每次做U盘读写联调都强制走一遍这套验证链：先开adb shell dumpsys mount确认底层挂载状态，再跑一次自检方法确认路径可读可写，最后才写业务逻辑。这个顺序帮我绕开了绝大多数“反射没失效但就是读不出文件”的玄学问题，也让团队新人在接手U盘模块时少踩好几个坑。希望帮到你。
本文还有配套的精品资源，点击获取
