playbooks

home / skills / openharmonyinsight / openharmony-skills / oh-interfaces-ipc-to-service

oh-interfaces-ipc-to-service skill

/skills/oh-interfaces-ipc-to-service

This skill helps integrate a transparent passthrough interface into OpenHarmony graphic_2d by generating IPC plumbing and service-side stubs.

npx playbooks add skill openharmonyinsight/openharmony-skills --skill oh-interfaces-ipc-to-service

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.9 KB
---
name: oh-interfaces-ipc-to-service
description: 在Openharmony项目的graphic_2d仓新增透传通路。当用户希望在graphic_2d仓新增RSInterface接口，且指明该接口为ToSerivce时，调用该能力
---

你是一名高级图形图像开发工程师，现在将在Openharmony graphic_2d仓的rs_interfaces.cpp/.h文件中，新增一个透传接口
考虑到这一类需求有的依赖于硬件底层实现，有的不依赖，所以统一将透传通路开辟到rs_screen.cpp/.h这一层即可，并在rs_screen.cpp的新增接口实现中，适当留空供用户实现底层调用逻辑
该工作通常包含以下几个步骤：

1. **询问用户接口声明**：用户传入期望新增的接口声明。注意，当用户传入的接口声明不符合C++语法时，需要告知用户并询问正确的接口声明

2. **询问用户接口更多信息**：询问用户期望接口具有 @System鉴权还是@Foundation鉴权，这两个信息后面代码生成要用到

3. **明晰参考接口**：重点参考rs_interfaces.cpp/.h中的SetDualScreenState()接口和GetPanelPowerStatus()接口的调用链

4. **新增透传通路：Client侧**：由于graphic_2d仓的接口通路采用C/S架构，因此，在Client侧，通常需要在rs_interfaces.cpp/.h、rs_render_service_client.cpp/.h中新增接口

5. **新增透传通路：Service侧**：在Service侧，通常需要在rs_client_to_service_connection.cpp/.h，rs_screen_manager.cpp/.h，rs_screen.cpp/.h中新增接口

6. **新增透传通路：IPC**：在graphic_2d仓中，Client侧到Service侧通过IPC实现，你需要在rs_iclient_to_service_connection.h这个抽象类中添加新接口的声明，在rs_client_to_service_connection_proxy.cpp/.h根据接口的形参列表和返回值调用MessageParcel和SendRequest的能力，在rs_client_to_service_connection_stub.cpp的OnRemoteRequest()函数中添加一个case用于响应proxy的请求，包括读取MessageParcel，调用rs_client_to_service_connection.cpp的新增接口，并将调用结果通过MessageParcel写回给Client侧。此外，有一个注意点：
1）case有个专门的枚举值存储在rs_iclient_to_service_connection_ipc_interface_code.h中，当需要新增接口时，你需要同步在这个文件中添加新枚举；

7. **新增透传通路：鉴权相关事项**：对于rs_iclient_to_service_connection_ipc_interface_code.h中新增的枚举值，还有两个地方会使用到：
1）在rs_client_to_service_connection_stub.cpp的descriptorCheckList中，需要新增这个枚举值；
2）在rs_irender_service_connection_ipc_interface_code_access_verifier.cpp的IsExclusiveVerificat函数中，需要新增一个case，根据用户期望的鉴权方式，调用IsSystemCalling或IsFoundationCalling进行鉴权

8. **检查代码**：最后，你需要检查代码修改是否严格遵循C++ 17的语法，以及是否和已有代码保持高度风格一致（例如函数名双驼峰，变量名单驼峰）

Overview

This skill adds a passthrough RSInterface endpoint in the OpenHarmony graphic_2d repository when the user requests a new interface tagged ToService. It guides the developer through declaring the C++ interface, choosing the required authorization (System or Foundation), and generating the client/service/IPC plumbing while leaving hardware-specific hooks for implementation. The output focuses on practical file edits, IPC code patterns, and verification steps to integrate the new interface cleanly.

How this skill works

I inspect the requested interface signature for valid C++ syntax and ask for corrections if needed. I then generate the required client-side, service-side, and IPC changes following the existing SetDualScreenState/GetPanelPowerStatus call chains, including new enum codes, proxy/stub parcel handling, descriptor checks, and access verification stubs. Hardware calls are left as clear TODO hooks in rs_screen.cpp for developers to implement.

When to use it

  • You want to expose a new RSInterface in graphic_2d marked ToService.
  • You need a passthrough path from client to service without adding business logic in graphic_2d.
  • You must add IPC transport code (proxy, stub, parcel read/write) for a new interface.
  • You require controlled authorization (System or Foundation) for a new interface.
  • You want consistent style and C++17-compliant integration with existing rs_* files.

Best practices

  • Provide a valid, compilable C++ function signature when asked; I will validate syntax before generating code.
  • Specify the authorization type (System or Foundation) up front so access verifier code is generated correctly.
  • Follow existing patterns in rs_interfaces.cpp/.h and rs_screen.cpp/.h; mirror SetDualScreenState/GetPanelPowerStatus chains for consistent behavior.
  • Add minimal, well-documented TODO hooks in rs_screen.cpp for vendor or hardware-specific calls instead of embedding platform logic in generated code.
  • Run a C++17 build and static analysis after changes to catch style or ABI mismatches early.

Example use cases

  • Expose a brightness or HDR control API from client UI to the screen service as ToService.
  • Add a hardware-specific calibration command that must be routed from client through IPC to the screen manager.
  • Create a diagnostic trigger interface that client tools call, with Foundation or System authorization as required.
  • Add a power-management hint that requires a direct passthrough to the service and vendor implementation.

FAQ

What if my interface signature is syntactically invalid?

I will flag syntax errors and request a corrected C++ signature before generating code; provide a valid declaration and retry.

Where do I implement hardware-specific calls?

The generated rs_screen.cpp contains TODO hooks in the new interface implementation. Place platform or vendor calls there to keep IPC and service logic separate.