com.webos.service.config

A static service in the system that provides product specific configurations to webOS components.

This service provides simple get/set interfaces to access the configurations.

[Terminology]

• config : It consists of 'key' and 'value'. Following is an example of config.
  • { 'language' : 'KOR' } // configName is 'language'. configValue is 'KOR'
• configs & configs.json : 'configs' is a set of configs. We called a file which describes the set as 'configs.json'. Normally, the file name is url name
  • com.webos.service.surfacemanager.json : configs.json file for lsm(luna surface manager)
  • layer & selector & selection : 'layer' is a set of 'configs.json' files. It means layer is same with directory. 
    • basedir in layer :It is a parent dir of others. Basically directories could be there.
    • selection in layer :It is leaf dir name. All 'configs.json' files should be in 'basedir' + 'selection'. If the layer type is "none" and there is no selection, configs.json files would be in basedir.
    • selector in layer : It is a method to get right selection. There are many types of selector in configd.
• configuration & reconfiguration
  • configuration is a set of layer. Actually, higher layer can overwrite lower layer's configs.
  • reconfiguration is a process to make configuration again. If selector can be changed, reconfiguration process is needed. Please refer below sections for more information.

Between webOS platform being built and its reaching the customer, it goes through various configs. For example, configs based on country, provider, language and etc. Making and maintaining separate builds for each of the variants is not practical.

At the moment, there are various non-uniform ways to customize the behavior of various components. Some depend on json config files stored on the root file system and some depend on the file system flags. Such disparity makes it impossible to provide the mechanism or tools to customize the product as a whole.

By specifying a common way to represent various flags and features, config service can provide a streamlined mechanism to our customers to customize the product.

[config & configs.json]

config name : Configd sets config name as CONFIGS_JSON_FILENAME.NAME.

• If there is a key-value like "compositorGeometry": "1920x1080+0+0r0" in com.webos.surfacemanager.json
• User can get configs as "com.webos.surfacemanager.compositorGeometry" or "com.webos.surfacemanager.*".
• As config name contains file name, key should be added in related feature file, and it is recommended that users add feature file same as service name. 

configs.json file structure : Both types of structures are supported for webOS

• Just define key:value pair

com.webos.surfacemanager.json 
{
  "compositorGeometry": "1920x1080+0+0r0"
}

• Define under "configs" category as array

{
    "configs" : [
        {
        "data": {
            "compositorGeometry" : "1920x1080+0+0r0"
        }
    }
    ]
}

[Restriction of getConfig values]

ACG is enabled on Configd and registered services can get configs via private or public bus. But for some cases, configs should be opened for only privileged services. To support this feature, configd allows to define permission by describing service name as array type at feature.json.

To define permission, config values should be described as new format of feature.json like explained above. Permission field would be fetched same way as configs are fetched, and it means that permission would be replaced while fetching upper layers' feature.json. 

Configd checks if requester is in the permitted service list, before returning getConfig and configd support servicename ended with asterisk.

Below example shows that only app3, app4 can get com.webos.component1.fileKey1, com.webos.component1.multiLayerKey. 

dump

fullDump

getConfigs

reconfigure

reloadConfigs

setConfigs

configs

It contains full name of config and value pair.

For example,