1 -> App Privacy Protection
With the popularization of mobile terminals and related services (such as mobile payment and terminal cloud), the importance of user privacy protection has become more and more prominent. Application developers need to consider the protection of user privacy in the product design stage to improve the security of their applications. HarmonyOS app development is subject to privacy protection rules, and when an app is released on the App Market, the App Marketplace will verify it according to the rules, and if the conditions are not met, it will not be released.
1.1 -> Transparent and controllable
When an app collects personal data, it should clearly and unambiguously inform users and ensure that they are informed of how their personal information will be used.
When an application applies for sensitive permissions on the operating system, it must clearly inform the user of the purpose and purpose of the permission request and obtain the user's consent.
Developers shall develop and comply with appropriate privacy policies that comply with all applicable laws, policies, and regulations when collecting, using, retaining, and sharing user data with third parties. For example, before collecting personal data, users need to be fully informed of the type, purpose, processing method, retention period, etc. of the personal data to be processed, and to meet the requirements of the rights of the data subject.
Any personal information disclosed by an app to a third party must inform the user of the content, purpose, and object of disclosure.
In order to make it easier for users to view the personal information collected by the app and the personal information disclosed to third parties, it is recommended that the list be displayed in the secondary menu of the app.
Personal data shall be collected for specific, explicit and legitimate purposes and shall not be further processed in a manner incompatible with such purposes. Re-consent is required for the purpose of collection and for re-use after the user has withdrawn consent.
The app needs to provide an entry point for the user to view the privacy statement. For example, the "About" screen of the app provides an entry point to view the privacy statement.
If the application calls a third-party meta-service, it is necessary to clarify the third-party responsibilities in the app's privacy statement, and if personal data collection is involved, the user needs to be informed of the name of the third party, the type, purpose and method of the personal data collected, the sensitive permissions requested, and the purpose of the application.
The processing of personal data is subject to the consent of the user or in compliance with applicable laws and regulations, and the user has sufficient control over his or her personal data.
The system sets the corresponding permissions for the user's sensitive data and key system resources, and the application needs to apply for the corresponding permission to access the data.
Application for sensitive permissions: The application pop-up window reminds the user to present the permissions that the application needs to obtain, the purpose of using the permissions, the data that the application needs to collect, and the purpose of use, etc., and completes the user's authorization by clicking "Allow" or "Allow during use only" or "Allow this use", so that the user's grant of application permissions and the use of personal data can be transparent, knowable, and controllable.
Users can modify or cancel the permissions granted to the application: When the user does not agree to a certain permission or data collection, the user should be allowed to use functions that are not related to this part of the permission and data collection. For example, in communication and social apps, users can refuse to grant camera permissions, which should not affect functions that are not related to the camera, such as voice calls.
It is not recommended to apply for sensitive permissions in a pop-up window before entering the main interface of the app, and only request the corresponding permissions when the user is using the function. For example, it is not recommended to apply for location permissions when launching the app when the location-related function is not enabled for communication and social networking apps.
Apps that use personal data for personalized advertising and targeted marketing will need to provide a separate opt-out option.
the need to provide users with the ability to control their personal data; If personal data is stored on a cloud service, you need to provide a method for deleting the data.
If an application supports both single-device and cross-device scenarios, users can disable cross-device scenarios independently.
If the app is designed for minors, or if the app identifies a user as a minor through the collected data on the user's age, the developer should specifically analyze the issue of the protection of the minor's personal data in light of the relevant laws of the target market country.
The consent of the guardian is required before collecting the data of minors.
1.2 -> Data minimization
The collection of applied personal data should be relevant to the purposes for which the data is processed, and should be appropriate and necessary. Developers should anonymize or pseudonymize personal data as much as possible to reduce the risk to data subjects. Personal data may only be collected and processed that is necessary for a specific purpose, and no processing may be carried out on data that is not related to a specific purpose.
When applying for sensitive permissions, you must meet the requirements of permission minimization, and apply for only the permissions required to obtain the necessary information or resources. If an app doesn't require camera permissions to be able to do its job, it shouldn't ask the user for camera permissions.
The app collects data to meet the minimum requirements and does not collect data that is not related to the service provided by the app. For example, communication and social networking applications should not collect users' web browsing records.
The functional requirements for the use of the data can benefit the user, and the collected data cannot be used for functions that are not related to the normal use of the user. For example, apps must not use sensitive personal data such as "biometrics" and "health data" for non-core business functions such as service improvement, advertising, or marketing.
The system disables apps from accessing camera and microphone data in the background;
In the course of an app's use of third-party payment transactions, unless required by applicable law or necessary to provide third-party payment services, it must not record user transaction authentication information, or disclose users' personal information unrelated to the user's specific transaction to a third party.
Apps must not request location permissions solely for ad serving or data analysis.
It is forbidden to print sensitive personal data in logs, and if it is necessary to print personal data, personal data should be anonymized or pseudonymized;
For example, the system provides NetworkID and DVID as device identifiers in distributed scenarios, OAID is recommended for advertising business scenarios, ODID and AAID are recommended for application-based analysis, and UUID can be generated in other scenarios that require unique identifiers.
Data that is no longer needed needs to be cleaned up in a timely manner to reduce the risk of data breaches. If a device is disconnected from the distributed network in a distributed business scenario, the temporarily cached data needs to be deleted in a timely manner.
If you want to continuously read location information in the background, apply for ohos.permission.LOCATION_IN_BACKGROUND permission.
Apps designed for minors aren't recommended for requesting location permissions.
1.3 -> Identity Protection
Privacy-enhancing technologies are used to protect the user's identity when the data leaves the device.
The app uses a random identifier that the user can reset instead of a unique identifier.
When an app exports personal data, the exported personal data is encrypted or anonymized.
1.4 -> Data Security
Technically ensure the security of data processing activities, including security mechanisms such as encrypted storage and secure transmission of personal data, which should be enabled by default or take security protection measures.
Data storage
The keys generated by the app and the user's sensitive personal data need to be stored in the app's private directory.
Applications can call the encryption API of the RdbStore, a local database provided by the system, to encrypt and store sensitive personal data.
The distributed data generated by the application can be stored in the distributed database of the system, and sensitive personal data needs to be encrypted by the encryption interface provided by the distributed database.
Secure transmission
Different security measures need to be taken for local and remote transmissions.
Local Transfer:
When an application transmits data across applications through an intent, it is necessary to avoid containing sensitive personal data and prevent the intent hijacking caused by implicit calls, resulting in personal data leakage.
In-app component calls should be made in a secure manner to avoid calling components implicitly and preventing component hijacking.
Avoid using sockets for local communication, generate a random localhost port number, and authenticate and authenticate the port connection objects.
Local IPC communication security: As a service provider, you need to verify the identity and access rights of service users to prevent identity spoofing or permission bypassing.
Remote Transmission:
HTTPS is used instead of HTTP for communication, and the HTTPS certificate is strictly verified.
Avoid using remote ports for communication, and if you need to use them, you need to authenticate and authenticate the objects connected to the port.
When an application communicates across devices, it needs to verify the identity information of the accessed device and application to prevent identity spoofing by the accessed device and application.
When an application communicates across devices, the service provider needs to verify the identity and permissions of the service user to prevent the service user from spoofing or permission bypass.
2 -> Third-party application invocation control mechanism
2.1 -> Why do you need to do call control?
If the background process starts too much, it will consume the system's memory, CPU and other resources, causing the user's device to consume power quickly and freeze. Therefore, in order to ensure user experience, the system will control PA calls between third-party user applications to reduce unnecessary associations.
Note: Third-party applications are user applications developed by third parties as opposed to system applications (applications that cannot be uninstalled or have an appId less than 10,000).
2.2 -> Related Concepts
Foreground: If the user application has a visible FA being displayed, the user application is considered to be in the foreground.
User in-app call: Access between FAs and PAs within the same user's application.
2.3 -> The general idea of invoking control
User in-app calls are not controlled.
Strict control of calls between third-party user applications: Third-party user applications are prohibited from calling the PAs of other third-party applications in the background. Strictly control the third-party user application to call the PA of other user applications in the foreground.
2.4 -> Control Rules
User in-app calls
Not controlled.
Three-party user calls between applications
Third-party application A calls the PA of third-party application B, and the specific limits are as follows:
A is not allowed to call B's PA in the background.
When B has a process alive, A is allowed to call B's PA in the foreground. When no process B survives, the call of A is prohibited.
3 -> Resource classification and access
During application development, resources such as colors, fonts, spacing, and images are often used, and the values of these resources may be different on different devices or configurations.
Application resources: With the help of resource files, developers can customize resources in applications and manage their performance on different devices or configurations.
System Resources: Developers can directly use the preset resource definitions in the system.
3.1 -> Resource classification
3.1.1 -> resources directory
All kinds of resource files used in application development need to be stored and managed in a specific subdirectory. The resources directory consists of three types of directories: the base directory, the qualifier directory, and the rawfile directory. The resource files that are common to multiple projects in the stage model are placed in the resources directory of AppScope.
The base directory exists by default, while the qualifier directory needs to be created by the developer. When an app uses a resource, the system prioritizes finding the resource from the matching qualifier directory based on the current device status. Only if there is no qualifier directory that matches the device status in the resources directory, or if the resource cannot be found in the qualifier directory, the resource directory is searched. rawfile is the original file directory and does not match different resources based on the device status.
Example of a resource directory:
resources
|---base // Default directory
| |---element
| | |---string.json
| |---media
| | |---icon.png
|---en_ GB-vertical-car-mdpi // Example of a qualifier directory, which needs to be created by the developer
| |---element
| | |---string.json
| |---media
| | |---icon.png
|---rawfile
3.1.2 -> List of qualifiers
The qualifier directory can be composed of one or more qualifiers that characterize the application scenario or device characteristics, including mobile country code and mobile network code, language, text, country or region, horizontal and vertical screen, device type, color mode, screen density, etc., and the qualifiers are connected by underscores (_) or hyphens (-). When creating a qualifier directory, developers need to master the naming requirements of the qualifier directory and the matching rules between the qualifier directory and the device status.
Naming requirements for the qualifier directory
The order in which the qualifiers are combined: mobile country code_mobile network code-language_text_country/region-horizontal and vertical screen-device type-color mode-screen density. Developers can select one or more of these qualifiers to form a directory name based on the usage scenario and device characteristics of the application.
Concatenation of qualifiers: Languages, characters, countries or regions are connected by underscores (), mobile country codes and mobile network codes are also connected by underscores (), and other qualifiers are connected by hyphens (-). For example: zh_Hant_CN, zh_CN-car-ldpi.
Scope of the value of the qualifier: The value of each type of qualifier must meet the conditions in the qualifier value requirements table, otherwise, the resource file in the directory cannot be matched.
The rules for matching the qualifier directory to the device state
When matching the corresponding resource file for a device, the priority of qualifier directory matching from high to low is: mobile country code and mobile network code > region (optional combinations: language, language_script, language_country or region, language_script_country or region), > landscape and portrait > device type > color mode > screen density.
If the qualifier directory contains mobile country codes, mobile network codes, language, text, horizontal and vertical screens, device types, and color mode qualifiers, the value of the corresponding qualifier must be exactly the same as the current device status before the directory can participate in the resource matching of the device. For example, the qualifier directory "zh_CN-car-ldpi" cannot participate in resource matching for "en_US" devices.
3.1.3 -> Resource group directory
You can create resource group directories (including element, media, and profile) in the base directory and qualifier directory to store specific types of resource files.
Property types:
Example of a resource file:
The contents of the color.json file are as follows:
{
"color": [
{
"name": "color_hello",
"value": "#ffff0000"
},
{
"name": "color_world",
"value": "#ff0000ff"
}
]
}
The contents of the float.json file are as follows:
{
"float":[
{
"name":"font_hello",
"value":"28.0fp"
},
{
"name":"font_world",
"value":"20.0fp"
}
]
}
The contents of the string.json file are as follows:
{
"string":[
{
"name":"string_hello",
"value":"Hello"
},
{
"name":"string_world",
"value":"World"
},
{
"name":"message_arrive",
"value":"We will arrive at %s."
}
]
}
The contents of the plural.json file are as follows:
{
"plural":[
{
"name":"eat_apple",
"value":[
{
"quantity":"one",
"value":"%d apple"
},
{
"quantity":"other",
"value":"%d apples"
}
]
}
]
}
3.2 -> Resource Access
3.2.1 -> Application Resources
Create a resource file
In the resources directory, you can create subdirectories and files in the directory as described in the qualifier directory and resource group directory.
At the same time, DevEco Studio also provides an interface for creating resource directories and resource files.
Create resource directories and resource files
In the resources directory, click New > Resource File from the context menu to create a directory and a file at the same time.
By default, files are created in the corresponding resource group in the base directory. If you select a qualifier, the qualifier + resource group directory is automatically generated according to the naming convention, and the file is created in the directory.
In the figure, Avaliable qualifiers are the list of qualifiers that can be added or deleted by the small arrow on the right. File name is the name of the file to be created, Resource type is the resource group type, and element is the default. Root Element is a resource type. The created directory name is automatically generated and the format is fixed to "Qualifier. Resource group", for example, if you create an element directory with the qualifier dark and the automatically generated directory name is dark.element.
Create a resource catalog
From the right-click menu of the resources directory, choose New > Resource Directory to create a resource directory.
The resource directory is created as the base directory, and other qualifier directories can also be created according to your needs. After you determine the qualifier, select a resource group type, which supports Element, Media, and Profile, and automatically generates a directory name after creation.
Create a resource file
In the right-click menu of the resource directory, choose New > XXX Resource File to create a resource file for the corresponding resource group directory.
For example, you can create an Element Resource File in the element directory.
Access app resources
In the project, you can reference the application resources in the form of "$r('app.type.name')". The app represents the resources defined in the resources directory in the app; Type represents the resource type (or storage location of the resource), which can be "color", "float", "string", "plural", and "media", and name represents the resource name, which is determined by the developer when defining the resource.
When referencing resources in rawfile, use the form "$rawfile('filename')", the filename must be represented as the relative path of the file in the rawfile directory, the file name must contain a suffix, and the path cannot start with "/".
Note: Resource descriptors cannot be concatenated and only common strings such as 'app.type.name' are supported. In the xxx.ets file, you can use the resources defined in the resources directory.
Text($r('app.string.string_hello'))
.fontColor($r('app.color.color_hello'))
.fontSize($r('app.float.font_hello'))
Text($r('app.string.string_world'))
.fontColor($r('app.color.color_world'))
.fontSize($r('app.float.font_world'))
// 引用string.json资源，$r的第二个参数用于替换%s，value为"We will arrive at five of the clock"。
Text($r('app.string.message_arrive', "five of the clock"))
.fontColor($r('app.color.color_hello'))
.fontSize($r('app.float.font_hello'))
// 引用plural$资源，第一个指定plural资源，第二个参数指定单复数的数量quantity，此处第三个数字为对%d的替换
// 单数下value为"5 apple"，复数下value为"5 apples"。
Text($r('app.plural.eat_apple', 5, 5))
.fontColor($r('app.color.color_world'))
.fontSize($r('app.float.font_world'))
Image($r('app.media.my_background_image')) // media资源的$r引用
Image($rawfile('test.png')) // rawfile$r引用rawfile目录下图片
Image($rawfile('newDir/newTest.png')) // rawfile$r引用rawfile目录下图片
3.2.2 -> System resources
System resources include colors, rounded corners, fonts, spacing, strings, and images. By using system resources, different developers can develop applications with the same visual style.
Developers can reference system resources in the form of "$r('sys.type.resource_id')" sys stands for system resources; type represents the resource type, which can be "color", "float", "string", or "media". resource_id represents the resource ID.
Illustrate:
Only the declarative development paradigm supports the use of system resources, and the quasi-web development paradigm does not.
For details about the usage scenarios, IDs, and parameters of system resources, see System Resources.
// API version 7
Text('Hello')
.fontColor($r('sys.color.id_color_emphasize'))
.fontSize($r('sys.float.id_text_size_headline1'))
.fontFamily($r('sys.string.id_text_font_family_medium'))
.backgroundColor($r('sys.color.id_color_palette_aux1'))
Image($r('sys.media.ic_app'))
.border({color: $r('sys.color.id_color_palette_aux1'), radius: $r('sys.float.id_corner_radius_button'), width: 2})
.margin({top: $r('sys.float.id_elements_margin_horizontal_m'), bottom: $r('sys.float.id_elements_margin_horizontal_l')})
.height(200)
.width(300)
// API version 8
Text('Hello')
.fontColor($r('sys.color.ohos_id_color_emphasize'))
.fontSize($r('sys.float.ohos_id_text_size_headline1'))
.fontFamily($r('sys.string.ohos_id_text_font_family_medium'))
.backgroundColor($r('sys.color.ohos_id_color_palette_aux1'))
Image($r('sys.media.ohos_app_icon'))
.border({color: $r('sys.color.ohos_id_color_palette_aux1'), radius: $r('sys.float.ohos_id_corner_radius_button'), width: 2})
.margin({top: $r('sys.float.ohos_id_elements_margin_horizontal_m'), bottom: $r('sys.float.ohos_id_elements_margin_horizontal_l')})
.height(200)
.width(300)
Top comments (0)