# Systems, apps, and components Source: [https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_environment.html](https://docs.qualcomm.com/doc/80-41102-3/topic/concepts_environment.html) TelAF supports a hierarchy of systems, apps and components. The tools help you develop and build your code into **components**. Components are then collected into **executables** and run within processes which then forms an app. **Apps** run their own secure sandbox and are assigned their unique user ID and file permissions are only granted to that user. Apps are then added to a **system** and the system is used to configure what Platform Services, other apps, build variables, kernel modules, commands and monitoring that is needed for your target. ## Components Components can contain any number of source code files, pre-compiled binary files, resource files (e.g., audio files or images), or whatever files the component needs. A component is defined by creating a folder in your system and naming it the name of your component. Components can be "built" generating output like object code libraries and other files. These files can be incorporated into applications and run on a target device Each component must have a defFileCdef Component.cdef file. The file describes the component and how to build it for the build tools. Think of it like a manifest or recipe for your source code. the `Component.cdef` are also used to specify the **external** **interfaces** and **internal** **content** of the components as well as defining the requirements from the system for the component. A component can either contain customized code or can also use to bundle in programs and libraries that were built outside of TelAF. Learn more about why TelAF uses the basicComponents component based model, and the rationale behind it. | Tutorial | Description | | --- | --- | | [Hello World > Create Component](bundle/publicresource/topics/80-41102-1) | How to create a `Component.cdef` for source
code | Example `Component.cdef` that contains 1 source file and provides 1 API and requires 1 API from another source: sources: { myComponent.c } provides: { api: { myComponent = firstComponent.api } } requires: { api: { anotherComponent.api } }Copy to clipboard ## Apps Apps are the execution environment for your code, they contain one or more executables that run together in a sandbox. Executables are created by combining one or more components. Executables are then given a process to run from within the app. Components within the app have liberal privileges between each other and can access shared files in and resources from within the app. Each app must have an [Application Definition .adef](https://docs.qualcomm.com/doc/80-41102-3/topic/def_files_adef.html) file which contains all the instructions and flags on how the app should behave and run. .adef file names are the name of the app. Apps can also be used to wrap around 3rd party programs and libraries to run them within the TelAF. Example .adef, with 2 components running in separate processes: sandboxed: true start: auto executables: { myComponent = ( myComponent ) anotherComponent = ( anotherComponent ) } processes: { run: { ( myComponent ) ( anotherComponent ) } faultAction: restart } bundles: { file: { [rx] script/example.sh /bin/ } } bindings: { myComponent.myComponent.dataRouter -> dataRouter.dataRouter }Copy to clipboard ## Systems Systems are the collection of apps, kernel modules(drivers) and configuration settings that are used to build the TelAF Runtime Environment that gets installed on your target. It includes all configuration and settings that are specific for a target and can also include other .sdefs and include files to build your full target. Each system must have a defFileSdef will contains all the configuration for your system to be built for a target. For example, TelAF includes a `default.sdef` file which includes all the configuration, platform services and tools that are needed to enable the hardware on a supported target. It contains environment variables so that when you run `mksys` -t <target>, it knows how to include all the configuration that is specific to that target. When you build your own system you need to include the default.sdef file so that your system is not only built with your apps but also includes all the default configuration and platform services built for your target. Example basic .sdef: //-------------------------------------------------------------------- // sample system definition that extends the default TelAF system and // includes configuration specific to XXXX company. // // Copyright(C) XXXX company. //--------------------------------------------------------------------- //Provides all default platform services and target specific configuration. #include "$TELAF_ROOT/default.sdef" apps: { $MYPROJECT/apps/myApp } commands: { myTool = tools:/scripts/myTool } interfaceSearch: { $MYPROJECT/interfaces } kernelModules: { $MYPROJECT/drivers/example }Copy to clipboard Note: It is highly recommended that you comment your def files so that other users will be able to know what they need to include or exclude if extending your .sdef. Last Published: Apr 23, 2025 [Previous Topic Glossary](https://docs.qualcomm.com/bundle/publicresource/80-41102-3/topics/glossary.md) [Next Topic Definition files](https://docs.qualcomm.com/bundle/publicresource/80-41102-3/topics/def_files.md)