Google is committed to advancing racial equity for Black communities. See how.

Component lifecycle (Components v2)

Component instances progress through four major lifecycle events: create, start, stop, and destroy.

Component instances may retain isolated persistent state on a storage medium while they are not running, which helps them maintain the illusion of continuity across restarts.

Creating a component instance

A component instance may be created in the following ways:

  • Configuring it as the root component of component manager.
  • Statically declaring it as the child of another component.
  • Dynamically creating it at runtime in a collection.

Every component instance has a moniker that uniquely identifies it, determined by its path from the root.

Once created, a component instance can then be bound to, started, or destroyed.

Binding to a component instance

A component instance A binds to another component instance B when A connects to some capability that is provided by B. When this happens, component instance B is started, unless it was already started. In most cases, this is the most common reason for a component instance to start.

Concretely, there are two ways that A can bind to B:

  • A connects to a capability in its namespace which is exposed or offered by B. This is the most common way.
  • A binds to one of its children using the Realm.BindChild protocol.

The word "bind" is meant to imply that a component is run on account of being "bound" by its clients. In theory, when no more clients are bound to a component, the framework could stop running it, but this behavior isn't currently implemented.

Starting a component instance

Starting a component instance loads and runs the component's program and provides it access to the capabilities that it requires.

Every component runs for a reason. The component framework only starts a component instance when it has work to do, such as when another component requests to use its instance's capabilities.

Once started, a component instance continues to run until it is stopped.

Stopping a component instance

Stopping a component instance terminates the component's program but preserves its persistent state so that it can continue where it left off when subsequently restarted.

The component framework may stop a component instance for the following reasons:

  • When the component is about to be destroyed.
  • When the system is shutting down.

A component can implement a lifecycle handler (example) to be notified of its impending termination and other events on a best effort basis. Note that a component can be terminated involuntarily and without notice in circumstances such as resource exhaustion, crashes, or power failure.

Components can stop themselves by exiting. The means by which a component exits depend on the runner that runs the component.

Once stopped, a component instance can then be restarted or destroyed.

Destroying a component instance

Destroying a component instance permanently deletes all of its associated state and releases the system resources it consumed.

Once destroyed, a component instance ceases to exist and cannot be restarted. New instances of the same component can still be created but they will each have their own identity and state distinct from all prior instances.

Legacy features

Eager binding

Component manifests let you mark a child as eager, which causes the component framework to implicitly bind to that child when any component binds to the parent. In other words, this causes the child to be immediately started whenever the parent is started. This is a legacy feature, and additional uses should be limited to tests. The future of this feature is being tracked at fxb/61721.

eager primarily has two uses: to start the first component, and as a convenience in tests to run components without having to explicitly bind to them.

If the eager child fails to start for any reason (such as a missing component), component manager exhibits the following behavior:

  • If the parent is not the root component, the parent will start but the component that bound to it will observe a dropped connection (just like any other failed binding).
  • If the parent is the root component, component manager will crash.