[Feature Request] 模块内配置的预配置与外部编辑

[jiwangyihao]

Is your feature request related to a problem?/你的请求是否与某个问题相关？

首先很抱歉提出重复的 Issue，但是在已关闭的 Issue 下留言大佬似乎不会看😂，总之请允许我重新介绍一下这个功能请求：

• 它的内容
• 它希望解决的问题
• 它有什么用

---

先从我遇到的实际问题开始讲起吧。我姑且算是一个模块开发者，之前因为苦于没有合适的修改应用内 DPI 的方案，于是就尝试开发了一个简单的模块『应用配置』，这个模块功能很简单，它会：

• 把应用内 DPI 修改为 189
• Hook 系统的获取应用列表方法并返回替代方法获取的应用列表（我使用的设备不开放读取应用列表的权限） 它在便携模式下工作的几乎完美，于是我在酷安上分享了这个模块

很快就有人问我是否可以加入自定义功能（自定义 DPI 的数值以及是否启用对应用列表方法的修改），尽管我觉得 DPI 189 对于那个设备（手表）来说是一个几乎完美的数值，修改应用列表的方法也没有什么明显的副作用，但作为我本来就打算做的东西，我也开始思考这个功能的实现方案。 在思考不同方案的时候，我发现，有一个需求无论如何都无法在现有框架下满足： 因为手表圈子里实际使用 XP 的人不多，同时手表也没办法解锁和 ROOT，再加上性能限制，『便携模式』就成了手表上使用模块的第一选择，更准确地说，是直接下载其他人已经做好了的嵌入过模块的应用成了第一选择。而事实上不论 DPI 的数值还是应用列表的修改与否主要取决于被修改的应用，对于同一个应用一个人觉得不错的 DPI 数值另一个人也不会觉得太差，至于对应用列表方法的修改与否就更不用说了，基本上不会有最终用户希望二次自定义。也就是说，与 QA 这样的模块不同，真正需要自定义功能的并不是那些『直接下载其他人已经做好了的嵌入过模块的应用』的最终用户，而是那些完成『修补应用』这一操作的『中间』用户。

所谓的『中间』用户是在过去的 xposed 环境中未曾出现的人，在过去，xposed 的使用主要涉及三部分人：

• 框架的开发和维护者
• 模块的开发和维护者
• 用户

而这些『用户』通常需要具备的能力包括：

• ROOT
• 安装并使用 xposed 框架
• 安装并使用 xposed 模块
• 自行调整模块的配置

而随着『便携模式』的普及，原来的用户变成了两类人：

• 中间用户
• 最终用户

中间用户主要是原来的用户，他们知道 Shizuku 的使用方法，对于 LSPatch 的使用得心应手，他们中的许多人不仅会自己使用，还愿意嵌入模块之后分享到像酷安这样的平台。 也正是这些中间用户大大拓展了原本的用户团体，让不会或者不能 ROOT、安装框架、安装模块的人也能轻松用上 xposed 模块，但同时也产生了新的问题：

『中间用户』在这个过程中起到了巨大的作用，但事实上他们只能简单地嵌入模块，不能进行任何进一步的调整，而能够进行调整的『最终用户』一方面大多缺乏相关的知识和经验，需要一个更加开箱即用的方案（也就是默认配置），另一方面事实上对于『中间用户』来说，提供一个默认配置也远比挨个解答不同用户的问题要轻松得多。

而对于通用类模块，比如『应用变量』来说，能够按照应用提供默认配置就意味着一个简单的应用修改器，而若是『SimpleHook』加默认配置，那更是意味着无限可能：简单的模块和传统的应用修改几乎完全可以被替代。

XP 模块的出现让过去的应用修改者可以通过模块的形式发布自己的修改，摆脱了『跟进更新』的需要； 而默认配置的出现不仅会让应用修改的发布变得更加便捷，也让更大范围的用户有了发布修改的能力，这将是一个会造成深远影响的功能，单单是当前我能想到的用途就已经足够具有想象力了，我相信大家会想出更有想象力的用法。

而考虑到实现当前数据的外部修改和预配置本身具有相当的共通性，所以在此一并提出，这个需求的作用才是用来增加过去开发的一些模块的可用性的，也就是所谓的可以通过『模块本身的适配』解决的问题。

Describe the solution you'd like/描述你想要的解决方案

在意识到问题后，我就在思考：什么样的功能可以实现解决这个问题，可以赋予『中间用户』更大的自由，思考后我的结论就是『预配置』，这首先是具有热情和动手能力的『中间用户』没有办法解决的，其次『预配置』这个功能也无法从模块的角度解决——『中间用户』操作的直接对象是 LSPatch 管理器，输入是宿主应用和模块，输出是嵌入模块的应用，而在嵌入模块的应用在正式被启动前模块无法进行任何操作，可等到应用被启动的时候，已经到达了『最终用户』的手中。

这种默认配置，必须也只能在应用被修补时提供，（在我的设想中应该）被存放在安装包中，就像 LSPatch 本身存放的关于签名破解和调试相关配置那样。

