离线激活这件事并不新。Windows 时代的光盘序列号、电话激活、硬件绑定；工业软件的加密狗；再到今天嵌入式 / Android 端算法 SDK 的 .reg 授权文件——核心问题始终是同一个：

在没有稳定联网校验的前提下，如何证明「这台设备有权使用这份软件」？

1. 离线激活要解决什么

在线激活很简单：客户端上报身份，服务端查库，返回 token。离线场景则多了几道约束：

1. 设备可能长期无网（工控机、体检设备、专网平板）。
2. 授权必须可落地到文件或本地存储，卸载重装后仍能恢复（或明确要求重新申请）。
3. 要防简单拷贝：把授权文件拷到另一台机器应失败。
4. 厂商侧要能审计：哪台设备、哪个包名、授权多久。

于是几乎所有离线方案都会收敛成三步：

采集设备指纹 → 生成设备身份（Device Code）→ 用私钥/密钥签发授权（License）
                     ↑                              ↓
              运行时本地重算，与 License 内绑定身份比对

服务端（或厂商工具）只在「发卡」时出现一次；之后设备完全离线，靠本地校验。

2. 历史对照：Windows 光盘激活在做什么

早期 Windows / Office 的激活，表面上是「输入序列号」，背后同样是离线身份绑定：

光盘序列号解决的是「你是否买过」；安装 ID 解决的是「你是否在同一台机器上」。
离线算法授权把「买过」固化成文件，把「同一台机器」固化成设备指纹——思路一脉相承。

3. 一种典型的 Android 离线算法授权链路

下面描述的是一类常见实现（JNI 引擎 + 本地 .reg），便于理解「设备码从哪来、授权怎么验」。

3.1 启动与初始化

应用在 Application 中异步预初始化 SDK：

1. 释放 / 解压 runtime（模型、配置、so）。
2. 读取设备码 getDeviceCode(context)。
3. 调用 init(runtimePath, context, licenseContent)；licenseContent 为 null 时，从约定路径读取 .reg（例如应用外部文件目录下的 .reg）。

初始化结果用错误码表达：成功、授权为空、设备码不匹配、过期等。

3.2 设备码怎么来：先指纹，再编码

设备码不是随意字符串，而是「指纹材料 → 结构化文本 → 混淆 → Base64」的结果。

指纹材料（示例）通常包括：

• 应用包名 / applicationId（Context.getPackageName()）
• Settings.Secure.ANDROID_ID（Android 8+ 往往与签名密钥、用户相关）
• Build.MODEL / Build.PRODUCT 等机型信息
• 若干系统路径的 lstat 节点信息（如 /system/bin、/vendor/bin、/data/local）
• 可选：某个关键文件的创建时间（ctime）等「文件属性」

这些材料被拼成中间串，形如：

SOB_DEVICEcom.SOB.health#2#2#2#3#9#1327105@version:2.0

可读含义大致是：

• 前缀：渠道 / 机型标识（如 RK3588 类设备）
• 中段：包名
• # 分隔的数字：目录节点等离散指纹
• @version：指纹协议版本

再包一层 JSON：

{
  "fileattr": "",
  "uu_code": "YF_...#...@version:2.0"
}

随后做字符串混淆（按字符下标加减常量一类可逆变换），再 Base64。于是日志里会看到「很长一串像 Base64 的设备码」——无论激活前后，编码形态都一样；有的带 == 只是长度对齐填充，并不代表「激活态」。

3.3 授权文件 .reg 里有什么

.reg 同样是「混淆 + Base64」后的结构化数据，解码后类似：

{
  "auth_days": 29,
  "dkey": "501",
  "device_code": "<当初发卡时绑定的设备码>",
  "auth_date_time": "1775120635",
  "md5": "<完整性摘要>"
}

要点：

• device_code 是发卡那一刻的设备身份快照，写死在文件里。
• auth_days / auth_date_time 约束有效期。
• dkey、md5 以及 native 层可能存在的 AES / RSA 校验，用来防止「手改 JSON 再重新编码」。

