企业官网建设流程全解析

简介：android平台ntfs-3g移植源码包，面向需要让Android设备读写NTFS格式TF卡、U盘或SATA硬盘的系统开发人员与嵌入式工程师，尤其适合车机、智能硬件等存储扩展场景，解决系统默认vold无法挂载NTFS分区的问题。源码已按Android工程习惯整理，解压到external目录下即可通过mm编译，也可把Ntfs.cpp与Ntfs.h加入system/vold，实现开机自动挂载；两种方式都便于集成到定制ROM中。资源共300个文件，以C源码和头文件为主体，另有Makefile与automake构建脚本、configure配置、man手册、多语言翻译文件等辅助内容，压缩包仅1.39MB，结构紧凑，适合快速移植与后续维护。目前已有1836人学习，内容覆盖ntfs-3g及ntfsprogs工具链，既支持手动挂载NTFS设备，也预留了开机流程接入思路；附带的man手册便于查阅各命令参数，对实际移植、排错和二次开发都有直接帮助。

1. Android平台的NTFS读写困局：这份可直接mm编译的ntfs-3g移植源码能解决什么

很多设备外接存储的方案里，最大的坑就是NTFS格式：Android原生没有写支持，插上移动硬盘要么只读，要么提示“不支持的文件系统”。要打通NTFS读写，最常见也最稳妥的是把ntfs-3g通过fuse方式跑在用户态。这份移植源码把这个过程打包了——源码放入Android源码树后直接mm，就能编出ntfs-3g、ntfs-3g.probe和libntfs-3g.so，省掉configure和交叉编译的手工适配。它解决的是系统定制、车载、工业平板外接NTFS盘读写的落地问题，适合需要自己控制挂载和权限的开发者。这篇笔记从源码结构、mm编译、挂载集成到避坑顺序讲一遍。

2. 移植包解剖：ntfs-3g源码在Android下的结构与适配点

2.1 源码包目录与核心模块：libntfs-3g、ntfs-3g与Android.mk的对应关系

打开移植包，迎面是一堆.c文件，但别被吓住。整个包按原版ntfs-3g的语义分成四块：libntfs-3g核心库、src工具目录、include公共头文件、libfuse-lite精简fuse库。最顶层的Android.mk是Android构建系统的入口，没有它mm就不知道该编什么。目录结构大致如下：

ntfs-3g-android/ ├── Android.mk ├── include/ │ ├── ntfs-3g/ │ │ ├── volume.h │ │ ├── attr.h │ │ └── ... │ └── fuse-lite/ │ ├── fuse.h │ └── fuse_common.h ├── libntfs-3g/ │ ├── dir.c │ ├── volume.c │ ├── compress.c │ ├── device.c │ └── ... ├── src/ │ ├── ntfs-3g.c │ ├── ntfs-3g.probe.c │ └── ntfsmount.c └── libfuse-lite/ └── fuse.c

各部分职责：libntfs-3g是真正干活的，NTFS的MFT、属性、压缩、加密都在这一层实现。src/ntfs-3g.c只是把库封装成命令行程序，通过fuse转发文件操作。ntfs-3g.probe.c是检测器，读设备前几个扇区判断是不是NTFS，返回值0表示是、非0表示否，自动挂载场景里这是安全阀门，防止U盘插上来还没确认格式就贸然挂载。ntfsmount.c则负责把fuse参数转换成内核挂载参数，但大部分Android裁剪版会弱化这个文件，因为Android的mount命令本身能处理fuseblk。

Android.mk与这些目录的对应关系不只是编译两个target。包里还带了ntfsfix、ntfsmkfs这类工具模块，有的默认打开，有的注释掉。保留它们的好处是量产测试时能直接对NTFS盘做修复和格式化，不用额外再编工具。我自己的项目通常把ntfsfix和ntfsmkfs一起编进去，它们在生产环境里省了不少事。

2.2 Android构建环境怎么影响ntfs-3g：Bionic、FUSE、共享库选型

这一节是“能不能编译过”的分水岭。桌面Linux用glibc，Android用bionic，两者在pthread、iconv、locale、ftw这些细节上差异很大。ntfs-3g源码本身是为glibc写的，直接拿给bionic编译，最常碰到的三个编译错误：

