revtutorials

> 我想问下如果上架的话，签名及更新有什么解决方案？ 签名应该是没什么问题的，因为这份源码总归是可以自己编译的。我认为可以直接在选框加上一些文字说明：“如果你是从F-Droid上安装本软件，那么请不要在这里更新，请在F-Droid应用商店内获取更新”

> > 签名应该是没什么问题的，因为这份源码总归是可以自己编译的 > > 看文档不是F-Droid那边会重新编译源码吗？这样的话签名就会不一样，除非从releases同步过去。 更新的问题如果没有其他好的办法那就把F-Droid搬放到另一个分支上，类似墨状态栏版 如果能另开个分支当然是最好的。这样就可以去除自动更新功能而只留下更新提示。只是我个人比较担心各位开发者没有精力（或者意愿）维护两个分支或者难以移除自动升级功能的实现。我本人只是个用户，是不知道怎么处理这些 Java 的，所以也没有主动提 PR 的能力。这样就只能增加大家的工作量了。 我现在主要是希望它能够快些得到收录，以待后续处理问题。当然它们如果在一个仓库，那确实也难以解决很多不可调和的矛盾。如果愿意另开一个官方分支的话，我可以修改收录的请求，重运行 issuebot 或把原收录请求 issue 给 close 掉，然后再开一个新的。

> 这个改动看起来不是很多，可以类似墨状态栏歌词的分支那样，现在要确认的是要做哪些功能上的修改 那可不可以合并一下

> 随意，我不反对上架这个商店，但看起来是使用新的签名构建，会导致签名冲突，需要有个方式识别并禁用内置更新机制 感谢您的支持！如果它真的进入了F-Droid的仓库，就可以去考虑这样的机制了。

已经做好了。你可以[过目](https://gitlab.com/fdroid/rfp/-/issues/2855)。

有一个重要问题。 > 在您的存储库中找不到 Fastlane！ 如果没有Fastlane，如果不通过 F-Droid 团队，就不可能有应用屏幕截图，并且无法更新应用描述，从而导致不必要的延迟。 强烈建议在您的存储库中建立 Fastlane。 [在Repo中使用Fastlane的方式](https://docs.fastlane.tools/getting-started/android/setup/) F-Droid 不需要完整的 Fastlane，它只需要一个 有内容的 Fastlane 目录即可。https://gitlab.com/-/snippets/1895688 我给你提一个PR

> #228 这是之前的讨论。 > > https://github.com/lyswhut/lx-music-mobile?tab=readme-ov-file#%E9%A1%B9%E7%9B%AE%E5%8D%8F%E8%AE%AE 协议有附加条款。**这个条款附加在 Apache-2.0 上就构成新的协议了。** > > > 感谢您的支持！如果它真的进入了F-Droid的仓库，就可以去考虑这样的机制了。 > > F-Droid 要求自动更新默认禁用，或者启动时要求用户选择。总之需要用户明确选择启用自动更新。 > > > 随意，我不反对上架这个商店，但看起来是使用新的签名构建，会导致签名冲突，需要有个方式识别并禁用内置更新机制 > > 如果启用可重复构建可以使 F-Droid 发布相同签名的 apk。 那我听一下管理员怎么说吧（至少我在初次发布的时候是得到允许的）。我个人认为这个24小时内删除的协议似乎有些苛刻。而且这个附加的协议是要使用即同意的（而不是关于再发布的授权，开源协议应该是着眼于此的），它同EULA没有什么区别。市面上好多自由软件都有它的（为了排除责任的）使用条款EULA以及隐私条款（比如红帽[EULA](https://www.redhat.com/licenses/Red_Hat_Gplv2_Based_EULA_APAC_Chinese_20200504.pdf)），它们没有被标记为开源许可，因为这些许可是同再分发没有关系的。 --- 我不确定这一协议如果影响再分发的话，是否还符合自由软件的协议。详见：https://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicenses...