鸿蒙OS 资源文件

鸿蒙OS 资源文件分类

resources目录
应用的资源文件（字符串、图片、音频等）统一存放于resources目录下，便于开发者使用和维护。resources目录包括两大类目录，一类为base目录与限定词目录，另一类为 rawfile 目录，详见表1。

资源目录示例：

resources
|---base  // 默认存在的目录
|   |---element
|   |   |---string.json
|   |---media
|   |   |---icon.png
|---en_GB-vertical-car-mdpi // 限定词目录示例，需要开发者自行创建   
|   |---element
|   |   |---string.json
|   |---media
|   |   |---icon.png
|---rawfile  // 默认存在的目录

resources目录分类

限定词目录

限定词目录可以由一个或多个表征应用场景或设备特征的限定词组合而成，包括语言、文字、国家或地区、横竖屏、设备类型和屏幕密度等六个维度，限定词之间通过下划线（_）或者中划线（-）连接。开发者在创建限定词目录时，需要掌握限定词目录的命名要求以及与限定词目录与设备状态的匹配规则。

限定词目录的命名要求

限定词的组合顺序：语言_文字_国家或地区-横竖屏-设备类型-屏幕密度。开发者可以根据应用的使用场景和设备特征，选择其中的一类或几类限定词组成目录名称。
限定词的连接方式：语言、文字、国家或地区之间采用下划线（_）连接，除此之外的其他限定词之间均采用中划线（-）连接。
例如：zh_Hant_CN、zh_CN-car-ldpi。

限定词的取值范围：每类限定词的取值必须符合表2中的条件，否则，将无法匹配目录中的资源文件。
限定词取值要求

限定词目录与设备状态的匹配规则

在为设备匹配对应的资源文件时，限定词目录匹配的优先级从高到低依次为：区域（语言_文字_国家或地区）> 横竖屏 > 设备类型 > 屏幕密度。
如果限定词目录中包含语言、文字、横竖屏、设备类型限定词，则对应限定词的取值必须与当前的设备状态完全一致，该目录才能够参与设备的资源匹配。例如，限定词目录“zh_CN-car-ldpi”不能参与“en_US”设备的资源匹配。

资源组目录

base目录与限定词目录下面可以创建资源组目录（包括element、media、animation、layout、graphic、profile），用于存放特定类型的资源文件

资源组目录 说明

系统资源文件

系统资源文件说明

鸿蒙OS 资源文件示例

boolean.json示例

{
    "boolean":[
        {
            "name":"boolean_1",
            "value":true
        },
        {
            "name":"boolean_ref",
            "value":"$boolean:boolean_1"
        }
    ]
}
color.json示例
{
    "color":[
        {
            "name":"red",
            "value":"#ff0000"
        },
        {
            "name":"red_ref",
            "value":"$color:red"
        }
    ]
}

float.json示例

{
    "float":[
        {
            "name":"float_1",
            "value":"30.6"
        },
        {
            "name":"float_ref",
            "value":"$float:float_1"
        },
        {
            "name":"float_px",
            "value":"100px"
        }
    ]
}
intarray.json示例
{
    "intarray":[
        {
            "name":"intarray_1",
            "value":[
                100,
                200,
                "$integer:integer_1"
            ]
        }
    ]
}

integer.json示例

{
    "integer":[
        {
            "name":"integer_1",
            "value":100
        },
        {
            "name":"integer_ref",
            "value":"$integer:integer_1"
        }
    ]
}

pattern.json示例

{
    "pattern":[
        {
            "name":"base",
            "value":[
                {
                    "name":"width",
                    "value":"100vp"
                },
                {
                    "name":"height",
                    "value":"100vp"
                },
                {
                    "name":"size",
                    "value":"25px"
                }
            ]
        },
        {
           "name":"child",
           "parent":"base",
           "value":[
               {
                   "name":"noTitile",
                   "value":"Yes"
               }
           ]
        }
    ]
}

plural.json示例

{
    "plural":[
        {
            "name":"eat_apple",
            "value":[
                {
                    "quantity":"one",
                    "value":"%d apple"
                },
                {
                    "quantity":"other",
                    "value":"%d apples"
                }
            ]
        }
    ]
}

strarray.json示例

{
    "strarray":[
       {
           "name":"size",
           "value":[
               {
                   "value":"small"
               },
               {
                   "value":"$string:hello"
               },
               {
                   "value":"large"
               },
               {
                   "value":"extra large"
               }
            ]
       }
    ]
}

string.json示例

{
    "string":[
        {
            "name":"hello",
            "value":"hello base"
        },
        {
            "name":"app_name",
            "value":"my application"
        },
        {
            "name":"app_name_ref",
            "value":"$string:app_name"
        },
        {
            "name":"app_sys_ref",
            "value":"$ohos:string:request_location_reminder_title"
        }
    ]
}

