@@ -1,135 +0,0 @@
# 安卓工作手机部署与防破解技术方案
> **适用场景**：工作手机 SDK / 存客宝 AI 手机控制引擎 · 以「预装卖手机」为基准 · 安装在手机端完成工作 · 重点防破解与二次分发
> **文档归属**：
> **更新**：
---
## 一、目标与约束
| 维度 | 说明 |
|:---|:---|
| **业务目标** | 应用直接安装在安卓工作手机上，用该手机完成私域/流量/自动化等工作；以「卖手机」为交付形态，设备与账号可控。 |
| **安全目标** | 防破解、防二次打包、防提取核心逻辑与密钥；提高逆向成本，保证商业与数据可控。 |
| **约束** | 需兼容现有工作手机 SDK 架构（设备端 Agent + uiautomator2/Frida、云端 WebSocket + 指令下发）；可与存客宝/触客宝对接。 |
---
## 二、技术路线全量对比
### 2.1 客户端形态对比
| 方案 | 描述 | 防破解能力 | 适配「卖手机」 | 开发/维护成本 | 结论 |
|:---|:---|:---|:---|:---|:---|
| **原生 Android（ ） | 单一 APK， **首选** |
| **原生 + H5/WebView 壳** | 壳为原生，部分 UI/逻辑在 Web； ， ） **推荐组合** |
| **Flutter** | Dart 编译为 Native， （
| **React Native** | JS Bundle 易被提取，
| **PWA / TWA** | 浏览器内核，依赖 Web | ⭐⭐ 依赖 Web 安全，本地无强控制 | ❌ 不适合「卖手机」强管控 | 低 | 不推荐 |
### 2.2 与项目现状的匹配度
- **工作手机 SDK 现状**：设备端为 Agent（ ； ， **Android 原生客户端** ：负责注册设备、建连、接收指令、调起自动化能力（或通过 ADB/本地服务与现有 Agent 协同）。
- **以卖手机为基准**：预装 APK、设备唯一标识绑定、远程禁用/擦除能力，均更适合 **原生 Android** 实现；防破解则依赖「原生 + 加固 + 关键逻辑上云」。
---
## 三、防破解方案分层
### 3.1 应用层加固（必做）
| 措施 | 说明 | 实施要点 |
|:---|:---|:---|
| **DEX 加密与多 DEX** | 核心 DEX 加密存储，运行时由壳/Application 解密加载 | 代理 Application、不侵入业务代码； ～
| **代码混淆** | ProGuard/R8 全量混淆，保留与 native/反射相关的 keep 规则 | 生成并保存 mapping.txt 便于线上堆栈还原 |
| **控制流混淆** | 控制流平坦化、虚假分支、间接跳转 | 对抗反编译与自动化分析，可与加固厂商方案结合 |
| **资源与 so 保护** | 资源加密/混淆、Native so 加固与反调试 | 防止资源与 so 被直接提取与篡改 |
### 3.2 完整性与环境检测（必做）
| 措施 | 说明 | 实施要点 |
|:---|:---|:---|
| **签名校验** | 校验 APK 签名与预期一致，防二次打包 | 启动时 + 关键操作前校验；校验逻辑可放 Native |
| **Root/模拟器/Hook 检测** | 检测 Root、模拟器、Frida/Xposed 等 | 检测到可限制功能或仅上报不直接崩溃，避免误伤 |
| **完整性校验** | 对 DEX/so 做哈希，与服务端或本地白名单比对 | 可与启动时 token 一起上报 |
### 3.3 通信与后端安全（必做）
| 措施 | 说明 | 实施要点 |
|:---|:---|:---|
| **HTTPS + 证书锁定** | 仅信任指定证书/公钥，防中间人 | 预置证书或公钥 pinning |
| **请求签名** | 关键接口带签名（如 deviceId + timestamp + nonce + 密钥） | 密钥不出现在 APK 内，或用服务端下发临时密钥 |
| **设备绑定** | 设备唯一 ID（
| **Token 与刷新** | 访问令牌短期有效，刷新令牌安全存储 | 使用 Android Keystore 存敏感材料 |
### 3.4 架构层：关键逻辑上云（强烈推荐）
| 做法 | 说明 | 效果 |
|:---|:---|:---|
| **指令与策略下发** | 核心「做什么」由服务端下发，端侧只做「执行 + 上报」 | 即使 APK 被逆向，拿不到完整业务规则与密钥 |
| **密钥与配置动态化** | 敏感配置、密钥由服务端在鉴权后下发，不写死 APK | 降低 APK 内敏感信息价值 |
| **风控与禁用** | 服务端根据设备/行为做风控，可远程禁用设备或降级能力 | 与卖手机场景契合，设备可控 |
---
## 四、推荐技术栈（最终方案）
### 4.1 总体选型
- **客户端**： （ ） **加固（ + **关键逻辑上云** 。
- **可选增强**：壳内嵌 **WebView** 承载部分运营/活动页，减少发版频率，核心能力仍走原生与后端。
### 4.2 技术栈清单
| 层级 | 技术选型 | 说明 |
|:---|:---|:---|
| 语言与框架 | Kotlin + Jetpack | 原生开发，与现有 Android 生态一致 |
| 构建与混淆 | AGP + R8/ProGuard | 混淆与优化，保留 mapping |
| 加固 | 第三方加固（ ）
| 网络 | OkHttp + 证书 Pinning | HTTPS，
| 安全存储 | Android Keystore | Token、密钥等敏感数据 |
| 设备标识 | 合规组合（如 AndroidID + 厂商 OAID 等） | 与后端设备绑定、风控一致 |
| 与现有 SDK 协同 | 通过 Binder/本地服务或 ADB 与既有 Agent 通信 | 保持与工作手机 SDK 架构兼容 |
### 4.3 与工作手机 SDK 的衔接
- **云端**：继续使用现有 **工作手机 SDK 服务端** （
- **设备端**：
- **方案 A**： （ ） ， ，
- **方案 B**：将部分自动化能力用原生 Android 实现（如 AccessibilityService） ，
两种方案均可；选型时权衡「开发量」与「对现有 Python Agent 的依赖」。
---
## 五、实施步骤建议
1. **Phase 1：
- 原生 Android 工程（ ） ， ： ）
- 签名与 ProGuard 开启，无加固也可先跑通流程。
2. **Phase 2：
- 接入加固（
- 实现签名校验、Root/模拟器检测、HTTPS 证书 Pinning、请求签名、设备绑定与 Token 管理。
3. **Phase 3：
- 核心指令与策略由服务端下发；端侧只做执行与上报。
- 服务端设备风控与远程禁用/降级能力，与「卖手机」流程打通。
4. **Phase 4（ ） ：
- 部分运营/活动用 H5，
- 配置与灰度可由服务端控制，减少发版。
---
## 六、文档与引用
- **工作手机 SDK 架构**： `开发/2、私域银行/工作手机/开发文档/2、架构/系统架构.md`
- **卡若AI 土渠手机自动化**： `05_卡土（ ）
- **Soul 技术基线参考**： `开发/2、私域银行/工作手机/开发文档/平台分析/Soul/调研/06_参考Soul开发APP的技术基线与实现方式.md`
- **防破解可延伸阅读**：
---
**结论** ：以「安卓直接安装 + 工作手机使用 + 卖手机为基准 + 防破解」为目标，**首选「原生 Android（ ） ，
