-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F-Droid #5
Comments
现在还远远没有完成,发上去感觉不是很合适。 |
这个应用完成度比 F-Droid 上一半的应用都要高 😂 。F-Droid 上每周都会有几个花了一天写出来的应用。 |
好家伙,你打包需要重新签名吗?如果需要,更新就会有问题了。 |
F-Droid 用自己的密钥签名,更新会通过 F-Droid 的应用推送。不同渠道之间没办法更新。不过这个应用我看了一下应该没有需要打补丁的地方,所以可以试试可重复构建。如果 F-Droid 能构建出完全相同的 apk 就可以直接发布你签名的版本。 |
我试了一下可重复构建,得到的 apk 内容是相同的但是打包的文件顺序不一样。你的 apk 文件顺序是打乱的。如果你可以在打包的时候对文件排序应该就可以构建出完全相同的 apk 了。F-Droid 一般使用 |
为什么要相同呢,签名一样不就好了 |
F-Droid 中可重复构建是通过 apksigcopier 实现的,它将上游的 apk 中的签名部分直接复制到构建出来的 apk 文件末尾。因此 apk 必须完全一直才能验证安装。但 apk 中的内容顺序不一致会产生不同的 zip 文件,虽然大小和内容都一样,但 hash 值不同。 |
这也太怪了😂要不你构建一下,我来签个名 |
😂 可以是可以,但这样就是每次都要麻烦你,没有办法自动更新。我用 GitLab CI 构建的 apk 在这。我认为比较好的办法是用 disorderfs 解决文件顺序的问题。 |
我是用as构建出来的,理论上disorderfs也会改变zip的哈希,这样v2签名是失效的。只要签名相同就能随便覆盖了,我每次构建也并不是走actions自动构建,签名不会太麻烦。总之我先签名了一下,你看看可不可用。 |
这个签名文件用 zipinfo 查看,第五个字段是 bl,但我构建的和你之前发布的 apk 这个字段是 b-。不知道是什么原因,可能是因为扩展名改了一次?
|
不过我这里是b-,那我再打包一层试试。 |
这三个是 b-,但大部分是 bl。但我构建的 apk 中所有文件都是 b-。很奇怪。 |
我换了个签名命令试了试,现在应该可以了。 |
非常好,这次没问题了,谢谢!那么我们就先用这种方式? |
可以,因为我也不是很经常发版😂之后有更新你可再在此issue提及。 |
可以把上面这个 apk 发在 release 里或者其他什么地方吗,这样就有一个有版本的稳定链接了。然后我可以在这个存储库里添加 fastlane 元数据吗?F-Droid 会从这里抓取应用描述。 |
你可以pr我看看,apk我已发至最新release |
请问设定页就是空的吗?还是要登录才有选项? |
空的,啥都没写( |
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/11199 MR 可以合并了,有什么需要补充的吗?比如捐款方式之类的。 |
没什么了,挺好的 |
谢谢,已合并,大概一周之内会发布。 |
我等会放readme |
新版本的 apk 文件还是乱序的。我用 AS 构建了一下并没有出现这种情况,或许是环境不同? |
不清楚,你试试v1 v2签名都选上呢 |
我构建的 apk 是未签名的。签名应该不影响文件顺序。我猜可能和文件系统操作系统什么的有关系。我只在 linux 上测试过。 |
很奇怪了😂,另外你写别急着更新,最近可能还有改动。 |
构建成功了,谢谢! |
没事👍 |
发布正式版后,似乎fdroid页面就没有更新,是因为正则没匹配上正式版的命名吗?😂 |
不是,只是 F-Droid 比较慢 🤣 应该快更新了。 |
好吧😂 |
更新了,网站还要等等。 |
ok |
7f5f183 里 |
|
我又发了一版,看看这次的情况吧😂 |
这个 cruncher 本身是不可重现的,它每次生成的图片都不太一样,所以启用之后多次构建会得到不同结果。可以直接把经过优化的图片提交到仓库里,然后关掉这个选项。 |
好,这次可以了,谢谢! |
好耶 |
2.3.1 构建失败,因为有 libjnidispatch.so 。可以直接用 jna 的 aar,这样应该也更方便。我用 aar 试了一下,发现你的 apk 是从 8206294 构建的。但我用相同的 commit 还是没有构建出相同 apk。https://gitlab.com/linsui/fdroiddata/-/jobs/6645094017 有什么工具链变了吗? 2.3.0 添加的增强数据访问应该是动态加载从 https://gitea.seku.su/fumiama/comandy 下载的库?是否可以直接打包到 apk 里?分 abi 打包成四个 apk 体积应该也可以接受。 |
我看看。
就升级了一下
不太想这么做,因为动态下载可以热更新。 |
试试2.3.2版本。 |
建议加上
|
我本来也想加,但是考虑了一下还是没加,因为如果真的有老版本的设备的话,我加这一行人家就安装不上了。但是实际上只要不打开我那个增强型的网络开关其实是可以继续用的。 |
那么老的设备真能用这个应用吗( 相比 2.3.1 体积居然还变小了 |
我有一个文石的电子书,就是安卓6的,但是32位,是armeabi😂。 |
https://gitlab.com/linsui/fdroiddata/-/jobs/6646968612 可重复构建失败了。.so 文件不一致应该是因为我没有装 ndk,但不知道 dex 文件为什么也不一致。另外你的 apk 不是从 tag 构建的,是因为先构建 apk 再打的 tag 吗? |
这个还能看出来吗?我确实是这样干的😂 |
Tag之前删过一次,现在最新这个是我又建的。 |
AGP 8.3 开始 git commit 会记录在 version-control-info.textproto 文件里,所以必须用相同的 commit 才能构建出相同的 apk,否则即使代码相同也不行。我想知道 apk 不一致有没有可能是因为你构建之后才提交的变更导致的。这个文件可以去掉,https://f-droid.org/docs/Reproducible_Builds/#%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6%E7%B3%BB%E7%BB%9Fvcs%E4%BF%A1%E6%81%AF 。 |
再试试吧😂 |
成功了,谢谢 👍 |
🤝🤝🤝 |
请问可以打包发布到 F-Droid 吗?
The text was updated successfully, but these errors were encountered: