AOSP System Service vs Service Differences

2019-07-09 04:57发布

问题:

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.

回答1:

  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.



回答2:

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.



回答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.