AOSP System Service vs Service Differences

Question

I'm trying to get a better understanding of the differences so I can evaluate if I should be implementing a System Service, or a Service. The differences that I have found from the docs are the following:

System Service

1. Started in SystemServer
2. Added to ServiceManager
3. Considered mandatory, and soft reboots the device on failure
4. More permissions? (Not sure what it can do that a Service can't)

Service

1. Initialized and started using an intent?

Is there anything else is different between the two? I'm modifying AOSP to include my own service, and any additional supplied information would be helpful in assisting me make a decision.

Answer 1

Below is the answer to the question, when to use SystemService and when Services System Services

1. SystemServices run under SystemServer process
2. If service is related to any special hardware component and APIs are going to expose
3. SystemServices has a different Sepolicy and has fewer restrictions as Compared system_app or unknown_app.
4. Above conditions for you is true then you can Either create SystemService by making changes in AOSP (Normal context.getSystemService(NAME) will work for custom service also) or you can create your own app where you can bind to Servicemanager Below link for reference https://devarea.com/aosp-creating-a-system-service/#.YCV3t_nhXDf

Service

1. it is Non UI component which will run on mainThread.
2. If requirement scope can be served within APP process context only then this is best place to make changes. Why to bother SystemServer for every small task. :)

Answer 2

Android Services

Android services are system component which allows performing a longer-running operation while not interacting with the user.

Just like Activities, Service runs on Main Thread and has a life cycle but unlike Activity, Services do not have a UI.

Anyone can use & create Service or its direct subclasses IntentServcice in their Apps and it works pretty well.

Common usages are: Playing Media, Downloading files from the Internet, etc.

System Services

System services are a direct derivative of SystemService class. They reside in com.android.server packagein AOSP tree

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/services/

System Services also run in Main Thread so if you want to do some CPU intensive task then you much reuse HandlerThread architecture of AOSP.

What makes System service different from Android Services?

System Services are started by SystemServer hence they run as a System process which gives them additional privileges which normal Android Service will never get hence they are named name SystemService.

Example: You can't use Instrumentation to inject events in App other than yours because you will need INJECT_EVENT permission which is not granted to normal apps. SystemService can do that because they have elevated access.

The simple example of System Service :

package com.android.server.appwidget;
import android.content.Context;
import com.android.server.AppWidgetBackupBridge;
import com.android.server.FgThread;
import com.android.server.SystemService;
/**
 * SystemService that publishes an IAppWidgetService.
 */
public class AppWidgetService extends SystemService {
    private final AppWidgetServiceImpl mImpl;
    public AppWidgetService(Context context) {
        super(context);
        mImpl = new AppWidgetServiceImpl(context);
    }
    @Override
    public void onStart() {
        mImpl.onStart();
        publishBinderService(Context.APPWIDGET_SERVICE, mImpl);
        AppWidgetBackupBridge.register(mImpl);
    }
    @Override
    public void onBootPhase(int phase) {
        if (phase == PHASE_ACTIVITY_MANAGER_READY) {
            mImpl.setSafeMode(isSafeMode());
        }
    }
    @Override
    public void onStopUser(int userHandle) {
        mImpl.onUserStopped(userHandle);
    }
    @Override
    public void onSwitchUser(int userHandle) {
        mImpl.reloadWidgetsMaskedStateForGroup(userHandle);
    }
}

Answer 3

They are very different. Their high-level differences are:

• A Service is an application component that is like an Activity without a UI. You can extend it to create your own version of the Service in your application.

• A System Service is part of the System Server. You need to modify AOSP to add your own System Service: provide its API class [MySystem]Manager, its implementation class [MySystem]Service, its AIDL file I[MySystem]Service.aidl, and more. Then you can access it by calling Context.getSystemService(...).

It’s a little confusing to call both of them Service.

Answer 4

It really depends on what exactly you want to implement. I generally prefer to add functionality over modifications to the Android platform so I don't recommend modifying system_server if you can avoid it.

The system_server process runs as user 1000 (aka system) but other processes can also run as user 1000 simply by specifying that in the AndroidManifest so it doesn't have any special selinux capabilities that other apps cannot have, assuming they are signed with the platform key and run as system.

Create System Application

A platform project can declare itself persistent so Android never kills the process, this may or may not be necessary for your situation.

Android What is use of persistent?

You may not actually need system permissions at all, you could simply have your app installed as a priv-app. Generally you only want to grant your app as much privilege as needed.

What is the difference between system apps and privileged apps on Android?

So finally allow me to suggest an alternative: A persistent content provider.

Assuming your app provides some kind of functionality to unprivileged apps then a content provider that exposes its functionality via the call method is a great choice since you do not need to build an aidl file for it or distribute that aidl to the apps, also apps don't need to bind to your service and you don't have to worry about lifecycle since persistent processes never die.

You can check permissions in the call method to ensure the apps declare themselves. If your process crashes then it doesn't take down the entire system_server with it and when you move to a new version of Android you don't have to figure out how to hack up system_server again.

Answer 5

1. All system services are run in the same process called system_server.

2. There's a lot of things which system service can but service can't. system service usually has a higher and more specified sepolicy which normal apps will not have, for example(change NFC hardware parameters).

so if you want add you own system service, notice things above, if you code has a deadlock, you will affect all system services. and without a sepolicy, you service may still unable to access some resources.