是什么、怎么做（方法概述）#

为什么（原理、问题避坑）#

对于【固件修改计划】：因为该设备搭载的 VelaOS 在底层限制了可安装的快应用总数，所以我删除了vela_quickapp分区里的全体系统预置快应用（除了“微信”和“融合设备中心”）。这样虽不能从根源解决问题，但仍能有效提升可安装快应用的数目。

删除vela_quickapp分区里的系统预置快应用不会对手表的正常运行造成任何影响。因为该操作不涉及代码修改，仅为简单的“系统精简”操作。如果您需要使用系统预置快应用（如“网易云音乐”等），请前往**该资源帖**进行下载。

对于【固件修改脚本】：因为小米官方未对vela_quickapp和vela_fonts分区做特征校验功能，所以可以通过 Python 对这两个分区里的内容进行修改。

• 因为这两个分区都是 romFS 格式的只读分区，所以脚本对两个分区的操作流程都是提取分区内文件、修改分区内文件、重新打包分区。
• 对于字体的修改，使用了 Fonttools 库把任意 .ttf 格式的字体元数据伪装成 MiSans，以骗过系统中可能的字体名称检测。

**切记！你所修改的字体大小不能超过原 MiSans 字体的大小！否则可能会导致其它分区数据被覆盖，最终致使系统无法正常启动。**这一点我在脚本中做了校验，一旦发现字体大小超出范围就会拒绝修改并回滚操作。但在实际使用中还是请多注意！

逻辑层：第一道报警哨卡 (13个限制)#

这是最外层的限制，表现为系统在安装时主动弹窗拦截。

• 发现因素： 固件中存在 CMP R1, #13 指令。
• 原理： 系统在安装快应用前会查询当前已安装列表的计数（Count），如果该值大于 13，逻辑分支会直接跳转到报错流程。
• 表现： 弹出“存储空间不足”的虚假提示，虽然此时 Flash 空间其实非常充裕。
• **解决方法：**使用十六进制编辑器，将#13修改为#64。意为“在逻辑上，将最大快应用安装数量改为64”。
• **是否解决问题：否。**手表仍只能安装最多 20 个快应用。

物理校验层：第二道硬性防线 (20个限制)#

即使绕过了 13 个的报警，系统在更深层的代码里还有一处针对“20”的硬性校验。

• 发现因素： 在安装器的核心逻辑区发现了 CMP R0, #20 (0x14)。
• 原理： 这是一个“死命令”，用于验证当前处理的应用索引号。如果索引号达到 20，即使检票员（第一道哨卡）放行了，后台的记录员（安装执行逻辑）也会因为数值超限而拒绝执行。
• 意义： 这解释了为什么删除了内置应用、腾出了名额，却依然无法突破 20 个总数的原因。
• **解决方法：**利用十六进制编辑器，将#20修改为#99。意为“在核心逻辑上，允许安装器接受 99 个快应用计数”。
• **是否解决问题：否。**手表仍只能安装最多 20 个快应用。

数据结构层：跳转表与数组长度 (跳转表溢出)#

这是最隐蔽、也是技术难度最高的一处限制。

• 发现因素： 发现了 TBH (Table Branch Halfword) 指令及配套的跳转表。
• 原理： 系统的快应用管理函数使用了一个 switch-case 结构的跳转表。这个表在内存中是定长的（只有 20 个条目）。
• 后果： 当尝试安装第 21 个应用时，程序会试图在跳转表中寻找第 21 个“座位”的地址。由于表长只有 20，程序会读取到表后的无关数据作为内存地址进行跳转，导致非法指令执行（Illegal Instruction）或系统保护性拦截。
• 解决方法：修改底层代码，将跳转表长度改为64。
• **是否解决问题：否。**手表仍只能安装最多 20 个快应用。