WinBoLL_Bck20260513_154646_588/docs/基于_sharedUserId_自有签名_LocalBroadcastManager_跨应用通信技术文档.md

基于 sharedUserId + 自有签名 + LocalBroadcastManager 跨应用通信技术文档一、技术方案概述本文档介绍同一设备下、两个自定义应用，通过配置统一 sharedUserId + 自有专属应用签名，结合 LocalBroadcastManager 实现应用间安全内网式广播通信的实现原理、安全机制、适用场景与约束限制。该方案核心特点：不走系统全局广播、仅自家签名应用互通、第三方无法嗅探拦截、无需跨进程 IPC 复杂绑定，适合自家多 App 之间状态同步、数据透传、服务实例共享等场景。二、核心配置前提1. 全局共享用户 ID 配置两个应用 AndroidManifest.xml 配置完全一致：xmlandroid:sharedUserId="cc.winboll.studio"android:sharedUserLabel="@string/shared_user_label"字符串资源统一：xml2. 统一应用签名机制两个应用必须满足：使用同一套专属 JKS 签名文件打包；签名私钥严格保密，不对外泄露；仅官方打包渠道使用该签名。三、底层运行原理系统对配置相同 sharedUserId + 相同签名的应用，分配同一个 Linux UID；共享 /data/data 私有目录、共享虚拟机运行环境、同进程内存空间；LocalBroadcastManager 原生设计为进程内内存广播，不经过系统广播总线；在同 UID 同进程机制下，两个 App 共享同一份内存广播注册表，A 应用发广播，B 应用可直接接收；非同款签名、非同一 sharedUserId 的第三方应用，无法进入该 UID 隔离域，完全无法监听、伪造、拦截广播。四、安全机制分析1. 双层隔离防护第一层：系统 UID 隔离只有匹配 sharedUserId 字符串 + 一致签名的 App，才能加入共享用户域。第二层：LocalBroadcast 内存隔离不注册到系统全局广播，不走 AMS 广播分发，仅在共享内存内流转，外部应用无入口嗅探。2. 防伪造、防窃听能力第三方即使猜到 sharedUserId 文本，无你的私有签名文件，无法匹配系统身份校验；无法伪装加入共享 UID 域，也就无法捕获广播数据；广播携带的 GPS 坐标、模拟状态、业务数据，不会泄露到外部应用。3. 相对系统全局广播的安全优势无需自定义权限申请、无需导出接收器；无被系统广播拦截、第三方静态注册嗅探的风险；通信延迟更低，纯内存转发，无跨进程开销。五、技术约束与注意事项LocalBroadcastManager 官方已废弃虽可用但不推荐长期依赖，可自行实现内存事件总线替代，逻辑完全兼容。Android 高版本进程隔离波动部分新版系统会主动拆分同 UID 应用进程，极端场景下广播可能失效，适合自用项目，不建议商用上架。应用升级必须同步两个 App 升级时需保持签名、sharedUserId 不变，否则会拆分 UID，通信失效。仅单机有效该方案仅限同一台设备内多 App 互通，不支持跨设备网络通信。六、适用业务场景自家多 App 之间 GPS 定位状态、模拟模式开关、坐标数据实时同步；多 App 共用同一个后台 Service 实例，通过广播下发控制指令；内部工具套件、私有生态应用间轻量通信，无需复杂 AIDL/ContentProvider；不想暴露全局广播、拒绝第三方监听的私有业务数据传递。七、总结基于 sharedUserId + 自有私有签名 + LocalBroadcastManager 的跨应用广播方案，在私有生态、自用套件、签名不泄露的前提下，安全可靠、轻量高效、接入简单；天然形成系统级隔离圈，第三方无法窃听伪造，完全适配内部多 App 状态同步与数据通信需求，是自用 Android 多应用联动的最优轻量方案之一。我可以帮你把这篇文档精简成标准版文档格式，或者改成 markdown 文件版本，需要吗？|（注：文档部分内容可能由 AI 生成）