So, hi everyone, I'm Francesco, and I work on the Unure project.
So we often hear about breaking the mobile do-opily.
So today I want to talk about our initiative and how we are bringing a mobile OS that
is designed for one specific regional ecosystem and how we bring it to the global open source
community and how we make it run on sound up phones.
So what is Unure and how does it relate to Open Harmony?
Open Harmony is a project that was launched in 2020 as a code donation from Huawei to the open
source community.
And it's a massive project, it's mature and it powers Harmony OS that runs on Huawei commercial
devices.
So Open Harmony was primarily incubated in the Chinese ecosystem and so that's the role
of Unure is to build a bridge and to bring this project globally.
So it's an Eclipse Foundation project and it's based in Europe and we take the Open Harmony
code base and we wrap it in the European governance.
So why do we need a bridge?
So if you're a developer outside of China and you want to work with Open Harmony, you
might hit some friction.
For example, Open Harmony code is hosted on Chinese GitHub from or the documentation
is often in Chinese and the hardware used by the community is often not available in Europe.
So Unure tries to strips that friction away and we maintain GitHub mirrors, we maintain
English first documentation and we focus on hardware enablement for devices that people
actually have, maybe already in your jar or you can actually buy and we also provide tooling
that are developer friendly.
So let's dive into the architecture, Open Harmony is not just a phone OS, it's one OS
any device and it can scale from the mini system running on MCU with kilobytes of RAM all
the way to the standard system that runs on phones and tablets.
So for this talk in the possible mobile context we're focusing on the standard system that
has the full stack, it has 3D GPU support and a complete application ecosystem.
So one question that I often hear is, is Open Harmony or Unure based on Android?
So the question is the answer is no and it's a completely new software stack and it's
designed from the ground up to enable seamless collaboration between wide range of smart devices.
So here's a high view level of the kernel and so the kernel at the kernel level we support
multiple kernels, we have light OS for the mini system and Linux for the standard system
and above that we have an hardware structure layer called hgf and a graphical layer called
the rows and so I'll explain this in a moment.
But the things get innovative with distributed capabilities, we have the distributed framework
that allows devices to collaborate with each other, discover each other and virtualized
hardware.
So think about the phones camera that can be mounted on two tablets over Wi-Fi as if they were
a single super device.
But for us, porters, the challenge starts at the kernel layer.
Open Harmony uses Linux 5.10 or 6.6 so you cannot use vanilla mainline and you need some
specific configuration enabled.
So we need binder IPC like in Android and Ashmem, anonymous shared memory, similarly to Android
until Android 12 recently Android migrated to MemFty but Open Harmony still relies on Ashmem
so you need to patch the kernel if you're tracking mainline and you need also some other
open Harmony specific extension like for hdf and for access token ID for the security
subsystem.
So these parties are required for our porting.
The part that usually confuses people coming from ASP or from Linux is the use of hdf,
the hardware driver from foundation.
So it might look like that we are reinventing the wheel but hdf is actually a middleware.
It's not a replacement for a kernel.
The Linux kernel remains there, we still use the device 3 and the user space rather than
talking directly to the kernel drivers it talks to the hdf which abstracts the service publishing.
So this allows us to write one driver interface once and you can run all on both the Linux
kernel and both on the light OS so it decouples the driver logic from the underlying kernel.
Moving to the graphics, the graphical stack is called Rosen, application don't draw the buffers,
they build a local scene graph and they batch this command via IPC to the render service
which reconstructs the scene and execute the GPU draw commands and how does it talk to
the hardware rely on the standard Linux graphical stack.
There's the display hardware device interface that wraps around the standard DRM and
KMS for mode setting and B-sync.
There's a memory hdf that wraps around the Ragnol, Ralloc or GPM and it uses direct memory
access buffers for zero copy buffer sharing.
So if you're porting a device that already has a good mainline support for DRM, you already
have with there for the display stack.
But here's the catch, the GPU driver problem, to get hardware acceleration you need drivers
and in the mobile world, the vendors often provide blocks that are linked against bionic
eclipsy for Android and on OpenHarmony, we use Mazol eclipsy that is more lightweight
but it's not binary compatible with bionic.
So either you have a very good friend at the chipset manufacturer that can build a Mazol-based
driver for you or you use open source Mazol drivers but many mobile SOC lock support for
Mazol.
So how do we support the already existing thousands of Android devices, we integrate the
libraries to access a translation layer.
So it sits in between the Mazol-based user space and the bionic-based vendor blocks
and it overrides the symbols and dynamically links the libraries.
So this allows you to run on existing hardware using the proprietary GPU drivers.
It's a workaround, it's not ideal but it can lock support for existing hardware.
So OpenHarmony is already ported by the community on many devices.
For example, we can demonstrate a OnePlus 60 which is the pure path, it has a good
mainline support and so we use pre-dreeno for the Mazol drivers so it's the fully open stack.
For the second example we have is we're porting to the Voila devices, here the mainline support
is thinner so we're implementing the hybrid approach and we got the system booting the
RAM display output and patch input.
So this proof that we can both tackle the open path and the proprietary paths.
Beyond physical devices we also developed a QMO-based emulator for development using
a Mazol-Grivers for software rendering.
It's using X86 architecture for a hyperparzac acceleration.
So you can use this rather than having to ship a development board from China.
Moving to the application layer, OpenHarmony uses RTS for development which is an extended
TypeScript language for design for this platform but you can also use other cross platform
frameworks so we are bringing React Native and other others.
So developers can bring their existing application without too much effort.
And we're also trying to improve the developer experience.
We are providing a only RID extension for VS code which can handle SDK building application
and deploy them on any device and its sports Linux.
So this can lower the entry barrier for.
So unfortunately I don't have much time so we're bringing mobile OS that is owned by any
single corporation so I invite you to join the community and let's code local while
thinking go boom thank you.