F-Droid

[linsui]

请问可以打包发布到 F-Droid 吗？

[fumiama]

现在还远远没有完成，发上去感觉不是很合适。

[linsui]

这个应用完成度比 F-Droid 上一半的应用都要高 😂 。F-Droid 上每周都会有几个花了一天写出来的应用。

[fumiama]

好家伙，你打包需要重新签名吗？如果需要，更新就会有问题了。

[linsui]

F-Droid 用自己的密钥签名，更新会通过 F-Droid 的应用推送。不同渠道之间没办法更新。不过这个应用我看了一下应该没有需要打补丁的地方，所以可以试试可重复构建。如果 F-Droid 能构建出完全相同的 apk 就可以直接发布你签名的版本。

[linsui]

我试了一下可重复构建，得到的 apk 内容是相同的但是打包的文件顺序不一样。你的 apk 文件顺序是打乱的。如果你可以在打包的时候对文件排序应该就可以构建出完全相同的 apk 了。F-Droid 一般使用 disorderfs --sort-dirents=yes --reverse-dirents=no.

[fumiama]

我试了一下可重复构建，得到的 apk 内容是相同的但是打包的文件顺序不一样。你的 apk 文件顺序是打乱的。如果你可以在打包的时候对文件排序应该就可以构建出完全相同的 apk 了。F-Droid 一般使用 disorderfs --sort-dirents=yes --reverse-dirents=no.

为什么要相同呢，签名一样不就好了

[linsui]

F-Droid 中可重复构建是通过 apksigcopier 实现的，它将上游的 apk 中的签名部分直接复制到构建出来的 apk 文件末尾。因此 apk 必须完全一直才能验证安装。但 apk 中的内容顺序不一致会产生不同的 zip 文件，虽然大小和内容都一样，但 hash 值不同。

[fumiama]

这也太怪了😂要不你构建一下，我来签个名

[linsui]

😂 可以是可以，但这样就是每次都要麻烦你，没有办法自动更新。我用 GitLab CI 构建的 apk 在这。我认为比较好的办法是用 disorderfs 解决文件顺序的问题。

[fumiama]

我是用as构建出来的，理论上disorderfs也会改变zip的哈希，这样v2签名是失效的。只要签名相同就能随便覆盖了，我每次构建也并不是走actions自动构建，签名不会太麻烦。总之我先签名了一下，你看看可不可用。
top.fumiama.copymanga_23.zip
我已经把apk扩展名改为zip，你改回去即可。

[linsui]

这个签名文件用 zipinfo 查看，第五个字段是 bl，但我构建的和你之前发布的 apk 这个字段是 b-。不知道是什么原因，可能是因为扩展名改了一次？

       第五个字段包含了两个字符,它们中的每个都能取若干个值.第一个字符可能是`t'或者`b',相应地表示
       文件是文本的或者是二进制的;但是如果文件被加密,zipinfo  通过大写字符(`T'或者`B')来表示.第二
       个字符可以取四个值,它依赖于是否存在一个本地的头信息并且/或者一个和那个文件相关的 "额外" 字
       段(详细解释参看 PKWare's APPNOTE.TXT,它基本上类似于ANSI  C中的pragmas,它们提供了一种包含非
       标准信息的标准方法).如果两者都不存在,该字段为连字符(`-');如果有一个扩展的本地头信息但是没
       有额外字段,则为`l';反之为`x';如果都存在,则为`X'.这样上面示例中的文件(很可能)是一个未被加密
       的文本文件,并且没有额外字段和本地头信息与之相关联.下面的例子则是一个有额外信息的二进制文
       件.

[fumiama]

不过我这里是b-，那我再打包一层试试。
top.fumiama.copymanga_23.apk.zip

[linsui]

这三个是 b-，但大部分是 bl。但我构建的 apk 中所有文件都是 b-。很奇怪。

[fumiama]

这三个是 b-，但大部分是 bl。但我构建的 apk 中所有文件都是 b-。很奇怪。

我换了个签名命令试了试，现在应该可以了。
top.fumiama.copymanga_23.apk.zip

[linsui]

非常好，这次没问题了，谢谢！那么我们就先用这种方式？