System Apps vs. Privileged Apps vs. Third-Party Apps in AOSP

1. Concept Breakdown

In the Android ecosystem, not all applications are created equal. Android categorizes apps into three main tiers based on where they are installed and what they are allowed to do.

1. Third-Party Apps (User Apps) These are standard applications. You usually download them from the Google Play Store or install them manually (sideload) as an APK file. They are "guests" on the device. They run in a restricted sandbox and cannot touch system settings without asking the user for permission.

• Examples: WhatsApp, Facebook, Candy Crush.
• Location: They live in the user data partition (/data/app).

2. System Apps These apps come pre-installed with the Android OS image. They are part of the "furniture" of the phone. While they are trusted more than third-party apps, standard system apps generally have the same permission capabilities as third-party apps. The main difference is that users cannot easily uninstall them because they live on a read-only partition.

• Examples: Calculator, Calendar, HTML Viewer.
• Location: They live in the system partition (/system/app).

3. Privileged Apps (Priv-Apps) These are the "VIPs" or "Security Guards" of the system. They are system apps that reside in a special directory. Because of this location, they can request privileged permissions—powerful capabilities that standard apps can never have (like managing network connections, interacting with hardware directly, or installing other packages silently).

• Examples: Settings, SystemUI (Status bar), Google Play Services, Default Launcher.
• Location: They live in a protected directory (/system/priv-app).

2. Architecture Logic

The Android system distinguishes these apps using three primary mechanisms: File System Location, Signing Keys, and Permission Protection Levels.

A. The File System Hierarchy

When Android boots, the PackageManagerService scans specific directories to register apps. The directory determines the trust level.

1. Read-Only Partitions (System/Vendor/Product):

   • /system/priv-app/: High trust. The system grants "SignatureOrSystem" and "Privileged" permissions here.
   • /system/app/: Medium trust. Cannot be uninstalled, but behaves mostly like a normal app regarding permissions.
   • /vendor/app/: Apps specific to the hardware chip (SoC).
   • /product/app/: Apps specific to the phone manufacturer (like Samsung or Pixel exclusive features).

2. Read-Write Partition (Data):

   • /data/app/: Low trust. Where user-installed apps live.

B. Protection Levels

In the AndroidManifest.xml of an app, permissions have a protectionLevel.

• normal: Anyone can use it (e.g., Internet access).
• dangerous: Needs user approval popup (e.g., Camera, Location).
• signature: Only granted if the app is signed with the exact same digital key as the Android OS (Platform Key).
• privileged: Only granted if the app is in the /system/priv-app folder AND is whitelisted in a system configuration file.

C. The Whitelist Requirement (Crucial)

Since Android 8.0 (Oreo), simply putting an app in /system/priv-app is not enough. You must also explicitly define which privileged permissions that app is allowed to use in an XML configuration file (usually found in /system/etc/permissions/).

The Flow:

1. App boots.
2. System checks: Is it in /system/priv-app?
3. System checks: Is there a privapp-permissions.xml entry for this app?
4. If both are YES, the powerful permission is granted.
5. If the XML is missing, the system may refuse to boot or crash the app to prevent security risks.

3. Minimal Code Example

Here is how you define these different app types in the AOSP build system using Android.bp (Soong).

1. Defining a Privileged App (Android.bp)

To make an app privileged, you set privileged: true. This moves the output to /system/priv-app.

android_app {
    name: "MyCustomSettings",
    srcs: ["src/**/*.java"],
    
    // This connects the app to the Android OS platform key
    certificate: "platform",
    
    // This places the APK in /system/priv-app/
    privileged: true,
    
    // Specific to the product partition (optional, but common for OEMs)
    product_specific: true,
    
    sdk_version: "current",
}

2. The Permission Whitelist (XML)

You must create an XML file to authorize the permissions.

File: frameworks/base/data/etc/privapp-permissions-mycustom.xml

<permissions>
    <privapp-permissions package="com.example.mycustomsettings">
        <!-- Allow rebooting the device -->
        <permission name="android.permission.REBOOT"/>
        <!-- Allow changing time settings -->
        <permission name="android.permission.SET_TIME"/>
    </privapp-permissions>
</permissions>

3. Requesting in Manifest (AndroidManifest.xml)

The app must request the permission normally.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.mycustomsettings">

    <!-- This is a privileged permission -->
    <uses-permission android:name="android.permission.REBOOT" />

    <application>
        ...
    </application>
</manifest>

4. Treble Connection

Project Treble re-architected Android to separate the core Android OS (Framework) from the manufacturer's implementation (Vendor). This separation affected where apps are placed.

Before Treble, almost all system apps were in /system. After Treble, we have distinct partitions to allow for easier updates:

1. System Partition (/system): Contains generic Android apps (AOSP code). E.g., Default Dialer, Settings.
2. Vendor Partition (/vendor): Contains apps and HALs specific to the chipset (Qualcomm/MediaTek). E.g., A specialized camera tuner app.
3. Product Partition (/product): Contains apps specific to the device brand. E.g., The Xiaomi Calculator or Samsung Notes. This allows the OEM to update their look-and-feel without touching the core System partition.
4. System_Ext (/system_ext): A newer partition for extending system capabilities without modifying the core system image directly.

Treble ensures that a priv-app inside /vendor cannot access private APIs meant for the core /system framework, enforcing a stricter security boundary.

5. Interview Masterclass

Q1: If I move a 3rd party APK into the /system/priv-app folder using Root, will it automatically get system privileges?

Answer: Not necessarily. While moving the APK to /system/priv-app satisfies the location requirement, two other checks must pass.

1. Signing: If the app requests signature level permissions, it must be signed with the device's platform key, which a 3rd party app won't have.
2. Whitelisting: Since Android 8.0, the system enforces a "Privileged Permission Whitelist." If you place an app in priv-app but do not create a corresponding XML configuration file in /system/etc/permissions declaring which permissions it is allowed to use, the system will enforce a boot violation and likely refuse to boot or crash the system to prevent malware from abusing that folder.

Q2: What is the difference between certificate: "platform" and privileged: true in an Android.bp file?

Answer: privileged: true determines the location of the app. It puts the APK into /system/priv-app, allowing it to request permissions marked as protectionLevel="privileged". certificate: "platform" determines the identity of the app. It signs the APK with the same key used to sign the Android OS. This allows the app to request permissions marked as protectionLevel="signature". A super-privileged app (like SystemUI) usually needs both. However, you can have a privileged app that is not platform-signed (e.g., GMS Core/Play Services), and you can have a platform-signed app that is not in the privileged folder.

Q3: How are system app updates handled? If I update the Calculator app via the Play Store, does it overwrite the file in /system?

Answer: No, the file in /system is read-only and cannot be overwritten at runtime. When a system app is updated via the Play Store:

1. The new APK is installed into /data/app (the user partition), just like a 3rd party app.
2. The PackageManager detects that this new APK has the same package name and signature as the one in /system.
3. The system "disables" the version in /system and uses the version in /data.
4. However, the app retains its system privileges (like permission grants) because its original identity was established in the system partition. If the user uninstalls the update, the system simply reverts to using the original APK found in /system.