鸿蒙OS 应用数据管理

本地应用数据管理

提供单设备上结构化数据的存储和访问能力。使用 SQLite 作为持久化存储引擎，提供了多种类型的本地数据库，分别是关系型数据库（Relational Database）和对象映射关系型数据库（Object Relational Mapping Database），此外还提供一种轻量级偏好数据库（Light Weight Preference Database），用以满足开发人员使用不同数据模型对应用数据进行持久化和访问的需求。

分布式数据服务

分布式数据库支持用户数据跨设备相互同步，为用户提供在多种终端设备上一致的数据访问体验。通过调用分布式数据接口，应用可以将数据保存到分布式数据库中。通过结合帐号、应用唯一标识和数据库三元组，分布式数据库对属于不同应用的数据进行隔离。

有关于分布式数据库的详细信息，请参阅分布式数据服务。

分布式文件服务

在多个终端设备间为单个设备上应用程序创建的文件提供多终端的分布式共享能力。每台设备上都存储一份全量的文件元数据，应用程序通过文件元数据中的路径，可以实现同一应用文件的跨设备访问。

数据搜索服务

在单个设备上，为应用程序提供搜索引擎级的全文索引管理、建立索引和搜索功能。

数据存储管理

为应用开发者提供系统存储路径、存储设备列表，存储设备属性的查询和管理功能。

鸿蒙OS 应用权限管理

应用权限管理是由接口提供方（Ability）、接口使用方（应用）、系统（包括云侧和端侧）以及用户等多方共同参与的整个流程，保证受限接口是在约定好的规则下被正常使用，避免接口被滥用而导致用户、应用和设备受损。

权限声明

应用需要在 config.json 中使用“reqPermissions”属性对需要的权限逐个进行声明。
若使用到的三方库也涉及权限使用，也需统一在应用的config.json中逐个声明。
没有在config.json中声明的权限，应用就无法获得此权限的授权。

动态申请敏感权限

动态申请敏感权限基于用户可知可控的原则，需要应用在运行时主动调用系统动态申请权限的接口，系统弹框由用户授权，用户结合应用运行场景的上下文，识别出应用申请相应敏感权限的合理性，从而做出正确的选择。

即使用户向应用授予了请求的权限，应用在调用受此权限管控的接口前，也应该先检查自己有无此权限，而不能把之前授予的状态持久化，因为用户在动态授予后还可以通过设置取消应用的权限。

自定义权限

系统已定义的权限满足了应用的基本需要，若有特殊的访问控制需要，应用可在config.json中以"defPermissions": []属性来定义新的权限，并通过“availableScope”和“grantMode”两个属性分别确定权限的开放范围和授权方式，使得权限定义更加灵活且易于理解。有关 HarmonyOS 权限开放范围和授权方式详细的描述，请参阅权限授予方式字段说明和权限限制范围字段说明。

权限保护方法

保护 Ability：通过在config.json里对应的 Ability 中配置"permissions": [“权限名”]属性，即可实现保护整个 Ability 的目的，无指定权限的应用不能访问此 Ability。
保护 API：若 Ability 对外提供的数据或能力有多种，且开放范围或保护级别也不同，可以针对不同的数据或能力在接口代码实现中通过verifyPermission(String permissionName, int pid, int uid)来对 uid 标识的调用者进行鉴权。

权限使用原则

权限申请最小化。跟用户提供的功能无关的权限，不要申请；尽量采用其他无需权限的操作来实现相应功能（如：通过intent拉起系统 UI 界面由用户交互、应用自己生成uuid代替设备 ID 等）。
权限申请完整。应用所需权限（包括应用调用到的三方库依赖的权限）都要逐个在应用的config.json中按格式声明。
满足用户可知。应用申请的敏感权限的目的需要真实准确告知用户。
权限就近申请。应用在用户触发相关业务功能时，就近提示用户授予实现此功能所需的权限。
权限不扩散。在用户未授权的情况下，不允许提供给其他应用使用。
应用自定义权限防止重名。建议以包名为前缀来命名权限，防止跟系统定义的权限重名。

鸿蒙OS 应用隐私保护

数据收集及使用公开透明

应用采集个人数据时，应清晰、明确地告知用户，并确保告知用户的个人信息将被如何使用。

应用申请操作系统受限权限和敏感权限时，需要明确告知用户权限申请的目的和用途，并获取用户的同意。受限权限 API 使用方案请参考权限章节。详细的 UX 设计方案请参考UX 设计隐私方案。

敏感权限获取弹框示例

