As it develops, more devices using HarmonyOS in the future may emerge, will Godot add export support for the HarmonyOS platform?
1 Like
Harmony is a rebranded AOSP distro up to version 4, so rebuilding for Android with their SDk should be doable. Edit: Make that an Android build might just run as is on those versions of HarmonyOS.
1 Like
tyra
May 30, 2026, 11:35pm
3
Hi, since this is one of the first posts that is showing up when searching an answer: There was already great work done to bring Godot to HarmonyOS, as you can see here:
opened 10:41AM - 05 Jul 25 UTC
topic:platforms
### Describe the project you are working on
I'm porting Godot Engine to OpenHar… mony - 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**
```mermaid
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
```
**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:
```typescript
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:
```cpp
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:
```cpp
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:
```cpp
// 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
- [x] Vulkan
- [ ] GLES
- Input
- [x] Touch Event
- [x] Text Input
- [x] Mouse Event
- [x] Keyboard Event
- Audio
- [x] Renderer
- [x] Capturer
- DispayServer
- [x] Portrait Layout
- [x] Landscape Layout
- [x] Window Resize
- [x] IME Control
- [x] Clipboard
- [ ] System Menu
- [ ] Multiwindow
- [ ] Multiscreen
- Scripts
- [x] GDScript
- [x] C# (Experimental)
- Network
- [x] TCP/IP stack
- [x] HTTP
- [x] HTTPS (TLS)
- TTS
- [ ] TTS
- Export
- [x] 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
https://github.com/user-attachments/assets/9dcad7fe-2986-40c3-93fc-3198429e2b42
https://github.com/user-attachments/assets/0dd3a7ff-e59a-46aa-846f-a56bbaf87021
### 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