The Component Framework is one of the key foundations for Fuchsia's usermode runtime environment. The original incarnation of components dates back to the inception of the Fuchsia OS and the initial commits in 2016. The framework has steadily evolved since then.
Presently there are two revisions of the Component Framework that exist on Fuchsia, which are referred to as Components v1 and Components v2.
Components v1 is largely comprised of:
appmgr
, a program that manages the runtime environment for v1 components. appmgr
implements the root of the v1 components tree, as well as some foundational services such as the Components v1 ELF runner and Loader service.sysmgr
, a component that manages the so-called "sys"
realm. sysmgr
is launched by appmgr
..cmx
file format for v1 component manifests.fuchsia.sys.*
FIDL library.Components v1 development reached its peak in 2018. In 2019, Fuchsia team began developing Component Framework v2.
Components v2 is largely comprised of:
appmgr
. appmgr
has become a v2 component itself, which serves as the parent of all v1 components still present in the system..cml
file format for v2 component manifests.fuchsia.sys2.*
FIDL library.In addition, both Components v1 and v2 use cmc
(component manifest compiler), a build-time host tool that processes all formats of component manifest files.
The nature of migrations is that they may take a long time and happen in incremental steps. The final step for migrating a component from v1 to v2 typically involves replacing a .cmx
file with a .cml
file.
Please see the self-service migration guide.
Use this terminology when talking about the state of migrating a component from v1 to v2.
A component and its tests can be migrated separately. For this reason, describe the state of migration for the component and its tests explicitly.
“root_presenter is partially migrated but its tests are not migrated.”
“stash and its tests are fully migrated.”
“basemgr is a partially migrated component with partially migrated tests. Specifically, ...”
“setui_service was prototyped to v2 and it exposed some missing dependencies.”
The component | Tests that exercise it | |
---|---|---|
Fully migrated | The component has a .cml file and no .cmx file AND the component runs as v2 in all product builds | All automated tests run the component as a v2 component |
Partially migrated | The component has a .cml file and a .cmx file AND the component runs as v1 in some product configurations but not others, or is guarded by a flag to do so for development purposes | Some automated tests exist in which the component runs as a v2 component, but others run it as v1 |
Prototyped | The component runs as a v1 component in all product configurations AND the component has a .cml file | All automated tests in CI/CQ run the component as v1 AND there are tests with the component as v2, but they don't run in CI/CQ |
Not migrated | The component does not have a .cml file | There are no tests that run the component as v2 |
Last updated: April 2021
A high-level diagram of the system's component topology is shown below:
Component manager is one of the initial processes that are started in the system boot sequence. The system startup sequence then launches a number of low-level system components that deal with various responsibilities, including in no particular order:
Component manager launches appmgr
, itself a v2 component, in order to manage v1 components. All v1 components on the system run under appmgr
. Users may continue developing and maintaining v1 components while v2 migrations take place at their own pace.
Build configurations that use the Session Framework also include the session_manager
component. All v1-backed capabilities the session needs are routed to the session_manager
from appmgr
.
Last updated: April 2021
Components v2 migrations are happening throughout the system. However there is currently additional focus on: