Describe the key features of Android as a mobile operating system

Android is the operating system I’ve spent the most time tinkering with, rooting, flashing, and occasionally bricking over the years. It powers the majority of smartphones worldwide, and its architecture reflects a very different philosophy from iOS — open-source at its core, highly customizable, and built on decades of Linux kernel engineering. In this article, I want to break down the key architectural and feature-level components that define Android as a mobile OS, from the kernel up to the app layer.

Android’s Layered Architecture

Android is structured in layers, each building on the one below:

graph TD
    A[Applications Layer] --> B[Application Framework]
    B --> C[Android Runtime - ART]
    C --> D[Native Libraries]
    D --> E[Hardware Abstraction Layer - HAL]
    E --> F[Linux Kernel]

1. Linux Kernel – Provides core services: process management, memory management, device drivers, power management, and security (via SELinux, discussed in my sandboxing article).
2. Hardware Abstraction Layer (HAL) – Standardized interfaces that let the Android framework call hardware-specific drivers without knowing implementation details (camera HAL, audio HAL, etc.).
3. Native Libraries – C/C++ libraries like WebKit, SQLite, OpenGL ES, and libc that provide core functionality to the framework.
4. Android Runtime (ART) – Executes app bytecode. Since Android 5.0, ART replaced Dalvik, using Ahead-Of-Time (AOT) and Just-In-Time (JIT) compilation hybrids for better performance and battery efficiency.
5. Application Framework – Java/Kotlin APIs that developers use: Activity Manager, Window Manager, Content Providers, Notification Manager, etc.
6. Applications – The apps themselves, both system and user-installed.

Key Feature 1: Open-Source Foundation (AOSP)

The Android Open Source Project (AOSP) is the base from which all Android builds — including Google’s own Pixel builds and heavily customized OEM skins like Samsung’s One UI — are derived. This openness enables:

• Custom ROM communities (LineageOS, GrapheneOS, CalyxOS)
• OEM differentiation (MIUI, One UI, ColorOS)
• Academic and security research access to full source code

Compare this to iOS, which is closed-source, giving Apple tighter control but eliminating the customization ecosystem Android is known for.

Key Feature 2: Application Sandboxing and Permissions

Each Android app runs in its own sandbox, isolated by a unique Linux UID, enforced further by SELinux. but as a headline feature, it’s foundational to Android’s security model. On top of this, Android’s runtime permissions system (introduced Android 6.0/Marshmallow) requires user consent for dangerous permission groups like camera, location, contacts, and storage.

Key Feature 3: Multitasking and Process Management

Android manages background processes through a priority-based process hierarchy:

When memory pressure increases, Android’s Low Memory Killer (LMK), now largely replaced by the kernel’s lmkd daemon working with cgroups, terminates lower-priority processes first to reclaim RAM.

# Example: viewing running processes via ADB
adb shell ps -A
adb shell dumpsys activity processes

Key Feature 4: Google Play Services and the App Ecosystem

Google Play Services is a background framework providing APIs for location, push notifications (Firebase Cloud Messaging), authentication, and more — separate from the core AOSP codebase. This is significant because:

• It allows Google to update core APIs without a full OS update.
• Devices without Google Play Services (like Huawei’s post-2019 phones, or privacy-focused ROMs like GrapheneOS) require alternative implementations (microG, HMS).

Key Feature 5: Customizability and Fragmentation

Android’s openness is a double-edged sword. On one hand, users get:

• Custom launchers, widgets, and home screen customization
• Default app choices (browser, messaging, dialer) without Apple-style restrictions
• File system access via file managers

On the other hand, this creates fragmentation:

Google has mitigated this over the years through Project Treble (separating the vendor implementation from the OS framework, easing OTA updates) and Project Mainline (allowing core system components to update via Play Store-like modules without full OS updates).

Key Feature 6: Notification and Background Task Management

Android’s notification system has evolved significantly, introducing notification channels (Android 8.0+), allowing users granular control per app-category. Background execution limits (introduced progressively since Android 6.0’s Doze mode) restrict what apps can do when the device is idle, balancing battery life against app functionality.

