add fastlane for F-Droid

[ErBWs]

按推荐把 flutter 作为 submodule 添加到仓库里，然后 F-Droid 在构建的时候用 submodule 的 flutter 进行编译

理论上应该把 workflow 的 flutter 也换成 submodule 的 flutter，但是本地 IDE 显示未正常安装无法配置，我就先没改

版本号的 +1 应该没有什么用处，F-Droid 靠这个版本号判断更新，我就删掉了

不过具体更新机制不知道是什么

剩下的就是要在 Gitlab 里面对 fdroiddata 仓库提一个 merge request，那个还没写

就是这个文件：https://gitlab.com/ErBWs/fdroiddata/-/blob/io.github.Predidit.Kazumi/metadata/io.github.Predidit.Kazumi.yml

[Predidit]

超棒的工作

不过版本号中的 +1 不能删去

这是 msix 构建中要求的版本号的第四位

删去会使 windows 的发布流程失败

[ErBWs]

原来如此

[Predidit]

另外直接将 flutter 作为 submodules 引入主线仓库是最佳实践吗。

我注意到其他有发布到 F-Droid 的 app 没有这么做，例如 pilipala。

这也让我们失去了对 flutter 版本的控制。

[ErBWs]

flutter 版本通过控制 submodule 的 commit 进行

目前 channel stable 最新 commit 就是 3.27.1

这是我参考的 MR 中官方人员给出的建议，如果不用 submodule 的话就需要每次更新 flutter 版本都要对 fdroiddata 仓库提交一次 MR

[Predidit]

我们能否移动 .flutter 文件夹到 fastlane 目录下, 这只和 F-Droid 构建相关，并且在根目录下可能会造成一些不必要的误解

[ErBWs]

理论上可以。

我一开始想的是把 workflow 的 setup flutter 修改为使用 submodule 而不是 action 来保持统一，F-Droid 通过对比它们构建的和 GitHub action 构建的 apk 文件是否一致来决定是否要重新签名

另外或许可以更新一下 README 中的截图

[Predidit]

我们可以先保留这种不一致并移动 flutter submodules 的位置，这能让本地工作环境和 workflow 保持一致

如果后续有需要我们可以再更改 workflow

我们确实应该更新 README 截图了，在尝试上架 F-Droid 的过程中一定会有一些截图，你有兴趣一并更新吗

[ErBWs]

OK，晚点修改

[ErBWs]

@Predidit 现在貌似有两个问题

1. fdroid 需要含有 fastlane 文件夹的工程，也就是这个 PR 合并后的工程文件，但是与 1.5.1 release 的 apk 二进制文件会有不同，对比失败，需要等下一次 release
2. fdroid 编译出来的产物貌似不含有签名，我不清楚这是哪里出了问题

相关链接：MR, Gitlab Pipeline

这是 1.5.1 release 的签名

MBP :: ~/Downloads » apksigner verify --print-certs Kazumi_android_1.5.1.apk | grep SHA-256
Signer #1 certificate SHA-256 digest: f4633dcf19ca0ccac7e730c57124a7acca57ce52b87913f9620d6bb718551d98

这是 Gitlab Pipeline 编译产物的签名

MBP :: ~/Downloads » apksigner verify --print-certs com.predidit.kazumi_2001.apk | grep SHA-256
DOES NOT VERIFY
ERROR: Missing META-INF/MANIFEST.MF

[Predidit]

我不了解 F-Droid 的工作方式，可能帮不到你

[ErBWs]

给打了个 non-free tag。是因为限制第三方商业化？

[ErBWs]

@Predidit 所以他认为这句话违反了 GPL-3.0 的协议

[Predidit]

理论上这个条款就是违反 GPL3.0 协议的，我来删去它

[ErBWs]

[Predidit]

也移除了，不过上架 oneAnime 是以后的事情了

[ErBWs]

@Predidit 看起来 F-Droid 需要配置 android/app/build.gradle 中的安卓签名

