Add official support for OpenHarmony OS

[kdada]

Describe the project you are working on

I'm porting Godot Engine to OpenHarmony - the open-source distributed OS backed by the OpenAtom Foundation. This enables Godot games/apps to run natively on 700M+ OpenHarmony devices (phones, tablets, IoT, and vehicle systems).

Describe the problem or limitation you are having in your project

Currently:

• Godot lacks official support for OpenHarmony

• Developers targeting OpenHarmony must use:

  • Web exports (limited performance)

• Major Chinese publishers may shun Godot in favor of Unity due to lack of OpenHarmony support

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Native OpenHarmony platform support including:

• DisplayServer_OpenHarmony for window/input management

• OS_OpenHarmony subsystem for filesystem/threads

• Vulkan/OpenGL ES rendering via OHOS graphics stack

• Audio and network integration

Benefits:

• Enable performance-critical games on OHOS devices

• Position Godot as primary game engine in OpenHarmony ecosystem

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Core Architecture

graph TD
    A[EntryAbility] --> B[Index Page]
    B --> C[XComponent]
    
    subgraph Godot Runtime
    C --> D[napi.setup]
    D --> E[godot_init]
    end
    
    subgraph Initialization
    E --> F1[Vulkan Context]
    E --> F2[FileAccessOpenHarmony]
    E --> F3[DirAccessOpenHarmony]
    E --> F4[OS_OpenHarmony]
    E --> F5[DisplayDriverOpenHarmony]
    E --> F6[AudioDriverOpenHarmony]
    E --> F7[Main::setup]
    end
    
    subgraph Rendering Thread
    F7 --> G[NativeVSync]
    G --> H[Main::setup2]
    H --> I[Frame Rendering Loop]
    end
    
    subgraph Input Handling
    C --> J[Device Input Events]
    J --> K[napi.input]
    K --> L[godot_input]
    L --> M[InputEvent Conversion]
    M --> N[Godot Input Singleton]
    N --> I
    end

Loading

Component Breakdown

1. EntryAbility

   • OpenHarmony application entry point
   • Launches the main UI container

2. Index Page

   • Primary ArkUI page
   • Creates XComponent for native rendering

3. XComponent

   • Core rendering surface (acts as Vulkan window)
   • Responsibilities:

     XComponent({
       id: 'window',
       type: 'surface',
     })
     .onLoad((context) => {
       napi.setup(context); // Initialize native bindings
     })
     .onTouch((event) => {
       napi.input(event); // Handle events
     })

4. napi.setup → godot_init
   Initialization sequence:

   void napi_setup(napi_env env) {
       // Initialize core subsystems
       godot_init();
   }
   
   void godot_init() {
       // 1. Platform setup
       FileAccessOpenHarmony::setup();
       DirAccessOpenHarmony::setup();
       os_openharmony = memnew(OS_OpenHarmony);
       
       // 2. Main setup
       Main::setup();
       
       // 3. Start render thread
       OH_NativeVSync_RequestFrame(native_vsync, godot_step);
   }

5. NativeVSync Rendering Thread
   Frame synchronization implementation:

   void godot_step() {
       if (STEP_STEUP)
         Main::setup2(false); step++;
       if (STEP_SHOW_LOGO)
         Main::setup_boot_logo(); step++;
       if (STEP_STARTED)
         Main::start(); os_openharmony->main_loop_begin(); step++;
   
       os_openharmony->main_loop_iterate();
   
       // Request next frame
       OH_NativeVSync_RequestFrame(native_vsync, godot_step);
   }

6. Input Event Flow
   Device-to-Godot mapping:

   // input_ohos.cpp
   void godot_input(InputEvent event) {
       Input::get_singleton()->parse_input_event(event);
   }

This architecture maintains OpenHarmony's application model while embedding Godot's runtime as a native rendering component, ensuring compatibility with OHOS's security sandbox and lifecycle management.

Implementation
Active development branch: https://github.com/kdada/godot/tree/openharmony

• Render
  • Vulkan
  • GLES
• Input
  • Touch Event
  • Text Input
  • Mouse Event
  • Keyboard Event
• Audio
  • Renderer
  • Capturer
• DispayServer
  • Portrait Layout
  • Landscape Layout
  • Window Resize
  • IME Control
  • Clipboard
  • System Menu
  • Multiwindow
  • Multiscreen
• Scripts
  • GDScript
  • C#
• Network
  • TCP/IP stack
  • HTTP
  • HTTPS (TLS)
• TTS
  • TTS
• Export
  • Export Project

Demo

• Shader: Change the color of ball （blue to white）
• GDScript: Change the position of ball (bottom to top)
• Touch: Click the bottom button (The touch dot is added by OpenHarmony's screen recorder, not rendered by Godot)
  • curl http://bing.com
  • IP/TCP and HTTP work properly
• SystemFont: Auto fallback to system font
• AudioStreamPlayer: Play BGM

6eafdf8e75ed8225425ad046ad78d175.mp4

ea56e5e1b556ae516b1abf58332d4681.mp4

If this enhancement will not be used often, can it be worked around with a few lines of script?

No viable workaround exists because:

• Platform ports require deep OS integration (cannot be done via scripts)

• Critical subsystems (windowing, input, graphics) need native C++ bindings

Is there a reason why this should be core and not an add-on in the asset library?

Add-ons cannot modify core platform abstraction layers

[Calinou]

• See Add support to export HAP (HarmonyOS Ability Package) #10067.

[jaysunxiao]

Awesome Job !!!