sequenceDiagram
    participant App
    participant AlarmManager
    participant Doze
    participant System
    App->>AlarmManager: Schedule background task
    System->>Doze: Device idle detected
    Doze->>AlarmManager: Defer non-critical alarms
    AlarmManager->>App: Deliver task in maintenance window

Key Feature 7: File System and Storage Model

Android uses ext4 (or f2fs on some devices) as its filesystem, with a partition layout typically including:

• /system – Core OS files (read-only in production builds)
• /data – User data and app private storage
• /vendor – Hardware-specific binaries and drivers (post-Project Treble)
• /cache – Temporary cached data
• /boot – Kernel and ramdisk

Since Android 10, Scoped Storage restricts direct file system access, requiring apps to use the MediaStore API or Storage Access Framework for accessing files outside their own sandboxed directory — a security-motivated restriction that initially caused significant developer friction.

Key Feature 8: Security Updates and Patch Levels

Android security patches are released monthly, addressing kernel vulnerabilities, framework bugs, and component-level CVEs. Google publishes these via the Android Security Bulletin. However, actual delivery to end users depends heavily on OEM cooperation — a key criticism compared to iOS’s centralized, simultaneous update rollout across all supported devices.

Comparing Android to Other Mobile/Desktop OS Philosophies

Real-World Example: Debugging an Android Boot Loop

I’ve dealt with this scenario multiple times while flashing custom ROMs. When a device boot loops, the diagnostic approach typically involves:

1. Booting into recovery mode and checking recovery.log for flashing errors.
2. Using adb logcat (if ADB is accessible) or fastboot to check bootloader-level errors.
3. Verifying the correct firmware/vendor partition matches the flashed system image (common Project Treble mismatch issue).
4. Re-flashing stock firmware via the manufacturer’s official flashing tool as a recovery path.

Best Practices for Android Users and Developers

1. Keep Google Play Services and system components updated via Play Store, even without full OS updates (thanks to Project Mainline).
2. Use scoped storage APIs rather than requesting broad storage permissions.
3. Review app permissions periodically via Settings > Privacy > Permission Manager.
4. For developers, target the latest API level to ensure compliance with the newest security and privacy restrictions.
5. Avoid installing APKs from unknown sources unless you fully trust the publisher.

Troubleshooting Common Android Issues

Key Feature 9: The Binder IPC Mechanism

Underneath almost every cross-process interaction on Android — starting an activity in another app, binding to a service, querying a content provider — is Binder, a custom kernel driver providing efficient, secure inter-process communication. I consider this one of the most underappreciated architectural components of Android, since it’s rarely visible to app developers directly but underlies essentially all system behavior.

sequenceDiagram
    participant AppA
    participant BinderDriver as Binder Kernel Driver
    participant AppB
    AppA->>BinderDriver: Transact() call with UID/PID context
    BinderDriver->>BinderDriver: Verify permissions against caller's UID
    BinderDriver->>AppB: Deliver transaction if authorized
    AppB->>BinderDriver: Return result
    BinderDriver->>AppA: Deliver response

Binder is significant because it embeds identity verification (UID/PID) directly into every IPC transaction at the kernel level, which is what allows Android’s permission system to reliably check “who is actually calling this API” even across process boundaries — a foundational piece of the sandboxing architecture.

Key Feature 10: Android Runtime (ART) Compilation Model

Android’s execution model has changed significantly since the Dalvik era, and understanding this evolution explains a lot about app performance and battery behavior:

The modern hybrid approach uses a background profile-guided compilation system: the runtime observes which methods are executed frequently during actual use, then compiles just those hot paths to native code during idle/charging periods (dex2oat with profile data), balancing install speed against long-term performance without wasting battery compiling rarely-used code paths.

Key Feature 11: Android’s Security Patch Levels vs. Feature Updates

It’s worth distinguishing two separate version concepts that often get conflated:

