Get application file path
The base class Context provides the ability to get the application file path, which is inherited by ApplicationContext, AbilityStageContext, UIAbilityContext and ExtensionContext. Application file path belongs to the application sandbox path, the above types of Context to get the application file path is different.
Get the path to the application files at the application level via ApplicationContext, which is the recommended path for storing the application's global information, which will be deleted when the application is uninstalled.
| causality | trails |
|---|---|
| bundleCodeDir | <path prefix>/el1/bundle |
| cacheDir | <path prefix>/<encryption level>/base/cache |
| filesDir | <path prefix>/<encryption level>/base/files |
| preferencesDir | <path prefix>/<encryption level>/base/preferences |
| tempDir | <path prefix>/<encryption level>/base/temp |
| databaseDir | <path prefix>/<encryption level>/database |
| distributedFilesDir | <path prefix>/el2/distributedFiles |
| cloudFileDir | <path prefix>/el2/cloud |
Get the path to the application files at HAP level via AbilityStageContext, UIAbilityContext, ExtensionContext. This path is the recommended storage path for HAP-related information. These files will be deleted after HAP is uninstalled, but will not affect the files in the application level path unless all HAPs for the application have been uninstalled.
| causality | trails |
|---|---|
| bundleCodeDir | <path prefix>/el1/bundle |
| cacheDir | <path prefix>/<encryption level>/base/haps/ |
| filesDir | <path prefix>/<encryption level>/base/haps/ |
| preferencesDir | <path prefix>/<encryption level>/base/haps/ |
| tempDir | <path prefix>/<encryption level>/base/haps/ |
| databaseDir | <path prefix>/<encryption level>/database/ |
| distributedFilesDir | <path prefix>/el2/distributedFiles/ |
| cloudFileDir | <path prefix>/el2/cloud/ |
Obtaining and modifying encrypted partitions
Application file encryption is a method of securing data that allows files to be protected from unauthorized access. In different scenarios, applications require different levels of file protection. In practice, developers need to choose appropriate encryption partitions according to the needs of different scenarios, so as to protect the security of application data. By reasonably using different levels of encrypted partitions, the security of application data can be effectively improved.
- EL1: For private files, such as alarms, wallpapers, etc., the application can place these files in a device-level encrypted partition (EL1) to ensure that they can be accessed before the user enters a password.
- EL2: For more sensitive files, such as private personal information, applications can place these files in a higher level encrypted partition (EL2) to ensure higher security.
- EL3: For apps that record steps, file downloads, music playback, and need to read, write and create new files while the screen is locked, it's more appropriate to put it in the encrypted partition of (EL3).
- EL4: For files related to user security information, which do not need to read or write files and cannot be created when the screen is locked, it is more appropriate to put them in the encrypted partition of (EL4).
- EL5: For the user's private and sensitive data files, the default after the lock screen can not be read or written, if you need to read or write the file after the lock screen, you can call the Access interface before the lock screen to apply to continue to read or write the file, or after the lock screen also need to create a new file and can be read or written, placed in the application-level encrypted partitions (EL5) is more appropriate.
Get the context of other mods in the application.
Call createModuleContext(moduleName:string) method to get the Context of other Module in this application, after getting the Context of other Module, you can get the resource information of the corresponding Module.
Subscribe to in-process UIAbility lifecycle changes
In an in-application DFX statistics scenario, if you need to count information such as dwell time and visit frequency of the corresponding page, you can use the subscription to the in-process UIAbility lifecycle change function.
With the capabilities provided by ApplicationContext, it is possible to subscribe to in-process UIAbility lifecycle changes. When the in-process UIAbility lifecycle changes, such as creation, visible/invisible, focus/out-of-focus, destruction, etc., the corresponding callback function will be triggered. Each time the callback function is registered, it will return a listener lifecycle ID, which will be incremented by +1. When the maximum number of listeners is exceeded by 2^63-1, it will return -1.