Open Harmony - more than an OS
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Schmidt, Stefan
Breaking hardware boundaries, transcending the classic dichotomy of an OS, this is what OpenHarmony is about. Catering the needs from tiny sensors up to powerful systems, from edge to cloud. In this presentation Stefan will address questions every FOSS developer will have, when hearing about OpenHarmony for the first time. If you are curious about the architecture, used FOSS projects, or want to know more about contribution guidelines and start picking in the code this talk would be a good start. Stefan will talk about the multiple-kernel approach, the distributed architecture and layers. He will also explain our public development infrastructure and contribution flows.
 Good evening everybody. My name is Stefan Schnett. I want to talk to you about Open Harmony, more than on operating systems. You can see here the abstract, which is also on the foster website. So I'm not going to read it out loud. It's mostly here for purpose when people are later touching the slides and understand what's going on. So the agenda for this talk today. I will start with talking about me a little bit, then talking about open source and worldwide in general, going into the open source technology center in particular, and then going to the technical parts about Open Harmony, its distributed architecture, what kind of open source projects we are already using, what kind of hardware we are running on, how our approaches to different kernels underneath our infrastructure and how we handle contributions right now, and then we will finish up with a little bit of a roadmap. So as I said before, my name is Stefan Schnett. I'm a principal architect, open source architect at the Open Source Technology Center at ULI. I joined ULI two months ago, so it's quite fresh for me as well. I've been working for different companies before, open local, bug lab, Samsung open source group. So in total I've been like 16 years in my open source career, I would say. So my first presentation at Foster Embedded Room was already in 2010. That was quite fun. I've been working in different parts of the open source ecosystem. Working on Open Embedded, Yocto, working on the Linux kernel, Subsystem maintainer, working on the Lightning Foundation libraries, other toolings here and there. So there's a lot of things going on. So open source and ULI, how does that fit together? So open source is really strategic to ULI. One aspect is it breaks down vendor lock-in. So that also helps the vendor as well. So that means people can choose what kind of hardware they are using together and how they can make the best use of it. But that also opens up possibilities for companies, obviously. And if you look at whoever products, the baseline that is really similar to other technologies or other devices out there is quite high. So while we obviously have technology on top differentiators from others, there's quite a lot of technologies that are shared the most. So it makes a lot of sense for whoever to invest into open source. And they're doing that for a while already. I mean, there's a lot of contributions in different projects, obviously a lot in the 5G and TECO space, but also in things like the Linux kernel, for example. If you look at the 5.10 stats at Linux Weekly News, you can see that whoever was the top employer for Linux kernel employees in 5.10. So the open source technology center, which was founded in 2020. So it's quite new. We only started like, per last year or something. It's pan-European. We have people sitting in offices in different cities like Milan, Munich, Helsinki, London, Warsaw, Cork, Lyon. It is also quite a diverse group. It's not only engineering, but we are also having people from product management. We have marketing. We have field engineering and evangelism and things like that. So the biggest project or the project we have right now is bringing Open Harmony to Europe. So what is Open Harmony? Open Harmony is a new operating system being developed by Huawei initially and now going out into the world as Open Harmony and working together with the communities and partners to fulfill the ideas. The idea is to have an edge-to-cloud operating system for small IoT devices, consumer devices, and so on. And the promise is we want to fulfill in the end is to have automomers and cooperative devices. One basic idea here, we come to that later as well, is that we're going to form so-called virtual super devices where we have the capabilities and resources from individual devices put together in one super device and then one application can use all of them together. And in this process, we're obviously leveraging a lot of open source components already. And what we want to do with Open Harmony is that we open up really early in this process. We want to have community engagement right from the start. So what you see in our public GitLab instance, for example, is what we are currently working on. That's not a code dump or something. That's something we are actively working on and defining what Open Harmony should be in the end. So you can be right there from the start. So the architecture we have here. So some parts are pretty common. Two parts are mostly the interesting areas, I would say. So the quite common part is that obviously we have a kernel and then we have a base system layer, plumbing layer, if you want. These are quite common to what you have seen before, I would say. We have a Linux system, Linux color running. We have the call libraries, we have our gdpc, we have our crypto libraries, for example, and so on. That's all quite normal stuff. The two big difference we have here is that we are going for a multiple kernel approach. So we will have Linux running on the powerful systems and Zafire running on the not so powerful systems. There might be more kernels later on, but that's what we are focusing on right now. The second aspect that is interesting in the Open Harmony architecture is the distributed virtual framework. There we will have a scheduler and other parts that are working to have different devices, forming a virtual bus and then using that to communicate. And by that breaking the hardware boundaries one single device has and the hardware sources a single device has and then pooling them together. This is aimed for consumer devices and not something like you would know from AI or other concepts. So what is this distributed virtual framework? Going to a bit more details here. So our vision is that you will have stationary as well as mobile devices and all of them are going to discover each other and connect over a distributed virtual bus as a communication channel. But on top of this channel the devices will have all their capabilities and resources they have. They can share them into a so called device resource pool. These device resource pool will then augment all the parts from the different device together and have one unified API on top of that. So that an application that runs on top of these API can use all these things without having any knowledge about what kind of devices are below it and how they are connected or whatsoever. So that opens up quite some interesting possibilities. But I mean being here for them the interesting part is what are we doing on the open source side of things. We have a strong focus on using existing open source projects, using them downstream as a consumer but as well as upstreaming our changes to that to lower our maintenance overhead and really free engineering to work on other parts as well. But we are not using the open source projects only on the engineering side. As I said before the OSDC is a quite diverse group and we have project management for example setting in the project in the group as well. So for these people we also have tools and we have to have tools and we are using things like OpenProject for example to help them do their work and really integrate it well with engineering. So here are just some examples what kind of open source project they are using right now. Obviously we are using something like Linux, we are using open embedded Jocktor for the building, we are using a lot of different libraries and tools in the last funding layer, we are using Zephyr project, we are using GitLab, a hosted Github instance, self-hosted Github instance to manage all our source code hosting and project stuff inside it. We have OpenProject for the project management aspect, we have MetaMOS for Shed, etc. There are a lot of other things I might have missed here but that is already in use and that is how we are running it. And while we are doing that we are looking at the code we have from other parts and we look at how we can bring out OpenHarmony in a way that actually is in real open source spirit. And that is what I mean, we look at each component we have in-house already and we try to see if that is working well or if that is something we can open source that makes sense to open source or if there is already something better. So we are trying to pick the right things and make the right choices here. So how would the building and development setup look like? So I would say if you are a Pamela with OpenBettered this looks quite common to you, quite normal to you. So we have MetaOS layer, OS standing for OpenHarmony OS. We have a layer there sitting where all our stuff is bundled together basically and having layer means it is quite easy to bring in other layers in the OpenBettered.io so you can bring in your BSP layer for your specific hardware. You can bring a software layer where you have your own applications and so on, your own middleware or whatever. So that is easy to bring in together and just build a full image out of that. So let's look at an example setup here. I mean, creating a directory is clear. Then we use Repo to make sure that we have all the needed repositories cloned and synced in one go. So you have a manifest you would edit from and then you sync. And after that you would basically have a normal OpenBettered workflow. You would do some variable initialization and then you would add some bit-baked layers. As an example we are using MetaOE and Metapycin here and after that you can go ahead and bit-bake whatever image or package you want to do. Right now we are using the DiskHero Pocky that might change and the machine here is the QM over the other. It will be a real hardware for it. Talking about hardware, what kind of hardware we are supporting right now? So for the first two boards we set it on something that is easy to purchase. So we decided to go with two boards from the 96 boards initiative from Linauro. As I said, they are easy to purchase and the hardware bring up is also quite easy because there has been done a lot of work already in Zephyr as well as on Linux to make that happen. The boards we are having are Avenger 69 and the Nitrogen board. The Avenger being a combination of Cortex A7 and 1M4 core and the Nitrogen being a single Cortex M4 core only. So obviously that means you would go and aim for running Zephyr on the Nitrogen and running Linux on the Avenger. Maybe even in configuration where we run Linux on the A7 core and Zephyr on the M4 core. But that is something we have to figure out how to do that best and for what use cases that does make sense. Beyond these two boards we are already going to support there will be more coming from outside as well but it is also something the community can really jump in and make sure that show us what you are interested in supporting. As I said, that should be as easy as making sure that the right layers are enabled for your OE build and going from there. Also there will be more boards coming that are interesting for Huawei as well as some partner companies we are working on but this is something that will just grow over time and depending on the demand and interest. Based on the fact that we are using Linux, Zephyr and OpenEmbedded Yocto as a build system it should really be easy to bring up new hardware into the project. Okay, so one of the other key interesting aspects for OpenHarmony that is quite different from other platforms that are launching is that we are really aiming for a multiple current approach. As I mentioned before the idea is to have Linux running on the powerful system let's say Cortex-A7 and Zephyr on the low end system let's say Cortex-M4. Obviously that is not bound to these processors it's more like a class of devices we are aiming for here. And again a combination of these in an heterogeneous setup where you have like a remote processor or devices with an A7 and M4 together and then have a communication channel like remote proper, remote messaging or something. That's also interesting or something we are aiming for. This Yocto and OE the overall build will be the same for both of them so there will be no differences in building your whole image or something you want to bring onto the device and it's independent from the kernel basically. So I thought you build it for the FYE or for Linux that doesn't matter it will all fall out of the same bit or something. There might be needs for having some support libraries to augment the kernel APIs we have on the different kernels. That is obviously something we might need to do. How we do that in detail that's not completely defined or confirmed yet. We don't want to have an overall abstraction layer to avoid complexity and latency and other things. So we have to see on a case by case basis how we're going to do that. On the outer side we are starting with the FYE and that's what we are going for right now but we can imagine that later on there might be interest and need for other choices like LITRA or FYE or free ARTOS. But that really depends on the demand and the interest and if people are going to work on that or not. Here's a screenshot on our public GitLab instance we have. So as you can see there's already a lot of repositories there and all of the work we are doing is already in the public. There's nothing hidden behind a firewall or something. All the day by day work we are doing is happening there and you can look at it and join and make comments and make make match requests and other things. So that's the open spirit we want to want to go with here. And that brings me to the point that the whole way we are running the project is more like an open source project and not like a company product right. So that's what we are the ideas behind all of that. We already have distributed development because we are all sitting in different offices and a lot of us working from home due to COVID. We have all the DevOps already in place for that. We have our public communication channels like Metamos for example. The whole team is sitting there and discussing technical aspects and plans we are going to do and how we are going to do it in the open public. So you can just join and see what's going on there. We have the public GitLab instances. It brings it all together. And for the product planning and management side we have open project. That is still in progress to get that out into the open but they are making good progress there. And on the CI and CD side we also have pipelines already set up from going from simple style checks and the aim is going as deep as doing on hardware testing for match requests and things like that. So it's quite common to what you would expect from an open source project. Maybe not so common what you see in the public at least on a company side but we want really to drive it that way. And said that we really welcome contributions already at this early stage. I mean there's nothing you can now put on your hardware and run and sell a product or anything but you can really be influential from the start making sure that things are working in a way you think that makes sense or does contribute and make it use it for your own product in the end. Yeah you can send in metric requests. You can discuss issues on GitLab. You can just join MetaMOS and look around, talk to people, see what's going on, what are our plans there. Talking about plans. Here's what we have as a roadmap. It's not so much future looking because that's some roadmap we did last year to actually envision how we want to get ob-memory and OSTC started. As you can see we only got founded in April 2020. So that means there's a lot of things just in flux still growing basically. Our main focus right now is to get all the engineering parts in place. So get our DevOps in place, get all the code preparations ready, make sure that license compliance is top-notch and start accepting code contributions and then at some point really getting out a release as a baseline. Not a release as like a final version you can just put on your devices and sell as a product and everything is happy. More like really a release as a baseline where we can work together and then really bring this thing forward. So that would be it from my side. Thanks a lot for listening in and thanks a lot also to all the people from FOSTA making that possible and I know that's quite a huge task for you to get it all in an individual environment and not having your user way of bringing everybody to Brussels. So I'm really happy that you did that and happy that you had a FOSTA this year as well. So you can again find us at theshedotc.eu.org. There's a GitHub instance as well. They're launching the website soon and I think with that I'm ready for questions.
 Good evening everybody. My name is Stefan Schnett. I want to talk to you about Open Harmony,  more than on operating systems. You can see here the abstract, which is also on the foster  website. So I'm not going to read it out loud. It's mostly here for purpose when people  are later touching the slides and understand what's going on. So the agenda for this talk  today. I will start with talking about me a little bit, then talking about open source  and worldwide in general, going into the open source technology center in particular, and  then going to the technical parts about Open Harmony, its distributed architecture, what  kind of open source projects we are already using, what kind of hardware we are running  on, how our approaches to different kernels underneath our infrastructure and how we handle  contributions right now, and then we will finish up with a little bit of a roadmap.  So as I said before, my name is Stefan Schnett. I'm a principal architect, open source architect  at the Open Source Technology Center at ULI. I joined ULI two months ago, so it's quite  fresh for me as well. I've been working for different companies before, open local, bug  lab, Samsung open source group. So in total I've been like 16 years in my open source  career, I would say. So my first presentation at Foster Embedded Room was already in 2010.  That was quite fun. I've been working in different parts of the open source ecosystem. Working  on Open Embedded, Yocto, working on the Linux kernel, Subsystem maintainer, working on the  Lightning Foundation libraries, other toolings here and there. So there's a lot of things  going on. So open source and ULI, how does that fit together? So open source is really  strategic to ULI. One aspect is it breaks down vendor lock-in. So that also helps the  vendor as well. So that means people can choose what kind of hardware they are using together  and how they can make the best use of it. But that also opens up possibilities for companies,  obviously. And if you look at whoever products, the  baseline that is really similar to other technologies or other devices out there is quite high.  So while we obviously have technology on top differentiators from others, there's quite  a lot of technologies that are shared the most. So it makes a lot of sense for whoever  to invest into open source. And they're doing that for a while already. I mean, there's  a lot of contributions in different projects, obviously a lot in the 5G and TECO space,  but also in things like the Linux kernel, for example. If you look at the 5.10 stats  at Linux Weekly News, you can see that whoever was the top employer for Linux kernel employees  in 5.10. So the open source technology center, which  was founded in 2020. So it's quite new. We only started like, per last year or something.  It's pan-European. We have people sitting in offices in different cities like Milan,  Munich, Helsinki, London, Warsaw, Cork, Lyon. It is also quite a diverse group. It's not  only engineering, but we are also having people from product management. We have marketing.  We have field engineering and evangelism and things like that. So the biggest project  or the project we have right now is bringing Open Harmony to Europe. So what is Open Harmony?  Open Harmony is a new operating system being developed by Huawei initially and now going  out into the world as Open Harmony and working together with the communities and partners  to fulfill the ideas. The idea is to have an edge-to-cloud operating system for small  IoT devices, consumer devices, and so on. And the promise is we want to fulfill in the end  is to have automomers and cooperative devices. One basic idea here, we come to that later  as well, is that we're going to form so-called virtual super devices where we have the capabilities  and resources from individual devices put together in one super device and then one  application can use all of them together. And in this process, we're obviously leveraging  a lot of open source components already. And what we want to do with Open Harmony is that  we open up really early in this process. We want to have community engagement right from  the start. So what you see in our public GitLab instance, for example, is what we are currently  working on. That's not a code dump or something. That's something we are actively working on  and defining what Open Harmony should be in the end. So you can be right there from the  start. So the architecture we have here. So some parts are pretty common. Two parts  are mostly the interesting areas, I would say. So the quite common part is that obviously  we have a kernel and then we have a base system layer, plumbing layer, if you want. These  are quite common to what you have seen before, I would say. We have a Linux system, Linux  color running. We have the call libraries, we have our gdpc, we have our crypto libraries,  for example, and so on. That's all quite normal stuff. The two big difference we have here  is that we are going for a multiple kernel approach. So we will have Linux running on  the powerful systems and Zafire running on the not so powerful systems. There might be  more kernels later on, but that's what we are focusing on right now. The second aspect  that is interesting in the Open Harmony architecture is the distributed virtual framework. There  we will have a scheduler and other parts that are working to have different devices, forming  a virtual bus and then using that to communicate. And by that breaking the hardware boundaries  one single device has and the hardware sources a single device has and then pooling them  together. This is aimed for consumer devices and not something like you would know from  AI or other concepts. So what is this distributed virtual framework? Going to a bit more details  here. So our vision is that you will have stationary as well as mobile devices and all  of them are going to discover each other and connect over a distributed virtual bus as  a communication channel. But on top of this channel the devices will have all their capabilities  and resources they have. They can share them into a so called device resource pool. These  device resource pool will then augment all the parts from the different device together  and have one unified API on top of that. So that an application that runs on top of these  API can use all these things without having any knowledge about what kind of devices are  below it and how they are connected or whatsoever. So that opens up quite some interesting possibilities.  But I mean being here for them the interesting part is what are we doing on the open source  side of things. We have a strong focus on using existing open source projects, using  them downstream as a consumer but as well as upstreaming our changes to that to lower  our maintenance overhead and really free engineering to work on other parts as well. But we are  not using the open source projects only on the engineering side. As I said before the  OSDC is a quite diverse group and we have project management for example setting in  the project in the group as well. So for these people we also have tools and we have to have  tools and we are using things like OpenProject for example to help them do their work and  really integrate it well with engineering. So here are just some examples what kind of  open source project they are using right now. Obviously we are using something like Linux,  we are using open embedded Jocktor for the building, we are using a lot of different  libraries and tools in the last funding layer, we are using Zephyr project, we are using  GitLab, a hosted Github instance, self-hosted Github instance to manage all our source code  hosting and project stuff inside it. We have OpenProject for the project management aspect,  we have MetaMOS for Shed, etc. There are a lot of other things I might have missed here  but that is already in use and that is how we are running it. And while we are doing  that we are looking at the code we have from other parts and we look at how we can bring  out OpenHarmony in a way that actually is in real open source spirit. And that is what  I mean, we look at each component we have in-house already and we try to see if that  is working well or if that is something we can open source that makes sense to open source  or if there is already something better. So we are trying to pick the right things and  make the right choices here. So how would the building and development  setup look like? So I would say if you are a Pamela with OpenBettered this looks quite  common to you, quite normal to you. So we have MetaOS layer, OS standing for OpenHarmony  OS. We have a layer there sitting where all our stuff is bundled together basically and  having layer means it is quite easy to bring in other layers in the OpenBettered.io so  you can bring in your BSP layer for your specific hardware. You can bring a software layer where  you have your own applications and so on, your own middleware or whatever. So that is  easy to bring in together and just build a full image out of that.  So let's look at an example setup here. I mean, creating a directory is clear. Then  we use Repo to make sure that we have all the needed repositories cloned and synced  in one go. So you have a manifest you would edit from and then you sync. And after that  you would basically have a normal OpenBettered workflow. You would do some variable initialization  and then you would add some bit-baked layers. As an example we are using MetaOE and Metapycin  here and after that you can go ahead and bit-bake whatever image or package you want to do.  Right now we are using the DiskHero Pocky that might change and the machine here is the QM  over the other. It will be a real hardware for it.  Talking about hardware, what kind of hardware we are supporting right now? So for the first  two boards we set it on something that is easy to purchase. So we decided to go with  two boards from the 96 boards initiative from Linauro. As I said, they are easy to purchase  and the hardware bring up is also quite easy because there has been done a lot of work already  in Zephyr as well as on Linux to make that happen.  The boards we are having are Avenger 69 and the Nitrogen board. The Avenger being a combination  of Cortex A7 and 1M4 core and the Nitrogen being a single Cortex M4 core only. So obviously  that means you would go and aim for running Zephyr on the Nitrogen and running Linux on  the Avenger. Maybe even in configuration where we run Linux on the A7 core and Zephyr on  the M4 core. But that is something we have to figure out how to do that best and for  what use cases that does make sense. Beyond these two boards we are already going to support  there will be more coming from outside as well but it is also something the community can  really jump in and make sure that show us what you are interested in supporting. As I said,  that should be as easy as making sure that the right layers are enabled for your OE build  and going from there. Also there will be more boards coming that are interesting for Huawei  as well as some partner companies we are working on but this is something that will just grow  over time and depending on the demand and interest. Based on the fact that we are using Linux,  Zephyr and OpenEmbedded Yocto as a build system it should really be easy to bring up new hardware  into the project. Okay, so one of the other key interesting aspects for OpenHarmony that is quite  different from other platforms that are launching is that we are really aiming for a multiple  current approach. As I mentioned before the idea is to have Linux running on the powerful system  let's say Cortex-A7 and Zephyr on the low end system let's say Cortex-M4. Obviously that is not  bound to these processors it's more like a class of devices we are aiming for here.  And again a combination of these in an heterogeneous setup where you have like a remote  processor or devices with an A7 and M4 together and then have a communication channel like  remote proper, remote messaging or something. That's also interesting or something we are aiming for.  This Yocto and OE the overall build will be the same for both of them so there will be no  differences in building your whole image or something you want to bring onto the device  and it's independent from the kernel basically. So I thought you build it for the FYE or for Linux  that doesn't matter it will all fall out of the same bit or something. There might be needs for  having some support libraries to augment the kernel APIs we have on the different kernels.  That is obviously something we might need to do. How we do that in detail that's not completely  defined or confirmed yet. We don't want to have an overall abstraction layer to avoid  complexity and latency and other things. So we have to see on a case by case basis how we're  going to do that. On the outer side we are starting with the FYE and that's what we are  going for right now but we can imagine that later on there might be interest and need for other  choices like LITRA or FYE or free ARTOS. But that really depends on the demand and the interest  and if people are going to work on that or not. Here's a screenshot on our public GitLab instance  we have. So as you can see there's already a lot of repositories there and all of the work we are  doing is already in the public. There's nothing hidden behind a firewall or something. All the  day by day work we are doing is happening there and you can look at it and join and make comments  and make make match requests and other things. So that's the open spirit we want to want to go with  here. And that brings me to the point that the whole way we are running the project is more like  an open source project and not like a company product right. So that's what we are the ideas  behind all of that. We already have distributed development because we are all sitting in different  offices and a lot of us working from home due to COVID. We have all the DevOps already in place for  that. We have our public communication channels like Metamos for example. The whole team is sitting  there and discussing technical aspects and plans we are going to do and how we are going to do it  in the open public. So you can just join and see what's going on there. We have the public GitLab  instances. It brings it all together. And for the product planning and management side we have  open project. That is still in progress to get that out into the open but they are making good  progress there. And on the CI and CD side we also have pipelines already set up from going from  simple style checks and the aim is going as deep as doing on hardware testing for match requests  and things like that. So it's quite common to what you would expect from an open source project.  Maybe not so common what you see in the public at least on a company side but we want really to  drive it that way. And said that we really welcome contributions already at this early stage. I mean  there's nothing you can now put on your hardware and run and sell a product or anything but you  can really be influential from the start making sure that things are working in a way you think  that makes sense or does contribute and make it use it for your own product in the end.  Yeah you can send in metric requests. You can discuss issues on GitLab. You can just join MetaMOS  and look around, talk to people, see what's going on, what are our plans there.  Talking about plans. Here's what we have as a roadmap. It's not so much future looking because  that's some roadmap we did last year to actually envision how we want to get ob-memory and OSTC  started. As you can see we only got founded in April 2020. So that means there's a lot of things  just in flux still growing basically. Our main focus right now is to get all the engineering  parts in place. So get our DevOps in place, get all the code preparations ready, make sure that  license compliance is top-notch and start accepting code contributions and then at some point really  getting out a release as a baseline. Not a release as like a final version you can just put on  your devices and sell as a product and everything is happy. More like really a release as a baseline  where we can work together and then really bring this thing forward.  So that would be it from my side. Thanks a lot for listening in and thanks a lot also to all the  people from FOSTA making that possible and I know that's quite a huge task for you to get it all in  an individual environment and not having your user way of bringing everybody to Brussels. So I'm really  happy that you did that and happy that you had a FOSTA this year as well. So you can  again find us at theshedotc.eu.org. There's a GitHub instance as well. They're launching the  website soon and I think with that I'm ready for questions.
open_harmony_os_0_179.png open_harmony_os_180_227.png open_harmony_os_228_443.png open_harmony_os_444_779.png open_harmony_os_780_1715.png open_harmony_os_1716_1811.png open_harmony_os_1812_2951.png open_harmony_os_2952_4883.png open_harmony_os_4884_5891.png open_harmony_os_5892_8039.png open_harmony_os_8040_8087.png open_harmony_os_8088_10271.png open_harmony_os_10272_11759.png open_harmony_os_11760_14795.png open_harmony_os_14796_17267.png open_harmony_os_17268_17963.png open_harmony_os_17964_18023.png open_harmony_os_18024_18887.png open_harmony_os_18888_20111.png open_harmony_os_20112_23303.png open_harmony_os_23304_24083.png open_harmony_os_24084_27059.png open_harmony_os_27060_27479.png open_harmony_os_27480_27743.png open_harmony_os_27744_28631.png open_harmony_os_28632_28715.png open_harmony_os_28716_29747.png open_harmony_os_29748_30151.png