{"id":38498139,"url":"https://github.com/rdkcentral/rdkservices","last_synced_at":"2026-01-17T05:56:54.765Z","repository":{"id":36966748,"uuid":"246602796","full_name":"rdkcentral/rdkservices","owner":"rdkcentral","description":"RDK Services","archived":false,"fork":false,"pushed_at":"2026-01-12T15:33:50.000Z","size":36931,"stargazers_count":42,"open_issues_count":195,"forks_count":409,"subscribers_count":16,"default_branch":"sprint/26Q1","last_synced_at":"2026-01-12T21:37:28.924Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rdkcentral.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SecurityAgent/AccessControlList.cpp","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":"NOTICE","maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2020-03-11T15:05:36.000Z","updated_at":"2026-01-05T16:17:47.000Z","dependencies_parsed_at":"2023-09-23T15:48:07.700Z","dependency_job_id":"c309073b-9e03-459e-bba7-a25b5fc33613","html_url":"https://github.com/rdkcentral/rdkservices","commit_stats":null,"previous_names":[],"tags_count":11,"template":false,"template_full_name":null,"purl":"pkg:github/rdkcentral/rdkservices","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Frdkservices","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Frdkservices/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Frdkservices/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Frdkservices/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rdkcentral","download_url":"https://codeload.github.com/rdkcentral/rdkservices/tar.gz/refs/heads/sprint/26Q1","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Frdkservices/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28501350,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T04:31:57.058Z","status":"ssl_error","status_checked_at":"2026-01-17T04:31:45.816Z","response_time":85,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-17T05:56:54.066Z","updated_at":"2026-01-17T05:56:54.744Z","avatar_url":"https://github.com/rdkcentral.png","language":"C++","funding_links":[],"categories":["Players \u0026 Clients"],"sub_categories":["Set-top Box Players"],"readme":"# RDK Services #\n\nRDK services are a set of JSON-RPC based RESTful services for accessing various set-top box components. RDK Services are managed and accessed through the [Thunder](https://github.com/rdkcentral/Thunder) framework. Thunder supports both HTTP and Websocket requests, making the services easily accessible to [Lightning](https://github.com/rdkcentral/Lightning), Web, and native client applications.\n\n[View Latest Documentation](https://rdkcentral.github.io/rdkservices/#/README)\n\u003cbr\u003e\n\n### Table of Contents ###\n\n[Contributing to RDKServices](#contributing-to-rdkservices)\u003cbr\u003e\n[Comcast CI/CD](#comcast-cicd)\u003cbr\u003e\n[Documentation](#documentation)\u003cbr\u003e\n[Coding Guidelines](#coding-guidelines)\u003cbr\u003e\n[Versioning](#versioning)\u003cbr\u003e\n[Code Review Checklist](#code-review-checklist)\u003cbr\u003e\n[Questions?](#questions)\u003cbr\u003e\n\n## Contributing to RDKServices ##\n\n### **License Requirements** ###\n1. Before RDK accepts your code into the project you must sign the RDK [Contributor License Agreement (CLA)](https://developer.rdkcentral.com/source/contribute/contribute/before_you_contribute/).\n\n2. Each new file should include the latest [RDKM license header](https://developer.rdkcentral.com/source/source-code/source-code/coding_guideline/).\n\n3. License for this project is included in the root directory and there shouldn't be any additional license file in any of the subfolders.\n\u003cbr\u003e\u003cbr\u003e\n\n### **How to contribute?** ###\n1. [Fork](https://docs.github.com/en/github/getting-started-with-github/quickstart/fork-a-repo) the repository, commit your changes, build and test it in at least one approved test platform/device.\n\n2. To test it in a RDKV device, update SRC_URI and SRCREV in the [rdkservices_git.bb](https://gerrit.teamccp.com/plugins/gitiles/rdk/yocto_oe/layers/meta-rdk-video/+/2103_sprint/recipes-extended/rdkservices/rdkservices_git.bb) recipe to point to your fork.\n\n3. Submit your changes as a [pull request](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) to the latest sprint branch.\n\n4. If more than one developer has to work on a particular feature, request for a dev branch to be created.\n\u003cbr\u003e\u003cbr\u003e\n\n### **Pull request Checklist** ###\n1. When a pull request is submitted, blackduck, copyright and cla checks will automatically be triggered. Ensure these checks have passed (turned into green).\n\n2. At least one reviewer needs to **review and approve** the pull request.\n\n3. For tracking and release management purposes, each pull request and all the commits in the pull request shall include **RDK ticket number(s) or Github issue number(s)** and “reason for the change”.\n\n4. Any pull request from Comcast developers should include a link to successful gerrit verification (in the comment section).\n\n5. To verify your changeset in gerrit, submit a test gerrit change to [rdkservices_git.bb](https://gerrit.teamccp.com/plugins/gitiles/rdk/yocto_oe/layers/meta-rdk-video/+/2103_sprint/recipes-extended/rdkservices/rdkservices_git.bb) with the SRC_URI and SRCREV pointing to your fork.\n\n6. If the changes to RDKServices require any Thunder framework changes, the contributor has to plan for a limited regression testing (with the Thunder and RDKServices changes) before submitting the pull request.\n\u003cbr\u003e\u003cbr\u003e\n\n## Comcast CI/CD ##\n\n### **RDKServices branches - sprint vs main (Specific to RDKV Builds)** ###\n1. Comcast gerrit sprint branch will point to rdkservices sprint branch.\n    1. For example [2103_sprint](https://gerrit.teamccp.com/plugins/gitiles/rdk/yocto_oe/layers/meta-rdk-video/+/2103_sprint/recipes-extended/rdkservices/rdkservices_git.bb#11) branch gerrit recipe will point to [sprint/2103](https://github.com/rdkcentral/rdkservices/tree/sprint/2103) branch in github.\n\n2. Comcast gerrit [stable2](https://gerrit.teamccp.com/plugins/gitiles/rdk/yocto_oe/layers/meta-rdk-video/+/stable2/recipes-extended/rdkservices/rdkservices_git.bb#11) branch will point to rdkservices [main](https://github.com/rdkcentral/rdkservices/tree/main) branch in github.\n\u003cbr\u003e\u003cbr\u003e\n\n### **Sprint/stable2 git hash updates (Specific to RDKV Builds)** ###\n1. Git hash in [rdkservices_git.bb (sprint_branch)](https://gerrit.teamccp.com/plugins/gitiles/rdk/yocto_oe/layers/meta-rdk-video/+/2103_sprint/recipes-extended/rdkservices/rdkservices_git.bb) will be updated periodically (at least once a week).\n    1. Dev owner to follow up as needed and update the JIRA ticket to “ready for sprint testing”.\n\n2. Once a change is verified in the sprint branch and approved by RM, the developer can contact the maintainers to cherry-pick the change set to the [main branch](https://github.com/rdkcentral/rdkservices/tree/main) or submit the cherry picked change set to the main branch.\n    1. Git hash in [rdkservices_git.bb (stable2)](https://gerrit.teamccp.com/plugins/gitiles/rdk/yocto_oe/layers/meta-rdk-video/+/stable2/recipes-extended/rdkservices/rdkservices_git.bb) will be updated periodically.\n    2. Dev owner to follow up as needed and update the ticket to “ready for release testing”.\n\n3. What if a changeset in the sprint branch fails sprint testing?\n    1. The developer has to submit a pull request to undo the commit before the end of the sprint cycle or\n    2. The changeset will be abandoned in the sprint branch and won’t make into the main/stable2\n\u003cbr\u003e\u003cbr\u003e\n\n### **Upstream Vs Patch** ###\n1. Patches will increase the chances of build failures when the git hash is moved to a newer version.\n\n2. We encourage everyone to upstream all the changes to GitHub instead of using patches\n\n3. On a need basis, a developer can request the maintainers for an approval to use a patch in RDKV build (as a stop-gap measure). An unapproved patch will be rejected.\n\u003cbr\u003e\u003cbr\u003e\n\n## Documentation ##\n\nRDK services are described using [JSON Schema](https://json-schema.org/). JSON Schema provides a standard approach for describing APIs and ensures consistency across all APIs. There are two schemas that are used to describe a service:\n\n* [plugin.schema.json](https://github.com/rdkcentral/rdkservices/blob/main/Tools/json_generator/schemas/plugin.schema.json): A schema for defining a service.\n* [interface.schema.json](https://github.com/rdkcentral/rdkservices/blob/main/Tools/json_generator/schemas/interface.schema.json): A schema for defining the properties, methods, and events of a service.\n\nEach RDK service has an instance of these schemas in the root of the service folder. For example, `MyServicePlugin.json` and `MyService.json`. These files are used to generate API documentation as Markdown. Each service has a Markdown file that is written to the `docs/api` folder. The following demonstrates the folder structure:\n\n```shell\n/rdkservices\n    /MyService\n        /MyService.json\n        /MyServicePlugin.json\n    /docs/api\n        /MyServicePlugin.md\n```\n\nMarkdown files are generated from the JSON definitions using the json_generator tool (`Tools/json_generator/generator_json.py`).\n\nThe generator tool requires:\n\n* Python 3.5 or higher\n* The jsonref library\n\nVerify your Python version:\n\n```shell\npython --version\n```\n\nInstall jsonref if it is not already installed:\n\n```shell\npip install jsonref\n```\n\n### Generating Markdown for a Single Service ###\n\nTo generate markdown for a single service:\n\n1. Change directories to `Tools/json_generator`.\n2. Run `generator_json.py` and provide the location of the service JSON plugin file using the `-d` argument and the output directory using the `-o` argument. You must also include the `--no-interfaces-section` argument; otherwise, an interface section is added to the markdown that links back to the ThunderInterfaces project. Make certain that you are pointing to the plugin definition and not the interface definition. Here is an example of using the tool:\n\n    ```shell\n    python ./generator_json.py -d ../../MyService/MyServicePlugin.json  -o ../docs/api --no-interfaces-section --verbose $files\n    ```\n\n    The `MyServicePlugin.md` file is written to the `../docs/api` folder. This is the standard directory where all the service API markdown files are written.\n\n### Generating Markdown for All Services ###\n\nA script is provided to generate the markdown for all services and does a complete build of the documentation. The script only generates the markdown for a service if the JSON definition has been updated. In addition, the script post-processes the generated markdown files to create standard link anchors and to clean the build.\n\nTo generate markdown for all services:\n\n1. From the rdkservices repository, change directories to `docs/Tools/md_generator`.\n2. Run `generate_md.py`. For example:\n\n    ```shell\n    python ./generate_md.py\n    ```\n\n    All markdown files are written to the `../docs/api` folder. This is the standard directory where all the service API markdown files are written.\n\nUse the existing services as a guide when learning the structure of both the plugin and interface schemas.\n\u003cbr\u003e\u003cbr\u003e\n\n## Coding Guidelines ##\n\n1. Style Guide\n\n    The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you’re saying rather than on how you’re saying it. If the code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm. Please Avoid this. If you’re editing code, take a few minutes to determine the coding style of the component and apply the same style.\n\n    * All RDK Services must have a callsign with a prefix of `org.rdk`. RDK Service name must use PascalCase (first letter of each word is capitalized). For instance org.rdk.**P**ersistent**S**tore\n    \n    * API \u0026 Event Names should use camelCase (first word is lowercase \u0026 first letter of subsequent words are capitalized). For instance getDeviceInfo, onAppResumed.\n\n    * JSON parameter names in request and responses should use camelCase and be valid ascii strings. For instance \"updateAvailable\".\n\n    * API getters should start with get. For instance [getDefaultInterface](https://rdkcentral.github.io/rdkservices/#/api/NetworkPlugin?id=getdefaultinterface). Setters should start with set. For instance [setDefaultInterface](https://rdkcentral.github.io/rdkservices/#/api/NetworkPlugin?id=setdefaultinterface).\n\n    * Event names should follow the convention **on[Noun Object][Action Verb]**. \n        * Object should be a noun and provide useful context on the event. \n        * Action should be a verb. Use present and past tenses to indicate if the event is triggered before or after. \n        * For instance onAppResumed, onAppResuming.\n    \u003cbr\u003e\u003cbr\u003e\n    * Capitalize acronyms by default. So use set**HDMI**Enabled instead of set**Hdmi**Enabled.\n\n    * Ensure JSON-RPC API responses return either result or error object on success or error respectively. Please refer to [JSON-RPC Spec](https://www.jsonrpc.org/specification#response_object) for more details on expected members in the response object. Highlighting important members below.\n        * result\n            * This member is REQUIRED on success.\n            * This member MUST NOT exist if there was an error invoking the method.\n        * error\n            * This member is REQUIRED on error.\n            * This member MUST NOT exist if there was no error triggered during invocation.\n            * The value for this member MUST be an Object as defined below.\n                * code\n                    * A Number that indicates the error type that occurred.\n                    * This MUST be an integer.\n                * message\n                    * A String providing a short description of the error.\n                    * The message SHOULD be limited to a concise single sentence.\n        * Either the result member or error member MUST be included, but both members MUST NOT be included.\n\n    * To maintain uniformity in all text-editors, set TAB size to 2 or 4 spaces and replace TAB by SPACES.\n    \n2. RDK services are implemented as Thunder Plugins and must adhere to the [PluginHost::IPlugin](https://github.com/rdkcentral/Thunder/blob/master/Source/plugins/IPlugin.h) interface. If a RDK service handles WEB requests it implements [PluginHost::IWeb](https://github.com/rdkcentral/Thunder/blob/master/Source/plugins/IPlugin.h). If it activates/deactivates and handles JSON-RPC it implements [PluginHost::IDispatcher](https://github.com/rdkcentral/Thunder/blob/master/Source/plugins/JSONRPC.h) (or derives from PluginHost::JSONRPC). If it implements custom interfaces it adds them to [ThunderInterfaces](https://github.com/rdkcentral/ThunderInterfaces) for RPC. If it exposes interfaces to other processes via RPC it develops an [RPC::Communicator](https://github.com/rdkcentral/Thunder/blob/master/Source/com/Communicator.h). A service specifies its interfaces like this:\n\n```shell\n    BEGIN_INTERFACE_MAP(MyPlugin)\n    INTERFACE_ENTRY(PluginHost::IPlugin)\n    INTERFACE_ENTRY(PluginHost::IDispatcher)\n    END_INTERFACE_MAP\n```\n\n3. MODULE_NAME\n\n    * Thunder provides a trace and warning reporting feature. To accurately identify the source of a warning, Thunder needs to know the human readable name of the package (executable or library). This package name is defined by the MODULE_NAME and declared by the  MODULE_NAME_DECLARATION()\n\n    * Any package that includes a Thunder component requires such a definition and declaration. If the definition is missing, a compiler error will be reported (error missing MODULE_NAME) and if the declaration is missing, a linker error will be reported (missing or duplicate symbol)\n\n    * Module.h defines the mandatory MODULE_NAME. It also includes framework headers (\u003cplugins/plugins.h\u003e)\n        ```shell\n        #ifndef MODULE_NAME\n        #define MODULE_NAME Plugin_IOController\n        #endif\n        ```\n    * Module.cpp defines the mandatory MODULE_NAME_DECLARATION\n        ```shell\n        #include \"Module.h\"\n        MODULE_NAME_DECLARATION(BUILD_REFERENCE)\n        ```\n\n4. A service is registered in a translation unit via a mandatory SERVICE_REGISTRATION(MyService, API_VERSION_NUMBER_MAJOR, API_VERSION_NUMBER_MINOR, API_VERSION_NUMBER_PATCH)\n\n5. MyPlugin.config can specify: autostart, startuporder, custom properties (passed to the service during activation via PluginHost::IShell::ConfigLine()). During the project configuration, write_config(MyPlugin) in CMakeLists.txt uses MyPlugin.config to generate and install a corresponding json file. Refer to [PersistentStore.config](https://github.com/rdkcentral/rdkservices/blob/main//PersistentStore/PersistentStore.config)\n\n6. MyPlugin.json documents JSON-RPC interface. It's added to both plugin folder and ThunderInterfaces. The latter generates classes for parameters or enums that can be included like #include \u003cinterfaces/json/JsonData_MyPlugin.h\u003e. In the plugin code, JSON-RPC methods and properties are registered like this:\n\n```shell\n    Register\u003cvoid /*input params*/, void /*output params*/\u003e(_T(\"sync\"), \u0026MyPlugin::endpoint_sync, this);\n    Property\u003cLocationData\u003e(_T(\"location\"), \u0026MyPlugin::get_location /*getter*/, nullptr /*setter*/, this);\n```\n\n7. Initialization and Cleanup\n\n    * Keep Plugin Constructors \u0026 Destructors lean. Most initialization should be done within Initialize() which gets called when the plugin is activated. More on that below. This will ensure that WPEFramework boots up faster since most of the plugins are not auto-started or activated on bootup. Similarly most of the plugin cleanup should happen within Deinitialize() instead of the destructor.\n\n    * Prefer to do Plugin Initialization within IPlugin [Initialize()](https://github.com/rdkcentral/Thunder/blob/master/Source/plugins/IPlugin.h#L71). If there is any error in initialization return non-empty string with useful error information. This will ensure that plugin doesn't get activated and also return this error information to the caller. Ensure that any Initialization done within Initialize() gets cleaned up within IPlugin [Deinitialize()](https://github.com/rdkcentral/Thunder/blob/master/Source/plugins/IPlugin.h#L80) which gets called when the plugin is deactivated.\n    \n    * Ensure that any std::threads created are joined within Deinitialize() or the destructor to avoid [std::terminate](https://en.cppreference.com/w/cpp/thread/thread/~thread) exception. Use the [ThreadRAII](helpers/UtilsThreadRAII.h) class for creating threads which will ensure that the thread gets joined before destruction.\n\n8.  Inter-plugin communication - There might be use cases where one RDK Service or plugin needs to call APIs in another RDK Service. Don't use JSON-RPC for such communication since it's an overhead and not preferred for inter-plugin communication. JSON-RPC must be used only by applications. Instead use COM RPC through the IShell Interface API [QueryInterfaceByCallsign()](https://github.com/rdkcentral/Thunder/blob/R4/Source/plugins/IShell.h#L247) exposed for each Plugin. Here is an [example](https://github.com/rdkcentral/rdkservices/blob/main/MaintenanceManager/MaintenanceManager.cpp#L199). \n    \u003cbr\u003e\u003cbr\u003e\n\n## Versioning ##\n\n* Versioning\n\n    * Given a version number MAJOR.MINOR.PATCH, increment the:\n        * MAJOR version when you make incompatible API changes that break backwards compatibility. This could be removing existing APIs, changes to API Signature or major changes to API behavior that breaks API contract, \n        * MINOR version when you add backward compatible new features like adding new APIs, adding new parameters to existing APIs,\n        * PATCH version when you make backwards compatible bug fixes.\n\n    * RDK Service version in MAJOR.MINOR.PATCH format is updated using SERVICE_REGISTRATION macro.\n\n    ```\n    SERVICE_REGISTRATION(DisplaySettings, API_VERSION_NUMBER_MAJOR, API_VERSION_NUMBER_MINOR, API_VERSION_NUMBER_PATCH);\n    ```\n\n    * There is also a Plugin::Metadata structure maintained for each RDK Service that keeps the versioning information. This is returned in call to Controller.1.status.\n\n    ```\n    static Plugin::Metadata\u003cPlugin::DisplaySettings\u003e metadata(\n            // Version (Major, Minor, Patch)\n            API_VERSION_NUMBER_MAJOR, API_VERSION_NUMBER_MINOR, API_VERSION_NUMBER_PATCH,\n            // Preconditions\n            {},\n            // Terminations\n            {},\n            // Controls\n            {}\n        );\n    }\n    ```\n\n    * Changes in version should be updated when commits are added to the main or release branches. There should be a version change per JIRA Ticket. This is not enforced on sprint branches since there could be multiple changes for the same JIRA ticket during development.  \n\n* Changelog\n\n    * Each RDK Service has a CHANGELOG file that contains all changes done so far. When version is updated, add a entry in the CHANGELOG.md at the top with user friendly information on what was changed with the new version. Please don't mention JIRA tickets in CHANGELOG. Refer to [Changelog](https://github.com/olivierlacan/keep-a-changelog/blob/main/CHANGELOG.md) as an example and [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) for more details.\n\n    * Please Add entry in the CHANGELOG for each version change and indicate the type of change with these labels:\n        * **Added** for new features.\n        * **Changed** for changes in existing functionality.\n        * **Deprecated** for soon-to-be removed features.\n        * **Removed** for now removed features.\n        * **Fixed** for any bug fixes.\n        * **Security** in case of vulnerabilities.\n\n    * Changes in CHANGELOG should be updated when commits are added to the main or release branches. There should be one CHANGELOG entry per JIRA Ticket. This is not enforced on sprint branches since there could be multiple changes for the same JIRA ticket during development. \n\n* Deprecation\n    * Breaking changes to the API that requires a major version update should first go through Deprecation by doing a minor version update. We recommend atleast 2 RDK releases with the deprecated API/s and minor version update to give time for clients and apps to make changes to remove the deprecated API. Following needs to be done for deprecation.\n        * The API/s getting deprecated should be marked with a [\"deprecated\"](https://github.com/rdkcentral/rdkservices/blob/main/SystemServices/System.json#L740) label in the json schema. This will ensure that it's updated in the API [documentation.](https://rdkcentral.github.io/rdkservices/#/api/SystemPlugin?id=getmilestones)\n        * Add a changelog entry with minor version update and include **Deprecated** label to call out the API/s getting deprecated. \n        * If this API/s is getting replaced by a newer API then it can come in the same minor version update with changelog entry with **Added** label.\n    \u003cbr\u003e\u003cbr\u003e\n\n## Code Review Checklist ##\n\nThis checklist is primarily intended for maintainers or reviewers. Please check for the following before approving Pull Requests.\n\n* [Coding Guidelines](#coding-guidelines) are followed. \n* API Changes are [documented](#documentation) and [versioned](#versioning).\n* JIRA Ticket Number is mentioned in the title or commit message for tracking.\n* Any Dependent HAL changes are to be merged first before merging changes to RDK Service to avoid build issues.\n* For a New RDK Service, ensure [autostart](https://github.com/rdkcentral/rdkservices/blob/main/AVInput/AVInput.config#L1) flag is set to false. The general recommendation is for RDK Services to **not** be autostarted or activated unless it's required on bootup. Resident Apps can activate the required RDK Services on demand.\n* Approve Pull Requests to [main](https://github.com/rdkcentral/RDKServices/tree/main) branch or release branches (release/*) only after you get Release Management approval for those specific branches.\n\n\n## Questions? ##\n\nIf you have any questions or concerns reach out to [Anand Kandasamy](mailto:anand_kandasamy@comcast.com)\n\nFor a plugin specific question, maintainers might refer you to the plugin owner(s).\n\u003cbr\u003e\u003cbr\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frdkcentral%2Frdkservices","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frdkcentral%2Frdkservices","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frdkcentral%2Frdkservices/lists"}