简介面向MTK、高通、展锐三大移动平台的版本升级烧录工具合集适合设备厂商、开发者与售后维修人员使用覆盖固件全量升级、增量升级、底层加载、分区写入、驱动识别与故障恢复等常见场景。资源包共1031个文件压缩后181.59MB核心内容以zip固件包、exe程序、dll动态库、lib链接库、hex/bin固件镜像为主同时包含h/c/cpp源码、ini配置、log日志、vbs/pl脚本与PDF文档可辅助驱动安装、固件准备、设备识别及烧录验证。包内还提供多组DA下载代理文件配合SP Flash Tool、QFIL等平台工具即可搭建刷机环境并用日志复盘失败。已有1875人学习适合具备一定刷机经验的中高级开发者作为工具链备查清单也可用作维修固件收集与DA文件补充来源。1. MTK、高通、展锐平台版本升级烧录工具一个项目为什么得备三套刷机方案“MTK、高通、展锐平台版本升级烧录工具”这串词基本就是 Android 方案商、智能硬件和物联网模组工程师的日常刚需把一份新固件从电脑灌进设备里。系统内 OTA 升级做不到的场景——产线首次烧录、售后救砖、降级回滚、非 Android 设备的离线升级——全靠一台 PC、一根 USB 线和一套专用烧录工具。这三个平台的工具并不通用MTK 认 SP Flash Tool 和 preloader高通认 QDLoader 和 9008 模式展锐认 ResearchDownload 和 FDLoader。三套工具协议不同、驱动不同、踩坑的姿势也完全不同。本文按平台一条条拆怎么选工具、怎么把固件写进去、哪些参数不能乱动、砖是怎么刷出来的。适合手里有开发板或量产样机、正被版本升级逼到抓狂的嵌入式与 Android 工程师。2. 三平台烧录工具链全景下载协议、驱动和选型逻辑2.1 为什么 MTK、高通、展锐的烧录工具互不通用先说结论这三家 SoC 的芯片内部 BootROM 只认自家的下载协议。MTK 从上电后的 BROM 引导 preloader通过 DADownload Agent和 PC 端 SP Flash Tool 通信高通的紧急下载模式走的是 Sahara 协议PC 端由 QDLoader 驱动承载展锐这边叫 FDLoader配套研究与下载工具是一套独立的 UART/USB 协议栈。协议不同驱动不同所以“一根数据线通吃三平台”的想法趁早放弃。确实有一些通用工具能读底层比如开源社区做的 mtkclient 能读 MTK 分区但也只覆盖了单平台生态跨平台烧录还是要回到原厂工具链。实际工程中的选型逻辑我一般先按“设备当前处于什么状态”来判断走哪条路设备能进系统但用户无法完成 OTA优先adb reboot bootloader或adb reboot download进入对应引导模式然后刷指定分区设备黑屏、无法进入系统、按键无反应MTK 走 BROM 强制下载高通走 EDL 9008展锐走 FDLoader 强制模式产线首次烧录直接跳过系统引导上电瞬间由夹具触发进入下载模式不依赖设备状态。这三条路径的下载协议、驱动和工具选型完全不同。可以先用下面这张表框住整体平台芯片自带的下载协议PC 端主工具关键驱动适用场景MTKBROM / Preloader DASP Flash Tool、SP MDT、mtkclientMTK USB VCOM含 DA 驱动客户端显示 MediaTek Preloader COM 口产线烧录、单板调试、全分区备份高通Sahara / QDLoader (EDL 9008)QFIL、QPST、fastboot、QDLQDLoader 9008 驱动、Qualcomm USB 驱动救砖、量产烧录、bootloader 级维护展锐FDLoader / FDL1-FDL2ResearchDownload、UpgradeDownloadUNISOC USB 驱动、展锐 Download 驱动功能机、低端智能机、猫池模组升级这张表看着简单实际项目里最容易翻车的反而是驱动热词里最常见的“高通 qdloader 驱动”问题就是这样系统认成“Qualcomm HS-USB QDLoader 9008”驱动版本不对或者没关强制签名QFIL 就永远停在“Sahara Communication”超时。后面第 4 章把这类典型问题集中列一遍。2.2 工具选型研发、产线、售后各用哪一套研发阶段我建议优先做两件事备份和最小烧录。备份用的工具是 mtkclient对 MTK和 QFIL 的 Full Backup 选项对高通先把 boot、vbmeta、persist、nvram 这类小分区导出避免后面刷挂了连后悔药都没有。最小烧录则是只刷你改动的分区而不是整个闪存全量覆盖。比如 MTK 平台只更新 kernel 或 dtbo 时用 SP Flash Tool 的 “Download Only” 并把其他分区取消勾选就行高通平台则用 fastboot 单独写 boot.img。量产阶段优先考虑的是效率和一致性的平衡。MTK 产线现场用的通常是 SP Flash Tool 的工厂模式也叫副档模式Firmware Upgrade配置一个MTK_AllInOneDA.bin加一份 scatter 文件按分区表全量写入整个过程不需要人工干预太多。高通产线则两种主流方式老型号走 QFIL 配单个 rawprogram.xml patch.xml新型号走 fastboot 逐个分区flash。展锐量产多用 ResearchDownload 工程版配 research 脚本批量操作工业模组客户经常直接把工具集成进自己的测试工装里。售后维修场景和研发又不完全一样设备系统还能开机优先用 OTA 包或本地升级包设备无法开机才用烧录工具救。这里要注意 Android 12 之后的 OTA 升级逻辑App 调用系统升级接口后升级服务会校验包签名、版本号、防回滚标志任何一个不过就升级失败。热词里“mtk android12 app调用ota升级”说的就是这种场景应用层 OTA 失败后系统还能正常进完全不需要上烧录工具直接用adb sideload推送完整包往往就解决了。只有在 OTA 把系统写坏、起不来的时候才动 PC 烧录工具。2.3 启动模式与刷机的对应关系什么阶段进什么模式烧录工具的本质是在 SoC 还没运行完整系统前先跑一段最小引导代码来接收主机端的固件。这段最小引导代码在各个平台有不同名字MTK 叫 Preloader/BROM高通叫 SBL/EDL紧急下载模式展锐叫 FDLoader。理解这个启动顺序你就知道“为什么刷机有时候要短接、有时候只要按音量键、有时候只用 adb 命令”。MTK 的烧录流程是先让芯片进入 BROM 模式BROM 再从 PC 端接收 preloader 并执行preloader 再拉起 DADA 最终负责把 boot、system、vendor 等分区写入。所以很多 MTK 设备短接测试点让芯片停留在 BROM 阶段目的就是跳过 preloader 校验直接让主机接管。高通相反9008 模式下芯片直接进入 Sahara 协议通信PC 端 QFIL 通过 QDLoader 驱动发送 bootloader 镜像和分区表不需要用户手动选 preloader。展锐的 FDLoader 分 FDL1、FDL2 两段FDL1 是极小的引导FDL2 才是完整下载器PC 工具写 FDL1 时设备画面可能毫无反应但这恰恰是正常现象。把这套模式对应关系记下来现场排查会快很多。我常用下面的状态判断设备在哪一层平台引导代码对应的 PC 端口特征触发方式MTKBROMMediaTek PreLoader USB VCOMVID 0x0E8D短接测试点、空电池上电MTKDAMediaTek DA USB VCOMpreloader 自动拉起或 SP Flash Tool 自动加载高通Sahara/EDL 9008Qualcomm HS-USB QDLoader 9008adb reboot edl、按键组合、短接展锐FDLoaderUNISOC 或 Spreadtrum 端口长按音量键 插入 USB、短接测试点注意一个细节MTK 的 “DA USB VCOM” 和 “PreLoader USB VCOM” 是两种不同的端口SP Flash Tool 报错“DA 连接失败”时很多新手盯着设备管理器看到 Port 编号变了就以为驱动坏了其实是 DA 阶段被防回滚或 preloader 版本不匹配拦截了得先看工具日志而不是重装驱动。3. 动手烧录三个平台一份固件从镜像到设备的完整路径3.1 MTK 平台BROM Preloader 备份与写入的最小操作MTK 平台我现在的习惯是能用官方 SP Flash Tool 就不折腾需要做分区备份或写小分区时用 mtkclient因为 mtkclient 对 scatter 文件的解析更直观还能绕过一些官方工具的交互限制。先确认驱动Windows 下装好 MTK USB VCOM 驱动后把设备短接进 BROM设备管理器会多出一个MediaTek PreLoader USB VCOM端口。确认无误后用 mtkclient 做一次全分区备份python3 mtk.py r boot boot.img python3 mtk.py r vbmeta vbmeta.img python3 mtk.py r nvram nvram.imgr表示读read紧接着是要读的分区名第三个参数是保存镜像的文件名。分区名必须和 scatter 文件里定义的名字一致常见的固定分区有boot、vbmeta、system、vendor、nvram、persist。如果直接跑python3 mtk.py r而不带参数工具会尝试把所有可读分区导出耗时较长产线环境不建议这么干。读备份的价值在于刷vbmeta或persist前先留底后面验证防回滚和恢复出厂配置都用得上。写入操作同样简单但风险完全不同python3 mtk.py w vbmeta vbmeta.img python3 mtk.py w boot boot.img python3 mtk.py w boot boot.imgw是写write同样第一个参数是目标分区名第二个是本地镜像文件路径。这里有个必须强调的边界vbmeta分区在 Android Verified Boot 下写错一个字节整机开不了机且 fastboot 里也不一定看得到分区另外 mtkclient 写入时默认会加载配套--loader参数如果--loader指向的 preloader 版本和设备固件版本差距过大会卡在 DA 阶段表现为客户端无任何输出也就是大家常说的“mtk client 手机没反应了”。解决方式并不复杂把--loader换成和当前固件同版本的 preloader 文件或者去掉--legacy参数再试一次。SP Flash Tool 的操作路径则是另一套但原理和 mtkclient 一样加载 scatter 文件选Firmware Upgrade还是Download Only。前者会先做格式化再整包写入适合产线后者只写勾选到的分区适合版本升级。参数上注意Download-Agent用MTK_AllInOneDA.bin且不要随便替换否则串口通信时序对不上会随机中断。3.2 高通平台9008 裸板刷机与 fastboot 分区写入顺序高通平台的烧录路径比 MTK 清晰但分区顺序要求更严格。设备能开机时优先用 fastboot 刷写设备彻底黑屏才走 9008 EDL 模式用 QFIL 烧全量。能开机场景先把设备推入 bootloaderadb reboot bootloader fastboot getvar all fastboot flash boot boot.img fastboot flash system system.img fastboot flash vbmeta vbmeta.img fastboot flash persist persist.img fastboot rebootfastboot getvar all用于确认当前设备的分区槽位slot、解锁状态、已烧录的 bootloader 版本。高通从 Android 9 开始普遍引入 A/B 槽位写入时注意分区名是否带_a或_b后缀不带后缀写入默认当前槽位。vbmeta分区是验证启动的根里面存了防回滚版本号刷写顺序放在 system 之后是因为它要覆盖前面所有分区版本信息并最终锁定验证链。persist分区保存的是校准数据、序列号、WiFi 蓝牙地址多数项目里 persist 不允许随便格式化否则设备拿回产线要重新校准。fastboot erase persist fastboot flash persist persist.img这两条命令必须成套出现单独执行erase会直接清掉出厂校准数据造成传感器、屏、天线参数全部失效很多转手设备“屏幕亮了但传感器全失灵”就是这个原因。设备黑屏进不了 fastboot 时热词“高通410刷机开adb”的场景就出现了老平台和高通 410 这种低资源芯片配套驱动不全QWER——不用 QWER说回正题。我们要把设备拉进 9008adb reboot edl如果设备完全无响应就得用按键组合或短接测试点进 9008。进 9008 后设备管理器出现Qualcomm HS-USB QDLoader 9008QFIL 选择对应的 rawprogram.xml 和 patch.xml点 Download 开始烧录。烧录时注意flat_boot和meta_build两个参数flat_boot决定镜像以分区方式还是整块方式写入meta_build里带 modem 相关配置高通 mbn 的 volte 功能与它绑定。所谓“高通 mbn volte”本质就是 modem 配置包中与 VoLTE 能力相关的 mbn 文件固件升级时如果不把整个 modem 分区一起更新网络侧注册就会出现只有数据没有语音的情况。高通还有一个容易忽略的点SDX85 这类蜂窝模组的启动流程和手机不同烧录顺序必须是 xbl、abl、devcfg、boot 依次写入中间隔任何一步模组起不来且 9008 再次进入困难。原因是 SDX85 的 bootloader 在 xbl 阶段会校验后面几个镜像的签名顺序反了直接拒绝加载。所以做模组方案的高通项目烧录工具里的分区顺序别按字母排按启动链排。3.3 展锐平台ResearchDownload 的烧写流程与参数边界展锐平台在低端手机、功能机和物联网模组里占比很高但资料少、工具闭源是三个平台里最“黑匣子”的一个。工具主推 ResearchDownload老项目也会用 UpgradeDownload。上手第一步不是开工具而是确认设备有没有进入 FDLoader 模式lsusb | grep -i unisoc # 预期输出类似 Bus 001 Device 008: ID 1782:4008 UNISOC adb deviceslsxusb那行是在 Linux 下检测展锐 USB 口Windows 下对应设备管理器里的UNISOC USB Driver端口。如果lsusb查不到设备先换 USB 线排除数据线供电不足再检查是否短接触发正确。展锐的下载模式比较挑线材充电线普遍只有电源线没有数据线烧录工具会一直显示Wait for device, please power on the phone这种“设备没反应”绝大多数是线的问题。设备正确识别后打开 ResearchDownload加载升级包配置里就三个关键参数TOC 校验、FDL2 加载方式、格式化选项。展锐固件的分区表存在 TOC 里相当于高通 rawprogram.xml 与 MTK scatter 的合体。TOC 校验开启后工具会对比镜像头部的校验值防止错版本混刷产线不建议关研发单板调试为了省时间可以关。写入成功后做一次校验防止“提示成功但起不来”的尴尬adb shell getprop ro.build.version.incremental adb shell getprop ro.build.display.id这两条命令读的是系统版本增量号和显示版本号拿来和发布固件做核对最直接。展锐平台还有一个特殊习惯很多项目把校准参数放在calibration分区ReseachDownload 烧录时选“仅升级”模式不会触碰它但选“全擦”模式会连校准一起擦掉。新产品导入时因为烧录工具选错模式把产线校准数据和工厂 MAC 地址全部抹掉的案例并不少见。升级版本优先选仅升级模式只有整机返修或换主板时才用全擦。4. 烧录失败排查五个必踩的坑与现场处理4.1 现象MTK 客户端连接后没有任何日志输出工具界面卡死原因mtkclient 或 SP Flash Tool 连接时DA 与 preloader 版本不匹配或者 USB 端口被系统独占另一个常见原因是 Windows 下多个 VCOM 驱动同时抢占设备端口。热词“mtk client 手机没反应了”描述的正是这种现场。解决先关掉 SP Flash Tool、QPST 等可能占用端口的工具再用python3 mtk.py r boot boot.img --debug跑一次把 debug 输出里报错的地址段贴出来。如果是Handshake failed去和当前固件同版本的 preloader 文件指定在--loader参数上重试。不要反复插拔 USB这个动作会让端口枚举紊乱反而更难连上。4.2 现象高通 9008 已识别为 COM 口但 QFIL 报 Sahara Communication Error原因QFIL 发送 Sahara 握手包时设备端没有进入期望状态。最常见的是设备在 fastboot 模式而不是 EDL 9008或者项目固件使用的 Sahara 协议版本与 QFIL 自带的不一致。解决先执行adb reboot edl让设备确认进入 9008如果已经是 9008换 QPST 自带的 QFIL 版本不要用第三方魔改版。检查 rawprogram.xml 里的filename和partition名是否和当前固件配置一致错一个分区名Sahara 阶段合法进入下一步烧写阶段立刻中断。4.3 现象Windows 设备管理器里展锐/高通设备显示黄色感叹号驱动无法加载原因两家的 USB 驱动没有微软签名Win10 以上默认强制驱动签名会拦截尤其是从网上下载的 QDLoader 驱动和展锐 Download 驱动。解决临时关闭 Windows 强制签名重启进高级启动选项选“禁用驱动程序强制签名”装好驱动后再恢复正常启动。产线电脑建议用 Win10 LTSC 版本并提前把驱动用 pnputil 预装避免每次插拔都弹签名提示。4.4 现象高版本固件能刷旧版本固件刷一半提示失败或直接开不了机原因防回滚Anti-Rollback机制拦截。高通在 vbmeta 里写 rollback indexMTK 在 preloader 和 seccfg 里存 security config展锐在 TOC 里记录版本号。回滚时任何一级校验不过烧录直接中止。解决确认项目是否启用了防回滚。研发板一般关了验证但量产的机器大多开着。降级不能硬刷要去 bootloader 或 preloader 层把 rollback index 一起处理。不要试图绕过——工程上最安全的做法是保留一个和量产版本同级的“开发签名固件”需要降级时先刷开发板配置再刷目标版本。4.5 现象系统内 OTA 升级失败随后按维修流程刷机全量烧录后设备无法开机原因App 调用 OTA 升级时只更新了 system 分区vendor/boot 版本不匹配设备处于半升级状态。此时直接用 PC 烧录工具做了全量格式化把原本能引导的旧版本 bootloader 也一起覆盖新 bootloader 又不兼容旧的 vendor 镜像。解决任何来自“OTA 升级失败”的机器先别急着全擦。进 bootloader 或 download 模式只写 boot 和 vendor 分区和 system 版本拉齐实在起不来再全量烧。这里嵌一句热词里的“oclp 在系统设置里直接进行 ota 小版本升级”——小版本升级走系统设置即可但大版本跨版本升级一旦中途断电后台服务下次启动会做恢复恢复失败只能离线烧录工具兜底。5. 产线化和回归验证从单台刷机到批量升级的收尾技巧单台刷通之后真正决定这个方案能不能落地的是两件事批量如何做烧完如何验证。我个人的做法是给产线写一个最小的循环脚本把所有校验集中在一个输出里#!/bin/bash # 批量烧录后的回归验证脚本适合产线或售后批量处理 for serial in adb devices | grep -w device | awk {print $1} do adb -s $serial wait-for-device versionadb -s $serial shell getprop ro.build.version.incremental paneladb -s $serial shell getprop persist.sys.panel echo $serial $version $panel result.txt done脚本逻辑不复杂先遍历所有已连接的设备序列号逐个等待系统起来读版本号和屏参属性统一落进 result.txt。产线上看这份文件就知道哪台刷成功、哪台没起来、哪台屏幕参数不对。验证点不要只盯着ro.build.version.incremental屏、TP、WiFi MAC、序列号这四个属性在刷机后最容易丢全部打出来再做一次 grep 核对。进阶一点的做法是在烧录工具之外加一层固件 hash 校验。每个分区镜像打包时生成 SHA256烧录完成后对设备里的分区做一次相同 hash 比对adb shell sha256sum /dev/block/bootdevice/by-name/boot sha256sum boot.img比对两条输出是否一致能快速判断到底是烧录问题还是系统本身问题。这批验证做完再回到功能层面查 GPS、VoLTE 这类依赖 modem 配置的功能因为 mbn 或 calibration 分区被误擦的情况hash 校验不一定看得出来必须真机插卡测一次注册。最后说一个我自己的习惯每次给新平台搭建烧录环境不管能不能开机先把 persist、nvram、modem 这三个分区各导出一份做备份。MTK 的写坏 nvram 会丢 WiFi 校准高通的写坏 persist 会丢序列号展锐的 calibration 坏了一次产线要花半小时重新校准。备份花五分钟救砖救一天。这套烧录工具的方向值不值得投入我的答案很直接只要产品在出货烧录工具链就不能缺它和 OTA 是两条腿OTA 管日常烧录管兜底兜底做得越稳售后和产线的损失越小。希望帮到你。本文还有配套的精品资源点击获取