AOSP Insider
Back to Blog
July 9, 2025
10 min read

System Apps vs. Third-Party Apps in Android: A Deep Dive

Android
AOSP
System Apps
Third-Party Apps
Development
SSamir Dubey
Samir Dubey

AOSP Engineer

An in-depth comparison of system and third-party apps in Android, covering installation, permissions, lifecycle, updates, and AOSP integration, with practical insights for developers and users.

In the Android ecosystem, apps are broadly categorised into system apps and third-party apps. These two types differ significantly in their origin, installation, privileges, and behaviour within the Android Open Source Project (AOSP) environment. Whether you're an Android enthusiast, developer, or just curious about how your device works, understanding these differences provides valuable insight into the Android OS.

This article explores the distinctions between system and third-party apps, with a focus on their technical underpinnings, lifecycle, and practical implications.

What Are System Apps and Third-Party Apps?

  • System Apps: These are apps pre-installed in the Android system image, included by the original equipment manufacturer (OEM) or as part of the AOSP build. Examples include the Dialer, Settings, and SystemUI apps, as well as Google apps on devices with Google Mobile Services (GMS).
  • Third-Party Apps: These are apps installed by users or third-party sources after the device is set up. They're typically downloaded from app stores like Google Play, sideloaded via APK files, or pre-installed as bloatware by OEMs. Examples include WhatsApp, Firefox, and Spotify.

Let's break down the key differences across various dimensions, including installation, permissions, lifecycle, and access to system resources.

Key Differences Between System and Third-Party Apps

1. Installation and Storage

System Apps:

  • Stored in read-only partitions: /system/app (standard system apps) or /system/priv-app (privileged system apps with elevated permissions).

  • Baked into the system image during the AOSP build process or included via OTA updates.

  • Example: The AOSP Settings app resides in /system/priv-app/Settings and is part of the core OS. Third-Party Apps:

  • Installed in the writable /data/app partition, allowing dynamic installation and removal.

  • Packaged as APK files and processed by Android's PackageManagerService during installation.

  • Example: Installing WhatsApp creates a directory like /data/app/com.whatsapp-<hash>.

For Developers: To understand the Android filesystem, explore the hierarchy of /system vs. /data partitions and how they're mounted during boot (check /etc/fstab). Dive into PackageManagerService in the AOSP source (frameworks/base/services/core/java/com/android/server/pm) to learn about app installation logic.

2. Permissions and Privileges

System Apps:

  • Can request privileged permissions (e.g., android.permission.WRITE_SECURE_SETTINGS or MODIFY_PHONE_STATE) unavailable to third-party apps.

  • Signed with the platform key (or OEM key), granting access to signature-level permissions and privileged APIs.

  • Run in privileged SELinux contexts (e.g., system_app), allowing broader access to system resources.

  • Example: The AOSP Dialer can directly control telephony hardware. Third-Party Apps:

  • Limited to normal (e.g., INTERNET) or dangerous permissions (e.g., CAMERA), which require user approval.

  • Signed with the developer's key, restricting access to privileged APIs.

  • Run in restricted SELinux contexts (e.g., untrusted_app), enforcing strict sandboxing.

  • Example: A third-party messaging app needs user-granted permissions to access SMS.

For Developers: Study Android's permission model (frameworks/base/core/java/android/content/pm) and SELinux policies (system/sepolicy). Use adb shell dumpsys package to inspect app permissions and experiment with permission declarations in app manifests.

3. Lifecycle and Removal

System Apps:

  • Cannot be uninstalled by users without root access or ADB commands (e.g., adb shell pm uninstall — user 0 <package>).
  • Persist across factory resets since they reside in the /system partition.
  • Example: The SystemUI app (com.android.systemui) is critical and non-removable.

Third-Party Apps:

  • Easily uninstalled via Settings or ADB (adb uninstall <package>).
  • Removed during factory resets since they're stored in /data.
  • Example: Uninstalling a game like Candy Crush clears its data from /data.

For Developers: Experiment with ADB package management commands (pm list packages, pm uninstall). Learn how /data is wiped during a factory reset in recovery mode.

4. Updates

System Apps:

  • Updated via OTA system updates or by sideloading new APKs during development.
  • On GMS devices, some system apps (e.g., Google Maps) can be updated via Google Play if decoupled from the system image.
  • Example: Updating the AOSP Camera app typically requires flashing a new system image.

