Question

我试图更好地理解差异，以便我可以评估是否应该实施系统服务或服务。我从文档中发现的差异如下：

系统服务

在SystemServer
已添加到ServiceManager
认为是强制性的，并在故障时软重启设备
更多权限？（不确定服务能做什么）

服务

已初始化并开始使用意图？

两者之间还有什么不同吗？我正在修改AOSP以包含我自己的服务，任何其他提供的信息都将有助于我做出决定。

Answer 1

所有系统服务都在名为system_server的同一进程中运行。
系统服务可以做很多事情，但服务不能。系统服务通常具有更高且更具指定性的sepolicy，例如普通应用程序不具备（更改NFC硬件参数）。

因此，如果您想添加自己的系统服务，请注意上面的内容，如果您的代码有死锁，您将影响所有系统服务。如果没有sepolicy，您的服务可能仍然无法访问某些资源。

Answer 2

Android服务

Android services是允许执行以下操作的系统组件：运行时间更长，同时又不与用户互动。

Activities像Service一样，在主线程上运行并具有生命周期，但是与Activity不同，Services没有UI。

任何人都可以在其Apps中使用并创建Service或其直接子类IntentServcice，并且效果很好。

常见用法是：播放媒体，从Internet下载文件等。

系统服务

系统服务是SystemService类的直接派生。它们位于AOSP树的com.android.server包中

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

系统服务也运行在主线程中，因此，如果您要执行一些CPU密集型任务，则将大量重用AOSP的HandlerThread体系结构。

是什么让系统服务与Android服务不同？

系统服务由SystemServer启动，因此它们作为系统进程运行，为它们提供了其他特权，而这些特权通常是Android服务永远无法获得的，因此它们被命名为SystemService。

示例：您将无法使用Instrumentation在您自己的应用程序之外注入事件，因为您将需要INJECT_EVENT权限，而该权限不会授予普通应用程序。 SystemService之所以可以这样做，是因为他们具有较高的访问权限。

系统服务的简单示例：

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

这实际上取决于您想要实施的内容。我通常更喜欢在Android平台的修改上添加功能，因此如果可以避免，我不建议修改system_server。

system_server进程以用户1000（也称为系统）运行，但其他进程也可以作为用户1000运行，只需在AndroidManifest中指定它，因此它没有任何其他应用程序无法拥有的特殊selinux功能，假设它们使用平台密钥签名并作为系统运行。

Create System Application

平台项目可以声明自己是持久性的，因此Android永远不会杀死进程，这可能对您的情况有用，也可能不是。

Android What is use of persistent?

您可能根本不需要系统权限，您可以将您的应用程序安装为priv-app。通常，您只想根据需要授予您的应用程序特权。

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

所以最后请允许我建议一个替代方案：持久内容提供商。

假设您的应用为非特权应用提供某种功能，那么通过调用方法公开其功能的内容提供商是一个很好的选择，因为您不需要为其构建aidl文件或将该aidl分发给应用，应用程序也不需要绑定到您的服务，您不必担心生命周期，因为持久化进程永远不会消亡。

您可以检查调用方法中的权限，以确保应用程序声明自己。如果您的进程崩溃，那么它就不会取消整个system_server，当您转移到新版本的Android时，您不必弄清楚如何再次破解system_server。

Answer 4

它们非常不同。它们的高级差异是：

服务是一个应用程序组件，类似于没有UI的活动。您可以扩展它以在您的应用程序中创建您自己的服务版本。
系统服务是系统服务器的一部分。您需要修改AOSP以添加您自己的系统服务：提供其API类[MySystem] Manager，其实现类[MySystem] Service，其AIDL文件I [MySystem] Service.aidl等。然后，您可以通过调用Context.getSystemService（...）来访问它。

将它们两者都称为服务有点混乱。

Answer 5

下面是问题的答案，什么时候使用SystemService，什么时候使用Services 系统服务

SystemServices 在 SystemServer 进程下运行
如果服务与任何特殊的硬件组件相关，并且 API 将要公开
与 system_app 或 unknown_app 相比，SystemServices 具有不同的 Sepolicy，并且限制更少。
以上条件为真，那么您可以通过在 AOSP 中进行更改来创建 SystemService（正常 context.getSystemService(NAME) 也适用于自定义服务），或者您可以创建自己的应用程序，您可以在其中绑定到 Servicemanager 以下链接供参考 https://devarea.com/aosp-creating-a-system-service/#.YCV3t_nhXDf

服务

它是将在 mainThread 上运行的非 UI 组件。
如果需求范围只能在 APP 流程上下文中提供，那么这是进行更改的最佳位置。为什么要为每个小任务打扰 SystemServer。 :)

AOSP系统服务与服务差异

5 个答案: