当前位置：网站首页>Summer Challenge ohos build custom service practice

Summer Challenge ohos build custom service practice

2022-06-28 16:17:00 【51CTO】

This article is participating in the starlight project 3.0– Summer Challenge

author ： Caochangyan
Facing the whole scene 、 Full connection 、 Under the background of full intelligence era ,OpenHarmony It will be supported by more and more developers , In different scenes , Some non essential subsystems or components will be tailored according to actual requirements , New subsystems or components will also be added . If you want to add subsystems or add services / Components , I hope this article can give you some enlightenment .

1 Basic concepts

Before introducing custom services , First, a few concepts are briefly introduced ：

① There are three basic concepts in Hongmeng system , They are Subsystem (subsystems), Components (components), function (features).

OpenHarmony Overall compliance Layered design , From bottom to top is ： Kernel layer 、 System service layer 、 Framework layer and application layer .

# Summer Challenge #OHOS Build custom service practice _ Kai Hong HarmonyOS

The system functions according to “ System > Subsystem > Components ” Step by step . Subsystem is a logical concept , It consists of corresponding components . A component is a further breakdown of a subsystem , Reusable software units , It contains the source code 、 The configuration file 、 Resource files and compilation scripts ; Can build independently , Binary integration , It is a binary unit with independent verification capability .

for instance , Hongmeng ( System ) --> multimedia ( Subsystem ) --> Audio ( Components ）–> collection （ function ）

②IPC（Inter-Process Communication） Mechanism ： Use Binder drive , Used for cross process communication within the device .IPC The client is usually used - The server （Client-Server） Model , Service requester （Client） Available service providers （Server） Agent for （Proxy）, The data communication between processes is realized by reading and writing data through this agent .

Usually ,Server Will register the system capability first （System Ability） To the System Capability Manager （System Ability Manager, abbreviation saMgr） in ,saMgr Responsible for managing these SA And to Client Provide relevant interfaces .Client With a specific SA signal communication , You have to start with saMgr Get the SA Agent for , Then use agents and SA signal communication . In general use Proxy Indicates the service requestor ,Stub Indicates that the service provider .

# Summer Challenge #OHOS Build custom service practice _ Kai Hong HarmonyOS_02

2 target

Goal one ： How to configure the new service , compile
Goal two ： How to integrate a new service into OHOS in
Goal three ： How to communicate with new services

3 Realization effect

3.1. Compile successfully

Once the configuration is complete , Code compiled successfully

With products rk3568-khdvk For example ,img File generation , Here's the picture

# Summer Challenge #OHOS Build custom service practice _ actual combat _03

3.2. The new service runs

burn img File to development board , New services hello Run in the background of the development board as an independent process , Here's the picture

# Summer Challenge #OHOS Build custom service practice _ actual combat _04

3.3. Communicate with new services

You can communicate with the server through command line mode or application startup trigger mode .

3.3.1 Command line communication

Client operation ： perform myhello Executable program , Enter the command send, Send string "Hello,World".

# Summer Challenge #OHOS Build custom service practice _ actual combat _05

Server response ： stay service The layer received the sent string "Hello,World".

# Summer Challenge #OHOS Build custom service practice _ actual combat _06

3.3.2 Application triggers communication

Application startup triggers ：

# Summer Challenge #OHOS Build custom service practice _ service _07

Server response ： Returns a string to print into the application form .

# Summer Challenge #OHOS Build custom service practice _ actual combat _08

4 The code implements the directory structure

The whole is located in the directory foundation Next , namely foundation/mytest/hello.

mytest
    └─hello
    │  ohos.build //  management mytest All levels of subsystem BUILD.gn
    │  
    ├─etc
    │      BUILD.gn  //  Precompiled configuration management 
    │      hello.cfg
    │      hello.rc
    │      
    ├─interface
    │  │  BUILD.gn 
    │  │  
    │  ├─include
    │  │      hello_client.h
    │  │      hello_logs.h //  Log header file 
    │  │      hello_proxy.h
    │  │      ihello.h 
    │  │      
    │  ├─src
    │  │      hello_client.cpp //  Receive the application layer interface call entry 
    │  │      hello_proxy.cpp  // IPC Communication agent 
    │  │      
    │  └─test
    │      │  BUILD.gn //  Yes cli Tools to manage 
    │      │  
    │      ├─include
    │      │      cli_tool.h 
    │      │      
    │      └─src
    │             cli_tool.cpp //  Client test entry 
    │              
    ├─sa_profile
    │      9999.xml //  With sa ID name 
    │      BUILD.gn //  Yes xml Conduct management 
    │      
    └─service
        │  BUILD.gn //  Server function management 
        │  
        ├─include
        │      hello_service.h
        │      hello_stub.h
        │      
        └─src
                hello_service.cpp  //  Service program 
                hello_stub.cpp     // IPC Communication pile  

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.

5 Implementation process

5.1 How to configure and compile the new service

5.1.1 How to configure the new service

The configuration files of a subsystem of Hongmeng operating system mainly include the following four ：

5.1.1.1 Module directory BUILD.gn file

Configure in the module directory BUILD.gn, Select the corresponding template according to the type .

Supported template types ：

ohos_executable //  Appoint  target  It's an executable 
ohos_shared_library //  Declare a dynamic （win=.dll、linux=.so）
ohos_static_library //  Static library （win=.lib、linux=.a）
ohos_source_set //  Define the source code set , Will be generated one by one  .o  file , That is, it has not been linked （link） The file of 

#  Precompiled templates ：
ohos_prebuilt_executable //  Copy the executable file 
ohos_prebuilt_shared_library //  Copy so file 
ohos_prebuilt_etc //  Copy files in other formats 

     1.
2.
3.
4.
5.
6.
7.
8.
9.

Example ：

ohos_shared_library Example

import("//build/ohos.gni")

ohos_shared_library("hello_native") { //  Dynamic library , Will generate libhello_native.z.so
    sources = [ //  Source file used 
        "src/hello_proxy.cpp",
        "src/hello_client.cpp"
    ]

    include_dirs = [ //  Header file contains location 
        "include",
        "//utils/native/base/include",
        "//utils/system/safwk/native/include",
        "//foundation/distributedschedule/samgr/interfaces/innerkits/samgr_proxy/include"
    ]

    deps = [ //  Rely on the module 
        "//utils/native/base:utils",
    ]
  #  Cross component module dependency definitions ,
  #  The definition format is  " Part name : Module name "
  #  Here, the dependent module must be the dependent part declared in inner_kits Module in 
    external_deps = [ //  External dependence 
        "hisysevent_native:libhisysevent",
        "hiviewdfx_hilog_native:libhilog",
        "ipc:ipc_core",
        "safwk:system_ability_fwk",
        "samgr_standard:samgr_proxy",
    ]

    part_name = "hello" //  Part name 
    subsystem_name = "mytest" //  Subsystem name 
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

ohos_executable Example ：

ohos_executable Template properties and ohos_shared_library Almost the same

import("//build/ohos.gni")

ohos_executable("myhello") { //  Generate executable files myhello
  install_enable = true // true Means to install 
  sources = [
    "src/cli_tool.cpp",
  ]

  include_dirs = [
    "//foundation/mytest/hello/interface/test/include",
    "//foundation/mytest/hello/interface/include",
  ]

  deps = [
    "//base/hiviewdfx/hilog/interfaces/native/innerkits:libhilog",
    "//foundation/mytest/hello/interface:hello_native",
    "//foundation/distributedschedule/safwk/interfaces/innerkits/safwk:system_ability_fwk",
    "//utils/native/base:utils",
  ]

  external_deps = [ "ipc:ipc_core" ]

  cflags_cc = [
    "-std=c++17",
  ]

  part_name = "hello"
  subsystem_name = "mytest"
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

explain ：

Executable modules （ namely ohos_executable Template defined ） The default is not to install , If you want to install , You need to specify the install_enable = true

ohos_prebuilt_etc Example ：

import("//build/ohos.gni")
ohos_prebuilt_etc("etc_file") {
  source = "file"
  deps = []  				#  In part module dependency 
  module_install_dir = "" 	#  Optional , Module installation path , from system/,vendor/ Start specifying after 
  relative_install_dir = "" #  Optional , Module installation relative path , be relative to system/etc; If there is module_install_dir When the configuration , This configuration does not take effect 
  part_name = "" 			#  Mandatory , Name of the component 
}

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.

import("//build/ohos.gni")

ohos_prebuilt_etc("hello_sa_rc") {
  source = "hello.cfg"
  relative_install_dir = "init"
  part_name = "hello"
  subsystem_name = "mytest"
}

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.

explain ：

To add a module to an existing part , It only needs to be in the module_list Add a new module in gn Compile target ; If this module is provided to other module interfaces , Need to be in inner_kits Add the corresponding configuration in ; If there are test cases for this module , Need to be added to test_list In the middle .

5.1.1.2 establish ohos.build file

Each subsystem has one ohos.build The configuration file （ Or there is bundle.json The configuration file ), In the root directory of the subsystem . Create in the folder corresponding to each component under the newly created subsystem directory ohos.build file , Define part information .

{
  "subsystem": " Subsystem name ",
  "parts": {
    " New part name ": {
      "module_list": [
        " The part contains the... Of the module gn The goal is "
      ],
      "inner_kits": [
      ],
      "test_list": [
        " The test case ",
      ]
    }
  }
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

explain ：

subsystem Defines the name of the subsystem ;parts Define the components included in the subsystem .

A part contains the part name , Modules included in the component module_list, Interfaces provided by components to other components inner_kits, Test cases for components test_list.

{
  "subsystem": "mytest",
  "parts": {
    "hello": {
        "module_list": [
          "//mytest/hello/service:hello_service",
          "//mytest/hello/sa_profile:hello_sa_profiles",
          "//mytest/hello/etc:hello_sa_rc",
          "//mytest/hello/interface:hello_native"
        ],
        "test_list": [
        ]
    }
  }
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

In the existing subsystem Add a new part , There are two ways ：

a) In the original of this subsystem ohos.build Add the part to the file

b) Create a new one ohos.build file

Either way, you should ohos.build The files are in the folder of the corresponding subsystem

ohos.build The file contains two parts , The first part subsystem Describes the name of the subsystem ,parts Define the components included in the subsystem , To add a part , You need to add the corresponding content of this part to parts In the middle . When adding, you need to specify the modules included in the component module_list, If there are interfaces provided for other components , Need to be in inner_kits Description in , If there are test cases , Need to be in test_list Description in ,inner_kits And test_list If you don't have one, you can leave it blank .

5.1.1.3 subsystem_config.json file

Modify the system build In the catalog subsystem_config.json file

{
  " Subsystem name ": {
    "path": " Subsystem Directory ",
    "name": " Subsystem name ",
    ...
  }
}

     1.
2.
3.
4.
5.
6.
7.

This file defines which subsystems exist and the folder path where these subsystems are located , When adding a subsystem, you need to describe the subsystem path And name, Represents subsystem path and subsystem name respectively .

# Summer Challenge #OHOS Build custom service practice _ actual combat _09

5.1.1.4 Product profile {product_name}.json

stay productdefine/common/products The product configuration under the directory is as follows RK3568-KHDVK.json Add corresponding parts in , Add directly to the back of the original part .

{
  "product_name": "RK3568-KHDVK",
  "product_company": "kaihong",
  "product_device": "rk3568-khdvk",
  "version": "2.0",
  "type": "standard",
  "product_build_path": "device/kaihong/build",
  "parts":{
  	......
    "multimedia:multimedia_histreamer":{},
    "multimedia:multimedia_media_standard":{},
    "multimedia:multimedia_audio_standard":{},
    "multimedia:multimedia_camera_standard":{},
    "multimedia:multimedia_image_standard":{},
    "multimedia:multimedia_media_library_standard":{},
    "mytest:hello":{}, //  Add your own parts （ Note the comma before and after , Keep the file format correct ）
    ......
  }
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

Indicates the product name , Product manufacturers , Product equipment , edition , The type of system to compile , And the parts included in the product .

# Summer Challenge #OHOS Build custom service practice _ Kai Hong HarmonyOS_10

5.1.2 How to compile the new service

Compile the entire open source Hongmeng system , The order is as follows ：

here {product_name} In actual operation, it is changed to Product name , for example ,rk3566,rk3568 etc. . The files generated by compilation are archived in out/{device_name}/ Under the table of contents , The result is mirrored output at out/{device_name}/packages/phone/images/ Under the table of contents .

After the compilation , As for how to burn, please refer to the official website or other articles .

5.2 Integrate new services into ohos in

From the code structure, we can see , except 5.1 Configuration , It also needs to be ：

5.2.1 establish sa_profile Contents and related documents

Create in the subsystem root directory sa_profile Catalog , Create services ID Prefixed xml Documents and BUILD.gn.

explain ：

service ID Value is defined in foundation/distributedschedule/samgr/interfaces/innerkits/samgr_proxy/include/system_ability_definition.h in , If not, create a new .

# Summer Challenge #OHOS Build custom service practice _ Customize _11

sa_profile Directory example ：

# Summer Challenge #OHOS Build custom service practice _ Customize _12

9999.xml File example ：

<info>
    <process>hello</process>  //  Process name hello
    <systemability>
        <name>9999</name> <!-- Declare the id of system ability. Must be same with //utils/system/safwk/native/include/system_ability_definition.h -->
        <libpath>libhello_service.z.so</libpath> <!-- Load path -->
        <run-on-create>true</run-on-create> <!--true:  After the process is started, it will send a message to samgr The component registers the SystemAbility; false: Start on demand , That is, access to the... In other modules SystemAbility When to start -->
        <distributed>false</distributed> <!--true: The SystemAbility For distributed , Support cross device access ; false: Local cross IPC visit -->
        <dump-level>1</dump-level>
    </systemability>
</info>

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

BUILD.gn Example ：

import("//build/ohos/sa_profile/sa_profile.gni")

ohos_sa_profile("hello_sa_profiles") {
  sources = [ "9999.xml" ]
  part_name = "hello"
}

     
      1.
      2.
      3.
      4.
      5.
      6.

5.2.2 establish etc Contents and related documents

Create in the subsystem root directory etc Catalog , Create the corresponding... Of the service process .rc file .

etc Directory example ：

# Summer Challenge #OHOS Build custom service practice _ Customize _13

hello.cfg Configuration example ：

{
    "services" : [{
            "name" : "hello",
            "path" : ["/system/bin/sa_main", "/system/profile/hello.xml"], //  Instruction use sa Pull it up , When configuring a file hello.xml
            "uid" : "system",
            "gid" : ["system", "shell"]
        }
    ]
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.

5.3 How to communicate with new services

5.3.1 Through the command line and server End to end communication

establish main Function to test , The code is as follows ：

int main()
{
    std::shared_ptr<CliTool> tool = getCliTool();

    if (tool == nullptr) {
        cerr << "Internal error!" << endl;
        return -1;
    }

    cout << tool->getName() << std::endl;

    while (true) {
        char cmd[MAX_LINE_SIZE] = "";
        cin.getline(cmd, MAX_LINE_SIZE - 1);
        cout << "Input is " << cmd << endl;

        if (strcasecmp("quit", cmd) == 0) {
            cout << "Quit" << endl;
            break;
        }

        if (strcasecmp("help", cmd) == 0) {
            tool->usage();
            continue;
        }

        string scmd(cmd);
        tool->execute(scmd);
    }

    return 0;
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

Definition AbilityCliTool class , Use send Bound function cmdSendMessage, adopt main in execute Function call AbilityCliTool::cmdSendMessage, The code is as follows ：

class AbilityCliTool: public std::enable_shared_from_this<AbilityCliTool>, public CliTool {
public:
    AbilityCliTool() {
        std::function<void(std::vector<std::string>&)> f;

        f = std::bind(&AbilityCliTool::cmdSendMessage, this, std::placeholders::_1);
        commands_.emplace("send", f); //  Use here send Bound function cmdSendMessage

        spProxy_ = std::make_shared<HelloClient>(); //  Instantiation HelloClient object spProxy_
        if (spProxy_) {
            spProxy_->InitService();
        }
    }

    virtual void usage() {
        std::cout << "AbilityCliTool usage" << std::endl;
    }

    virtual std::string getName() {
        return "AbilityCliTool";
    }

    virtual void execute(std::string &cmd) {
        std::cout << "AbilityCliTool::execute(" << cmd << ")" << std::endl;
        auto args = StringSplit(cmd, " "); 
        auto func = commands_[args[0]];
        if (func) {
            func(args);
        }
    }

    virtual ~AbilityCliTool() {
        std::cout << "~AbilityCliTool()" << std::endl;
    }

private:
    void cmdSendMessage(std::vector<std::string> &args) {
        std::cout << "cmdSendMessage args:";
        for (auto &arg: args) {
            std::cout << " " << arg;
        }
        std::cout << std::endl;
        if (spProxy_) {
            spProxy_->SendMessage("Hello,World\n"); // 
        }
    }

    std::map<std::string, std::function<void(std::vector<std::string>&)>> commands_;

    std::shared_ptr<HelloClient> spProxy_;
};

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.

HelloClient The class implementation code is as follows ：

namespace {
    constexpr int32_t MAX_RETYE_COUNT = 30;
    constexpr uint32_t WAIT_MS = 200;
}

int32_t HelloClient::InitService()
{
    if (helloServer_ != nullptr) {
        HELLO_LOGI(HELLO_NATIVE, "[InitService]Already init");
        return ERR_OK;
    }

    auto systemAbilityManager = SystemAbilityManagerClient::GetInstance().GetSystemAbilityManager(); //  adopt SystemAbilityManager Of GetSystemAbility Method to obtain the corresponding SA Agent for IRemoteObject
    if (systemAbilityManager == nullptr)  {
        HELLO_LOGE(HELLO_NATIVE, "[InitService]GetSystemAbilityManager failed");
        return ERR_NO_INIT;
    }   

    int retryCount = 0;
    do {
        helloServer_ = iface_cast<IHello>(systemAbilityManager->GetSystemAbility(HELLO_SERVICE_ID)); //  Equivalent to generating a proxy object ,said Unique identification SA, Here we use HELLO_SERVICE_ID.  Use here iface_cast Macro to concrete type 
        if (helloServer_ != nullptr) { 
            HELLO_LOGI(HELLO_NATIVE, "[InitService]InitService success.");
            return ERR_OK;
        }
        HELLO_LOGI(HELLO_NATIVE, "[InitService]Get service failed, retry again ....");
        std::this_thread::sleep_for(std::chrono::milliseconds(WAIT_MS));
        retryCount++;
    } while (retryCount < MAX_RETYE_COUNT);
    HELLO_LOGE(HELLO_NATIVE, "[InitService]InitService timeout.");
    return ERR_TIMED_OUT;
}

int32_t HelloClient::SendMessage(const std::string& msg)
{
    std::lock_guard<std::mutex> lock(mutex_);
    if (helloServer_ != nullptr) {
        return helloServer_->SendMessage(msg);
    }

    if (InitService() != ERR_OK) {
        return ERR_NO_INIT;
    }
    HELLO_LOGI(HELLO_NATIVE, "[SendMessage]Call SendMessage");
    return helloServer_->SendMessage(msg);
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.

It's going to be HelloProxy Object SendMessage function , The specific code is as follows ：

int32_t HelloProxy::SendMessage(const std::string& msg)
{
    MessageParcel helloData;
    MessageParcel helloReply;
    MessageOption helloOption(MessageOption::TF_SYNC);

    if (!helloData.WriteString(msg)) {
        return ERR_INVALID_VALUE;
    }

    int32_t helloRet = Remote()->SendRequest(CMD_HELLO_SEND_MESSAGE, helloData, helloReply, helloOption);
    if (helloRet != ERR_OK) {
        return helloRet;
    }

    return ERR_OK;
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

HelloProxy Class is Proxy Server-side implementation , Inherit IRemoteProxy<IHello>, call SendRequest Interface to Stub End send request , Expose the capabilities provided by the server .HelloStub The specific code of the class is as follows ：

int32_t HelloStub::OnRemoteRequest(uint32_t code, MessageParcel& data, MessageParcel& reply, MessageOption& option)
{
    switch (code) {
        case CMD_HELLO_SEND_MESSAGE:
            return HelloStubSendMessage(data, reply, option);
        case CMD_HELLO_GET_VERSION:
        default: {
            HELLO_LOGD(HELLO_SERVICE, "%{public}s: not support cmd %{public}d", __func__, code);
            return IPCObjectStub::OnRemoteRequest(code, data, reply, option);
        }
    }
}

int32_t HelloStub::HelloStubSendMessage(MessageParcel& helloData, MessageParcel& helloReply, MessageOption& helloOption)
{
    std::string msg = helloData.ReadString();

    int32_t helloRet = SendMessage(msg);
    if (helloRet != ERR_OK) {
        HELLO_LOGD(HELLO_SERVICE, "%{public}s failed, error code is %d", __func__, helloRet);
        return helloRet;
    }

    return ERR_OK;
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.

explain ：

This class is and IPC Framework related implementation , Need to inherit IRemoteStub<ITestAbility>.Stub The end is the end that receives the request , Need to rewrite OnRemoteRequest Method is used to receive client calls .

Next through HelloStubSendMessage The specific implementation class of the service side business function is called HelloService in SendMessage function , The specific code is as follows ：

REGISTER_SYSTEM_ABILITY_BY_ID(HelloService, HELLO_SERVICE_ID, true);

HelloService::HelloService(int32_t sysAbilityId, bool runOnCreate) : SystemAbility(sysAbilityId, runOnCreate)
{
    HELLO_LOGI(HELLO_SERVICE, "[HelloService]%{public}p", this);
}

int32_t HelloService::SendMessage(const std::string& msg)
{
    HELLO_LOGI(HELLO_SERVICE, "[SendMessage]This is just for test. %{public}s", msg.c_str()); //  Log verification point , To this end 
    return ERR_OK;
}

void HelloService::OnStart()
{
    HELLO_LOGI(HELLO_SERVICE, "[OnStart]%{public}s start.", __func__);
    bool isPublished = SystemAbility::Publish(this); //  Publish your own service to saMgr in 
    if (!isPublished) {
        HELLO_LOGD(HELLO_SERVICE, "[OnStart]publish LocationService error");
        return;
    }
}

void HelloService::OnStop()
{
    HELLO_LOGI(HELLO_SERVICE, "[OnStop]]%{public}s stop.", __func__);
}

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.

5.3.2 Trigger and... Through the application layer server End to end communication

In tools DevEcoStudio Create project , stay index.js The specific code in the document is as follows ：

import hello_native from '@ohos.hello'

export default {
    data: {
        title: ""
    },
    onInit() {
        hello_native.hello();
    }
}

     
      1.
      2.
      3.
      4.
      5.
      6.
      7.
      8.
      9.
      10.

Generated after compilation hap package , Install on the development board , Execute the order as follows ：

In addition to modification at the application layer , You also need to make the following changes in the framework layer ：

#include <assert.h>
#include "napi/native_api.h"
#include "napi/native_common.h"
constexpr uint32_t STR_LEN = 13
static napi_value Method(napi_env env, napi_callback_info info) {
    HELLO_LOGI(HELLO_NATIVE, "[Method]Call SendMessage");
    napi_status status;
    napi_value world;
    status = napi_create_string_utf8(env, "Hello, world!", STR_LEN, &world);
    HelloClient::SendMessage(world);
    assert(status == napi_ok);
    return world;
}

static napi_value Init(napi_env env, napi_value exports) {
    HELLO_LOGI(HELLO_NATIVE, "[Method]Call Init");
    napi_status status;
    napi_property_descriptor desc[] = {
        DECLARE_NAPI_FUNCTION("hello", Method),
    };
    status = napi_define_properties(env, exports, sizeof(desc) / sizeof(desc[0]), desc);
    assert(status == napi_ok);
    return exports;
}
/* * Module register function */
NAPI_MODULE(hello_native, Init)

     1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.

thus , From the application layer, you can trigger the call when initializing the application hello namely SendMessage function , And return the string “Hello,World" Show... In the application .

6 summary

Go through the above steps , stay ohos Customize subsystems or services in the system , Compile and burn into the overall system through configuration , And then through cli The function is verified by the command line or application startup trigger , It has achieved the expected three goals , Master the process and architecture of building custom services .

For more original content, please pay attention to ： Shenkaihong technical team

Beginner to master 、 Skills to cases , Systematic sharing HarmonyOS Development technology , Welcome to contribute and subscribe , Let's move forward hand in hand to build Hongmeng ecology .

Want to know more about open source , Please visit ：

51CTO Open source basic software community

https://ost.51cto.com/#bkwz

原网站

版权声明
本文为[51CTO]所创，转载请带上原文链接，感谢
https://yzsam.com/2022/179/202206281532366456.html