Overview of Azure Sphere applications

Azure Sphere devices can run two types of applications:

  • High-level applications run containerized on the Azure Sphere OS
  • Real-time capable applications (RTApps) run on bare metal or with a real-time operating system (RTOS) on the real-time cores

A high-level application is required for every Azure Sphere device; RTApps are optional.

High-level applications

Every Azure Sphere device has a high-level application, which runs on the Azure Sphere OS and uses the application libraries. A high-level application can:

  • Configure and interact with Azure Sphere peripherals, such as the general-purpose input/output (GPIO) pins, universal asynchronous receiver/transmitters (UARTs), and other interfaces

  • Communicate with RTApps

  • Communicate with the internet and cloud-based services

  • Broker trust relationships with other devices and services via certificate-based authentication

A high-level application runs in a container in Normal World user mode, as described in What is Azure Sphere?. The application container supports a subset of the POSIX environment and a set of application libraries (Applibs) that are specific to the Azure Sphere OS. The libraries and functions that are available to high-level applications are restricted to ensure that the platform remains secure and can be easily updated. Applications can access only the libraries and run-time services that Microsoft provides; neither direct file I/O nor shell access are available, among other constraints. The Development environment topic describes the base API set and introduces the Azure Sphere application libraries that support device-specific features.

High-level applications are expected to run continuously and are automatically restarted if they stop or fail.

Overview of high-level application development provides more information about features.

Real-time capable applications

An Azure Sphere device may also have one or more real-time capable applications in addition to its high-level application. An RTApp can:

  • Configure and interact with peripherals integrated into the Azure Sphere MCU, such as the GPIO pins and UARTs
  • Communicate with high-level applications

RTApps can run either on bare metal or with a real-time operating system (RTOS). The Azure Sphere samples repo on GitHub includes bare-metal samples that you can start with. If you choose instead to use an RTOS, you will need to port the RTOS to Azure Sphere.

Each RTApp runs isolated on a particular I/O core and can communicate only with a high-level application; it cannot use the internet, the Azure Sphere applibs, or other features of the Azure Sphere OS.

Overview of RTApp development provides more information about the features and development process for RTApps.

Features common to all applications

Despite the significant differences between high-level and RTApps, all Azure Sphere applications have some things in common. The Azure Sphere SDK Preview for Visual Studio enables you to use the Visual Studio integrated development environment (IDE) to develop, build, and debug both types of applications. The SDK preview also supports IntelliSense for both types of applications.

In addition, the following security features apply to both high-level and RTApps:

  • Application capabilities
  • Device capabilities
  • Signing and deployment requirements

Application capabilities

Regardless of where it runs, every Azure Sphere application must specify the external services and interfaces that it requires—for example, its I/O and network requirements—to prevent any unauthorized or unexpected use.

Application capabilities are the resources that an application requires. Application capabilities include the peripherals that the application uses, the internet hosts to which a high-level application connects, and permission to change the network configuration, among others. Every application must have an application manifest, which identifies these resources.

Device capabilities

A device capability enables a device-specific activity. Device capabilities are granted by the Azure Sphere Security Service and are stored in flash memory on the Azure Sphere chip. By default, Azure Sphere chips have no device capabilities.

The appDevelopment device capability changes the type of signing that the device trusts. By default, Azure Sphere devices trust production-signed image packages but do not trust SDK-signed image packages. As a result, you cannot sideload an SDK-signed image package to an Azure Sphere device that does not have this capability. When the appDevelopment capability is present, however, the device trusts SDK-signed image packages. In addition, it enables you to start, stop, debug, or remove an application from the device. In summary, the application development capability must be present on the device before you can:

  • Sideload an image package that was built by Visual Studio or the azsphere image package command.
  • Start, stop, debug, or remove an image package from the Azure Sphere device, regardless of how the image package is signed.

The azsphere device enable-development command creates and applies the appDevelopment capability and prevents the device from receiving cloud application updates.

Signing and deployment requirements

All image packages deployed to an Azure Sphere device must be signed. The Visual Studio Extension for Azure Sphere Preview and the azsphere image package command sign image packages for testing by using an SDK signing key. Azure Sphere devices trust this key only if the appDevelopment device capability is also present.

The Azure Sphere Security Service production-signs image packages when you upload them to the cloud. Production-signed image packages can be sideloaded or loaded over the air.

To prevent the installation of rogue software, applications can be loaded on an Azure Sphere device in only two ways:

  • Sideloading for software development and testing. Sideloading requires direct access to the device and a device capabilty that allows test-signed software. Visual Studio sideloads applications during development and debugging; you can also sideload manually by using the azsphere command-line interface (CLI).

  • Cloud update, which can be performed only by the Azure Sphere Security Service. Use the azsphere CLI to create and manage cloud deployments.

Partner applications

Applications that work together can be considered partner applications and then can be sideloaded separately. When you sideload an application that has a partner, the partner application remains on the Azure Sphere device if it has already been deployed. Each application declares a list of its partners in its project properties:

  • Applications that use Visual Studio projects (.vcxproj) specify the component ID of the partner app on the Project Properties>Debugging page:

    Partner Components in VS

  • Applications that use CMake specify the component ID of the partner app in the partnerComponents field of the configurations section of the launch.vs.json file:

    "partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]