Mobile Operating Systems
A smartphone is a supercomputer that lives in your pocket, runs on a battery, and is constantly connected to the internet. To make this possible, the operating systems we’ve studied—Linux and Darwin—had to be radically modified to handle two massive constraints: Power Management and Security.
The Mobile Constraint: Energy
On a desktop, if a process uses 10% of the CPU while you’re not looking, it’s a minor annoyance. On a phone, it means your battery will be dead by lunch. Mobile OSs use a technique called Aggressive Suspension.
- When an app is not on your screen, it is often “frozen” in memory. The OS saves its state and removes its access to the CPU entirely.
- If the OS needs more RAM, it will simply kill the background app. The app developer is expected to save the app’s state to disk so it can “resume” later as if nothing happened.
Android: The Linux Modification
Android is built on the Linux Kernel. However, if you log into an Android phone via the terminal, it won’t look like Ubuntu.
- No GNU Tools: Android replaces the standard GNU libraries (glibc) with its own: Bionic.
- The HAL (Hardware Abstraction Layer): Because phone hardware is so diverse, Android has a complex HAL that allows the high-level Java code to talk to camera and sensor drivers without knowing the specifics of the hardware.
- ART (Android Runtime): Apps on Android are written in Java or Kotlin. They are compiled into specialized “DEX” bytecode. The Android Runtime (ART) then compiles this into native machine code on the device.
The Binder
In standard Linux, IPC is done via pipes or shared memory. In Android, almost everything goes through a special kernel driver called the Binder. It is a fast, efficient, and highly secure message-passing system that allows different apps and system services to talk to each other.
iOS: The Secure Sandbox
As we saw, iOS is built on the Darwin (XNU) kernel. Its primary focus is User Security and Predictability.
- No Backgrounding: Until recently, iOS apps were almost never allowed to run in the background. They could only perform specific tasks (like playing music or tracking GPS).
- Strict Sandboxing: Every app on iOS runs in its own “Sandbox.” It cannot see the files of another app, it cannot see the list of other running apps, and it cannot even access your photos unless you explicitly grant it a “Capability.”
- Code Signing: The kernel will refuse to run any piece of code that hasn’t been cryptographically signed by Apple or a verified developer. This makes it almost impossible for traditional “viruses” to function on iOS.
Cross-Platform Comparison
| Feature | Android | iOS |
|---|---|---|
| Kernel | Linux | XNU (Darwin) |
| Customization | High (Change shell, icons, ROMs) | Low (Locked by Apple) |
| App Language | Java / Kotlin / C++ | Swift / Objective-C |
| Updates | Dependent on Manufacturer | Controlled by Apple |
| File Access | User-accessible system | Hidden from user |
Real-Time Constraints: The I/O Problem
Mobile OSs also have to act like Real-Time Operating Systems (RTOS) for certain tasks.
- Touch Latency: When you move your finger on the screen, the display must update within milliseconds. If the CPU is busy indexing a file in the background, your phone will feel “laggy.”
- Audio Processing: To prevent “clicks” and “pops” in your music or calls, the OS gives the audio threads absolute priority over almost everything else.
The Future: Convergence
We are currently seeing a “Merging of the Worlds.”
- iPadOS is getting multi-window support and file management that looks more like macOS.
- macOS is gaining the security features (signed system volumes) and the ability to run mobile apps from iOS.
- Android is becoming more standardized via “Project Treble,” making it easier to update the underlying Linux kernel without breaking the hardware drivers.
In the next section, we will leave the theory behind and learn the actual “Basics” of interacting with these systems using the most powerful tool available: the Command Line.