Third-Party Apps:

  • Updated dynamically via app stores, manual APK installation, or auto-updates.
  • Managed by PackageManagerService to ensure version compatibility.
  • Example: WhatsApp updates are seamlessly downloaded from Google Play.

For Developers: Explore Android's OTA update mechanism (system/update_engine) and A/B update systems (bootctrl HAL) to understand how system app updates are handled.

5. Access to System Resources

System Apps:

  • Can interact with internal system services (e.g., WindowManagerService, TelephonyManager) via privileged APIs.
  • Preloaded in the Zygote process for faster startup, sharing core classes and resources.
  • Example: The Settings app can modify system-wide configurations like Wi-Fi or Bluetooth.

Third-Party Apps:

  • Restricted to public APIs exposed via the Android SDK.
  • Loaded on-demand, resulting in slower startup since ART compiles app-specific classes.
  • Example: A third-party Wi-Fi manager app relies on public WifiManager APIs.

For Developers: Study the Zygote process (frameworks/base/cmds/app_process) to understand app startup optimisation. Explore system services in frameworks/base/services to see how system apps leverage privileged APIs.

AOSP-Specific Considerations

System Apps in AOSP

  • Defined in the AOSP source tree (e.g., packages/apps/ for Dialer, Settings).
  • Built into the system image using Android.mk or Android.bp files.
  • Can be customised or replaced by OEMs (e.g., swapping the AOSP Dialer for a vendor-specific version).
  • Example Modification: Adding a custom system app to /system/priv-app requires updating the AOSP build system, signing with the platform key, and flashing the modified image.

Third-Party Apps in AOSP

  • Not included in AOSP builds; installed post-build by users or OEMs.
  • OEMs may pre-install third-party apps in /data/app (bloatware), but these lack true eme app privileges unless explicitly granted.
  • Example: An OEM might pre-install a third-party browser, but it operates within the same constraints as any user-installed app.

For Developers: Try building a custom system app in AOSP using the m command and flash it to a device. Compare this with installing a third-party APK via adb install.

Practical Implications for Users and Developers

For Users

  • System Apps: Often seen as "bloatware" since they can't be removed without advanced tools. However, they're critical for core functionality (e.g., the Dialer or Settings). Some system apps, like Google apps, can be updated or disabled.
  • Third-Party Apps: Offer flexibility and customisation but require careful permission management to ensure privacy and security. They're easier to install and remove, making them ideal for experimentation.

For Developers

  • System Apps: Developing or modifying system apps requires deep knowledge of AOSP, access to platform keys, and the ability to build and flash custom system images. This is common in OEM or custom ROM development.
  • Third-Party Apps: Easier to develop and distribute via app stores, but developers must work within the constraints of public APIs and user-granted permissions.

Interview-Style Questions and Answers

Here are two common questions about system and third-party apps, along with concise answers: Q: How would you add a custom system app to an AOSP build? A: Create an app module in AOSP (e.g., packages/apps/MyApp). Define it in an Android.mk or Android.bp file with LOCAL_PRIVILEGED_MODULE := true for /system/priv-app. Sign the app with the platform key (platform.x509.pem). Add it to the build system (PRODUCT_PACKAGES += MyApp). Build with make and flash the system image. Verify with adb shell pm list packages. Q: Why can't a third-party app access privileged APIs? A: Privileged APIs are protected by signature or system permissions, requiring the app to be signed with the platform key or installed in /system/priv-app. Third-party apps, signed with developer keys and running in the untrusted_app SELinux domain, are restricted to public APIs to maintain Android's security model.

Conclusion

System apps and third-party apps serve distinct roles in the Android ecosystem. System apps are deeply integrated into the OS, offering privileged access and persistence, while third-party apps provide flexibility and user-driven customisation. For developers, understanding these differences is crucial for building apps, customising Android builds, or troubleshooting device behaviour. Whether you're diving into AOSP development or simply managing apps on your device, knowing how these app types interact with the Android OS empowers you to make informed decisions. Want to Explore More?

  • Experiment with ADB to inspect or manage apps (adb shell pm).
  • Dive into the AOSP source code to understand system app integration.
  • Check out Android's official documentation on app permissions and the build system for deeper insights.

By mastering the intricacies of system and third-party apps, you'll unlock a deeper understanding of Android's architecture and its vibrant app ecosystem.