AOSP System Service与Service差异对比及选型咨询

Great question! Let's break down the key differences between AOSP System Services and regular Android Services beyond what you've already noted, to help you decide which to implement:

Core Differences #

• Launch & Registration Mechanism

  • As you mentioned, System Services are initialized and started directly by the SystemServer process during system boot. They're registered with the ServiceManager via ServiceManager.addService() so other system components can locate them.
  • Regular Services are launched via Intent (either explicitly or implicitly), initialized by the app's ActivityThread process, and declared in the app's AndroidManifest.xml.

• Permission & Privilege Level

  • System Services run with full system-level privileges, accessing restricted permissions like android.permission.INTERACT_ACROSS_USERS_FULL, android.permission.MANAGE_DEVICE_ADMINS, or direct access to kernel-level resources—permissions that regular app Services can never obtain, even with runtime permissions. They also bypass many Binder inter-process communication (IPC) permission checks since they reside in the trusted system_server process.
  • Regular Services are constrained by their app's permission set, signature, and sandbox restrictions. Cross-process access requires explicit permission declarations or signature matching with the calling app.

• Host Process

  • All System Services run within the system_server process, a high-priority system core process that's never killed by the system's low-memory killer.
  • Regular Services run in their parent app's process by default (or a custom process specified via android:process in the manifest). These processes are subject to the system's memory management and can be terminated when resources are low.

• Failure Impact

  • A critical failure in a System Service will trigger a system soft reboot (restarting the system_server process and all dependent services) to restore system stability—since the system_server is the backbone of Android's framework.
  • A regular Service failure only crashes its host app process. The system may restart the app based on its importance, but this doesn't affect the overall system functionality.

• Access & Usage Pattern

  • System Services are accessed via Context.getSystemService(Class) (for app-side proxies) or ServiceManager.getService(String) (for internal system components). They provide core system capabilities like activity lifecycle management, package installation, or power control.
  • Regular Services are accessed via startService() or bindService() from within the app or other authorized apps, used for background tasks like file downloads, media playback, or data synchronization.

• Implementation Requirements

  • System Services must follow AOSP framework conventions, often inheriting from the SystemService base class, and require integration into the SystemServer boot sequence (via code changes in AOSP source).
  • Regular Services only need to extend android.app.Service, declare in the manifest, and follow standard Android app development practices—no AOSP source modifications are needed.

Which to Choose? #

• Implement a System Service if you need to provide a core system-wide capability, require unrestricted system access, or need your service to be always available and critical to system operation. Note that this requires working within the AOSP codebase.
• Implement a Regular Service for app-specific background tasks, where you don't need system-level privileges, and your service's lifecycle is tied to your app's operation.

内容的提问来源于stack exchange，提问作者Taztingo