Glossary

The purpose of this document is to provide short definitions for a collection of technical terms used in Fuchsia.

To add a glossary definition, see Adding glossary entries.

Terms

Glossary area




  • The binary-level interface to the system.


    The Application Binary Interface(ABI) for a system is the binary-level interface to the system. Typically you don't write software that uses the system ABI directly. Instead, you write software against the system API. When the software is compiled, the binary artifact created by the compiler interfaces with the system through the ABI. Changes to the system ABI may require you to recompile your source code to account for the changes in the ABI.


  • Fuchsia uses a bootloader with two partitions A and B, and a recovery slot.


    Fuchsia uses a bootloader with two partitions A and B, and a recovery slot. This logic is not required to boot Zircon or run a basic Fuchsia system, but it is required to take full advantage of Fuchsia's over-the-air (OTA) update features.

    The term slot is used to refer to a set of partitions that update together. If an update fails, the partitions fall back together. This works because there are two copies of each partition on disk. By convention, the slots used for normal updates are denoted A and B, and the corresponding partitions are labeled with a suffix of "_a" or "_b". The slot used for recovery is denoted R which is chosen when neither A nor B is bootable.



  • Keys that have a distinct special action.


    Keys corresponding to specific actions, such as "display brightness increment", "display brightness decrement" etc, which are specifically named in the USB HID usage tables.


  • An API element is an individual piece that makes up an API.


    An API element is an individual piece that makes up an API. Examples include types, members, and functions. For FIDL, elements include protocols, methods, tables, and members.


  • The JSON file that the product owner writes in order to specify (1) lists of product-specific packages, components, drivers, and configuration and (2) platform features and configuration. This is the configuration that encapsulates both a Product Config and a Platform Config.



  • An Assembly Input Bundle is a self-contained directory of artifacts with a manifest file in the root describing what is included. This bundle is used internally by the Software Assembly tool. Fuchsia is composed of many packages, components, drivers, and configuration data. These elements are grouped together inside Assembly Input Bundles (AIBs) for inclusion together into the assembled product. All AIBs other than the Legacy AIBs are "platform AIBs".



  • Language for definition protocols that communicate between drivers.


    Banjo is a language for defining protocols that are used to communicate between drivers. It is different from FIDL in that it specifies an ABI for drivers to use to call into each other, rather than an IPC protocol.


  • The language used to write bind libraries and bind rules in a static file.



  • A bind library is a mechanism used to define node properties. The node properties can be assigned to nodes by their parent drivers or used in the bind rules. Bind libraries are defined through the bind language.



  • Bind rules are a defined set of conditions provided by a driver that must be satisfied in order for the driver to match to a node. The conditions are evaluated against node properties. Formerly known as a bind program.



  • A board is a complete computer hardware platform with a CPU, memory, peripherals, and so on.


    A board is a complete computer hardware platform with a CPU, memory, peripherals, and so on. It defines the architecture that the build produces for, and key features of the device upon which the build is intended to run. This configuration affects what drivers are included, and may also influence device-specific kernel parameters.



  • A board driver is a specialized driver that contains the platform-specific information needed by the platform bus and controls what other drivers will be loaded by the platform bus.


    A board driver is a specialized driver that contains the platform-specific information needed by the platform bus and controls what other drivers will be loaded by the platform bus. The board driver is the first driver loaded and parented by the platform bus.



  • The boot filesystem that contains the files needed early in the boot process.


    The bootfs RAM disk contains the files needed early in the boot process when no other filesystems are available. It is part of the zircon boot image, and is decompressed and served by bootsvc. After the early boot process is complete, the bootfs is mounted at `/boot`.


  • Provides a filesystem service for the bootfs and a loader service.


    The second process started in Fuchsia. It provides a filesystem service for the bootfs and a loader service that loads programs from the same bootfs. After starting these services, it loads the third program, which defaults to `component_manager`.


  • A driver that is available in the Fuchsia image and not critical for bootstrapping the system. These drivers are loaded from the system's storage, so they need to be loaded after the boot drivers have enabled storage (for example, USB drivers, networking drivers).


    A driver that is available in the Fuchsia image and not critical for bootstrapping the system. These drivers are loaded from the system's storage, so they need to be loaded after the boot drivers have enabled storage (for example, USB drivers, networking drivers). Base drivers reside in the base packages.


  • A driver that exists in the Zircon Boot Image (ZBI) and is needed for bootstrapping the system (for example, storage drivers).


    A driver that exists in the Zircon Boot Image (ZBI) and is needed for bootstrapping the system (for example, storage drivers). The Zircon Boot Image (ZBI) has limited space for such drivers, a constraint that does not generally apply to base drivers.


  • The process of getting Fuchsia to run on a new board.


    Bringup is the catchall term for all of the engineering work related to getting Fuchsia to run on a new board. The term "bringup" should not be used for situations where Fuchsia support for the board already exists. For example, flashing a Fuchsia image onto a VIM3 is not bringup. The original engineering work of implementing the drivers and so on so that Fuchsia can run on the VIM3 is bringup.



  • A driver for a device that has multiple children.


    A driver for a device that has multiple children. For example, hardware interfaces like PCI specify a topology in which a single controller is used to interface with multiple devices connected to it. In that situation, the driver for the controller would be a bus driver. A bus driver does not necessarily correspond to a physical bus.


  • A private directory, that may be cleared by the system at any time, within which a component instance may cache data local to the device.


    A private directory, that may be cleared by the system at any time, within which a component instance may cache data local to the device. Similar to a data directory, except that the contents of a cache directory may be cleared by the system at any time, such as when the device is under storage pressure. Canonically mapped to /cache in the component instance’s namespace.



  • A value that combines an object reference and a set of rights.


    A capability is a value that combines an object reference and a set of rights. When a program has a capability it is conferred the privilege to perform certain actions using that capability. A handle is a common example for a capability.



  • A way for one component instance to give capabilities to another component instance.


    A way for one component instance to give capabilities to another instance over the component instance tree. Component manifests define how routing takes place, with syntax for service capabilities, directory capabilities, and storage capabilities.



  • An IPC primitive provided by Zircon.


    A channel is an IPC primitive provided by Zircon. It is a bidirectional, datagram-like transport that can transfer small messages including handles. FIDL protocols typically use channels as their underlying transport.



  • A key that sends characters to the computer.


    A key that sends characters to the computer. This definition does not specifically account for the effect of key composition and dead keys, which are present on certain keyboard layouts, but is operational enough for effective use.


  • A child component instance is a component instance that is owned by another instance, the parent.



  • A node that receives resources from parent driver(s).



  • A cloud service for storing and distributing packages. Packages can be arbitrary collections of files, but most often contain prebuilt binaries.


    The Fuchsia project uses CIPD to download, publish, and distribute compiled software such as the Fuchsia SDK. Jiri has built-in support for versioning and downloading CIPD packages.



  • A driver is colocated with another driver when they share the same driver host.



  • A Driver Framework v2 (DFv2) driver that wraps a Driver Framework v1 (DFv1) driver so that the DFv1 driver can run in a DFv2 environment.


  • Components are the common abstraction that defines how all software is described, sandboxed, and executed on a Fuchsia system.


    Components are the common abstraction that defines how all software (regardless of source, programming language, or runtime) is described, sandboxed, and executed on a Fuchsia system. Components may specify a binary executable, and may be composed of multiple child components.



  • A node in the component instance tree whose children are dynamically instantiated rather than statically defined in a component manifest.


    A node in the component instance tree whose children are dynamically instantiated rather than statically defined in a component manifest.



  • The process of tailoring a component instance to the context it's running in.


    The process of tailoring a component instance to the context it's running in. This includes defining and delivering the data that a component can use to understand and adapt to the context in which it was launched.



  • Data supplied to a component instance that it can use to understand and adapt to the context in which it was launched.


    Data supplied to a component instance that it can use to understand and adapt to the context in which it was launched.



  • A FIDL table that includes information about a component.


    A component declaration is a fidl table (fuchsia.sys2.ComponentDecl) that includes information about a component’s runtime configuration, capabilities it exposes, offers, and uses.



  • An application framework for declaring and managing components, consisting of build tools, APIs, conventions, and system services.



  • A specific runtime instantiation of a particular component at a specific location in the component instance tree at runtime.



  • A tree structure that represents the runtime state of parent-child relationships component instances.


    A tree structure that represents the runtime state of parent-child relationships between component instances. If instance A launches instance B then in the tree A will be the parent of B. The component instance tree is used to route capabilities such that parents can offer capabilities to their children to use, and children can expose capabilities for their parents to expose to their parents or offer to other children.



  • A system service that lets component instances manage their children and capability routing between them, thus implementing the component instancetree.


    A system service that lets component instances manage their children and capability routing between them, thus implementing the component instancetree. Component manager is the system service that implements the component runtime.



  • A binary file ending in .cm that encodes a component declaration, often distributed as part of a package. The term is sometimes used interchangeably with component manifest source.


    A binary file ending in .cm that encodes a component declaration, often distributed as part of a package. The cmc tool generates a component manifest from a component manifest source file.



  • A JSON5 file with a .cml extension that describes a component's declaration, and is compiled by [cmc] to produce a [component manifest].


    A JSON5 file with a .cml extension that describes a component's declaration, and is compiled by [cmc] to produce a [component manifest].

    The file contains information about a [component]'s executable and runtime configuration (if any), any child [component]s, as well as [capability routing] between itself, its parent, and its children.



  • Additional component manifest metadata.


    Additional metadata that is carried in a component manifest. This is an extension point to the framework.



  • A unique, stable identifer for a component instance.


    A unique, stable identifer for a component instance. The instance id is the canonical identifier for a component instance. The component runtime uses this to key a component's persistent resources, if it has any. While a component instance's moniker may change, its instance ID remains the same.

    Instance IDs are assigned to component instances using a component ID index.



  • Collective term for the component instance tree and the capability routes over that tree.


    The component topology describes the set of relationships between component instances in a Fuchsia system. It consists of the parent-child relationships of the component instance tree as well as the capability routes over that tree.



  • URL that identifies a component's declaration and package.


    URL that identifies a component's declaration and package, most often used when instantiating a component. Example: fuchsia-pkg://fuchsia.com/stash#meta/stash_secure.cm.



  • A driver that only binds to a composite node. A driver can be defined as a composite via its bind rules.



  • A node with multiple parents. The driver that is bound to the composite node can access the combined resources provided by the parent drivers. Formerly known as a composite device.



  • A composite node specification is a mechanism for creating a composite node. It describe the nodes that can parent the composite node and the driver that can bind to the composite node.



  • A capability that provides a data value that a component can use for configuration. A component using a configuration capability will be able to read the value in it's structured configuration.



  • A hardware driver that supports multiple concurrent operations.


    A hardware driver that supports multiple concurrent operations. This may be, for example, through a hardware command queue or multiple device channels. From the perspective of the core driver, the device has multiple pending operations, each of which completes or fails independently. If the driven device can internally parallelize an operation, but can only have one operation outstanding at a time, it may be better implemented with a sequential device driver.


  • Graphical content containing a bitmap that is attached to a Transform in Flatland. Image, Viewport and FilledRect are types of Contents.


    Graphical content containing a bitmap that is attached to a Transform in Flatland. Image, Viewport and FilledRect are types of Contents. Each Transform can have, at most, one attached Content. A Content inherits all of the attributes from its attached Transform.


  • A driver that implements the application-facing RPC interface for a class of drivers.


    A driver that implements the application-facing RPC interface for a class of drivers (e.g. block drivers, ethernet drivers). It is hardware-agnostic. It communicates with a hardware driver through banjo to service its requests.


  • The artifact containing Fuchsia APIs, Fuchsia tools, binaries, and metadata. Used to access the Fuchsia tools, or the Fuchsia APIs.


  • A private directory within which a component instance may store data local to the device.


    A private directory within which a component instance may store data local to the device, canonically mapped to /data in the component instance’s namespace.


  • The ratio between the display's physical pixels and the display's device independent pixels.


    The ratio between the display's physical pixels and the display's device independent pixels. Each logical or device independent pixel is displayed on screen by one or more physical pixels, as determined by this scale.



  • A capability that bundles multiple capabilities together.


    A capability that bundles multiple capabilities together. A dictionary is a key-value data collection, where the key is a capability name string and the value is a capability. The value itself may be another dictionary, which can be used to achieve directory-like nesting.



  • A capability that permits access to a filesystem directory by adding it to the namespace of the component instance that uses it.


    A capability that permits access to a filesystem directory by adding it to the namespace of the component instance that uses it. If multiple component instances are offered the same directory capability then they will have access to the same underlying filesystem directory.



  • A dispatcher is an interface for scheduling asynchronous operations.


    A dispatcher, when assigned to a driver, coordinates and performs asynchronous operations for the driver. A dispatcher mainly handles two tasks: it schedules asynchronous work to run on threads in a driver host and it actually runs the work on those threads on behalf of a driver.



  • The corresponding class or data type in a target language (such as C++) used to represent a FIDL type. A domain object usually models an entity in a problem domain space.


  • A driver is a dynamic shared library that enables and controls one or more nodes.


    A driver is a dynamic shared library that enables and controls one or more nodes. Drivers are loaded into driver hosts by the driver manager.



  • The process where a driver is matched to a node, started, and then handed the node’s resources.


    The process where a driver is matched to a node, started, and then handed the node’s resources. A driver bound to a node can access the node's resources and create child nodes.



  • A process containing one or more device drivers.


    A process containing one or more device drivers. They are created by the Driver Manager, as needed, to provide isolation between drivers for stability and security.


  • The driver index is a Fuchsia component that is responsible for keeping track of all available drivers.


  • The Driver Manager (formerly devmgr or devcoordinator) is responsible for enumerating, loading, and managing the life cycle of device drivers.


  • The process where the Driver Framework finds a driver and assigns it to a node. A driver that’s assigned to the node is considered as a matched driver.



  • The driver runtime is an in-process runtime modeled after the Zircon kernel that enables colocated drivers to communicate with each other locally. It is much more efficient than communicating using Zircon channels.


    The driver runtime is an in-process runtime modeled after the Zircon kernel that enables colocated drivers to communicate with each other locally. It is much more efficient than communicating using Zircon channels. It also provides a set of primitives mirroring Zircon kernel objects and a threading model for drivers which allows for the sharing of Zircon threads.



  • The driver transport is a transport system in FIDL that's implemented on top of channels.


    Related links
  • A container for a set of components.


    A container for a set of components, which provides a way to manage their lifecycle and provision services for them. All components in an environment receive access to (a subset of) the environment's services.


  • A driver that is not included in the board configuration. These drivers are loaded from the universe package set<> at runtime.


  • Graphics library for compositing user interface content.


    Graphics library for compositing user interface content. Its design is inspired by modern real-time and physically based rendering techniques though Fuchsia anticipates most of the content it renders to have non-realistic or stylized qualities suitable for user interfaces.


  • The artifact containing experimental Fuchsia APIs.


  • A keyword for a component instance to indicate that it is making a capability available to its parent to route.


    A component instance may use the expose manifest keyword to indicate that it is making a capability available to its parent to route. Parents may offer a capability exposed by any of their children to their other children or to their parent, but they cannot use it themselves in order to avoid dependency cycles.



  • A file system directory that contains the set of exposed capabilities for a component.


    A file system directory provided by component manager that contains the set of capabilities exposed by a component to its parent.



  • The Fuchsia Archive Format is a container for files to be used by Zircon and Fuchsia.



  • FBL is the Fuchsia Base Library, which is shared between kernel and userspace.



  • The Fuchsia driver framework is the documentation, APIs, and ABIs necessary to build Zircon device drivers.


    The Fuchsia driver framework is the documentation, APIs, and ABIs necessary to build Zircon device drivers. Device drivers are implemented as ELF shared libraries loaded by Zircon's driver manager.



  • The core Fuchsia method for talking about files and other I/O primitives are FIDL protocols over Zircon channels.


    It provides the implementation of posix-style open(), close(), read(), write(), select(), poll(), etc, against the RemoteIO RPC protocol. These APIs are return- not-supported stubs in libc, and linking against libfdio overrides these stubs with functional implementations. Sometimes referred to as "POSIX Lite".



  • Fuchsia's primary tool for working with a Fuchsia system and Fuchsia tools. Example use cases include stream logs from a device and start an emulator.



  • Fuchsia Host Objects is a set of APIs connecting `ffx` with subtools.


    Fuchsia Host Objects is a set of APIs connecting `ffx` with subtools. It acts as a compatibility layer between the program and a device or virtual machine running Fuchsia, allowing the tool to ignore all the setup necessary to connect to the device, establish FIDL channels to services on the device, and log useful information about the interactions.



  • A solid color rectangle can be attached to a Transform in Flatland.


    A solid color rectangle can be attached to a Transform in Flatland. FilledRect is type of a Content.


  • The Fuchsia Interface Definition Language (FIDL) is a language for defining protocols.


    The Fuchsia Interface Definition Language (FIDL) is a language for defining protocols that are typically used over channels. FIDL is programming language agnostic and has bindings for many popular languages, including C, C++, Dart, Go, and Rust. This approach lets system components written in a variety of languages interact seamlessly.



  • A FIDL protocol that allows sending 2D graphical content to Scenic.


    The 2D composition API for Fuchsia graphics clients. Flatland clients can construct their scene graph and send to Scenic to compose into the shared scene graph that is submitted to the display.


  • A fragment is a node that composes a Driver Framework v1 composite node. Each fragment binds to a fragment driver which provides protocols and metadata to the composite node. Only used in Driver Framework v1.



  • Deprecated, replaced by RFC. An FTP is the way developers can suggest changes to FIDL.


    An FTP is the way developers can suggest changes to FIDL. After being written, an FTP goes through a formal review process where it is either accepted or rejected.



  • The Fuchsia API Surface is the combination of the Fuchsia system interface and the client libraries included in the Fuchsia IDK.


  • The Fuchsia emulator (FEMU) is the default emulator for Fuchsia.


    The Fuchsia emulator (FEMU) is the default emulator for Fuchsia. It allows you to test Fuchsia components and applications without needing a Fuchsia device. FEMU is based on the Android Emulator (AEMU), which is a fork of QEMU.



  • A scheme that refers to a repository, a package, or a package resource.


    A scheme that refers to a repository, a package, or a package resource. The syntax is fuchsia-pkg://[/][#]]`. For example, for the component test_manager.cm published under the package test_manager's meta directory, from the fuchsia.com repository, its URL is fuchsia-pkg://fuchsia.com/test_manager#meta/test_manager.cm.



  • An extension for Visual Studio Code (VsCode) supporting common developer workflows for Fuchsia, like environment set up, editing, debugging, and testing.



  • The Fuchsia IDK contains a small set of libraries and tools required to start building and running programs that target Fuchsia. The contents of the IDK represent the most basic contract that the Fuchsia platform developers offer to prospective developers.


  • Set of deliverables from the Fuchsia Authors that make it easier to develop components against Fuchsia. Some artifacts include: Fuchsia SDK, Fuchsia tools, components, and editor extensions.


  • The Fuchsia SDK is the set of APIs, tools, build system integrations, and language integration artifacts produced by Fuchsia that enable the production of software and products for and with Fuchsia.


  • An integration of the Bazel build system with the Fuchsia SDK. Enables developers to compile, run, and test their software with Bazel. Supports C++ through a bundled Clang toolchain.


  • The binary interface that the Fuchsia operating system presents to software it runs.


    The binary interface that the Fuchsia operating system presents to software it runs. For example, the entry points into the vDSO as well as all the FIDL protocols are part of the Fuchsia System Interface.



  • Programs designed to help work with Fuchsia. For example, tools to compile FIDL IDL (interactive data language), or tools to get logs from a device.


  • Fuchsia Volume Manager (FVM) is a partition manager providing dynamically allocated groups of blocks known as slices into a virtual block address space.


    Fuchsia Volume Manager (FVM) is a partition manager providing dynamically allocated groups of blocks known as slices into a virtual block address space. The FVM partitions provide a block interface enabling filesystems to interact with it in a manner largely consistent with a regular block device.



  • The common name for the keys F1, F2, F3, ...


    The common name for the keys F1, F2, F3, ...


  • GN is a meta-build system that generates build files.


    GN is a meta-build system that generates build files so that Fuchsia can be built with Ninja. GN is fast and comes with solid tools to manage and explore dependencies. GN files, named `BUILD.gn`, are located all over the repository.



  • A FIDL protocol that organizes and presents graphical views.


    A FIDL protocol that organizes and presents graphical views. The presented views can be annotated with element annotations to communicate presentation properties to the GraphicalPresenter. This protocol is used, for example, when a window manager accompanying a session component written in Rust wants to delegate presentation logic to a child component written in Flutter, or when a window manager delegates the presentation of element views launched by the session component to a child component that implements GraphicalPresenter.



  • A Handle is how a userspace process refers to a kernel object.


    A Handle is how a userspace process refers to a kernel object. They can be passed to other processes over channels.



  • A driver that controls a device.


    A driver that controls a device. It receives requests from its core driver and translates them into hardware-specific operations. Hardware drivers strive to be as thin as possible. They do not support RPC interfaces, ideally have no local worker threads (though that is not a strict requirement), and some will have interrupt handling threads. They may be further classified into sequential device drivers and concurrent device drivers.


  • A bitmap containing pixels that can be attached to a Transform in Flatland.


    A bitmap containing pixels that can be attached to a Transform in Flatland. Image is type of a Content.


  • This configuration file that tells the Software Assembly tooling which images to generate and how to generate them.


    The Images Config is an internal contract between the two subsystems of Software Assembly -- Product Assembly and Image Assembly. The structure and contents of this file is subject to rapid iteration, as it is consumed only by the Software Assembly team.



  • Relating to or describing an action to be performed inside a Fuchsia checkout.


    For instance, checking out the Fuchsia source code is a prerequisite for performing any in-tree development. The `fx build` command is used to operate the in-tree build system.



  • Software for sophisticated text input.


    From MSDN: "A software component that enables a user to input text in a language that can not be represented easily on a standard keyboard."


    • Input Method Editor API

  • API to implement IMEs


    A FIDL API offered by the keyboard subsystem for integrating with built-in or custom made input method editors.


    • Input Method Editor

  • Fuchsia system component for handling input-related events.


    A library and component for processing of input-related events on Fuchsia in a sequential manner. The input pipeline mediates between driver-level input and "UI Framework" facing services. One of the input pipeline's tasks is to apply a keymap by attaching a key meaning to a key event.


    • key event
    • key meaning
    • keymap
    • RFC-0096

  • A Rust trait in the input pipeline client library.


    Represents a connection to a physical input device (e.g. mouse, keyboard) in an input pipeline. An InputDeviceBinding does the following:

    The input pipeline creates and owns InputDeviceBinding`s as new input peripherals are connected to a device.



  • Describes the ranges of values a particular input device can generate.


    A property of the Rust struct InputReport of type enum InputDeviceDescriptor and a FIDL table. For example, a InputDeviceDescriptor contains the keys available on the keyboard, and a InputDeviceDescriptor::Touch contains the maximum number of touch contacts and the range of x- and y- values each contact can take on.



  • Represents an input event from an input device.


    A property of the Rust struct InputEvent. InputDeviceEvent`s contain more context than the raw InputReport`s they are parsed from. For example, InputDeviceEvent::Keyboard contains all the pressed keys, as well as the key's phase (pressed, released, etc.).


    Related links

  • An event from an input device containing context (a InputDeviceDescriptor and state (e.g. phase and location of a button press). The input pipeline generates InputEvent`s from hardware signals.


    A Rust struct in the input pipeline client library.



  • Represents a client of InputEvent in an input pipeline. When an InputHandler receives an InputEvent, it does at least one of the following:


    A Rust trait in the input pipeline client library.



  • A stateless representation of an event from a physical input device.


    A FIDL struct. Zircon generates InputReport`s from HID Reports.



  • Jiri is a tool for multi-repo development.


    It is used to checkout the Fuchsia codebase. It supports various subcommands, which makes it easy for developers to manage their local checkouts.



  • A kernel object that groups a set of related processes, their child processes, and their jobs (if any).


    Every process in the system belongs to a job and all jobs form a single rooted tree.



  • A kernel object is a kernel data structure that is used to regulate access to system resources such as memory, I/O, processor time and access to other processes.


    Userspace can only reference kernel objects through handles.



  • A switch that can be pressed or released.


    A switch that can be pressed or released. Usually, but not always, it has a keycap with one or more symbols written on it. It is traditionally a mechanical, or electromechanical device, but modern input modes have seen purely software key implementations, as a user-interface element coupled with a touch-screen, or a computer mouse for actuation. ISO/IEC 9995-1:2009 does not explicitly define the term key, but notes that a keyboard has keys that can be actuated. We will use the term physical key to emphasize a key on a physical keyboard where otherwise confusion would arise.


    • keyboard
    • keycap
    • physical key

  • Physical action to cause a key effect.


    Doing something to a key to cause a key effect. For example, pressing a key. Actuation is probably a better term to use in general, since while each press is an actuation, not every key actuation has to be a key press. Some keys may be actuated by a tap, or a throw switch, or a twist etc. It's OK to use "key press" when talking about pressable keys in the narrow sense - such as on a standard PC keyboard. Prefer "key actuation" in formal contexts, or where precision is important.


    • Physical key
    • Key effect

  • A key chord and its key effect, together.


    A pair of a key chord and a key effect. For example pressing "Ctrl+O" causes the "Open File" dialog box to be shown.


    • Key actuation
    • Key chord
    • Key effect

  • A message that reports a state change for a key.


    A message reporting a state change associated with a single key. "Key 'A' has just been pressed" is a representation of a key event. On Fuchsia, a key event can only ever be delivered to a View that is in focus. This feature ensures that potentially sensitive keyboard input is always delivered only to the View that is permitted to receive it.


    • Keyboard
    • Physical key
    • View

  • One or more simultaneous key actuations.


    One or more key actuations that happen at the same time. It may be impossible to actuate a specific key chord without actuating other key chords first. For example, on mechanical keyboards, "Ctrl+Alt+Del" can not be actuated until at least one of "Ctrl", or "Alt" or "Del" is actuated first, as it is physically impossible to press all the three keys at the same time. This is not a universal definition, so expect variations across time periods, operating systems, and schools of thought. For example, KDE uses the term "chord" to mean "key sequence". But this usage seems unusual and not intuitive, as it deviates from the use of "chord" in music, so we don't follow this precedent and recommend against following it.


    • Physical key

  • The final destination for the events generated by the keyboard subsystem.


    A client that is the final destination for the events generated by the keyboard subsystem. Prefer the term consumer to client, since the keyboard subsystem has multiple collaborators, each of which can be a client in the context of a particular 1:1 collaboration.


    • key event
    • keyboard subsystem

  • Effect that results when a key is actuated.


    "Effect that results when a key is actuated, depending on the active level, and possibly by the concurrent operation of a qualifier key or keys." (ISO/IEC 9995-1:2009, section 4) Example: the letter "a" appearing on a screen is a key effect, caused by an actuation of the key with the keycap "a" on the keyboard.


    • key
    • keycap
    • keyboard

  • An API that provides discrete key events.


    E.g. fuchsia.ui.input3. API that gives access to discrete key events, possibly annotated with information about the currently applicable keyboard layout. At this stage, events corresponding to button presses have not yet been interpreted as language. May be used for limited use-cases such as controlling a game, but most clients should prefer the text edit API.


    • Text Edit API

  • An encoding corresponding to the meaning a key event has to the key consumer, with all layout and other mappings that apply.


    An encoding corresponding to the meaning a key event has to the key consumer, with all layout and other mappings that apply.


  • A sequence of key chords.


    A sequence of key chords. Example: in Emacs, pressing C-x followed by C-s saves the current buffer. Since a single key actuation is a key chord (see definition above), every sequence of single key presses such as "hello world" is also a key sequence.


  • A means for input of information by a human being.


    An "[...] intermediate element between a user and an information processing system. The keyboard is specifically intended as a means for input of information by a human being." (ISO/IEC 9995-1:2009, section 5). This link has some examples of computer keyboards.


    • physical keyboard
    • virtual keyboard

  • The set of Fuchsia system services that process keyboard and text related input.


    The set of Fuchsia system services that process keyboard and text related input.


    • Keyboard
    • key event

  • A map that transforms a sequence of physical keys into a key meaning.


    A map that transforms a sequence of physical keys into a key meaning. Also known as keymap, or keyboard layout.


  • A special kind of key binding.


    A key chord that appears in some key binding. All keyboard shortcuts are chords, but only chords that have a key effect associated with them are shortcuts. On Fuchsia, a distinctive feature of shortcuts is that they can be routed to Views that are not in focus. This allows top-level Views such as the graphical shell, or Accessibility, to install system-wide shortcuts and intercept them instead of yielding them over to child views. Contrast to the behavior of key events, which are only ever delivered to focused views.


  • The symbol displayed on top of a key.


    The symbol that is displayed on a key of the physical keyboard, or on the UI item representing a virtual keyboard button that acts as a key. The user's expectation is that actuating a key with a specific symbol on the keycap would, by default, cause that symbol to be communicated to the computer.


    • Physical key
    • Keyboard
    • Key meaning

  • A Kernel Object Identifier.



  • The "Legacy AIB" is an AIB that includes both platform and product artifacts that are specified via the GN build arguments such as base_product_labels and bootfs_labels.


    The Legacy Assembly Input Bundle (LAIB) is an AIB that includes both platform and product artifacts that are specified via the GN build arguments such as base_product_labels and bootfs_labels. Eventually, all the contents of the Legacy AIB will be migrated to platform AIBs or the Assembly Config, and it will be deleted entirely. As of November 2022 (last time this definition was updated), Software Assembly is not feature-complete, and products have not been fully migrated over to using Software Assembly. Many of the current platform features and product code lack the support in Assembly to define them inside the Assembly Config, therefore we invented a temporary solution.



  • View's device independent pixels.


    View's device independent pixels. This affects the content layout. Each pixel is displayed on-screen by one or more physical pixels, as determined by device pixel ratio.



  • Caps lock, num lock, fn lock, scroll lock


    A "state set by actuating a lock key, singly or in combination with a [modifier] key". (ISO/IEC 9995-1:2009, section 4.5) Example lock state keys on PC keyboards are: CapsLock, NumLock, FnLock, ScrollLock.


  • Little Kernel (LK) is the embedded kernel that formed the core of the Zircon Kernel.


    LK is more microcontroller-centric and lacks support for MMUs, userspace, system calls -- features that Zircon added.



  • Underlined character in a menu option.


    The underlined character in a menu (Wikipedia). For example, the "F" in "File" which is accessed by pressing "Alt+F". Mnemonics are localized. For example, the "File" menu in an English version of a program has "F" as the mnemonic, so "Alt+F" would be used to access. The Dutch version of the same program would have "Bestanden" as the title of that very same menu, so "Alt+B" would be used for access. Mnemonics differ from shortcuts: in an application an "Open" command could have "O" as mnemonic, but Ctrl+F12 as a shortcut.


  • A key that modifies the effect of other keys.


    A "key whose operation has no immediate effect, but which, for as long as it is actuated, modifies the effects of other keys. A modifier key can be, for example, [...] a control key." (ISO/IEC 9995-1:2009, section 4.17)


  • Identifies a specific component instance in the component tree using a topological path.


    A component's moniker is defined as a path to the component instance in the component instance tree.



  • Fuchsia's standard C library (libc) is based on Musl Libc.



  • A namespace is the composite hierarchy of files, directories, sockets, services, and other named objects offered to components by their environment.



  • An implementation of TCP, UDP, IP, and related networking protocols for Fuchsia.


  • The build system executing Fuchsia builds.


    It is a small build system with a strong emphasis on speed. Unlike other systems, Ninja files are not supposed to be manually written but should be generated by other systems, such as GN in Fuchsia.



  • An entity in the Driver Framework that contains a set of resources that a driver can interact with and a set of properties. A node can be thought of as a hardware or virtual device, or a node can be a part of a hardware device.



  • Node properties are key-value pairs contained in nodes. They are used by bind rules to evaluate whether a driver is matched to the node.


    Node properties are key-value pairs contained in nodes. They are used by bind rules to evaluate whether a driver is matched to the node.The keys can be of integer or string type. The values can be of integer, string, boolean, or enum type.



  • The node topology describes the parent-child relationships between nodes in a Fuchsia system. These nodes form a single node topology, expressed in a directed acyclic graph.



  • A keyword for a component instance to route a capability that was exposed to it.


    A component instance may use the offer manifest keyword to route a capability that was exposed to it to one of its children (other than the child that exposed it).



  • Relating to or describing an action that can be done outside of a Fuchsia checkout.


    For instance, the IDK allows developing for Fuchsia outside the Fuchsia tree. The SDK tools are available as prebuilts so developers don't need to check out Fuchsia code and build the same tools from source code using Fuchsia's in-tree build system.



  • A file system directory where a component serves protocol handles to capabilities it has exposed.


    A file system directory where a component serves protocol handles to capabilities it has exposed. Other components connect to these exposed capabilities using the handles in this directory.



  • Over-the-air update.


    Over-the-air updates are changes made to device software (generally the full system, but possibly smaller modules as well) without re-initializing the device's disk via a pave or flash.



  • A unit of software distribution in Fuchsia.


    A unit of software distribution in Fuchsia. It is a collection of files, such as manifests, metadata, zero or more executables (e.g. components), and assets. Individual Fuchsia packages can be identified using fuchsia-pkg URL. Packages can contain other packages (known as Subpackages).



  • Also known as the Fully-Qualified Package URL, a url with the "fuchsia-pkg" scheme (fuchsia-pkg:///) representing a fully qualified location for a fuchsia package. For example: fuchsia-pkg://fuchsia.com/package_name

  • A package URL with a URL parameter "hash" with value that is the merkle hash of the package's meta.far (fuchsia-pkg:///?hash=). Pinning a package is the act of uniquely identifying a version of a package, through the hash URL parameter. For example: fuchsia-pkg://fuchsia.com/package_name?hash=716178364a3a0fc8be2850f88a7414f95ed895489bc0f74bc2d60d78d3682c65

  • A parent component instance is a component instance that owns other instances called child component instances



  • A driver that provides resources from its node to its child nodes.



  • A tool in Zircon that installs partition images to internal storage of a device.



  • A physical device for text entry.


    A physical device for text entry, which relies on an arrangement of keys.


    • physical key
    • keycap
    • key effect

  • A positioning of keycaps on a physical keyboard.


    A positioning of keycaps on a physical keyboard.


    • keycap
    • physical keyboard

  • The numeric code associated with a key, as assigned by Fuchsia.


    The numeric code associated with a key, as assigned by the operating system. In Fuchsia, the physical key codes are unsigned 32-bit integers, derived from the USB HID usage tables. The USB HID usage page number is encoded in the upper 16 bits, and the usage ID within a page is encoded in the lower 16 bits. An encoding of a physical key code used in Fuchsia: see input.Key.


    • Physical key
    • Scan code

  • Display's physical pixel count.


    Display's physical pixel count. i.e. if there are 4K and FHD variants of the same size display, 4K has 3840x2160 physical pixels and FHD has 1920x1080 physical pixels. However, they may have the same amount of logical pixels so the layout of the content looks the same.



  • A process KOID. A KOID that uniquely identifies a process object.



  • The platform is the common foundation for products built using Fuchsia.


    Products built using Fuchsia share a common foundation, which is the underlying Fuchsia platform. The platform consists of (a) the core system, including the Zircon kernel, component framework, driver framework, and software delivery subsystem, (b) services that let components share hardware resources, including the connectivity, graphics, media, and local storage subsystems, and (c) widely used components, including the web runtime, POSIX compatibility layers, and diagnostics. Not every product uses every aspect of the platform. For example, products without displays do not use the graphics subsystem. The platform has a versioned, stable binary interface, which developers can target using the Fuchsia SDK.



  • A node added by the board driver to the platform bus.



  • The first driver loaded in Fuchsia. The platform bus is the root driver and contains all the resources and privileges necessary to interact with hardware.



  • The open source code hosted on fuchsia.googlesource.com, which comprises the source code for Fuchsia.


    A given Fuchsia system can include additional software from outside the platform source tree by adding the appropriate Fuchsia package.


  • A specification for an assembled system.


    For instance, the Fuchsia platform defines products such as `bringup` and `core` in terms of build-time configuration values and a set of packages to assemble into a system image.



  • The set of artifacts representing a Fuchsia product which are needed to emulate, flash, boot, or update the product on a Fuchsia target.


    A Product Bundle contains all the images required for an A/B/R Fuchsia target. Artifacts include, but are not limited to, the product image and packages associated with it.



  • Whoever defines a product, and is responsible for its provenance and releases.



  • A kernel object that represents an instance of a program as a set of instructions that are executed by one or more threads together with a collection of capabilities.


    Every process is contained in a job.



  • In FIDL, a protocol groups methods and events to describe how one process interacts with another.


    In the component runtime, protocols are routed to and used by other components as protocol capabilities.



  • A capability that permits communicating with a protocol over a channel using a specified FIDL protocol.


    The server end of the channel is held by the component instance that provides the capability. The client end of the channel is given to the component instance that uses the capability.



  • A subtree of component instances in the component instance tree. Acts as a container for component instances and capabilities in the subtree.



  • Resources are contained in nodes and are used by drivers for communication. There are multiple types of resources, including but not limited to: IPC, kernel, memory map, and I/O.


  • A roller is an infrastructure job that watches for updates to a repository's pinned dependencies and automatically creates and submits a commit that updates the pinned version (a "roll") when it detects that a new version of a dependency is available.


    The Fuchsia project uses rollers to update pinned versions of repositories and CIPD packages. Rollers can be configured to trigger automatically on new commits to a repository, run as a cron job that periodically polls for changes, or only be triggered manually.


  • The root of the job tree and the first job in the system.


    The root job is created by the kernel to allow [userboot](/docs/glossary#userboot) to begin execution.



  • A component that provides a runtime environment for other components, e.g. the ELF runner, the GTest runner.


    Every component needs a runner in order to launch. Components express their dependency on a runner in the component's declaration. When the component framework starts a component, it first determines the capabilities that the component should receive, then asks the component's runner to launch the component. The runner is responsible for creating any necessary processes, loading executable code, initializing language runtimes, handing control to the component's entry points, and terminating thecomponent when requested by the component framework.



  • A sequence of numeric values associated with a key.


    A sequence of numeric values associated with a key, as assigned by the hardware controller of the physical keyboard. While standardized scan codes exist, keyboards are varied enough that operating systems usually have to map all scan code sequences into a single space of physical key codes.


    • key
    • physical keyboard

  • Scenic is Fuchsia's system compositor, which composes graphical objects from multiple components into a shared scene graph.


    Scenic includes views, input, compositor, and GPU services.



  • A subset of files in the SDK.


    An *SDK Atom* is a collection of files that can be included in an SDK. Fuchsia represents SDK Atoms using the sdk_atom template in GN.


  • A hardware driver that will only service a single request at a time. The core driver synchronizes and serializes all requests.


  • In FIDL, a service groups protocols to describe how one process interacts with another.


    A service is used and routed to other components as a service capability.



  • A capability that permits communicating with a service over a channel using a specified FIDL service.


    The server end of the channel is held by the component instance that provides the capability. The client end of the channel is given to the component instance that uses the capability.



  • A session component is a component that encapsulates a product's user experience and runs as a child of the platform `session_manager` component.


    A "session component" is a component. Each Fuchsia product encapsulates its user experience within a session component (and its descendent components). The term "user experience" is used broadly: it encompasses traditional graphical experiences with touch/mouse/keyboard interaction, as well as simpler experiences with a single RGB LED and several hardware buttons, or those with only network I/O. Simple products may specify a session component with no children, while complex products have many children of the session component, such as delegating graphical presentation responsibility to an accompanying window manager.



  • A FIDL protocol, exposed by the session manager, used to start or restart sessions.


    It is available to developer tools such as session_control to control session components at runtime.



  • The platform component that manages the lifecycle of the session component.


    The session manager defines the set of system capabilities provided to sessions at runtime.



  • The process of gathering compiled artifacts, configuration metadata, and other information required to create a complete Product Bundle.


    The Software Assembly process is carried out by an ffx plugin which gathers various targets declared in the Assembly Config, Legacy AIB, and Platform AIBs. The result of Software Assembly is a Product Bundle.



  • A runner that allows for running unmodified Linux binaries on Fuchsia.


    A runner that allows for running unmodified Linux binaries on Fuchsia. Linux binaries are not run inside a virtual machine. Instead, starnix creates a compatible runtime environment by implementing the Linux UAPI.



  • A storage capability is a capability that allocates per-component isolated storage for a designated purpose within a filesystem directory.


    Multiple component instances may be given the same storage capability, but underlying directories that are isolated from each other will be allocated for each individual use. This is different from directory capabilities, where a specific filesystem directory is routed to a specific component instance. Isolation is achieved because Fuchsia does not support dotdot. There are three types of storage capabilities:



  • A sub-realm is the realm corresponding to a child component instance.



  • A Fuchsia package contained (by reference) in another package.


    A Fuchsia package can declare dependencies on one or more packages, by containment. The containing package is sometimes referred to as the superpackage and the contained packages are its subpackages. Subpackages are declared by reference, but the existence of the superpackage implies the existence of its subpackages, regardless of the medium (including a Fuchsia runtime, in a package repository, or in a package archive format, for example). Packages and Components can reference contained packages and subpackaged components, respectively, by relative subpackage URLs.



  • A partial Fuchsia Package URL, starting from the URI path.


    A relative subpackage URL requires a "resolution context", which simply means a known starting package (or "superpackage"). The path (a single path segment with no slashes: `/`) refers to a subpackage, declared and named by its superpackage; for example: my-package#meta/comp.cm, representing a component within a subpackage, with the locally-scoped name "my-package".



  • An async dispatcher where posted tasks are run in order, and each task will observe the side-effects from previous tasks.



  • An API that allows editing a UI text field.


    E.g. fuchsia.ui.text. This API allows the platform to access and edit the contents of a text field implemented by a UI Framework. This type of editing is a requirement for most text manipulation, in particular when the text is interpreted as human language rather than discrete button events. This API is required for accented characters (anything using a dead key) and most CJK languages.


    • Key Event API

  • A kernel object that represents a time-shared CPU execution context. Each thread is contained in process.



  • A hierarchical piece of a Flatland graph.


    A hierarchical piece of a Flatland graph. Transform is the fundamental object used to organize a Flatland graph. Transforms can have children Transforms and can attach a Content.


  • Tools used by developers to compile sources into binaries. Fuchsia supports Clang for C/C++.


  • Top-Of-Tree: The source tree (or build artifact thereof) based on the most recent commit to the main development branch of the source code.


    Top-Of-Tree (or Tip-of-Tree, both are used interchangeably) refers to various artifacts, depending on context. The common denominator is that the artifact of interest is not relating to a stabilizing branch like releases/f18. Frequent examples:

    • A Fuchsia git checkout sync'ed to JIRI_HEAD.
    • The resulting artifacts from a build from a Fuchsia git checkout sync'ed to JIRI_HEAD.
    • The resulting artifacts from a component built from the development HEAD of a component, against an unspecified version of the Fuchsia SDK.


  • An ephemeral driver from a specific Fuchsia package set that is registered manually after the system's initial boot.


  • A keyword for a component instance to consume a capability that was offered to it.


    A component instance may use the use manifest keyword to to consume a capability that was offered to it by its parent.



  • The first process started by the Zircon kernel.


    It is loaded from the kernel image in the same way as the vDSO, instead of being loaded from a filesystem. Its primary purpose is to load the second process, bootsvc, from the bootfs.



  • A region of the Scenic scene graph and the reference frame of a Scenic client.


    The region a Scenic client can draw in, and the coordinate system input events are delivered in. Views can be referred to cross-process by their associated ViewRef.



  • The parent endpoint of two connected Flatland instances.


    The parent endpoint of two connected Flatland instances. View is the child endpoint. Viewport is type of a Content.


  • Uniquely identifies the parent connection point of a connection between two Flatland instances.


    Uniquely identifies the parent connection point of a connection between two Flatland instances. There is only one ViewCreationToken associated with a ViewportCreationToken.


  • Represents a handle to a remote View that was launched by calling PresentView() on a GraphicalPresenter.


    A FIDL protocol. With this handle, the caller (often, the session) can control the View's lifecycle. Closing the ViewController should close the presented view, and allow the system to reclaim its resources.



  • Uniquely identifies the child connection point of a connection between two Flatland instances.


    Uniquely identifies the child connection point of a connection between two Flatland instances. There is only one ViewportCreationToken associated with a ViewCreationToken.


  • Uniquely identifies an attachment point for a view in the global scene graph.


    A FIDL struct. Each ViewHolderToken has exactly one corresponding ViewToken.



  • A handle to a kernel object that identifies a unique View across the system.


    A FIDL struct. Two ViewRef`s to the same view have the same KOID. During cross-process communications Scenic clients are referred to by ViewRef. This is common for Input, Accessibility and Focus.



  • A description of a view to be presented by a GraphicalPresenter.


    A FIDL table.



  • Uniquely identifies a View, which is the root point for a subgraph in the global scene graph.


    A FIDL struct. Each ViewToken has exactly one corresponding ViewHolderToken.



  • The Virtual Dynamic Shared Object (vDSO) is a Virtual Shared Library.


    It is provided by the Zircon kernel and does not appear in the filesystem or a package. It provides the Zircon System Call API and ABI to userspace processes in the form of an ELF library that's always there. In the Fuchsia IDK and Fuchsia driver framework it exists as libzircon.so for the purpose of having something to pass to the linker representing the vDSO.


  • A keyboard represented with software.


    While traditionally a keyboard is a mechanical or electromechanical device, modern keyboards can be visual elements on a screen, or can use voice dictation for example. Also called on-screen keyboard (OSK). [wikipedia]


    • keyboard
    • physical keyboard

  • A Virtual Memory Address Range (VMAR) is a Zircon kernel object that controls where and how virtual memory objects may be mapped into the address space of a process.



  • A Virtual Memory Object (VMO) is a Zircon kernel object that represents a collection of pages (or the potential for pages) that may be read, written, mapped into the address space of a process, or shared with another process by passing a handle over a channel.



  • A component (or multiple components) that controls the placement and appearance of windows supplied by applications.


    A component (or multiple components) that controls the placement and appearance of windows supplied by applications. On some systems, this system is also responsible for rendering UI (e.g. title bars). Because the Fuchsia platform may be used to implement a variety of products with very different graphical and input capabilities, the distribution of window manager responsibilities on Fuchsia may look very different than other operating systems where the platform is more closely tied to a single user experience. A window manager typically accompanies a Session component to present any graphical interfaces presented by elements launched as a part of the session. A window manager and a session together create a product experience.



  • Zircon is the kernel and lowest level userspace components (driver runtime environment, core drivers, libc, etc) at the core of Fuchsia.


    In a traditional monolithic kernel, many of the userspace components of Zircon would be part of the kernel itself.



  • A Zircon Boot Image (ZBI) contains everything needed during the boot process before any drivers are working.


    This includes the kernel image and a RAM disk for the boot filesystem.



  • A recovery image that is used to install and boot a full Fuchsia system.


    Zedboot is actually an instance of the Zircon kernel with a minimal set of drivers and services running used to bootstrap a complete Fuchsia system on a target device. Upon startup, Zedboot listens on the network for instructions from a bootserver that may instruct Zedboot to install a new OS. Upon completing the installation Zedboot will reboot into the newly installed system.


  • An abbreviation of Zircon used in Zircon C APIs and ABIs zx_channel_create(), zx_handle_t, ZX_EVENT_SIGNALED, etc) and libraries (libzx in particular).


  • The native low-level system debugger.