This is the fourth day of my participation in Gwen Challenge

All applications in HarmonyOS run within the app sandbox. By default, an application can access only a limited number of system resources. The system manages the access permissions of applications to resources. Application permission management is a whole process involving the interface provider (Ability), interface user (application), system (including cloud side and end side), and users. It ensures that restricted interfaces are used normally under agreed rules and avoids interface abuse that may cause damage to users, applications, and devices.

Permission statement

  • The application needs to declare the required permissions one by one in config.json using the “reqPermissions” attribute.
  • If the third-party libraries used also involve permissions, they must be declared one by one in the config.json file of the application.
  • Without the permission declared in config.json, the application cannot be granted this permission.

Dynamically apply for sensitive rights

Dynamic application for sensitive permissions Based on the principle that users can know and control, the application needs to actively invoke the interface that dynamically applies for permissions during running. The system pop-up box is authorized by users. Users can identify the rationality of applying for sensitive permissions based on the context of application running scenarios, so as to make a correct choice.

Even if the user grants the requested permission to the application, the application should check whether it has the requested permission before invoking the interface controlled by the requested permission. The application should not persist the previously granted state, because the user can cancel the requested permission by setting the Settings after the dynamic grant.

For more information about applying sensitive permissions dynamically, see Applying For Permissions dynamically.

Custom permissions

To prevent the interface provided by the application from being invoked maliciously, HarmonyOS authenticates the caller who invokes the interface.

In most cases, the permissions defined by the system meet the basic requirements of the application. If the application has special access control requirements, the application can use “defPermissions” in config.json: [] attribute to define new permissions, and through the “availableScope” and “grantMode” two attributes to determine the open scope of permissions and authorization mode, making the definition of permissions more flexible and easy to understand. For a detailed description of the scope of permission granted and the authorization mode in HarmonyOS, see The Permission Grant Mode Field Description and Permission Limit Scope Field Description.

You are advised to name new permissions with the first two fields of the package name to avoid the same name of user-defined permissions between applications of different developers.

Permission Protection methods

  • Ability: protect Ability by setting “permissions” in Ability in config.json: [“

    Permission to name

    “] to protect the entire Ability that cannot be accessed by undesignated applications.

  • Protect the API: When Ability provides more than one set of data or capabilities externally with different levels of access or protection, Callers identified by uid can be authenticated by verifyPermission(String permissionName, int PID, int UID) in interface code implementations for different data or capabilities.

Permission Usage Rules

  • Permission application is minimized. Do not apply for permissions that have nothing to do with the functions provided by users; Try to use other actions that do not require permissions to implement corresponding functions (for example, using intent to pull up the system UI interface for user interaction, or using the application to generate its own UUID instead of the device ID).
  • The permission application is complete. The permissions required by the application (including the permissions dependent on third-party libraries that the application calls) are declared in the application’s config.json format one by one.
  • It is known to the user. The purpose of applying for sensitive permissions must be truly and accurately communicated to users.
  • Apply for permission nearby. When a user triggers a service function, the application prompts the user to grant the required permission for the function.
  • Non-proliferation of permissions. It is not allowed to be used by other applications without the user’s authorization.
  • Apply custom permissions to prevent duplicate names. You are advised to use the prefix of the package name to prevent the permissions from being the same as those defined by the system.

Local application data management

Provides storage and access to structured data on a single device. Using SQLite as a persistent storage engine, it provides multiple types of local databases, namely Relational Database and Object Relational Mapping Database. It also provides a Light Weight Preference Database to meet the needs of developers to persist and access application data using different data models.

Distributed data service

A distributed database synchronizes user data across devices, providing users with consistent data access experience on multiple terminals. By invoking a distributed data interface, an application can save data to a distributed database. A distributed database isolates data belonging to different applications by combining account numbers, application unique identifiers, and database triples.

Distributed File Service

Provides multi-terminal distributed sharing capability between multiple terminal devices for files created by applications on a single device. Each device stores a full copy of file metadata. Applications can access the same application file across devices through the path in the file metadata.

Data Storage Management

Application developers can query and manage storage paths, storage device lists, and storage device properties.