Thinking about mass-producing devices running Windows 10 IoT Core? Use the Windows ADK IoT Core Add-ons to create images that you can quickly flash onto new devices.
You can create test images, which include tools for quickly accessing and modifying devices. Test images are great for:
- Developers, hardware vendors, and manufacturers (OEMs) who are trying out new device designs.
- Hobbyists and organizations that are creating devices designed to run in non-networked or controlled network environments.
You can create retail images, which can be made more secure for public or corporate networks while still receiving updates.
You can add customizations, including apps, settings, hardware configurations, and board support packages (BSPs).
For OEM-style images, you’ll wrap your customizations into package (.cab) files. Packages let OEMs, ODMs, developers, and Microsoft work together to help deliver security and feature updates to your devices without stomping on each other's work.
- Get the tools needed to customize Windows IoT Core
- Lab 1a: Create a basic image
- Lab 1b: Add an app to your image
- Lab 1c: Add a file and a registry setting to an image
- Lab 1d: Add networking and other provisioning package settings to an image
- Lab 1e: Add a driver to an image
- Lab 1f: Build a retail image
- Lab 2: Creating your own board support package
- Lab 3: Update your apps
You can use the walkthrough as a guide to build both your test and retail images. In general terms:
- Test your customizations, including apps, settings, drivers, and BSPs, to make sure they work.
- Install test certificates on your PC, and package your customizations into .cab files.
- Create a test image that includes your customizations, along with the IoT Core package, and any updates from your hardware manufacturer.
- Flash the image to a device and test it. Use the test tools built into the test images to troubleshoot any new issues.
- If it works, sign your customizations, and repackage them into new .cab files.
- Create a retail image with your signed files, and use it to manufacture new devices.
Packages are the logical building blocks of IoT Core. They contain all the files, libraries, registry settings, executables, and data on the device. From device drivers to system files, every component must be contained in a package. This modular architecture allows for precise control of updates: a package is the smallest serviceable unit on the device.
Each package contains:
- The contents of the package, such as a signed driver binary or a signed appx binary.
- A package definition (.pkg.xml) file specifies the contents of the package and where they should be placed in the final image. See %SRC_DIR%\Packages\ directory for various samples of package files.
- A signature. This can be a test or retail certificate.
pkggen tool combines these items into signed packages. Our samples include scripts:
createprovpkg, which call pkggen to create packages for our drivers, apps, and settings.
The process is similar to that used by Windows 10 Mobile. To learn more about creating packages, see Creating mobile packages.
Feature manifests (FMs)
After you've put everything into packages, you'll use FM files to list which of your packages belong in the final image.
You can use as many FMs into an image as you want. In this guide, we refer to the following FMs:
- OEMFM.xml includes features an OEM might add to a device, such as the app and a provisioning package.
- BSPFM.xml includes features that a hardware manufacturer might use to define a board. For example, OEM_RPi2FM.xml includes all of the features used for the Raspberry Pi 2.
The process is similar to that used by Windows 10 Mobile. To learn more, see Feature manifest file contents.
You'll list which of the features to add by using these tags:
- <BasePackages>: Packages that you always included in your images, for example, your base app.
- <Features>\<OEM>: Other individual packages that might be specific to a particular product design.
The Feature Merger tool generates the required feature identifier packages that are required for servicing the device. Run this tool whenever any changes are made to the FM files. After you change OEM FM or OEM COMMON FM files, run
Buildfm oem. After you change bspfm files, run
buildfm bsp <bspname>.
Creating the image: ImgGen and the image configuration file (OEMInput.xml)
To create the final image, you'll use the
imggen tool with an image configuration file, OEMInput.xml file.
These are the same tools used to create Windows 10 Mobile images. To learn more, see OEMInput file contents.
The image configuration file lists:
The feature manifests (FMs) and the packages that you want to install from each one.
An SoC chip identifier, which is used to help set up the device partitions. The supported values for soc are defined in the corresponding bspfm.xml, under <devicelayoutpackages>.
A Device identifier, which is used to select the device layout. The supported values for device are defined in the corresponding bspfm.xml, under <oemdeviceplatformpackages>.
The ReleaseType (either Production or Test).
Retail builds: We recommend creating retail images early on in your development process to verify that everything will work when you are ready to ship.
These builds contain all of the security features enabled.
To use this build type, all of your code must be signed using retail (not test) code signing certificates.
For a sample, see %SRC_DIR%\Products\SampleA\RetailOEMInput.xml.
Test builds: Use these to try out new versions of your apps and drivers created by you and your hardware manufacturer partners.
These builds have some security features disabled, which allows you to use either test-signed or production-signed packages.
These builds also include developer tools such as debug transport, SSH, and PowerShell, that you can use to help troubleshoot issues.
For a sample, see %SRC_DIR%\Products\SampleA\TestOEMInput.xml.
|Retail builds||Test builds|
|Image release type||ReleaseType: Production||ReleaseType: Test|
|Package release type||Only Production Type packages are supported||Both Production Type or Test Type are supported|
|Test-signed packages||Not supported||Supported
IOT_ENABLE_TESTSIGNING feature must be included.
|Code integrity check||Supported. By default, this is enabled.||Not supported
IOT_DISABLE_UMCI feature must be included
Board Support Packages (BSPs)
Board Support Packages contain a set of software, drivers, and boot configurations for a particular board, typically supplied by a board manufacturer. The board manufacturer may periodically provide updates for the board, which your devices can receive and apply.
OK, let's try it!
Start here: Get the tools needed to customize Windows IoT Core.