Android is architected in the form of a software stack comprising applications, an operating system, run-time environment, middleware, services, and libraries. All these layers can be simplified in this form:

Android Build Artifacts

  • Android applications: The top of the stack is where all the built-in applications, third-party applications, and your own applications live. Digi provides a set of sample applications demonstrating the new APIs.

  • Application framework: The second layer includes the application framework, which gives you the tools to write applications such as the SDK, activity managers, location managers, notification managers, and the view system. This level includes the set of new built-in Digi API extensions to access new hardware interfaces: I2C, SPI, CAN, ADC, GPIO, CPU and GPU management, Ethernet, PWM, serial port, and watchdog.

  • Libraries and Android runtime: The hardware access layer is where libraries are located for interacting with Ethernet, Wi-Fi, Bluetooth, and other hardware features. The runtime is also at this layer. Each application runs in its own virtual machine (VM) instance, which means that applications cannot directly invade each other’s process space. The system provides Linux-style permission controls while maintaining an open system through Intents and other interprocess communication capabilities.

  • Linux kernel: At its lowest level, the Linux kernel handles drivers, power management, and other low level processes.

  • U-Boot: Residing below all these layers, U-Boot is not part of Android, but it is needed to load the Android components.

Build artifacts

When the Digi Embedded for Android platform is built, it generates the following build artifacts (files):

Android Build Artifacts

  • super.img: This is a dynamic partition holding "system", "vendor", and "product". It includes all the Android libraries, runtimes, API frameworks, and default applications that run in the device.

  • vendor_boot.img: This partition consists of a header, the vendor ramdisk, and the device tree blob (DTB).

  • boot.img: This image includes the kernel and the ramdisk. U-Boot executes this image after boot, and it mounts the rest of the Android partitions.

  • dtbo-imx8mm.img: This image includes the device tree file and overlays. It includes device tree (DT) data structure of named nodes and properties describing the hardware used by the kernel.

  • <u-boot-file>.imx: This file contains the U-Boot bootloader. This is the first piece of code that is executed when the device boots. It initializes the device and launches the operating system.

  • vbmeta-imx8mm.img: This is the image for the verified boot. Verified Boot strives to ensure all executed code comes from a trusted source, establishing a full chain of trust. See VBMeta image.

  • partition-table.img: This image contains the partition table structure of the eMMC based on its geometry, it is, the description of the system-as-root eMMC layout starting at a certain address.

eMMC layout

The eMMC (internal memory of the ConnectCore 8M Mini device) is split into four physical partitions:

image

  • bootloader: This partition contains the U-Boot bootloader image that is executed when the device is powered on. It starts the installed operating system and allows some device configurations.

  • environment: This partition contains the U-Boot environment and its redundant copy.

  • RPMB: This is the replay-protected memory-block partition, used to manage data in an authenticated and replay-protected manner. See Replay Protected Memory Block (RPMB) secure storage.

  • User Data: User Data holds the operating system divided into the following logical partitions:

    • dtbo_a: This partition contains Android’s device tree overlays.

      This is the partition where the dtbo-imx8mm.img file is programmed.

    • dtbo_b: Redundant DTBO partition.

    • boot_a: This partition contains Android’s kernel and ramdisk.

      This is the partition where the boot.img file is programmed.

    • boot_b: Redundant boot partition.

    • vendor_boot_a: The partition consists of a header, the vendor ramdisk, and the device tree blob (DTB).

      This is the partition where the vendor_boot.img file is programmed.

    • vendor_boot_b: Redundant vendor_boot partition.

    • misc: This is used for recovery storage bootloader messaging.

    • metadata: The metadata partition is used for device encryption.

    • presistdata: This partition is used internally by Android to store information about the unlock capability of Fastboot.

    • super: The super partition contains metadata listing the names and block ranges of each dynamic partition within super. The dynamic partitions included here are system, vendor, and product.

      This is the partition where the super.img file is programmed.

    • userdata: This partition contains the user’s data – this is where your settings and applications are located.

    • fbmisc: Used to store the state of lock/unlock.

    • vbmeta_a: This data structure contains a number of descriptors (and other metadata) and all of this data is cryptographically signed.

      This is the partition where the vbmeta-imx8mm.img file is programmed. See VBMeta image.

    • vbmeta_b: Redundant VBMeta partition.