Closed klzgrad closed 1 month ago
如果用户愿意是可以直接使用 naive 上游的构建版本的,这个是做了兼容的。以 naive 为例,会先寻找 android:host="io.nekohasekai.sagernet"
的插件,找不到再去寻找 android:host="moe.matsuri.lite"
的。
这里仅仅是重新构建一下,升级 Android 部分的依赖和 targetSdk 等,native 部分应该没什么区别。
那是否可以把这里发布的naive plugin合并到上游?好处:
@xchacha20-poly1305 如果要将 naive 官方发布的插件改成 SagerNet 兼容的(使用 android:host="io.nekohasekai.sagernet"
,android:authorities="io.nekohasekai.sagernet.plugin.naive.BinaryProvider"
)你怎么看?你对插件的可重复构建有兴趣吗?
以 naive 开发者的意愿为准。
可重复构建只要上游能实现,apk 应该不难。
所以现在的结论是,如果把naive上游发布的apk改成android:host="io.nekohasekai.sagernet",android:authorities="io.nekohasekai.sagernet.plugin.naive.BinaryProvider",就可以兼容Exclave和husi?
Exclave 和 husi 现在无需上游 naive 插件作出修改就是兼容的。如果作最小化的修改,把 android:host 和 android:authorities 修改为原始 SagerNet 的,那就可以兼容 SagerNet 本身以及其他基于 SagerNet 开发的软件(理论上;如果不故意写不兼容代码的话)。 比较完整的修改大概会像这样 https://github.com/klzgrad/naiveproxy/compare/master...dyhkwong:naiveproxy:master
另外 naive 二进制不能运行在 Android 6.0 及以前的设备上(模拟器测试),所以 minSdk = 24 应该是合理的。
感觉也没什么问题
于 2024年9月12日 GMT+08:00 19:11:08,klzgrad @.***> 写道:
https://github.com/klzgrad/naiveproxy/releases/tag/v128.0.6613.40-3
如何?
-- Reply to this email directly or view it on GitHub: https://github.com/dyhkwong/Exclave/issues/73#issuecomment-2346001287 You are receiving this because you commented.
Message ID: @.***>
io.nekohasekai.sagernet.plugin.naive
这个包名可能在不少地方上架/收录过,SagerNet 最后一个 Naive 插件的版本号是 155,我这里的版本号已经到了 275(出于不知道什么原因,SagerNet 插件每次版本号是 +5 的)。不知道某些应用商店会不会无脑提示更新。所以可能需要提升一下版本号,或者干脆换个包名?
能不能到https://github.com/klzgrad/naiveproxy/pulls 提一个PR?
因为不知道要改成什么包名和/或版本号,而且也就两行的事情,所以也不太好 PR。
这样改 就可以了,把 applicationId
替换为想要的包名。
app/build.gradle.kts: versionCode = System.getenv("APK_VERSION_NAME").removePrefix("v").split(".")[0].toInt()
改成
dottedVersion = System.getenv("APK_VERSION_NAME").removePrefix("v")
majorVersion = dottedVersion.split(".")[0].toInt()
releaseVersion = dottedVersion.split("-")[1].toInt()
versionCode = majorVersion * 10 + releaseVersion
https://github.com/klzgrad/naiveproxy/releases/tag/v129.0.6668.81-1 versionCode生效为1291
我觉得现在这个 issue 可以被关闭了?
我看到这里的commits里面还在不断的跟踪naive的上游版本。
但是上游已经构建了naive plugin apk,是否可以把这个版本跟踪的维护环节节约掉?另一个好处是减少核查供应链reproducible build的工作,见历史讨论。
当然因为历史原因,上游支持的provider是moe.matsuri.exe.naive。但兼容性应该不是一个大问题。