开发者应制定并遵从适当的隐私政策，在收集、使用留存和第三方分享用户数据时需要符合所有适用法律、政策和规定。需充分告知用户处理个人数据的种类、目的、处理方式、保留期限等，满足数据主体权利等要求

根据以上原则，我们设计了示例以供参考。隐私通知/声明的参考示例如下：

应用隐私通知示例图 点击放大

应用隐私声明示例图

个人数据应当基于具体、明确、合法的目的收集，不应以与此目的不相符的方式作进一步处理。对于收集目的变更和用户撤销同意后再次使用的场景都需要用户重新同意。隐私声明变更示例图，隐私声明撤销同意。

隐私声明变更示例图

撤销同意示例图

应用的隐私声明应覆盖本应用所有收集的个人数据。
有 UI 的 Ability 运行时需要在明显位置展示 Ability 的功能名称及开发者名称/logo。
应用的隐私声明应在应用首次启动时通过弹框等明显的方式展示给用户，并提供用户查看隐私声明的入口。
调用第三方 Ability 时，需要明确调用方与被调用方履行的隐私责任，并在声明弹框中告知数据主体相关隐私权责。
调用第三方 Ability 时，如涉及个人数据的分享，调用方需在隐私声明中说明分享的数据类型和数据接收者的类型。

数据收集及使用最小化

应用个人数据收集应与数据处理目的相关，且是适当、必要的。开发者应尽可能对个人数据进行匿名或化名，降低数据主体的风险。仅可收集和处理与特定目的相关且必需的个人数据，不能对数据做出与特定目的不相关的进一步处理。

敏感权限申请的时候要满足权限最小化的要求，在进行权限申请时，只申请获取必需的信息或资源所需要的权限。
应用针对数据的收集要满足最小化要求，不收集与应用提供服务无关联的数据。
数据使用的功能要求能够使用户受益，收集的数据不能用于与用户正常使用无关的功能。

数据处理选择和控制

对个人数据处理必须要征得用户的同意，用户对其个人数据要有充分的控制权。

应用申请使用系统权限：应用弹窗提醒，向用户呈现应用需要获取的权限和权限使用目的、应用需要收集的数据和使用目的等，通过用户点击“确认”的方式完成用户授权，让用户对应用权限的授予和使用透明、可知、可控。
用户可以修改、取消授予应用的权限：当用户不同意某一权限或者数据收集时，应当允许用户使用与这部分权限和数据收集不相关的功能。
在进入应用的主界面之前不建议直接弹窗申请敏感权限，仅在用户使用功能时才请求对应的权限。
系统对于用户的敏感数据和系统关键资源的获取设置了对应的权限，应用访问这些数据时需要申请对应的权限。

数据安全

从技术上保证数据处理活动的安全性，包括个人数据的加密存储、安全传输等安全机制，系统应默认开启或采取安全保护措施。

数据存储

应用产生的密钥以及用户的敏感数据需要存储在应用的私有目录下，敏感数据定义可参考数据分类分级标准。
应用可以调用系统提供的本地数据库 RdbStore 的加密接口对敏感数据进行加密存储。接口详见关系型数据库章节。
应用产生的分布式数据可以调用系统的分布式数据库进行存储，对于敏感数据需要采用分布式数据库提供的加密接口进行加密，接口详见分布式数据服务。

安全传输

需要分别针对本地传输和远程传输采取不同的安全保护措施。

本地传输：

应用通过 intent 跨应用传输数据时避免包含敏感数据，intent scheme url 协议使用过程中加入安全限制，防止 UXSS 等安全问题。
应用内组件调用应采用安全方式，避免通过隐式方式进行调用组件，防止组件劫持。
避免使用 socket 方式进行本地通信，如需使用， localhost 端口号随机生成，并对端口连接对象进行身份认证和鉴权。
本地 IPC 通信安全：作为服务提供方需要校验服务使用方的身份和访问权限，防止服务使用方进行身份仿冒或者权限绕过。

远程传输：

使用 https 代替 http 进行通信，并对 https 证书进行严格校验。
避免进行远程端口进行通信，如需使用，需要对端口连接对象进行身份认证和鉴权。
应用进行跨设备通信时，需要校验被访问设备和应用的身份信息，防止被访问方的设备和应用进行身份仿冒。
应用进行跨设备通信时，作为服务提供方需要校验服务使用方的身份和权限，防止服务使用方进行身份仿冒或者权限绕过。
本地化处理
应用开发的数据优先在本地进行处理，对于本地无法处理的数据上传云服务要满足最小化的原则，不能默认选择上传云服务

未成年人数据保护要求

如果应用是针对未成年人设计的，或者应用通过收集的用户年龄数据识别出用户是未成年人，开发者应该结合目标市场国家的相关法律，专门分析未成年人个人数据保护的问题。收集未成年人数据前需要征得监护人的同意