[Predidit]

听上去这意味着我们要公开当前签名？

[ErBWs]

当前签名是 signingConfig signingConfigs.debug，不被认为是有效签名，貌似需要用 GitHub secrets 存储签名文件，或许可以参考一下 pilipala 的办法？

signpath 可以 sign 安卓吗？

[Predidit]

我们的签名本来就在 Github secrets

参考 release workflow 中 sign APK 的部分

signpath 不能签 apk

[ErBWs]

这是 pipeline 的 log

==== detail begin ====
signature copying failed: APK Signing Block offset < central directory offset
Comparing reference APK to unsigned APK...
Unexpected diff output:
Only in /tmp/tmpw6hg07aj/tmp_binaries_com.predidit.kazumi_2001.binary/content/META-INF: ANDROIDD.RSA
Only in /tmp/tmpw6hg07aj/tmp_binaries_com.predidit.kazumi_2001.binary/content/META-INF: ANDROIDD.SF
Only in /tmp/tmpw6hg07aj/tmp_binaries_com.predidit.kazumi_2001.binary/content/META-INF: MANIFEST.MF
Binary files /tmp/tmpw6hg07aj/tmp_binaries_com.predidit.kazumi_2001.binary/content/lib/arm64-v8a/libapp.so and /tmp/tmpw6hg07aj/tmp_com.predidit.kazumi_2001/content/lib/arm64-v8a/libapp.so differ
Binary files /tmp/tmpw6hg07aj/tmp_binaries_com.predidit.kazumi_2001.binary/content/lib/arm64-v8a/libmpv.so and /tmp/tmpw6hg07aj/tmp_com.predidit.kazumi_2001/content/lib/arm64-v8a/libmpv.so differ
==== detail end ====

https://github.com/obfusk/apksigcopier#what-does-the-apk-signing-block-offset--central-directory-offset-error-mean

看来我理解错了，大概是 apk 不一致导致的签名复制失败，看起来还是需要等 1.5.2 发布再推进 MR 了

[Predidit]

libapp.so 是项目 dart 代码的编译产物
libmpv.so 刚刚完成版本迭代

这两个库校验不通过符合预期

此外 libflutter.so 没有出现在报错中，它是 flutter 引擎的编译产物，只和 flutter 版本相关。如果它的校验通过了，在迭代版本后，剩下的两个 .so 应该也能校验通过

也许我们应该看看剩下三个报错

[Predidit]

@ErBWs

我大概看了一下上面的链接，似乎在 1.5.2 发布之前，我们的 relsease workflow 似乎需要调整

1. 文档中提到向 F-Droid 提交的 apk 需要是未经签名的，我们是否需要发布未签名 apk 来符合其要求
2. 我看到我们的提交中似乎启用了所有的架构，但我们目前只发布 armv8 架构的 apk ，这是否需要调整

[ErBWs]

1. 我们提交的应该是签名后的 apk，这样 f-droid 就可以复制签名进行发布
2. 现在 mr 提交的也是 armv8 版本，可以提交多个版本也可以只提交一个版本

你可以直接在那个 mr 中向他们的开发者提问，他们会给出他们的推荐，我也只是根据过往 mr 进行猜测

[ErBWs]

也许我们应该看看剩下三个报错

剩下三个报错应该和签名相关

[Predidit]

好的，感谢你的回答

除了 .so 之外的三个报错需要我们处理吗

[ErBWs]

我想至少目前不需要，这应该是没能成功复制签名导致的

[ErBWs]

@Predidit 坏消息，Pipeline 以一模一样的原因又 fail 了

[Predidit]

QWQ

可重复构建是必须的吗

[ErBWs]

不是必须的，这只是 F-Droid 的推荐

[ErBWs]

好消息，F-Droid 构建成功了，不过我们可能需要修改一下 versionCode 来解决自动检测更新的问题，正在等回复