.1 PurposeAn image recipe is a BitBake (.bb) file placed under recipes-core/images/. It defines the full contents of the root filesystem that will be assembled into the final Bolt package, including which packages, binaries, libraries, and supporting components are installed. 4.2 What to IncludeThe image recipe should declare all runtime dependencies of the native application so that the resulting Bolt package is complete and self-contained. The following image recipes in meta-bolt-youtube can be used as templates: 5. Native Application RecipesNative application recipes are BitBake recipes that build the application binaries and libraries included in the final package. They can be sourced in one of two ways: 5.1 Reuse from Dependent LayersIf an existing recipe for the native application already exists in one of the meta-layers declared in manifests/deps.xml, that recipe can be consumed directly without duplication. 5.2 Adding New RecipesWhen a suitable recipe does not exist upstream, new .bb recipe files or .bbappend overlay files can be added under the local recipes-extended tree: | Code Block |
|---|
recipes-extended/<app_or_component>/ |
Keeping customisations in recipes-extended isolates them from upstream changes and makes future maintenance easier. 6. Package ConfigurationThe package-configs directory holds JSON configuration files that the Bolt tool reads to determine how to build a target image and assemble the final Bolt package. There are two distinct config file types for each application: 6.1 <app_name>.bolt.jsonThis file is the primary Bolt build configuration. It instructs the Bolt tool on: - Which Yocto image target to build
- Which metadata files to include in the final Bolt package
Reference examples in meta-bolt-youtube: 6.2 com.rdkcentral.<app_name>.jsonThis file contains the native application package metadata that is shipped inside the Bolt package. At runtime, the on-device application management service reads this file to determine: - Which dependent Bolt packages (such as base and runtime) must be mounted before launch
- Which environment variables and configuration must be exported into the app container.
- How the application is to be started within the Bolt runtime model.
Reference examples in meta-bolt-youtube: 7. Setup EnvironmentThe setup-environment and repo-sync scripts provided in meta-bolt-youtube are intentionally generic and designed to be reused in new Bolt application repositories with little to no modification. To adapt them for a new repository: - Copy setup-environment and repo-sync into the root of the new meta-bolt-<app_name> repository.
- Ensure the dependency layout declared in manifests/deps.xml aligns with any path assumptions made by the scripts.
- Apply only minimal repo-specific changes where required, such as updating default repository names or local build directory paths.
Reusing these scripts keeps the bootstrap and workspace initialization process consistent across all native Bolt application projects. Build Commands:| Info |
|---|
| To build an application that depends on base/runtime Bolt packages (for example, com.rdkcentral.base+<version>.bolt), ensure those dependent packages are available first. Either build them separately or place the corresponding .bolt artifacts in the following location before running the build: |
| Code Block |
|---|
source setup-environment
mkdir bolts/ # inside your build folder
cp <copy your dependent bolt package for eg. base.bolt> bolts/
bitbake bolt-env && hash bolt #build bolt tools for your build setup
bolt make <app_name> |
The bolt make command reads the corresponding <app_name>.bolt.json config, triggers the Yocto image build for the declared target, and packages all required content into the final Bolt package. References |