一是pthread函数找不到。bionic把pthread实现直接并进libc，没有单独的libpthread.so，所以Android.mk里残留的-lpthread必须删掉。二是iconv_open报undefined reference。bionic自带iconv能力，但头文件和glibc不完全一样，要么链接iconv相关库，要么在config.h里关掉HAVE_ICONV，让ntfs-3g走内部转换路径。三是struct stat的成员名差异，比如st_mtim在glibc下可用，在bionic下要换成st_mtim.tv_sec，这个用条件编译处理。

fuse层是第二个关键。ntfs-3g有两种工作路径：一是直接对设备块读写，不经fuse，但这种模式在Android下要处理内核锁和并发问题，基本不可取；二是通过fuse变成用户态文件系统，这也是Android外置存储的标准做法。完整版libfuse对Android不友好，它用到ulockmgr、daemonize、/etc/mtab这些经典Unix概念，链接时一堆undefined reference。libfuse-lite从这里裁剪出来，只保留fuse_main_loop、fuse_mount、fuse_exit等核心接口，把系统依赖减到能干净编译。

链接方式选型直接影响后续集成：

这份源码默认选第二种，实际用下来也是第二种最稳。vold在挂载前可能要调用libntfs-3g的库接口识别分区，动态链接正好把这一层留给集成者。

2.3 mm与普通make的区别：为什么必须放进Android源码树编译

普通Linux编译项目，configure脚本会自己探测编译器、库、头文件。Android源码树里不是这个逻辑，mm命令直接用当前lunch配置决定的sysroot、toolchain和crt文件。要编arm64设备用的产物，就必须在arm64的lunch环境里执行mm，否则编出来的是host工具或错误架构的二进制。

典型操作序列：

cd /src/android source build/envsetup.sh lunch aosp_arm64-userdebug cd vendor/xxx/ntfs-3g mm -j8

lunch aosp_arm64-userdebug决定了目标架构是arm64、目标API等级是当前源码分支的userdebug版本。换成aosp_arm-userdebug后，同一份源码mm出来的产物是32位arm，两个文件不能互换。所以编译前先确认环境：

echo $TARGET_ARCH echo $TARGET_PRODUCT

输出如果和设备不一致，重新lunch。这个检查我几乎每个项目都要做，因为很容易忙起来就忘了当前shell环境是哪个产品。

还容易迷惑的是mm到底做了什么。mm是make module的缩写，只处理当前目录Android.mk里列出的模块。很多人把mm当成全量编译，跑完发现镜像里没有，其实是没执行PRODUCT_PACKAGES对应的镜像打包步骤。mm负责“造文件”，PRODUCT_PACKAGES负责“装进镜像”，两件事顺序不能反。

3. 直接mm编译：从放置源码到出产物的完整流程

3.1 放置源码与编写Android.mk：一份最小可编译的构建脚本

源码包放进源码树的路径会影响后续维护。放vendor/ /ntfs-3g比较稳妥，因为它是厂商定制部分，不会跟着系统源码同步被清掉。放到external/ntfs-3g也可以，但用厂商源码树时，每次同步都可能覆盖external目录，vendor目录不会。量产项目里这一点很实际。

放好后看顶层Android.mk。移植包的写法通常把libntfs-3g、libfuse-lite、ntfs-3g、ntfs-3g.probe拆成独立模块，每个模块有自己的CLEAR_VARS和BUILD_*声明。下面的片段是核心结构，省略了一长串.c文件列表：

LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := libntfs-3g LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := \ libntfs-3g/volume.c \ libntfs-3g/attr.c \ libntfs-3g/dir.c \ libntfs-3g/compress.c \ libntfs-3g/runlist.c \ libntfs-3g/device.c LOCAL_C_INCLUDES := $(LOCAL_PATH)/include \ $(LOCAL_PATH)/include/ntfs-3g LOCAL_CFLAGS := -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include include $(BUILD_SHARED_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libfuse-lite LOCAL_SRC_FILES := libfuse-lite/fuse.c LOCAL_C_INCLUDES := $(LOCAL_PATH)/include \ $(LOCAL_PATH)/include/fuse-lite LOCAL_CFLAGS := -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H include $(BUILD_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := ntfs-3g LOCAL_SRC_FILES := src/ntfs-3g.c src/utils.c LOCAL_C_INCLUDES := $(LOCAL_PATH)/include \ $(LOCAL_PATH)/libfuse-lite/include LOCAL_CFLAGS := -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 \ -D_GNU_SOURCE -DFUSE_USE_VERSION=26 LOCAL_SHARED_LIBRARIES := libntfs-3g LOCAL_STATIC_LIBRARIES := libfuse-lite include $(BUILD_EXECUTABLE) include $(CLEAR_VARS) LOCAL_MODULE := ntfs-3g.probe LOCAL_SRC_FILES := src/ntfs-3g.probe.c LOCAL_C_INCLUDES := $(LOCAL_PATH)/include \ $(LOCAL_PATH)/libfuse-lite/include LOCAL_SHARED_LIBRARIES := libntfs-3g include $(BUILD_EXECUTABLE)

逐段解析：libntfs-3g模块编成共享库，libntfs-3g.so会被主程序和probe共同链接。LOCAL_EXPORT_C_INCLUDES把include路径导出给链接本库的其他模块，这样ntfs-3g和probe不需要重复写完整头文件搜索路径。libfuse-lite是静态库，不单独安装到镜像，而是链接进ntfs-3g可执行文件里，让fuse依赖直接消解在可执行文件内部。

LOCAL_CFLAGS里的-FUSE_USE_VERSION=26不能省。新版fuse头文件会根据版本号切换结构体字段布局，不指定时，默认值在不同版本间可能不一样，即使编译过了，运行时fuse协议版本也可能对不上，导致mount失败。这不是编不过的问题，是能编过但跑不动，属于看不见摸不着的排查黑洞。源码包里的Android.mk如果没写这个宏，建议一定加上。

参数调整场景：如果项目只需要挂载能力，不需要修复工具，把ntfsfix和ntfsmkdir相关模块注释掉，镜像体积能省几十KB。如果产品走vold集成，保留libntfs-3g.so，因为vold的C++层可能直接调用库接口，留着so是更干净的依赖边界。

3.2 执行mm与查看产物：编译命令、日志关键字与产物清单

执行mm前，我习惯先清理上一次产物，避免增量编译的脏obj带偏判断：

cd /src/android source build/envsetup.sh lunch aosp_arm64-userdebug cd vendor/xxx/ntfs-3g rm -rf out/target/product/xxx/obj/EXECUTABLES/ntfs-3g_intermediates mm -j8 2>&1 | tee build.log

-j8是并行编译线程数，不是越大越好。16核机器直接-j16可能因内存不足把编译进程杀了，反而没-j8稳定。日志里看两行就够：

target Executable: ntfs-3g Install: out/target/product/xxx/system/bin/ntfs-3g

如果只出现“target Executable: ntfs-3g”没有Install线，说明mm只做了编译和链接，没把产物拷贝到镜像目录。最常见原因是模块的LOCAL_MODULE_TAGS是optional且没通过PRODUCT_PACKAGES声明进包，或Android.mk里漏了安装路径配置。

查看产物架构和动态依赖：

file out/target/product/xxx/system/bin/ntfs-3g readelf -d out/target/product/xxx/system/bin/ntfs-3g | grep NEEDED

file输出会显示ELF 64-bit LSB executable ARM aarch64，架构不对就回头检查lunch。readelf输出里正常情况下会看到libntfs-3g.so、libc.so、libm.so，不会见到libpthread和libfuse，因为前者并进libc，后者被静态打包了。

3.3 把产物编进system镜像：PRODUCT_PACKAGES与分区选择

mm编译完，产物还只是“躺在out目录里的文件”。要随固件发布，必须在产品mk里声明。以device/ / / .mk为例：

PRODUCT_PACKAGES += \ ntfs-3g \ ntfs-3g.probe \ libntfs-3g

PRODUCT_PACKAGES的含义是“最终镜像里必须包含的模块列表”。编译系统从Android.mk注册的模块里找同名模块，编出来放进system分区。忘了这步，就算在源码树里编了一百遍，最终刷机镜像里也不会有这个文件。这就是mm管造文件、PRODUCT_PACKAGES管装车。

system分区放不下的场景很常见。车载、机顶盒这类产品system分区常被预装占满，可以把ntfs-3g挪到vendor分区。Android.mk里做两个修改：

LOCAL_MODULE_RELATIVE_PATH := . LOCAL_PROPRIETARY_MODULE := true

LOCAL_PROPRIETARY_MODULE=true会让产物落到out/target/product/xxx/vendor/bin和vendor/lib。然后在vendor对应的产品mk里加上PRODUCT_PACKAGES。注意SELinux策略对vendor分区的domain处理跟system分区不同，挂载时要额外确认。

调试阶段想跳过镜像打包，直接热替换文件到设备上也行：

adb root adb remount adb push out/target/product/xxx/system/bin/ntfs-3g /system/bin/ adb push out/target/product/xxx/system/lib/libntfs-3g.so /system/lib/ adb shell chmod 755 /system/bin/ntfs-3g

这套热替换对快速验证很有效，不需要重打整包。等确认没问题，再回到PRODUCT_PACKAGES声明正式进镜像。

4. 从编译到实用：挂载NTFS分区的三条集成路径

4.1 手动挂载：mount命令、参数与分区设备节点

直接在adb shell里手动挂载是所有方案的第一步。插上U盘后，用lsblk确认设备节点：

adb shell su lsblk

输出里找类似sda1的块设备，size和U盘容量对上就行。看到多个分区时，先确认哪个是数据分区，别把启动分区挂上去。然后挂载：

mkdir -p /mnt/usb mount -t fuseblk -o rw,uid=1023,gid=1023,fmask=113,dmask=022 /dev/block/sda1 /mnt/usb

mount -t fuseblk走的是内核的fuseblk文件系统类型，内核再调用用户态ntfs-3g执行真正读写。也可以直接执行ntfs-3g：

ntfs-3g /dev/block/sda1 /mnt/usb -o rw,uid=1023,gid=1023

两种方式最终都会调用同一个fuse主程序。区别在于mount命令是否在本机配置了fuse helper。如果mount -t fuseblk报“unknown filesystem type”，但ntfs-3g直接执行能成功，说明mount的helper路径没配好，优先用第二种方式。

参数设计原理：uid=1023,gid=1023是Android的media_rw用户，App层经过MediaProvider访问外接存储时，文件owner必须是media_rw，否则扫描不到。fmask=113表示对other用户去掉写权限，防止第三方App绕过MediaProvider乱改文件；dmask=022让目录可以被list和进入，但不能随便删别人的文件。调试阶段可以临时用umask=000，量产建议按fmask/dmask收紧。

挂载成功后，先验证读写：

echo test > /mnt/usb/test.txt cat /mnt/usb/test.txt sync /mnt/usb

写完必须sync一次再拔盘，否则缓存没落盘，数据容易丢。这一步是很多人忽略的。

4.2 开机自动挂载与热插拔：init.rc脚本与vold集成

手动挂载能做功能验证，量产需要开机自动识别NTFS U盘，常见两条路：init.rc service轮询，或vold扩展。

init.rc方案适合快速落地。定义一个oneshot服务，检测到设备节点后执行挂载脚本：

service ntfs_auto /system/bin/sh /system/bin/mount_ntfs.sh class late_start user root group root disabled oneshot

在init.rc的on boot阶段触发：

on property:dev.mount.ntfs=1 start ntfs_auto

对应脚本处理设备检测循环：

#!/system/bin/sh while [ ! -e /dev/block/sda1 ]; do sleep 2 done /system/bin/ntfs-3g /dev/block/sda1 /mnt/usb \ -o rw,uid=1023,gid=1023,fmask=113,dmask=022

这个脚本逻辑简单但能用，缺点是固定sda1节点，换个USB口可能变sdb1，轮询就废了。更稳的写法是动态探测：

#!/system/bin/sh for dev in /sys/block/sd*; do base=$(basename "$dev") if [ -f "/sys/block/$base/device/model" ]; then mount "/dev/block/${base}1" /mnt/usb && break fi done

真正能处理热插拔的标准路径是vold。vold由内核uevent事件驱动，自动挂载sdcard和usb otg。要让vold识别NTFS，需要fstab里声明voldmanaged，并给vold注册NTFS挂载实现。fstab配置：

/dev/block/sda1 auto auto defaults voldmanaged=usb:auto

vold拿到块设备后，按文件系统类型对照表找挂载方式。对照表里没有NTFS时，常见做法是让vold调用/system/bin/ntfs-3g，把挂载后的路径广播给StorageManager。这会涉及实现一个继承PublicVolume的类，重写doMount和doUnmount，工作量和风险比init.rc方案大一个量级，但热插拔、权限广播、多用户空间处理都走正规流程。如果产品要求“插上U盘自动弹窗”，就走vold，别用init.rc硬撑。

4.3 SELinux与存储权限：让App能真正读写NTFS盘

挂载命令能执行成功，不代表App能读写。Android 8以上强制SELinux enforce模式，挂载点、设备节点、ntfs-3g进程的domain规则缺一不可。在adb shell里执行mount时，shell进程的domain是shell域，默认策略不允许shell mount文件系统。

查看拦截日志：

dmesg | grep avc

如果dmesg只显示一行avc denied，信息不全，可以切换到events buffer：

adb logcat -b events | grep avc

典型日志：

avc: denied { mounton } for pid=2014 comm="ntfs-3g" path="/mnt/usb" dev="sda1"

处理思路：不要图省事给shell域放行mount，这个口子太危险。正确做法是把挂载动作转移到有权限的domain，Android里/media_rw本来就是负责外置存储读写的用户，所以最合理。在对应的te文件中添加：

allow media_rw block_device:blk_file { read write open ioctl getattr }; allow media_rw block_device:dir { read write open mounton getattr ioctl }; allow media_rw fuseblk:filesystem { mount getattr unmount };

补完规则后重编boot.img或vendor.img，开启enforcing验证。补权限时不要一把梭，宁可一条条加，加完跑一遍挂载、复制、删除测试，确认没放开多余权限。我见过有人把整个block_device放给shell域，结果安全测试直接打回。

5. 移植避坑指南：五条踩坑记录与排查方法

5.1 现象：mm编译报错“找不到ntfs-3g头文件”或“cannot find -lpthread”

现象：编译时出现fatal error: ntfs-3g/volume.h: No such file or directory，随后一串include链错误。另一种是链接阶段报cannot find -lpthread。

原因：LOCAL_C_INCLUDES路径没覆盖到include/ntfs-3g这一层。原版ntfs-3g头文件路径是include/ntfs-3g/xxx.h，源码里的#include写的是<ntfs-3g/volume.h>，编译器只在你指定的目录里查找。如果你只加了include目录本身，没加include/ntfs-3g，就会找不到。pthread的问题则是因为bionic把pthread实现并进libc，Android.mk里还残留桌面版Makefile的-lpthread参数。

解决：检查Android.mk的LOCAL_C_INCLUDES，确保include和include/ntfs-3g都写进去；把-lpthread删掉，线程函数直接用libc。用mm -j8重编，日志里不再出现这两个错误就说明头文件路径通了。

5.2 现象：产物编译成功，运行报“fuse: device not found”

现象：把编好的ntfs-3g推上开发板，执行挂载命令，终端输出“fuse: device not found”，挂载立即失败。

原因：目标设备内核没有/dev/fuse节点，说明CONFIG_FUSE_FS没有开启。不是所有Android内核都开fuse，一些功能机模组、IoT设备为了精简会关闭该配置。

解决：内核config里确认CONFIG_FUSE_FS=y，重新编译并烧录内核。验证/dev/fuse是否存在：

ls -l /dev/fuse

如果设备不允许改内核，另一个思路是走libntfs-3g的库接口直接读写NTFS分区，不走fuse挂载。但文件系统实时挂载能力就没了，应用层访问路径也要重写，工作量和风险都会放大。所以硬件选型阶段就把fuse支持作为硬性条件更保险。

5.3 现象：挂载成功，写入大文件后NTFS分区损坏

现象：拷贝一个2GB镜像到NTFS U盘，中途突然拔盘或设备断电，再在PC或Android上读盘，提示“需要修复”。

原因：ntfs-3g依赖fuse协议把写请求提交到内核，写缓存和元数据回刷时机受内核块层影响。写入过程中掉电时，NTFS日志机制虽然设计了回放，但异常场景下MFT或日志本身仍可能出现不一致。

解决：第一，不要用sync参数挂载，sync让每次写入强制落盘，反而会放大掉电损坏概率并拖慢速度。第二，在应用层对重要写操作做整体fsync，拷贝结束后主动落盘：

sync /mnt/usb

第三，量产方案建议在挂载前跑ntfsfix或probe检查dirty位，存在则引导用户先修复。如果产品允许，最好直接把U盘格式化为exFAT，避免NTFS日志复杂度带来的不确定性，这是产品设计阶段就要做的决策。

5.4 现象：挂载命令提示“Operation not permitted”，但dmesg里是avc denied

现象：在adb shell里敲mount命令，返回“mount: Operation not permitted”，不是“No such device”，也不是“Invalid argument”。查看dmesg只看到一条avc denied。

原因：SELinux在enforce模式下拦截了mount系统调用。mount命令权限不足，不是文件系统或设备问题。

解决：先临时切换permissive模式，确认挂载动作本身没问题：

adb shell setenforce 0 adb shell mount -t fuseblk ...

能挂上之后，按4.3节的规则给对应domain补te权限，再切回enforce模式重新验证。注意setenforce 0只对当前运行态生效，重启会恢复，千万别把permissive写进生产脚本。某些版本avc日志会被logd吞掉，dmesg只有一行时，用logcat -b events grep avc拿全量信息。

5.5 现象：拔掉U盘后挂载点残留，再次插入时挂不上

现象：热拔U盘后/mnt/usb目录还在，但ls /mnt/usb报Input/output error。再次插入U盘后，mount提示设备忙，挂载点无法恢复。

原因：拔盘时ntfs-3g进程没有收到umount请求，fuse连接一直保持，内核认为挂载点仍被占用，新插入的同一设备节点无法再次挂载。

解决：热拔前必须umount。vold方案里由vold统一卸载；init.rc方案则要监听uevent事件调umount。没有专门监听时，拔盘后执行：

umount -l /mnt/usb fusermount -u /mnt/usb

umount -l是延迟umount，先把挂载点从命名空间解除，再让fuse连接异步关闭；fusermount -u主动关闭fuse连接。如果系统里没有fusermount这个工具，至少执行umount -l。另外，热插拔场景建议给ntfs-3g挂载参数加-o sync_write，写入请求尽快落盘，避免拔盘瞬间的写回失败。

6. 验证与进阶：从编译通过到稳定量产的一点点经验

6.1 量产前的四轮验证清单

功能挂载只能证明“能用”，要到“能出货”还得跑完整测试。我建议的验证顺序：先做读写校验，往NTFS盘里写几个不同大小的文件（1KB、10MB、1GB），再用md5校验读回是否一致：

md5sum /mnt/usb/test.bin md5sum /本地缓存/test.bin

再做异常断电测试，写文件时直接拔电，插回后跑ntfsfix看日志回放是否正常。接着是100次拔插疲劳测试，每次挂载、写入、卸载三连，记录dmesg里有没有fuse死锁、system_server崩溃或SELinux异常。三轮过了，量产场景基本有底。

6.2 性能调节与参数建议

功能稳定后再调性能。默认mount参数只保证通用性，NTFS顺序读写在Android上会被fuse用户态拷贝拖慢速度。增加big_writes参数能改善顺序大文件拷贝：

ntfs-3g /dev/block/sda1 /mnt/usb \ -o rw,uid=1023,gid=1023,fmask=113,dmask=022,big_writes

big_writes允许fuse请求一次携带更大数据块，减少用户态和内核态之间的IO次数。普通4K随机小文件读写改善不明显，视频拷贝这类顺序场景提升明显。

6.3 收尾习惯

最后说一个从多次现场事故里养成的习惯：每次改完SELinux策略或mount参数，我都强制走一遍“插拔脚本+md5校验+dmesg avc检查”，确认没有permissive绕过才交出去。NTFS移植本身不算玄学，但每一步都藏着没测到的角落。这套源码包可以直接拿来mm编译，如果你正在做Android外接NTFS支持，可以下载后按这篇笔记跑一遍流程，能省下不少自己从configure踩到mm的时间。希望帮到你。

本文还有配套的精品资源，点击获取