session_manager
Chrome sometimes needs to behave differently on different Chrome OS devices. It's preferable to test for the hardware features that you care about directly within Chrome: if you want to do something special on Chromebooks that have accelerometers, just check if an accelerometer device is present.
Sometimes it's not possible to check for these features from within Chrome, though. In that case, the recommended approach is to add a command-line flag to Chrome and update session_manager
to pass it with the appropriate value (if any).
Chrome's command line is constructed by chrome_setup.cc. This file uses the ChromiumCommandBuilder class to create directories needed by Chrome, configure its environment, and build its command line.
ChromiumCommandBuilder
reads a subset of the Portage USE flags that were set when the system was built from /etc/ui_use_flags.txt
; these can be used to determine which flags should be passed. To start using a new USE flag (including a board name), add it to the libchromeos-use-flags ebuild file. (Relegating this file to a tiny dedicated package allows us to use the same prebuilt chromeos-chrome
and chromeos-login
packages on devices that have different sets of USE flags.)
Configuration that would apply both to the Chrome browser and to other products that could be built using the Chromium codebase (e.g. a simple shell that runs a dedicated web app) should be placed in ChromiumCommandBuilder
. This includes most compositor- and audio-related flags.
Configuration that is specific to the Chrome browser should instead be placed in chrome_setup.cc. This includes most flags that are implemented within Chrome's //ash
and //chrome
directories.
The preferred way to add model-specific switches to the command line is to use chromeos-config to specify the model specific configuration.
To do so, no changes to session_manager
are required. Simply generate the corresponding switches in cros_config_schema (search for AshSwitches
).
If you need a model-specific configuration for a pre-unibuild device (2016 and before), or you need to apply a feature to experimental builds, the best way to do this is USE flags.
Note: USE flags are not able to introduce model-specific switches in the unibuild world.
If possible, introduce a new USE flag named after the feature that you‘re adding and set it in the appropriate board overlays rather than making session_manager
examine board USE flags like samus
or eve
. Using feature-specific USE flags reduces the number of changes needed to enable the feature for a new board — just set the USE flag in the new board’s overlay. In contrast, if session_manager
contains an expression like this:
if (builder->UseFlagIsSet("samus") || builder->UseFlagIsSet("eve")) builder->AddArgs("--enable-my-feature");
then additionally enabling the feature for newboard
will require:
newboard
to IUSE
in libchromeos-use-flags if it's not there alreadysession_manager
to additionally check for the newboard
USE flag/etc/chrome_dev.conf can be modified on dev-mode Chrome OS systems (after making the root partition writable) to add or remove flags from Chrome‘s command line or modify Chrome’s environment. The file contains documentation about its format.