Glossary

Acronyms

• 3PL: Third Party Labs.
• ACLs: Access Control Lists.
• AFE: Auto Test Front End.
• AP: Application Processor.
• AU: Auto Updates.
• AVL: Approved Vendor List.
• BCS: Binary Component Server.
• BFT: Board Function Testing.
• BOM: Bill of Materials.
• BSP: Board support package.
• BVT: Build & Verification Test.
• CL: "Change List", a set of changes to files (akin to a single git commit).
• CPFE: ChromeOS Partner Front End.
• CQ: "Commit Queue", infrastructure to automatically check/build/test/verify/etc... CLs before merging into the tree. See also the Chromium CQ.
• CRX file: CRX files are ZIP files with a special header and the .crx file extension used to package Extensions and Apps.
• CTS: Android Compatibility Test Suite.
• CWS: "Chrome Web Store", used to host & distribute Chrome extensions.
• DDOC: Design Document. Describes & outlines a project and everything related to it to help others review & decide whether & how to move forward.
• DPTF: (Intel's) Dynamic Platform & Thermal Framework.
• DUT: "Device under test", used to refer to the system running Chromium [OS] and where tests are being executed.
• DVT: Design Validation and Testing.
• EC: Embedded Controller.
• EVT: Engineering Validation and Testing.
• FAFT: Fully Automated Firmware Test.
• FCS: Final Customer Ship.
• FFT: Final Function Testing.
• FSI: Final Shipping Image.
• FSP: Firmware Support Package.
• GBB: Google Binary Block, a chunk of data stored in the NVRAM. Contains variables related to boot and identity.
• GERBER: When ODM gives full set of files for board vendor  to make appropriate holes etc.
• GRT: Google Required Tests.
• GS: "Google Storage", used to refer to Google Storage Buckets (e.g. gs:// URIs).
• GTM: Go To Market.
• GTTF: "Green Tree Task Force".
• GoB: "Git-on-Borg" or "Gerrit-on-Borg" or "Gitiles-on-Borg" depending on the context. Used as an umbrella term to refer to the git related services on chromium-review.googlesource.com and chromium.googlesource.com.
• HDCP: High Bandwidth Digital Content Protection.
• HEDT: High End Desktop.
• HW WP: Hardware Write Protect. Physical mechanism to prevent disabling software write protect. Typically a signal grounded by a screw.
• IQC: Incoming Quality Control.
• LGTM: "Looks good to me", commonly used to approve a code review.
• LKCR: "Last known compilable revision" - similar to LKGR (below), the last build that compiled.
• LKGM: "Last known good manifest", the last manifest version that passed a minimal set of tests.
• LKGR: "Last known good revision", the last build that passed all tests.
• LOEM: Local OEM, process model that different OEMs share exactly same device (with no difference) that uses same firmware code and disk image. Only OEM is different.
• LSC: Large Scale Change
• MLB: Main Logic Board (aka motherboard).
• MVP: "Minimum viable product", used to refer to the subset of a feature we want to ship initially.
• NRE: Non-Recoverable Engineering cost.
• OGR: OEM Gate Review Meetings.
• OOBE: Out-of-box experience.
• OQC: Ongoing Quality Control, check for sampling.
• PCB: Printed Circuit Board.
• PCIe: Peripheral Component Interconnect Express expansion bus standard for connecting devices.
• PCRs: Platform Configuration Registers.
• PDD: Privacy Design Document. Outlines everything privacy related to make sure the project is doing the right thing.
• PDG: Platform Design Guide.
• PFQ: "Preflight queue", used to describe bot configurations in the waterfall that run to test/gate changes before they're allowed into the tree for everyone to see.
• PRD: Product Requirements Document. Used to justify a feature/project, not to design it.
• PS: Patchset. Never used to mean "patch series".
• PSR: Panel Self Refresh (eDP).
• PTAL: "Please take a[nother] look", often used when someone is happy with the state of a CL and want reviewers to look [again].
• PVT: Production Validation and Testing.
• PoR: Process of Record / Plan of Record.
• QAV: Quality Assurance Verification.
• RSLGTM: "Rubber stamp looks good to me", used when the reviewer is merely granting OWNERS approval without doing a proper code review.
• RVG: The "Restrict-View-Google" label used to restrict issues in monorail to Google employees (in addition to the reporter or people cc-ed).
• SGTM: Secret Google Time Machine "Sounds good to me".
• SI: Signal Integrity.
• SMT: Surface-mount Technology.
• SW WP: Software Write Protect.
• Servo: a debugging board that connects via USB to a host machine and a device under test.
• TBR: "To be reviewed". In specific circumstances used to land code and have it reviewed later.
• TCPC: Type C Port Controller.
• TPM: "Trusted Platform Module", Tamper-resistant chip that the CPU can talk to. Securely stores keys and does cryptographic ops. We use this to encrypt the keys used to encrypt user files (to make passphrase recovery more difficult). See also TpmQuickRef.
• ToT: "Tip of Tree" or "Top of Tree", as in the latest revision of the source tree.
• UFS: Universal Flash Storage.
• UMA: User Metrics Analysis.
• VPD: Vital Product Data.
• WAI: "Working As Intended", e.g. the behavior described is not a bug, but working as it is supposed to. This is not to say the intention cannot change (as a feature request), simply that it is not a bug.
• WIP: "Work In Progress" - e.g. a patch that's not finished, but may be worth an early look.
• Zerg: Process model for partner to build multiple new devices that only had slight variance from the reference board (touch/no touch, etc…). These devices share single firmware code and disk image.

English Acronyms and Abbreviations

• AFAICT: as far as I can tell
• AFAIK: as far as I know
• DTRT: Do(ing) The Right Thing.
• e.g.: (latin) for example
• FWIW: for what it's worth
• IANAL: I am not a lawyer
• IIRC: if I recall/remember correctly
• IIUC: if I understand correctly
• IMO: in my opinion
• IMHO: in my honest opinion
• IOW: in other words
• i.e.: (latin) in other words
• nit: short for "nitpick"; refers to a trivial suggestion such as style issues
• PSA: public service announcement
• WRT: with respect to

Chrome Concepts

• Chrome Component: Components of chrome that can be updated independently from Chrome its self. Examples are PDF Viewer, Flash Plugin.
• Component App / Component Extension: App or Extension built and shipped with Chrome. Examples are Bookmark Manager, File manager.
• Default Apps: Apps or Extensions that are shipped with Chrome as .CRX files and installed on first run.
• Extension: Third party developed code that modifies the browser.
• Packaged App: Packaged apps run outside of the browser, are built using web technologies and privileged APIs.
• Packaged App (old): Older packaged apps (pre 2013) still ran in tabs, but with offline packaged resources.
• Shared Modules: Extensions or Apps that export resources accessible from other Ext/Apps. Dependencies are installed automatically.
• Aura: The unified graphics compositor (docs).
• Ash: The Aura shell (e.g. the ChromiumOS look); see Ash for more info.

Building

• buildbot: A column in the build waterfall, or the slave (machine) connected to that column, or the build waterfall infrastructure as a whole.
• clobber: To delete your build output directory.
• component build: A shared library / DLL build, not a static library build.
• land: Landing a patch means to commit it.
• slave: A machine connected to the buildbot master, running a sequence of build and test steps.
• tryserver: A machine that runs a subset of all tests on all platforms.
• sheriff: The person currently charged with watching over the build waterfall to make sure it stays green (not failing). There are usually two sheriffs at one time. The current sheriffs can be seen in the upper left corner of the waterfall page.
• symbolication: The process of resolving stack addresses and backtraces to human readable source code methods/lines/etc...
• tree: This means the source tree in subversion. Often used in the context of "the tree is closed" meaning commits are currently disallowed.
• try: To try a patch means to submit it to the tryserver before committing.
• waterfall: The page showing the status of all the buildbots.

General

• Flakiness: Intermittent test failures (including crashes and hangs), often caused by a poorly written test.
• Jank/Jankiness: User-perceptible UI lag.
• Chumping: Bypassing the CQ and committing your change directly to the tree. Generally frowned upon as it means automatic testing was bypassed before the CL hits developer systems.

User Interface

• Bookmark bubble: A "modal" bubble that appears when the user adds a bookmark allowing them to edit properties or cancel the addition.
• Download bar: The bar that appears at the bottom of the browser during or after a file has been downloaded.
• Extensions bar: Similar to the download bar, appears at the bottom of the screen when the user has installed an extension.
• Infobar: The thing that drops down below asking if you want to save a password, did you mean to go to another URL, etc.
• NTB: New Tab button (the button in the tab strip for creating a new tab)
• NTP or NNTP: The New Tab Page, or the freshly rebuilt new tab functionality dubbed New New Tab Page.
• Status bubble: The transient bubble at the bottom left that appears when you hover over a url or a site is loading.

Video

• channels: The number of audio channels present. We use "mono" to refer to 1 channel, "stereo" to refer to 2 channels, and "multichannel" to refer to 3+ channels.
• clicking: Audio artifacts caused by bad/corrupted samples.
• corruption: Visible video decoding artifacts. Usually a result of decoder error or seeking without fully flushing decoder state. Looks similar to this.
• FFmpeg: The open source library Chromium uses for decoding audio and video files.
• sample: A single uncompressed audio unit. Changes depending on the format but is typically a signed 16-bit integer.
• sample bits: The number of bits per audio sample. Typical values are 8, 16, 24 or 32.
• sample rate: The number of audio samples per second. Typical values for compressed audio formats (AAC/MP3/Vorbis) are 44.1 kHz or 48 kHz.
• stuttering: Short video or audio pauses. Makes the playback look/sound jerky, and is often caused by insufficient data or processor.
• sync: Audio/video synchronization.

Display

• active region: The region of a frame where the video data is being transmitted.
• Adaptive Sync: VRR standard developed by VESA.
• amdgpu: Name of the AMD gpu/display driver in Linux kernel.
• bpp: Bits per pixel.
• bridge: DRM (driver) object representing hardware which can convert one display protocol to another (ie: HDMI to DP).
• Chameleon: A device which can mimic a connected display. Used for automated display testing.
• Chamelium: See Chameleon.
• connector: DRM (driver) object representing the physical connector on the device. Is used to communicate with the panel.
• CRTC: DRM (driver) object which refers to the engine responsible for scanning framebuffers from memory to encoder(s). Originally stood for Cathode Ray Tube Controller.
• DP: DisplayPort.
• DP++: DisplayPort Dual-Mode.
• DRM (content protection): Digital Rights Management.
• DRM (driver): Direct Rendering Manager, the Linux subsystem for kernel gpu/display drivers.
• DSC: VESA Display Stream Compression. Used to save bandwidth between the transmitting/source device and the display.
• DSI: MIPI Display Serial Interface.
• DSI command mode: A MIPI DSI operational mode which sends pixels on demand.
• DSI video mode: A MIPI DSI operational mode which sends pixels continuously.
• eDP: Embedded DisplayPort.
• encoder: DRM (driver) object which sits between the CRTC and bridge/connector. Responsible for transcoding the output of a CRTC into a format digestible by the bridge/connector.
• format: An agreed upon layout of pixel data in memory.
• format modifier: Denotes that the format has undergone modification (most commonly compression).
• fourcc: A code representing a format.
• framebuffer: DRM (driver) object representing a collection of memory which can be scanned out to the display.
• HBR: DisplayPort High Bit Rate (2.70 Gbit/s).
• HBR2: DisplayPort High Bit Rate 2 (5.4 Gbit/s).
• HBR3: DisplayPort High Bit Rate 3 (8.1 Gbit/s).
• HDCP: High Definition Content Protection.
• HDMI: High Definition Multimedia Interface.
• horizontal active (hactive): The width of the active region.
• horizontal blank (hblank): The region before and after each row of scanout where there is no video being transmitted.
• horizontal front porch: The portion of a blanking region which appears after the active region of a row.
• horizontal back porch: The portion of a blanking region which appears before the active region of a row.
• horizontal sync (hsync): An interrupt signalling the panel has started scanning out the horizontal back porch for a row.
• i915: Name of the Intel gpu/display driver in Linux kernel.
• lane: A data channel which transmits video.
• layer: See plane (display).
• MIPI: Mobile Industry Processor Interface.
• msm: Name of the Qualcomm gpu/display driver in Linux kernel.
• MST: DisplayPort Multi-Stream Transport.
• overlay: See plane (display).
• PAVP: Intel Protected Audio/Video Pipeline.
• PCLK: Pixel Clock.
• PBN: DisplayPort Payload Bandwidth Number.
• pitch: Number of bytes in the active region of single row.j
• plane (display): DRM (driver) object which represents a portion of the screen filled with framebuffer data. Multiple planes can make up a scene and they can be layered on top of each other.
• plane (framebuffer): A buffer containing a single layer of data in a multi-planar framebuffer.
• PSR: Panel Self Refresh.
• RBR: DisplayPort Reduced Bit Rate (1.62 Gbit/s).
• SST: DisplayPort Single-Stream Transport.
• TCON: Panel timing controller.
• UHBR10: DisplayPort Ultra High Bit Rate 10 (10 Gbit/s).
• UHBR13.5: DisplayPort Ultra High Bit Rate 13.5 (13.5 Gbit/s).
• UHBR20: DisplayPort Ultra High Bit Rate 20 (20 Gbit/s).
• VCPI: DisplayPort Virtual Channel Payload Identifier.
• VRR: Variable Refresh Rate.
• vertical active (vactive): The height of the active region.
• vertical back porch: The portion of a blanking region which appears before the active region.
• vertical blank (vblank): The region before and after the active region where no video is being transmitted.
• vertical front porch: The portion of a blanking region which appears after the active region.
• vertical sync (vsync): An interrupt signalling the panel has started scanning out the vertical back porch.
• VESA: Standards body responsible for DP, DSC and other common display standards.

Toolchain (compiler/debugger/linker/etc...)

• ASan, LSan, MSan, TSan: AddressSanitizer, LeakSanitizer, MemorySanitizer, and ThreadSanitizer bug detection tools used in Chromium testing. ASan detects addressability issues (buffer overflow, use after free etc), LSan detects memory leaks, MSan detects use of uninitialized memory and TSan detects data races.
• AFDO: Automatic FDO; see FDO & PGO.
• FDO: Feedback-Directed Optimization; see AFDO & PGO.
• fission: A new system for speeding up processing of debug information when using GCC; see this page for more details.
• gold: The GNU linker; a newer/faster open source linker written in C++ and supporting threading.
• ICE: Internal Compiler Error; something really bad happened and you should file a bug.
• PGO: Profile Guided Optimization; see AFDO & FDO.

ChromiumOS

• board: The name of the system you're building ChromiumOS for; see the official ChromeOS device list for examples.
• build_target: The new, preferred term for board.
• model: Model generally refers to a ChromeOS device that is unique in the market. A model typically maintains the major hardware components of its parent board but may vary in minor elements of one or more of: physical design, OEM, or ODM.
• platform: Platform may refer to any of the following: (1) a System on a Chip family, (2) a ChromeOS device, (3) the ChromeOS Platform Team.
• image: A set of binary files created from the ChromeOS source code that contains everything needed to run ChromeOS on a device. There are numerous types of images, including unsigned build images (which can be deployed on a device for development and testing), signed build images (which support secure verified boot), and Final Shipping Images (FSI, which are deployed to a device during manufacturing).
• manifest: Refers to ChromeOS's Repo manifest. A Repo manifest is an XML file or set of XML files that describes the Git repositories and refs that make up a ChromeOS image. See Local & Remote Source Tree Layouts.
• buildspec: A manifest where every git repository is pinned to a specific git revision, used to represent a specific build (version) of ChromeOS.
• snapshot: A manifest where every git repository is pinned to a specific git revision, created regularly by annealing at regular time intervals from tip-of-tree.
• firmware: Software that provides low-level control of a device's hardware. Perhaps the two most important pieces of firmware on a Chromebook are for the Application Processor (AP) and Embedded Controller (EC), but there are many others, for example in WiFi adapters, fingerprint sensors, touchscreen controllers, and many more. External peripherals such as USB-C docks and Bluetooth accessories may also have updatable firmware.
• devserver: System for updating packages on a ChromiumOS device without having to use a USB stick or doing a full reimage. See the Dev Server page.
• powerwash: Wiping of the stateful partition (system & all users) to get a device back into a pristine state. The TPM is not cleared, and Lockbox is kept intact (thus it is not the same as a factory reset). See the Powerwash design doc.

ChromiumOS Build

Terms related to building ChromiumOS.

• buildroot: The buildroot refers to the source root of the checkout that is being built. This term is rarely used, but in certain contexts is necessary to distinguish between the current process' source root, and that of the checkout that is actually being built.
• chroot: A chroot jail is used to isolate the CrOS SDK. The term chroot refers to an instance of the SDK for our contexts.
• sysroot: The term sysroot comes from portage. With respect to ChromeOS, a sysroot is where a build target (board) is built. When completed, sysroots essentially have the filesystem you will find on a device's root partitions. By default, they can be found in /build/ inside your chroot.
• uprev: The process of updating the revision (or version) of a package. The purpose is to produce a new ebuild with a higher overall version number to allow the build system to pick up changes made to the package. Packages that inherit from cros-workon can be automatically uprevved by the builders. There is a generic process that covers most packages, and some specialized processes for a few specific packages (e.g. chrome, android).
• overlay: Directory on disk with Portage metadata, forming a collection of packages and profiles. Portage uses the set of overlays visible for a given board and composes it all into a build. See Gentoo Docs for overlays. Examples: chromiumos, chipset-stnyridge (Google-internal), amd64-generic.
• private overlay: Per-device specialized packages on top of an existing overlay. Could contain ebuild/config for proprietary targets such as firmware, media drivers, etc. Example: grunt-private (Google-internal).
• profile: One or more files where the majority of board customization happens -- USE customizations across all packages in make.defaults, or USE and KEYWORDS on a per-package basis (via the package.use and package.keywords files, respectively). See Gentoo Docs for profiles. Example: amd64-generic:base
• stepping stone: An intermediate OS version that a device must update to before it can upgrade to newer versions. e.g. CrOS R50 must update to R72 before it can upgrade to R100.
• variant: A CrOS-specific deprecated mechanism, still in-use by some boards, to share settings across similar boards.
• USE flag: A Portage mechanism to enable/disable features for packages, e.g. support for X11.
• Keyword flag: Used in cros_workon for uprevving packages.