diff --git a/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md b/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md index 16602e69ef26c7ddc5e383c8658cb4bce5938f90..e10289c626c0a22be29a97a109d5254c54e4cc75 100644 --- a/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md +++ b/en/device-dev/subsystems/subsys-aiframework-tech-codemanage.md @@ -15,15 +15,19 @@ In the overall planning of the AI engine framework, northbound SDKs are a part o - SDK code directory: //foundation/ai/engine/services/client/algorithm\_sdk - e.g. //foundation/ai/engine/services/client/algorithm\_sdk/cv + Examples: + + //foundation/ai/engine/services/client/algorithm\_sdk/cv - e.g. //foundation/ai/engine/services/client/algorithm\_sdk/nlu + //foundation/ai/engine/services/client/algorithm\_sdk/nlu - Plug-in code directory: //foundation/ai/engine/services/server/plugin - e.g. //foundation/ai/engine/services/server/plugin/cv + Examples: - e.g. //foundation/ai/engine/services/server/plugin/nlu + //foundation/ai/engine/services/server/plugin/cv + + //foundation/ai/engine/services/server/plugin/nlu ## Rule: Store all external APIs provided by plug-ins in the **interfaces/kits** directory of the AI subsystem. diff --git a/en/device-dev/subsystems/subsys-boot-init-jobs.md b/en/device-dev/subsystems/subsys-boot-init-jobs.md index 8bbbc1a8c030cf07366fc49c010862b99555f207..31e52aa9bb74cb28168744a9427a88df47279460 100644 --- a/en/device-dev/subsystems/subsys-boot-init-jobs.md +++ b/en/device-dev/subsystems/subsys-boot-init-jobs.md @@ -160,6 +160,20 @@ A job is a command set, where you can manage the commands to be executed. A maxi Small and standard systems + + + write + + + write filename value
Example:
write /data/testfile 0 + + + Writes a file. filename and value respectively indicate the absolute file path and the string to write. + + + Standard system + + stop @@ -300,6 +314,20 @@ A job is a command set, where you can manage the commands to be executed. A maxi Small and standard systems + + + syncexec + + + syncexec Path of the executable file Parameters passed by the executable file
Example:
syncexec /system/bin/udevadm trigger + + + Runs an executable file synchronously. The **wait** function will be called to wait for the child process to end. The command must not contain more than 10 parameters. + + + Standard system + + mknode diff --git a/en/device-dev/subsystems/subsys-boot-init-service.md b/en/device-dev/subsystems/subsys-boot-init-service.md index 38f88f250c710101c84320f59b378b3cc827d568..6c306c1543b4dd7ff81b0e090eb3306483a73704 100644 --- a/en/device-dev/subsystems/subsys-boot-init-service.md +++ b/en/device-dev/subsystems/subsys-boot-init-service.md @@ -114,7 +114,7 @@ The service management module is available only for the mini system and standard By parsing the *.cfg file, you can obtain **service** fields, and then set and start the service. ### Parameters - **Table 1** Description of service fields + **Table 1** Description of service fields @@ -208,11 +208,11 @@ By parsing the *.cfg file, you can obtain **service** fields, a importance
- Current service priority. + Service priority (for the standard system) or service importance (for the mini system). Standard system: The service priority ranges from -20 to 19. A value beyond the range is invalid.
- Small system: The value 0 indicates an unimportant process and a value greater than 0 indicates an important process. + Small system: The value 0 indicates that a system restart is not required, and a value greater than 0 indicates the opposite.
Small and standard systems @@ -362,7 +362,7 @@ By parsing the *.cfg file, you can obtain **service** fields, a | option | Socket option. This field is passed when **setsockopt** is called. Currently, the available options include SOCKET_OPTION_PASSCRED, SOCKET_OPTION_RCVBUFFORCE, SOCK_CLOEXEC, and SOCK_NONBLOCK.| ### Available APIs - **Table 3** FD proxy APIs + **Table 3** FD proxy APIs | API | Function| Description | | ---------- | ---------- |--------| | int *ServiceGetFd(const char *serviceName, size_t *outfdCount) | Obtains the proxy FD from the init process.| Return value: Returns the pointer to the fd array if the operation is successful; returns **NULL** otherwise. (Note: Manual release is required.)
Arguments:
**serviceName**: service name.
**outfdCount**: length of the returned fd array.| diff --git a/en/readme/figures/location_En-1.png b/en/readme/figures/location_En-1.png new file mode 100644 index 0000000000000000000000000000000000000000..1ae4bcd7173f2e95004c96fa13d420c09f017f76 Binary files /dev/null and b/en/readme/figures/location_En-1.png differ diff --git a/en/readme/location.md b/en/readme/location.md index 09cacb485331c6b0e5b46af2c070acae735690c6..2e7ba90b4b18d9f86e708ddb16cf0aa539b7fc07 100644 --- a/en/readme/location.md +++ b/en/readme/location.md @@ -8,7 +8,7 @@ With the location awareness capability offered by OpenHarmony, mobile devices wi Your application can call location-specific APIs to obtain the location information of a mobile device for offering location-based services such as drive navigation and motion track recording. -Basic Concepts +**Basic Concepts** Location awareness helps determine where a mobile device locates. The system identifies the location of a mobile device with its coordinates, and uses location technologies such as Global Navigation Satellite System (GNSS) and network positioning (for example, base station positioning or WLAN/Bluetooth positioning) to provide diverse location-based services. These advanced location technologies make it possible to obtain the accurate location of the mobile device, regardless of whether it is indoors or outdoors. @@ -28,6 +28,10 @@ Location awareness helps determine where a mobile device locates. The system ide WLAN or Bluetooth positioning estimates the current location of a mobile device based on the locations of WLANs and Bluetooth devices that can be discovered by the device. The location accuracy of this technology depends on the distribution of fixed WLAN access points (APs) and Bluetooth devices around the device. A high density of WLAN APs and Bluetooth devices can produce a more accurate location result than base station positioning. This technology also requires access to the network. +**Figure 1** ** Location subsystem architecture** + +![](figures/location_En-1.png) +![](figures/location_En-1.png) ## Directory Structure @@ -102,7 +106,8 @@ The following table describes APIs available for obtaining device location infor **Obtaining the device location information:** 1. Before using basic location capabilities, check whether your application has been granted the permission to access the device location information. If not, your application needs to obtain the permission from the user. - The system provides the following location permissions: + + The system provides the following location permissions: - ohos.permission.LOCATION - ohos.permission.LOCATION_IN_BACKGROUND @@ -131,7 +136,7 @@ The following table describes APIs available for obtaining device location infor } ``` - For details about the configuration fields, see the description of the **module.json** file. + For details about the configuration fields, see [Application Package Structure Configuration File](../application-dev/quick-start/stage-structure.md). 2. Import the **geolocation** module by which you can implement all APIs related to the basic location capabilities. @@ -204,7 +209,8 @@ The following table describes APIs available for obtaining device location infor ``` 4. Instantiate the **Callback** object for the system to report location results. - Your application needs to implement the callback defined by the system. When the system successfully obtains the real-time location of a device, it will report the location result to your application through the callback interface. Your application can implement the callback interface in such a way to complete your own service logic. + + Your application needs to implement the callback defined by the system. When the system successfully obtains the real-time location of a device, it will report the location result to your application through the callback interface. Your application can implement the callback interface in such a way to complete your own service logic. ``` var locationChange = (location) => { @@ -239,6 +245,7 @@ The following table describes APIs available for obtaining device location infor **Converting the coordinates and geocoding information:** > **NOTE** +> > The **GeoConvert** instance needs to access backend services to obtain information. Therefore, before performing the following steps, ensure that your device is connected to the network. 1. Import the **geolocation** module by which you can implement all APIs related to the geocoding and reverse geocoding conversion capabilities. @@ -248,6 +255,7 @@ The following table describes APIs available for obtaining device location infor ``` 2. Obtain the conversion result. + - Call **getAddressesFromLocation** to convert coordinates into geographical location information. ``` @@ -258,6 +266,7 @@ The following table describes APIs available for obtaining device location infor ``` Your application can obtain the **GeoAddress** list that matches the specified coordinates and then read location information from it. For details, see the *API Reference*. + - Call **getAddressesFromLocationName** to convert geographic description into coordinates. ```