Goal & motivation
The Component Framework is one of the key foundations of 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.
What's been migrated?
Last updated: September 2021
The migration is underway, but broadly speaking:
- Over a third of production components have been migrated.
- All usermode tests have been migrated to run as modern components.
Modern and legacy components
Presently there are two revisions of the component framework, the legacy architecture (also called appmgr after its main program, or sometimes Components v1 ) and the modern architecture (also called Component Framework, or sometimes Components v2 ).
The legacy framework is largely comprised of:
appmgr, a program that manages the runtime environment for legacy components.
appmgris the root of the legacy components tree, and provides some foundational services such as the legacy component ELF runner and Loader service.
, a component that manages the
sysmgris launched by
.cmxfile format for legacy component manifests.
- The TestWithEnvironment testing library.
The legacy framework's development reached its peak in 2018. In 2019, Fuchsia team began developing the modern Component Framework. Component Framework is largely comprised of:
- Component manager, a program that manages the runtime environment for modern components.
.cmlfile format for modern component manifests.
- The RealmBuilder testing library.
The following component framework software supports both modern and legacy components:
- Libraries that wrap Component Framework APIs, such as the SDK
C++ component library, the internal
fuchsia-componentRust component library
cmc, the component manifest compiler.
A high-level diagram of the system's component topology is shown below:
- Modern components are shown in blue boxes.
- Legacy components are shown in red boxes.
- The dashed arrow between the session and Modular represents bidirectional communication between both systems.
In addition, all unit tests with generated manifests are modern components.
Component manager launches
appmgr, itself a modern component, which manages
appmgr is the ancestor of all legacy components running on
the system. Users may continue developing and maintaining existing legacy
components while migrations take place at their own pace. However, if you write
a new component, you are strongly advised to make it a modern component unless
there is some reason it must be legacy. All legacy components in-tree must
appear in the GN allowlist at //build/components/cmx.
Build configurations that use the Session Framework also
component which runs under
session_manager. All capabilities hosted by legacy components that are
required by the session are routed from
Use this terminology when talking about the state of migrating a legacy component and its tests to the modern framework.
|The component||Tests that exercise it|
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.
setui_service's modern component was prototyped and it exposed some missing
How to help
Picking a task
Component migrations are happening throughout the system. Any component that
still has at least one
.cmx file is a migration candidate.
sys realm components you may use the
self-service migration guide. Multiple component
owners have recently seen success in using this guide, including but not limited
- Software Delivery
Doing a task
Component migrations may take multiple incremental steps to complete due to dependencies between other components that have not been migrated yet. For example, a component and its tests can be migrated separately. For more details on the incremental stages, see terminology.
The final step for migrating a component typically involves replacing all
files with equivalent
.cml files. For detailed instructions on migrating a
component and its tests, see the
self-service migration guide.
Completing a task
Send code reviews to owners of the directories with the component definitions that you're changing, and to one of the people listed below:
- 504575: [http-client] Migrate to Components v2
- 504523: [soundplayer] transition to CFv2
- 489757: [device_settings] Migrate to CFv2
Reach out for questions or for status updates: