HarmonyOS鸿蒙Next上架检测FAQ：应用或元服务权限清单必须指定

HarmonyOS鸿蒙Next上架检测FAQ：应用或元服务权限清单必须指定

概述

应用/元服务权限清单必须指定，该检测项是兼容性测试中的而重要标准，要求App pack包中，所有hap、hsp和har模块的ReqPermissions权限清单必须明确指定。

设计原则

APP pack包中，所有hap、hsp和har的模块的ReqPermissions权限清单必须指定：

1、可以为空；

2、若为非空，则name必填，权限名称为用户授权（user_grant）的开放权限，则reason、usedScene字段必填。

典型案例

常见问题一：您的应用未指定权限清单，ReqPermissions权限清单中，name权限名称为user_grant权限，reason或usedScene为空，不符合审核标准。

{
  "module": {
    // ···
    // 1.ohos.permission.APPROXIMATELY_LOCATION与ohos.permission.LOCATION为user_grant权限，reason和usedScene为必填字段。
    // 2.ohos.permission.USE_BLUETOOTH为system_grant权限，reason和usedScene为选填字段。
    "requestPermissions": [
      {
        "name": "ohos.permission.APPROXIMATELY_LOCATION",
        "reason": ,
        "usedScene": {
          "abilities": [
            "FormAbility"
          ],
          "when": "inuse"
        }
      },
      {
        "name": "ohos.permission.LOCATION",
        "reason": "$string:location_permission_reason",
        "usedScene": {
          
        }
      },
      {
        "name": "ohos.permission.USE_BLUETOOTH"
      }
    ]
  }
}

修改指引

ReqPermissions权限清单若为非空，则name必填，权限名称为user_grant的开放权限，则reason、usedScene字段必填。详情见申请应用权限-声明权限。

当应用需要访问用户的隐私信息或使用系统能力时，如获取位置信息、访问日历、使用相机拍摄照片或录制视频等，应向用户申请授权。这些权限属于user_grant权限。当应用申请user_grant权限时，开发步骤详情见申请应用权限-向用户申请授权。

应用上架前迭代版本测试可使用DevEco Testing应用上架预检功能在本地设备/虚拟机提供黑盒专业测试能力，提前发现上架基础体验类问题，提升上架审核效率。

应用上架提审前可使用云测试应用上架预检功能在云端提供远程黑盒专业测试，包含多品类，多设备，多OS的兼容测试能力，提前发现上架基础体验类问题，提升上架审核效率。


更多关于HarmonyOS鸿蒙Next上架检测FAQ：应用或元服务权限清单必须指定的实战教程也可以访问 https://www.itying.com/category-93-b0.html

4 回复

收藏一下

更多关于HarmonyOS鸿蒙Next上架检测FAQ：应用或元服务权限清单必须指定的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


666

鸿蒙Next上架要求应用或元服务权限清单必须明确指定权限用途。开发者需在配置文件中使用<allow-permission>或<deny-permission>标签声明权限，并详细说明权限使用场景。未正确声明权限清单的应用将无法通过审核。

这是一个非常关键的上架检测项，直接关系到应用能否通过审核。核心要求是：App Pack包中每个模块（hap/hsp/har）的requestPermissions权限清单必须显式声明，不能缺失。

根据您提供的FAQ，我补充几点关键实践和常见误区：

1. 核心规则再明确：

  • 必须存在：每个模块的module.json5中都必须包含"requestPermissions": []字段。即使该模块不申请任何权限，也必须保留这个空数组 []，不能整个字段缺失。
  • user_grant权限的完整声明：对于需要用户动态授权的权限（如ohos.permission.CAMERA, ohos.permission.APPROXIMATELY_LOCATION），name、reason、usedScene三者缺一不可。
    • reason：需要在resources/base/element/string.json中定义，向用户清晰说明申请该权限的目的。
    • usedScene：必须明确指定使用该权限的abilities（Ability名称列表）和场景when（inuse 或 always）。

2. 典型案例代码问题分析： 您提供的JSON示例正是典型的错误案例：

  • ohos.permission.APPROXIMATELY_LOCATION："reason"字段值为空（应为$string:xxx引用），这是必填项缺失，会导致检测失败。
  • ohos.permission.LOCATION："usedScene"对象内容为空，缺少abilities和when，同样是必填项缺失。
  • ohos.permission.USE_BLUETOOTH：作为system_grant权限，仅声明name是符合规范的。

正确声明user_grant权限的示例：

{
  "requestPermissions": [
    {
      "name": "ohos.permission.APPROXIMATELY_LOCATION",
      "reason": "$string:location_reason",
      "usedScene": {
        "abilities": ["MainAbility", "MapAbility"],
        "when": "inuse"
      }
    }
  ]
}

3. 排查与验证建议：

  • 全局检查：使用IDE的搜索功能，全局搜索"requestPermissions"，确保所有module.json5文件都已正确配置。
  • 善用预检工具：在提交审核前，务必使用 DevEco Testing的“应用上架预检”功能 或 云测试的预检功能。它们能精准识别此类权限声明不规范问题，避免因基础合规项不通过而浪费审核次数和时间。
  • 区分权限类型：明确每个申请权限是system_grant（系统授权）还是user_grant（用户授权）。仅user_grant权限需要完整填写reason和usedScene。

总结：该检测项旨在确保应用权限声明的透明度和规范性。开发者必须严格按照规范，为每一个模块完整、准确地声明权限，特别是用户授权类权限，其reason和usedScene的完整性是审核的重点。

回到顶部