从权限申请到能力边界控制：CheckMe 的 HarmonyOS 安全隐私实践

摘要

很多人一提到“安全隐私”，就以为是纯合规话题，和技术实现关系不大。但在 CheckMe 这个设备信息类项目里，安全隐私恰恰体现在大量具体代码细节里，比如权限按需申请、能力先检测后调用、敏感信息不伪造、受限能力保守处理等。本文将结合项目实现，拆解一个 HarmonyOS 工具类应用该如何更克制、更专业地处理安全隐私问题。

四个主题适配说明

这篇文章的主方向是 安全隐私，重点讲权限按需申请、能力先检测后调用、受限数据保守处理和本地化展示。它也能补充 创新体验，因为低打扰、可解释的权限体验本身就是更好的使用体验；补充 能力增强，因为权限管理、LocationKit、CameraKit 等能力需要在边界内正确接入；补充 高端精致，因为可信、稳定、不过度索权的工具应用比堆满不可靠数据的页面更有完成度。

一、为什么设备信息类应用天然更容易碰到隐私边界

CheckMe 这种项目看起来只是做设备信息展示，但实际上会接触到很多容易越界的能力：

• 定位
• 相机
• 网络状态
• 设备基础信息
• 蓝牙和传感器

如果处理不好，就容易出现两个问题：

1. 权限开得太大

项目一开始就申请一堆权限，用户会产生强烈不信任感。

2. 数据展示过度包装

有些拿不到的数据，为了“显得功能齐全”而硬凑，这会直接影响可信度。

所以我在做 CheckMe 时，给自己定了一个原则：

能力按需使用，权限按需申请，拿不到的数据不伪装成拿到了。

二、项目里哪些地方体现了权限按需申请

先看模块声明：

项目声明的权限主要和真实功能直接相关，比如：

• ohos.permission.GET_NETWORK_INFO
• ohos.permission.GET_WIFI_INFO
• ohos.permission.INTERNET
• ohos.permission.APPROXIMATELY_LOCATION
• ohos.permission.LOCATION
• ohos.permission.CAMERA

这里我没有为了“未来可能会用”而把权限全部铺开，而是尽量只保留当前功能真正需要的部分。

这一步虽然看似简单，但其实就是安全隐私意识的第一层体现。

三、权限声明只是起点，真正关键的是运行时策略

即使在模块里声明了权限，也不代表功能一上来就应该直接调用。

例如项目中的手电筒能力：

这里的实现思路不是“先调接口再看报错”，而是：

1. 先检测设备是否支持
2. 再判断权限是否已授予
3. 必要时再请求权限
4. 最后执行操作

比如先只做能力提示：

public async getTorchCapabilityHint(context: common.UIAbilityContext): Promise<string> {
  try {
    const camManager: camera.CameraManager = camera.getCameraManager(context);
    if (!camManager.isTorchSupported()) {
      return '设备不支持';
    }
    const granted: boolean = await this.isCameraPermissionGranted(context);
    if (!granted) {
      return '需相机权限';
    }
    return '可用';
  } catch (_e) {
    return '检测失败';
  }
}

这种写法会带来明显好处：

• 用户在点击前就知道当前能力是否可用
• 不会无意义弹权限框
• 项目看起来更专业、更克制

四、定位模块为什么最能体现“安全隐私不是口号”

项目中的定位能力可以用 LocationService 统一封装：

这里我特别重视几件事。

1. 先判断系统定位是否开启

if (!geoLocationManager.isLocationEnabled()) {
  return {
    location: null,
    failureReason: LocationFailureReason.SERVICE_DISABLED,
    failureHint: '系统定位服务已关闭。请在「设置 > 位置信息」中开启定位。'
  };
}

2. 再处理权限申请

const permissionOk: boolean = await this.requestLocationPermissionsIfNeeded(context);
if (!permissionOk) {
  ...
}

3. 就算拿到坐标，也区分地址解析是否成功

也就是说，项目不会把“有坐标”和“有完整地址”混成一件事，而是分别判断、分别反馈。

这种写法的核心价值是：用户永远知道当前失败在哪一层，而不是笼统地看到一个“定位失败”。

五、受限能力为什么不能为了好看硬凑数据

这一点在 DeviceInfoService.ts 中体现得很明显。

例如 SIM 卡信息和音频信息部分，项目没有为了“功能全”而拼一些不可信内容，而是选择了更保守的处理方式。

这种策略看似“少了一些展示”，但实际上提升了项目可信度。因为对于设备信息类应用来说，用户最不希望看到的就是：

• 看起来功能很多
• 但一细看都是不准确的数据

所以我更愿意在拿不到时明确返回 null 或空结构，而不是把猜测值包装成真实值。

六、为什么能力边界控制也是项目质量的一部分

很多人做工具类项目时，容易把“能调多少能力”理解成“项目越强”。但在我看来，真正成熟的能力控制更像这样：

• 先判断这个能力第三方应用是否真能稳定落地
• 再判断当前设备是否支持
• 再考虑是否值得对用户开放

例如在 ToolsService.ts 中，项目有一段注释我很认同自己的这个取舍：

仅保留第三方应用可真实落地的能力

这意味着：

• 截屏、录屏、扫码等如果依赖系统封闭能力，就不强塞进项目
• 只保留当前真正可做、可解释、可维护的工具能力

这其实就是一种很实际的“安全与边界意识”。

七、本地采集、本地展示，本身也是隐私友好设计

CheckMe 项目中的很多核心数据，比如：

• CPU
• 内存
• 存储
• 电池
• 本地网络状态

本质上都是本地采集后本地展示，没有依赖把设备状态上传到远端做处理。

从项目设计角度看，这也有两层好处：

1. 降低隐私敏感度
2. 提升工具类应用的即时性和离线可用性

当然，这不意味着以后永远不能加云能力，而是说在这个项目阶段，本地化路线本身就更适合它的产品定位。

八、为什么这篇文章很适合“安全隐私”方向

因为它不是在写概念口号，而是在写可落地的实现策略：

• 权限不滥用
• 能力不越界
• 受限信息不伪造
• 错误提示更明确
• 本地数据处理优先

这些内容虽然没有服务卡片和图表那么容易“看起来很炫”，但非常能体现项目的专业性和完成度。

九、实战中最容易忽略的几个问题

1. 先申请权限再说

更好的顺序应该是：先判断是否真的需要，再在对应场景申请。

2. 拿不到的数据直接显示错误字符串

更好的做法是由 Service 层统一处理失败结构，再交给页面表达。

3. 设备不支持也照样开放按钮

更好的做法是像 QuickToolsService 那样先做能力探测。

4. 为了功能多而展示不可靠数据

这是设备信息类项目特别容易伤信任感的一点，应该尽量避免。

十、结语

安全隐私并不只是“少要几个权限”，而是一套贯穿项目设计、能力接入、错误处理和数据表达的思路。

CheckMe 在这方面做得未必完美，但至少我在实现上明确坚持了一条线：项目可以少做一些不可靠能力，但不能为了显得强大而突破边界。

如果你也在做 HarmonyOS 工具类项目，这类细节很值得认真打磨，因为它会直接影响项目看起来是不是“像一个成熟作品”。