没有厂商侧密钥，只能做出「格式像」的文件，过不了完整校验——这和伪造 Windows 确认 ID 一样。

3.4 校验时比的是什么

本地校验的关键日志形态往往是：

verifyDeviceCode local <本机现算设备码> user <License 内设备码> failed

逻辑很直白：

1. 用当前环境重新计算 local 设备码。
2. 从 .reg 解出 user 设备码。
3. 二者必须一致（通常还要过摘要 / 签名 / 有效期）。
4. 不一致则激活失败（例如设备码不匹配类错误码）。

因此：

• 「激活前 / 激活后设备码看起来不一样」，很多时候是误读：一个是本机现算（local），一个是文件里绑死的历史码（user）。
• 激活不会把设备码「升级成另一种 Base64」；成功时只是校验通过。

4. 通用设计范式（可复用的架构）

把上述实现抽象一下，离线激活可以落成下面这张图：

┌──────────────┐     指纹材料      ┌─────────────────┐
│  硬件 / OS   │ ───────────────► │ Device Fingerprint│
│  应用身份    │                  └────────┬────────┘
└──────────────┘                           │
                                           ▼
                                  ┌─────────────────┐
                                  │  Device Code    │
                                  │ (可展示给用户)  │
                                  └────────┬────────┘
                     用户把设备码发给厂商     │
                                           ▼
                                  ┌─────────────────┐
                                  │ License Issuer  │
                                  │ (私钥 / 卡密)   │
                                  └────────┬────────┘
                                           │ 下发 .reg / .lic
                                           ▼
┌──────────────┐   本地重算并比对   ┌─────────────────┐
│  运行时校验  │ ◄─────────────── │ License Store   │
└──────────────┘                  └─────────────────┘

设计时建议明确几件事：

1. 指纹稳定性策略

   • 要「重装仍可用」：避免把「仅随安装变化」的量写进指纹（或接受 ANDROID_ID 与签名绑定的语义）。
   • 要「防拷贝到别的 App」：把 applicationId、签名摘要纳入指纹。

2. 设备码展示形态

   • 给人看的可以是 Base64 / 分段码；内部应是可解析结构，便于客服核对包名与版本。

3. License 最小字段

   • 绑定设备码、生效/失效、产品线或功能位、完整性校验；密钥不要下发到客户端可逆区域。

4. 错误码语义

   • 区分：无授权文件、设备码不匹配、过期、文件损坏。运维成本会低很多。

5. 迁移与售后

   • 换机、刷机、改包名都要有「重新申请」流程；设备码应一键导出。

5. 为什么「包名和签名都对了」仍可能激活失败

同一台物理设备上，常见坑位：

1. License 仍是旧设备码签发的
   包名一致，但中间指纹段（如 #52#... vs #2#...）已变，local ≠ user。
2. ANDROID_ID 随签名变化（Android 8+）
   调试签名与正式签名不一致时，指纹会变。
3. 系统升级 / 分区变化
   依赖 lstat 节点一类因子时，系统更新可能导致数字段变化。
4. 授权文件路径不对或内容被截断
   读到空 license 与读到错误 license，错误码不同，但都是失败。
5. 把「user 码」当成「激活后本机码」
   日志里两串都在，需分清 local / user。

排查建议：解码（或日志输出）当前 uu_code，与 .reg 内 device_code 解码结果并排对比，看是包名问题还是数字指纹段问题。

6. 和加密狗、在线激活的分工

工业现场、医疗设备上的算法 SDK，之所以仍大量采用「设备码 + .reg」，是因为部署环境天然离线，且售后可以接受「导出设备码 → 厂商发卡 → 拷回文件」的人工闭环——这和当年打电话念安装 ID、听确认 ID 是同一类业务。

7.人话

角色：

• 海关
• 签发机构
• 人

人：身份特征的确定，也就是指纹，前面所谓的设备ID

签发机构：把人的指纹给到机构，机构给你颁发证书，内容包括：你的指纹，允许出关时长，盖章(防伪)

海关：校验签名，也就是看章是不是伪造的；不是伪造的对比你的指纹信息，发现指纹一致，按上面所显示的内容去执行允许出关