Components interact with one another through capabilities . A capability combines access to a resource and a set of rights, providing a access control and a means for interacting with the resource. Fuchsia capabilities typically access underlying kernel objects through handles provided in the component's namespace .
A component can interact with the system and other components only through the discoverable capabilities from its namespace and the few numbered handles it receives.
Components declare new capabilities that they offer to the system and capabilities provided by other components (or the framework) that they require in their component manifest. Component framework uses these declarations to populate the namespace.
For capabilities to be available at runtime, there must also be a valid capability route from the consuming component to a provider. Since capabilities are most often routed through parent components to their children, parent components play an important role in defining the sandboxes for their child components.
Some capability types are routed to environments rather than individual component instances. Environments configure the behavior of the framework for the realms where they are assigned. Capabilities routed to environments are accessed and used by the framework. Component instances do not have runtime access to the capabilities in their environment.
Routing terminology divides into the following categories:
- Declarations of how capabilities are routed between the component, its parent, and its children:
- Declarations of capabilities consumed or provided by the component:
use: For executable components, declares capabilities that this component requires in its namespace at runtime. Capabilities are routed from the
parentunless otherwise specified, and each capability must have a valid route from its source.
capabilities: Declares capabilities that this component provides. Capabilities that are offered or exposed from
selfmust appear here. These capabilities often map to a node in the outgoing directory .
The following capabilities can be routed:
||A filesystem node that is used to open a channel backed by a FIDL protocol.||components|
||A filesystem directory that is used to open a channel to one of several service instances.||components|
||A filesystem directory.||components|
||A writable filesystem directory that is isolated to the component using it.||components|
||A capability that, when registered in an environment, causes a component with a particular URL scheme to be resolved with that resolver.||environments|
||A capability that, when registered in an environment, allows the framework to use that runner when starting components.||environments|
Consider the following example that describes capability routing through the component instance tree:
In this example, the
echo component instance provides an
protocol in its outgoing directory. This protocol is routed to the
component instance, which uses it. It is necessary for each component instance
in the routing path to propagate
fuchsia.Echo to the next component instance.
The routing sequence is:
fuchsia.Echoprotocol in its outgoing directory. Also, it exposes
selfso the protocol is visible to its parent,
fuchsia.Echofrom its child
echoto its parent,
fuchsia.Echofrom its child
servicesto its other child
parent(i.e., its parent) to its child
echo_toolruns, it will find
fuchsia.Echoin its namespace.
For a more detailed example of capability routing, see
For more information on what happens when connecting to a capability, see Life of a protocol open.