Android 10+下plus.device.imei返回空或固定值是系统强制拦截，因谷歌自API 29起屏蔽普通应用访问硬件IMEI；应改用设备指纹或服务端绑定方案替代。
Android 10+ 下 plus.device.imei 直接返回空或固定值
这不是你代码写错了，是系统强制拦截。从 Android 10（API 29）起，普通应用调用 plus.device.imei 会得到空字符串、"000000000000000" 或抛出权限异常，即使已声明 READ_PHONE_STATE 并动态申请——因为谷歌在底层直接屏蔽了该接口的硬件访问路径。
实操建议：
- 不要在 onLaunch 里直接读
plus.device.imei，它大概率失败且触发无意义的权限弹窗 - 若仍需兼容旧设备（Android 9 及以下），可先判断
plus.os.name === 'Android' && parseInt(plus.os.version) 再尝试调用 - 调试时务必用真机 + 对应系统版本验证，模拟器返回值完全不可信
plus.device.getOAID 需要插件支持且仅限原生 App 环境
plus.device.getOAID 不是开箱即用的 API：它依赖厂商 SDK（如华为 HMS、小米 MSA、OPPO/ vivo 的 OAID 库），且只在「App 平台」的标准基座或自定义基座中生效；H5、小程序、快应用等环境直接报 undefined。
实操建议：
- 确认你打包的是 App（不是 H5），并在 manifest.json 中勾选「oaid 支持」（uni-app 项目需启用对应原生插件）
- 首次调用
plus.device.getOAID可能延迟 200–500ms（需初始化 SDK），建议在onLaunch中预热一次并缓存结果 - 必须加错误兜底：
if (!oaid || oaid === '00000000-0000-0000-0000-000000000000')视为获取失败 - 小米/OPPO/vivo 用户若未安装对应厂商服务框架（如“MSA 服务”），
getOAID也会返回空
真正稳定可用的方案是链式 fallback：OAID → android_id → 本地 UUID
单一标识符在安卓生态里注定不可靠。国内合规又实用的做法是按优先级逐层降级，而不是死磕某一个：
-
第一顺位：用
plus.device.getOAID（用户可重置，但符合隐私规范） -
第二顺位：fallback 到
plus.device.androidId（Android ID，恢复出厂设置会变，但卸载重装不变） -
第三顺位：生成并持久化一个本地 UUID：
uni.getStorageSync('device_id') || (function(){ const id = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, c => { const r = Math.random() * 16 | 0; return (c === 'x' ? r : (r & 0x3 | 0x8)).toString(16); }); uni.setStorageSync('device_id', id); return id; })()
注意：plus.device.uuid 不推荐作为主标识——它由 5+ Runtime 生成，不同基座、不同 uni-app 版本可能生成逻辑不一致，且卸载重装后必然变化。
权限弹窗时机错乱导致用户拒绝授权
很多开发者发现「明明没调 imei，却在启动时弹设备信息授权框」，这是 targetSdkVersion ≥ 26 后的典型问题：uni-app 初始化阶段会提前加载设备信息模块，触发系统权限检查，哪怕你后续根本不用它。
实操建议：
- 禁用自动初始化敏感字段：改用
plus.device.getInfo()替代直接读取imei/imsi属性，它不会主动触发权限请求 - 把所有设备标识获取逻辑收口到一个函数内，并加防抖和缓存（避免多次调用触发重复弹窗）
- 如果业务允许，把首次标识获取延迟到用户完成关键操作（如登录、进入首页）之后再执行，提升授权通过率
最常被忽略的一点：OAID 和本地 UUID 都解决不了「跨 App 共享设备身份」的需求。如果你的场景涉及多个自家 App 联动，得靠服务端统一绑定 token + 设备指纹（比如 UA + 屏幕尺寸 + 系统语言组合哈希），而不是指望客户端吐出一个“绝对唯一 ID”。