之后，不得不承认的问题就是——不同模块的配置保存方式可能天差地别。但是，我们并非没有一种比较标准、易用并且较为广泛地被许多模块所使用来存储配置的 API——XSharedPreferences。更好的是，XSharedPreferences 的索引的字符串类型也为手动编辑提供了更多可能。

在我的设想中，我们可以提供一种这样的功能：

• 首先，我们可以在管理器中加入一种类似编辑『环境变量』的功能来允许用户根据宿主应用和模块手动编辑模块的 XSharedPreferences 中的数据，同时还可以在修补应用时就提供其中数据的默认值；
• 其次，我们可以提供一种类似于 xposed 中用于描述模块信息的 API，以便模块可以向管理器描述自己所使用的数据的
  • 索引
  • 名称
  • 描述 这样就可以让用户更加简单地完成『手动编辑』这一操作
• 最后，当嵌有模块和默认配置的应用被更新时，对于相应数据的更新策略应该是：
  • 如果该数据未曾在安装后被编辑过（也即保持着最初安装时修补者设定的默认值），那么这种数据用户应当期待当自己更新了修补者的新版应用以后自动应用修补者设定的新的默认值；
  • 如果该数据曾经在安装后被编辑过，也即用户手动对此设定了新的值，那么这种数据用户应当希望继续保持自己的自定义设置。

大致上来说就是这样。

Additional context/其他信息

最后希望大佬不要急着关闭 Issue 😂

在写 Issue 的时候可能思路不够清晰，表达不够明了，但我确实认为这是一个很有意义的功能。（留着这个 Issue 也好让我提供进一步的说明啊😂）

[Howard20181]

为什么要让用户手动编辑XSharedPreferences，这并不稳定 你也说了并不是每个模块都用XSharedPreferences存储数据，提供这个功能会造成混乱

配置文件预置是模块的功能，应该开发模块的人处理

[jiwangyihao]

配置文件预置是模块的功能，应该开发模块的人处理

在说明中我有提到，这个预置是由『中间用户』提供的，因为对于特别是通用型模块来说，目标应用是不可知的，因此在模块开发时提供这样的预置并不可能

事实上正如我在说明中写的，这个功能的主要目的就是能让那部分有能力、乐意做更多并且已经做了很多的『中间用户』有更大的修改自由

而想要从模块角度实现让『中间用户』提供预置似乎也没有办法

这种默认配置，必须也只能在应用被修补时提供，（在我的设想中应该）被存放在安装包中，就像 LSPatch 本身存放的关于签名破解和调试相关配置那样。

[jiwangyihao]

并不是每个模块都用XSharedPreferences存储数据

关于这一点，事实上 LSPatch 现在的通用性也不足够高，我觉得这个功能能够对相当一部分模块生效就已经足够了

至于不稳定嘛，唔，（改改就稳定了嘛😂），我觉得作为一个比较进阶的功能，加上面对的本来就是有一定知识的『中间用户』，实际使用这个功能的人一定程度上对稳定性的容忍程度和处理能力都会更高一点吧

[jiwangyihao]

另外其实从需求上来说提供一个 API 让模块自己主动读取并处理默认配置似乎是更好的选择，但这意味着功能推出后支持的模块数量为 0，也很难说会很快有模块跟进这个功能，所以不如试着从已有的 API 入手，我是这样想的😂

[Howard20181]

这个算行为变更了吧，不能乱改 要做也要提升API版本，旧模块也不能用了

[jiwangyihao]

唔，行为变更吗，这倒确实没想到诶。

不过作为一个默认禁用的用户可选功能也不可以吗，而且虽然说是行为变更，但一来变更后的行为并不会影响模块本身的正常运行逻辑，二来这毕竟是用户选择的操作，出现不兼容也是可以尝试自行处理的吧

或者，嗯，提升 API 版本，但是在修补时加入『允许忽略模块对 API 版本的要求』这样的设置项怎么样？

[vvb2060]

要求模块开发者实现应用内的配置界面，参考哔哩漫游。如果不会的话，允许其它人修改模块apk。

[jiwangyihao]

@vvb2060 能不能仔细看下，请问在目前的框架下我作为一个模块的「开发者」如何允许负责嵌入模块和二次分发他们嵌入了模块的应用的「中间用户」为最终使用应用的「最终用户」提供预设的配置？

[vvb2060]

如果不会的话，允许其它人修改模块apk即可。

[vvb2060]

模块读取assets目录下文件内容。我相信修改apk里面的文本文件对用户不是麻烦事

[jiwangyihao]

@vvb2060 当然这可以一定程度上解决问题。。。事实上如果「LSPatch」坚持不做这个功能的话这就是我考虑的备选方案

[jiwangyihao]

但是如果可以的话我觉得这个功能还是应该由框架提供一个统一的方案会比较好

[vvb2060]

需求奇怪，并且付出和收获严重不对等，没兴趣搞

[jiwangyihao]

@vvb2060 如果确实不愿意搞的话也没办法。。。虽然确实觉得这个功能很有意义（毕竟事实上极大拓展了「中间用户」能做的事情）

能问下目前「LSPatch」的开发重心吗？