Mobile Operating Systems

Smartphones and mobile devices operate under hardware constraints that differ fundamentally from traditional desktop systems. To function efficiently on limited battery reserves and maintain security over cellular networks, desktop kernel architectures (Linux and Darwin) underwent significant modifications. The resulting mobile operating systems—Android and iOS—rely on specialized power management, sandboxing, and execution runtimes.

The Mobile Constraint: Energy

On desktop operating systems, background processes may consume CPU cycles with minimal immediate impact on the user. On mobile hardware, unnecessary background CPU activity rapidly drains battery capacity and increases thermal output.

Mobile operating systems implement Aggressive Suspension models:

• Process Freezing: When an application transitions out of the user’s active viewport, the OS suspends its execution threads, removing access to the CPU scheduler while preserving its state in RAM.
• Low Memory Killers: If system memory pressure increases, the kernel’s low-memory killer terminates suspended background processes. Applications must serialize their execution state to persistent storage to support seamless resumption.

You can inspect the power management and battery subsystem diagnostics of a connected mobile device from the command line:

# Example: Query power management state and battery status on an Android device via ADB
adb shell dumpsys battery

The tool reports battery state metrics directly from the kernel driver:

Current Battery Service State:
  AC powered: false
  USB powered: true
  Wireless powered: false
  Max charging current: 500000
  status: 2
  health: 2
  present: true
  level: 98
  scale: 100

Android: The Linux Modification

Android is constructed on top of the Linux kernel, but it does not include standard GNU libraries or the X Window System:

• Bionic libc: Replaces standard glibc. Bionic is a lightweight C library optimized for low memory footprints, lacking support for complex POSIX features like wide characters, and designed to prevent licensing conflicts.
• Hardware Abstraction Layer (HAL): Defines standard interfaces for hardware vendors (e.g., Camera, Audio, Bluetooth). This allows high-level Java frameworks to interact with drivers without compiled-in knowledge of underlying kernel-driver structures.
• Android Runtime (ART): Applications are compiled into DEX (Dalvik Executable) bytecode. ART compiles this bytecode into native machine code on-device using a combination of Ahead-of-Time (AOT) and Just-in-Time (JIT) compilation.

package "System Apps / User Apps" {
[Camera / Settings / Apps]
}
package "Java API Framework" {
[Window Manager]
[Activity Manager]
}
package "Native Libraries & Android Runtime (ART)" {
[bionic (libc)]
[Media Framework]
}
package "HAL (Hardware Abstraction Layer)" {
[Graphics HAL]
[Camera HAL]
}
package "Linux Kernel" {
[Display Driver]
[Flash Memory Driver]
[Binder (IPC)]
}

The Binder

Android replaces traditional UNIX Inter-Process Communication (IPC) with a custom driver called Binder. Operating as a character device driver (/dev/binder), it provides high-performance, object-oriented remote procedure calls (RPC) and handles transaction validation:

/* android_log_example.c - Using Android's Bionic log library instead of glibc printf */
#include <android/log.h>

#define LOG_TAG "LibreUniMobile"

void log_system_event(void) {
    // Bionic intercepts standard stdout/stderr, routing logs through a kernel logger channel
    __android_log_print(ANDROID_LOG_INFO, LOG_TAG, "Initialization of mobile component complete.");
}

iOS: The Secure Sandbox

iOS, derived from Darwin, emphasizes application security and system predictability through strict architectural sandboxing:

• Process Sandboxing: Every app executes in an isolated sandbox directory. Apps cannot view other active processes, read external files, or access hardware resources without explicit entitlement declarations.
• Mandatory Code Signing: The kernel’s page-fault handler refuses to execute any memory page that lacks a valid cryptographic signature verified against Apple’s root authority, blocking arbitrary code execution exploits.
• Capability-Based Permissions: Apps request system services (e.g., camera, location, contacts) by declaring capabilities in their application manifest.

Developers configure sandboxing access by declaring explicit permissions in the application properties manifest:

<!-- Info.plist - Declaring capability entitlement for Camera access on iOS -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSCameraUsageDescription</key>
    <string>This application requires access to the camera to demonstrate entitlement sandboxing.</string>
</dict>
</plist>

If the entry is omitted, the operating system kernel immediately blocks access to the device driver.

Cross-Platform Comparison

An example of key differences between Android and iOS architectures is summarized in the table below:

To audit active third-party application directories on an Android device from the shell, developers query the package manager service:

# Example: List installed third-party packages on Android
adb shell pm list packages -3

This returns a list of package identifiers managed by the Android runtime:

package:com.libreuni.exampleapp
package:org.mozilla.firefox

Real-Time Constraints: The I/O Problem

Mobile devices must deliver low-latency responses to user inputs (like screen touch and audio processing) to ensure a fluid user experience:

• Touch Priority: Touch event delivery pipelines are allocated dedicated realtime priorities to prevent UI frame drops.
• Real-Time Audio: Audio processing threads bypass standard fair-share scheduling, running under real-time FIFO policies to prevent audio buffer underruns.

The following C program demonstrates setting a thread to real-time scheduling priority under a POSIX-compliant mobile subsystem:

/* rt_audio_thread.c - Setting real-time priority for audio threads under POSIX */
#include <pthread.h>
#include <stdio.h>

void make_thread_realtime(pthread_t thread) {
    struct sched_param param;
    param.sched_priority = 99; // Set priority for real-time scheduling
    
    // Configure thread to use First-In, First-Out real-time scheduling policy
    if (pthread_setschedparam(thread, SCHED_FIFO, &param) == 0) {
        printf("Thread priority set to real-time SCHED_FIFO.\n");
    } else {
        perror("pthread_setschedparam failed");
    }
}

The Future: Convergence

Mobile and desktop operating systems are converging towards shared architectures:

• Kernel Standardization: Android’s Generic Kernel Image (GKI) decouples the core Linux kernel from SoC-specific drivers, standardizing update paths.
• Desktop Sandbox Integration: Desktop macOS incorporates iOS-style security policies, including Signed System Volumes and application entitlements.
• Project Treble: Decouples Android OS frameworks from vendor-specific HAL implementations, enabling faster OS upgrades:

# Example: Query Project Treble system property status on Android
getprop ro.treble.enabled

If Treble is active, the system confirms modular separation of the OS and driver layers:

true

Interactive Practice: Mobile Operating Systems

To demonstrate your understanding of mobile OS constraints and sandboxing, complete the practice quiz below.

References & Further Reading

For an example of detailed documentation on Android and iOS architecture, refer to the sources below:

• Yaghmour, K. (2013). Embedded Android. O’Reilly Media.
• Levin, J. (2013). Mac OS X and iOS Internals: To the Apple’s Core. Wrox.
• Apple Inc. (2020). iOS Security Guide. Apple Developer Reference.
• Power management (CC-BY-SA 4.0)