ukanth
[ISSUE] v3.6.1 not available in F-Droid store (build fails)
Describe the bug The version v3.6.1 of afwall is not available in the F-Droid store. An auto updater updated it (see MR/commit), but the build failed (see logs) and an maintainer from f-droid just disabled the new version (see commit).
I doubt I can support f-droid builds anymore. Building these binaries using their infra is harder. I added support of building binaries using github. If they allow supporting pre-built binaries from github, then I can fix it.
Maybe with a Own F-Droid Repository than we can added this as separated or @IzzySoft https://apt.izzysoft.de/fdroid/index/info can added this to his own.
Or he @IzzySoft https://github.com/IzzySoft supported you for adding for his Repository!
Actually we have only Google Play Store/Aurora Store for your App included Updates/Update Functionality!
And only Google Play Store to https://github.com/ukanth/afwall/issues/1432 for buying the Donated Version or the Donated License to Unlock this in the Main App!
I don't know is F-Droid supporting pre-built binaries from github. A Developer or others Experts can speak more about this.
I don't know is F-Droid supporting pre-built binaries from github.
It does not. What binaries are we talking about? We could take a look whether we can take it in to our repo. APK size fits, scanner results are mostly OK (the Locale plugin would raise NonFreeAdd maybe) – only this one should preferably be addressed with the next release:
SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)
Easily done by adding a few lines to build.gradle:
android {
dependenciesInfo {
// Disables dependency metadata when building APKs (for IzzyOnDroid/F-Droid)
includeInApk = false
// Disables dependency metadata when building Android App Bundles (for Google Play)
includeInBundle = false
}
}
For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.
Ah, I see the binaries directory. Where do those binaries originate? I see there is a build-binaries.yml for a Github action. So maybe git clone › rm -f binaries/* › run build-binaries workflow › run android workflow should produce the (hopefully identical) APK? But would that even be needed? I don't see e.g. the busybox binary in the APK.
Maybe @ukanth its Izzy's Answer helpful for you or you are talking about the adding/Update Process.
or you are talking about the adding/Update Process
Just saying: should those binaries not be needed to build the APK (as I wrote, it seems they are not included), adding AFWall to IzzyOnDroid should be easy, and (hopefully) straight forward.