基于 APK 与基于服务的插件答案

【问题标题】：APK based vs. service based plugins基于 APK 与基于服务的插件
【发布时间】：2017-07-18 03:14:14
【问题描述】：

我现在正在考虑重新构建一个基于库的 Android 应用程序，这样我就不会在构建时提供每个库的功能（仅限于我的扩展），而是提供一个基础应用程序和一个 SDK，以允许任何开发者都可以独立编写插件。

我在 Android 上找不到很多方法来实现这一点（与支持独立 DLL 的 .NET 的 Unity 依赖注入框架不同）。我发现的是：

我的问题是：是否有其他方法可以做到这一点？（注意：Google Play 服务条款中合法的方式）

另外，在您看来，我上面列出的两种方法中哪一种更好？

【问题讨论】：

1 和 2 是不可分割的，因为没有 APK 就无法获得服务。任何 IPC 选项（活动、服务、接收者、提供者）都可以构成插件系统的一部分。
谢谢，但为什么要投反对票？这不是一个无知的人可以提出一些无知的问题的地方吗？ :) 请发表您的评论作为答案，我会接受。谢谢。
“但为什么要投反对票？” - 我没有否决这个问题。如果我不得不猜测，那是因为您引用了 Play 商店的 ToS 和 questions about app distribution channels are considered to be off-topic。此外，“上级”意味着征求意见，这也被认为是题外话。
@CommonsWare 感谢您的解释。我不知道你描述的SO规则，所以从现在开始我会小心不要重复这些错误，

【解决方案1】：

一般来说，如果一个应用会接受来自其他开发者的某种插件，这些插件会以 APK 文件的形式分发，无论是通过 Play 商店还是通过其他渠道。例如，这些插件可能需要与您不同的权限，并且只有当它们是 Android 设备上的一等公民时才能实现。

因此，插件只是通过一些记录和支持的 IPC 机制与您的应用程序交互的其他应用程序。四大 Android 组件——活动、服务、接收者和提供者——都可能与插件相关。这实际上取决于您希望插件做什么以及插件需要您的应用程序做什么才能做到。在摘要中，我们无法告诉您使用哪一个。

就个人而言，如果我要做这种事情，我会编写基本应用程序以及至少三个插件。编写这些插件时“吃你自己的狗粮”的行为将有助于指导您了解需要哪些 IPC 机制。即使最终您将插件的功能直接嵌入到主应用程序中，拥有“真正的”插件也将有助于塑造您的 SDK、您的安全模型等。

【讨论】：