• Android OS version (e.g., Android 14) – Determines available APIs, UI paradigms, and major feature sets.
• Security Patch Level (SPL) (e.g., “August 2026 security patch”) – A monthly patch cycle applied independently of major OS version upgrades, addressing specific CVEs.

A device can be running an older Android OS version while still receiving current-month security patches, though Google’s Android Enterprise Recommended program and most vendor support commitments tie patch-level guarantees to a limited number of years post-release — a frequent point of criticism compared to iOS’s longer, more uniform support window across device generations.

Key Feature 12: Accessibility Services and Their Double-Edged Nature

Android’s Accessibility API is genuinely powerful, allowing apps like screen readers (TalkBack) to interact deeply with UI elements across the entire system on behalf of users with disabilities. However, this same power has made Accessibility Services one of the most abused permission categories by malware, since an app with Accessibility access can effectively observe and interact with anything shown on screen — including reading two-factor authentication codes from notification banners or auto-clicking through consent dialogs.

Google has progressively tightened Play Store policy around Accessibility Service usage, requiring explicit justification and restricting it to apps with genuine accessibility use cases, precisely because this feature sits at an unusual intersection of “essential for some users” and “dangerous if abused.”

Key Feature 13: Battery and Power Management Architecture

Android’s power management has grown increasingly sophisticated with each release, since battery life remains one of the most consistently cited user concerns across the entire ecosystem:

These mechanisms collectively represent a shift from a purely reactive power-saving model (user-triggered “battery saver” mode) toward a proactive, usage-pattern-driven model that continuously adjusts background restrictions per app without requiring explicit user intervention — a good example of how Android’s architecture has evolved to balance developer flexibility against real-world battery constraints.

Comparing Android’s Update Model to iOS: A Closer Look

Building on the fragmentation discussion earlier, it’s worth quantifying just how different the two platforms’ update distribution actually looks in practice. Apple typically achieves adoption of its latest major iOS version across a large majority of eligible devices within months of release, since updates roll out simultaneously to all supported hardware directly from Apple’s servers with no OEM or carrier intermediary step. Android’s adoption curve has historically been far slower and more fragmented, since each OEM must first integrate Google’s upstream AOSP changes with their own custom skin and hardware drivers before an update can reach end users — a process that varies enormously between manufacturers, with some (like Google’s own Pixel line and a growing number of others committing to Android Enterprise Recommended timelines) now offering multi-year guaranteed update windows comparable to Apple’s historical commitment.

Summary

Android’s defining features — its open-source AOSP foundation, layered architecture from the Linux kernel up through ART and the application framework, robust sandboxing and permissions model, and deep customizability — make it both powerful and complex. This openness enables an enormous ecosystem of devices, custom ROMs, and OEM differentiation, but it also introduces fragmentation challenges that Google has spent years mitigating through initiatives like Project Treble and Project Mainline. Understanding these layers is essential for anyone doing serious Android development, security research, or system administration work.

Frequently Asked Questions

Q: Is Android based on Linux? A: Yes, Android uses a modified Linux kernel, extended with Android-specific components like Binder IPC, ashmem, and wakelocks.

Q: What is the difference between AOSP and stock Android? A: AOSP is the pure open-source codebase; “stock Android” usually refers to Google’s own implementation with Google apps and services layered on top (as seen on Pixel devices).

Q: Why do some Android phones get updates slower than others? A: Because Android updates require OEM and sometimes carrier customization/certification before rollout, unlike iOS’s centralized Apple-controlled update pipeline.

Q: What is Project Treble? A: An architectural change (Android 8.0+) that separates the Android OS framework from vendor-specific hardware implementations, making it easier for OEMs to update the OS without rewriting vendor code.

Q: Can Android run without Google Play Services? A: Yes, though many apps depend on Google APIs (like push notifications via FCM); alternatives like microG or Huawei Mobile Services attempt to fill this gap.

References

• Android Open Source Project documentation (source.android.com)
• Android Developers – Platform Architecture guide (developer.android.com/guide/platform)
• Android Security Bulletins (source.android.com/security/bulletin)
• Google Project Treble and Project Mainline overviews (developer.android.com)