Android Layer 1: HMI & Applications

The HMI (Human Machine Interface) & Applications layer is the top-most layer of the Android stack. This is where users interact with the device. It includes both the System UI (the "chrome" of the OS) and the applications (Apps) that run on it.

System UI

System UI is a specialized, privileged system application (com.android.systemui) that provides the core visual interface elements of the OS, most notably the Status Bar and Navigation Bar. Unlike regular apps, it starts automatically and handles these global UI elements.

💡 Analogy: Think of System UI as the Dashboard of Your Car. It shows you important information (speed/battery, time, warnings) and provides controls (lights/Wi-Fi, wipers/brightness) without being the actual engine.

Key Components:

• Status Bar: Top bar showing time, battery, signal strength, notifications
• Navigation Bar: Bottom bar with Back/Home/Recents buttons (or gestures)
• Notification Shade: The pull-down panel for managing notifications
• Quick Settings (QS): Toggles for Wi-Fi, Bluetooth, Airplane mode, etc.
• Lock Screen: The secure entry point to the device

Architecture Note: SystemUI is just an APK! It lives in /system_ext/priv-app/SystemUI/.

What happens when SystemUI crashes?

• The screen goes black momentarily
• system_server detects the crash via ActivityManagerService
• Because SystemUI is marked android:persistent="true", it's automatically restarted
• User apps continue running unaffected (they're in separate processes)
• The entire restart typically takes 1-2 seconds

App Types and APIs

Not all apps are created equal. Android strictly creates categories of apps based on their permissions and location.

1. Android App (User/Third-Party)

An app created solely using the Android API (public SDK). These are what you download from the Play Store.

• Location: /data/app/
• Permissions: Limited. Must request runtime permissions.
• Sandboxing: Full isolation (unique UID).
• Examples: Chrome, Spotify, WhatsApp.

2. Privileged App

System apps that are critical to the device experience and signed with the platform key or allow-listed.

• Location: /system/priv-app/ or /product/priv-app/
• Permissions: Can access System APIs (marked @SystemApi) and privileged permissions (e.g., REBOOT, MASTER_CLEAR).
• Examples: SystemUI, Settings, Launcher, TelephonyService.

3. Device Manufacturer App

OEM-specific apps that may bypass standard APIs to interact deeply with hardware or proprietary frameworks.

• Location: /vendor/app/, /odm/app/
• Examples: Samsung OneUI Home, Custom Camera App.

4. Persistent App

Special system apps that are marked with android:persistent="true" in their manifest.

• Behavior: The system (ActivityManager) ensures these processes are always running. If they crash or are killed, they are automatically restarted immediately.
• Use Case: Critical core services that must never die, like SystemUI or the Phone app (TelephonyService).
• Difference from Normal Apps: Persistent apps have lower OOM scores (typically 200-400), making them less likely to be killed. However, under extreme memory pressure, even persistent apps can be killed—but they will be immediately restarted by ActivityManagerService.

📁 Official Documentation: android:persistent

App Installation Locations

API Levels & Sandboxing

• Android API (Public): Stable, documented SDK (Context, Activity, View).
• System API (Hidden): Powerful APIs for OEMs/Privileged apps (PackageManager.installPackage, EthernetManager).

Android Permissions Deep Dive

Android uses a permission-based model to protect user privacy and system integrity. Apps must request permission to access sensitive data or hardware.

1. Install-Time Permissions (Normal)

Automatically granted at installation because they pose little risk to user privacy.

• Examples: INTERNET, VIBRATE, ACCESS_NETWORK_STATE.
• Declaration: <uses-permission android:name="android.permission.INTERNET" />

2. Runtime Permissions (Dangerous)

Permissions that give apps access to sensitive user data or hardware. From Android 6.0 (API 23), users grant these at runtime, not install time.

• Examples: CAMERA, ACCESS_FINE_LOCATION, READ_CONTACTS.
• User Flow: App requests permission → System dialog appears → User Approves/Denies.
• Best Practice: Apps must gracefully handle denial (e.g., disable the feature requiring camera instead of crashing).

3. Signature Permissions

These are the most restrictive and secure. The system grants the permission only if the requesting app is signed with the same cryptographic certificate as the app that declared the permission (usually the OS platform key).

• Use Case: Used by OEMs to allow their suite of apps (e.g., Dialer, Contacts) to share data securely without exposing it to third-party apps.
• Level: android:protectionLevel="signature"

4. Privileged Permissions (SignatureOrSystem)

Allows access to apps that are either:

1. Signed with the platform key.
2. Installed in a privileged partition (/system/priv-app/).

• Use Case: System UI, Settings, Carrier Services.
• Note: This allows trusted system apps to perform administrative tasks (like rebooting or clearing app data) without being signed by Google/OEM.

5. Special Access

Permissions that are too powerful for standard runtime requests, requiring the user to go deep into Settings > Special App Access to grant.

• Examples: MANAGE_EXTERNAL_STORAGE (All Files Access), SYSTEM_ALERT_WINDOW (Draw over other apps).

📁 Official Documentation: <permission>

Process Lifecycle & Low Memory Killer (LMK)

Android doesn't have a "Swap" space (traditionally). When RAM is full, it must kill processes to make room. The Low Memory Killer (LMK) daemon decides who dies based on an OOM Score (Out of Memory).

⚠️ Technical Detail: The LMK is a kernel driver (or user-space daemon lmkd in modern Android) that receives updated OOM scores from ActivityManagerService via a socket. when free RAM dips below a threshold (minfree), it kill -9 the process with the highest score.

Advanced Manifest Attributes

The AndroidManifest.xml controls the strict boundaries between your app and the OS.

1. Process Isolation (android:process)

By default, all components of an app run in the same process. You can split them:

• Colon (:name): Private to the app.
• Lowercase (com.example.music): Global process (can be shared with other apps).

2. Shared User ID (Deprecated)

Historically, apps signed by the same key could specify android:sharedUserId="com.example.corp".

• Effect: They run as the same Linux UID.
• Result: They can read each other's files and run in the same process.
• Status: Deprecated in API 29. Use Content Providers/Service Binding instead.

3. Package Visibility (<queries>)

From Android 11 (API 30), apps cannot see all other installed apps by default. You must declare what you need to see.

The Sandbox

Every app runs in its own generic Linux process. Android assigns a unique UID (User ID) starting from 10000 to every app. App A (UID 10051) cannot read App B's (UID 10052) files unless explicitly shared via Content Providers or granted permissions.

SELinux Enforcement

Beyond UID isolation, every app runs in a SELinux context:

Context Breakdown:

• u:r:untrusted_app:s0: SELinux domain (restricts syscalls and file access)
• c154,c256,c512,c768: MCS (Multi-Category Security) labels for app isolation
• Each app gets unique category labels to prevent cross-app data access

What SELinux Blocks:

• Direct access to /system files (must use APIs)
• Raw socket creation (network isolation)
• Access to other apps' data directories
• Kernel module loading

📁 Official Documentation: Application Sandbox

<div id="apk-deep-dive" className="scroll-mt-24"></div>

APK Structure

An APK (Android Package) is the distribution format for Android apps. It is simply a ZIP file.

🧳 Analogy: Think of an APK as a Suitcase. It contains everything the app needs to travel to your phone: clothes (code), toiletries (resources), passport (manifest), and travel documents (signatures).

Modern Distribution: App Bundles & Splits

Android App Bundles (.aab) replaced APKs for publishing. The Play Store takes an AAB and generates optimized, specific Split APKs for the user's device configuration (e.g., only English strings, only ARM64 code, only xxhdpi images).

APK Signing Layers:

1. v1 (JAR): Signs files individually. (Legacy)
2. v2 (Read-Before-Write/Full APK): Signs the binary blob. Faster & Safer.
3. v3+: Supports key rotation.