BitBoxSwiss
chore: Add fastlane for F-Droid
F-Droid uses the information in the fastlane folder to show metadata like description, screenshots and changelogs to its users.
This PR includes everything that is necessary. Optionally the featureGraphic.png could be more beautiful. I took it from Google Play. The icon.png could be 512x512px.
This was discussed in #1171.
could you update the commit body describing why this change is necessary
i.e. I copied this for you, but am not sure if there is another reason:
maintain summary/description/screenshots in your app's repo and will not need to open MRs each time you change them
see also: https://github.com/digitalbitbox/bitbox-wallet-app/blob/master/CONTRIBUTING.md
F-Droid definitely needs a fastlane structure for the metadata like descriptions and screenshots. Should I open a PR for that?
Is there anything else that will be needed?
that page also mentions tvBanner.png is this optional?
could you update the commit body describing why this change is necessary
i.e. I copied this for you, but am not sure if there is another reason:
maintain summary/description/screenshots in your app's repo and will not need to open MRs each time you change them
see also: https://github.com/digitalbitbox/bitbox-wallet-app/blob/master/CONTRIBUTING.md
I don't think that there is another reason. Theoretically you could use fastlane for automating many things but F-Droid just needs it for the metadata. Am I wrong, @linsui?
F-Droid definitely needs a fastlane structure for the metadata like descriptions and screenshots. Should I open a PR for that?
Is there anything else that will be needed?
that page also mentions tvBanner.png is this optional?
Yes, that's optional. I suppose this PR is 100% sufficient for F-Droid.
Yes, F-Droid only needs the metadata. The fastlane structure must be put in the root path currently. You can use the Triple-T structure instead if you don't want to put it in the root path.
Yes, F-Droid only needs the metadata. The fastlane structure must be put in the root path currently. You can use the Triple-T structure instead if you don't want to put it in the root path.
@IzzySoft wrote on GitLab:
It needs to be in document root (or alternatively in /src/<buildFlavor>/fastlane/metadata/android/ if you need to cater multiple flavors).
Can we go that way or is the root path needed? Would that be an issue for you, @thisconnect?
https://github.com/digitalbitbox/bitbox-wallet-app/pull/2020#issuecomment-1476669596
could you add this to the git commit body message? see also: https://github.com/digitalbitbox/bitbox-wallet-app/blob/master/CONTRIBUTING.md
maintain summary/description/screenshots in your app's repo and will not need to open MRs each time you change them
Can we go that way or is the root path needed?
I think ideally it would be somewhere in https://github.com/digitalbitbox/bitbox-wallet-app/tree/master/frontends/android cc @Beerosagos wdyt?
is this the fastlane https://gitlab.com/-/snippets/1895688 docs?
what is Triple-T structure?
I think ideally it would be somewhere in master/frontends/android cc @Beerosagos wdyt?
That won't work as F-Droid's build process would not find it there. It's only looked for in the standard locations, as pointed out. And btw, /frontends/android/fastlane/metadata/android just looks a bit weird, doesn't it? Two times Android. And it looks even weirder should you add iOS support: /frontends/android/fastlane/metadata/ios, the apple fans would send a lynch-mob being "put under Android" :see_no_evil:
what is Triple-T structure?
A little more complex, and linked from the snippet you've just linked:
For Triple-T, see this snippet
:wink:
I think ideally it would be somewhere in https://github.com/digitalbitbox/bitbox-wallet-app/tree/master/frontends/android cc @Beerosagos wdyt?
Agree. Our tree is probably a bit unusual compared to most pure mobile apps, but /frontends/ folder would be the best place for it, imho. If this is not possible maybe /metadata/<locale>/? I would definitely avoid something in /src since that would be misleading.
/metadata/<locale>/ would indeed work (a side-effect as that reflects F-Droid's internal structures). It's not a "full fastlane structure" then – but if you don't plan using something like fastlane supply that should not matter.
/metadata/<locale>/would indeed work (a side-effect as that reflects F-Droid's internal structures). It's not a "full fastlane structure" then – but if you don't plan using something likefastlane supplythat should not matter.
Alright, I updated the location of the folder.
Not sure if metadata/android/en-US does work, but you can try. AFAIR it's either fastlane/metadata/android/en-US (fastlane format) or just 'metadata/en-US` (F-Droid internal structure).
If I interpret this correctly, fdroid would reject this because of the bundled BitBox02 firmware. If that is correct, we can't proceed here, right?
If I interpret this correctly, fdroid would reject this because of the bundled BitBox02 firmware. If that is correct, we can't proceed here, right?
I'm not 100% sure, @benma, but I fear so.
But you may merge this PR anyways and @IzzySoft could put it in his private repository perhaps?
and @IzzySoft could put it in his private repository perhaps?
Luckily it's not "private" (only visible/accessibly by myself) but "personal" (run by me) :stuck_out_tongue_winking_eye: But then, I see no APK at the releases which I could pick. And seeing the size of the *.exe there I need to mention the size limit in my repo (30 MB per app). Apart from that: yes, in my repo that would just mean the NonFreeDep (currently; later, once implemented, it would be NonFreeComp aka contains a non-free component instead of the work-around depends on a non-free component which is not included).
Update: ah, there's just no APK at the latest release. Hm, so it's just slightly over the limit. And that could be mitigated by having an "ARM only" build, leaving out the (rarely used) x86 which could still be available with the "fat build" or a separate "x86 only". Yes, in that case I could take it into my repo then.
But then, I see no APK at the releases which I could pick.
If you are talking about BitBoxApp v4.36.1: that was a hotfix to the Windows release. 4.36.0 is the latest Android release
Do you need anything from me before continuing with the merge?
As far as I understand we can't get into fdroid because of the firmware binary that is still bundled in the app. I guess it does not make sense to merge before there is a clear path to inclusion/publishing?
I guess it does not make sense to merge before there is a clear path to inclusion/publishing?
Depends on what sense you're looking for :wink: First, it doesn't hurt – and second, you could use the very same metadata for listing in other places, as Fastlane is considered quite standard. For example, fastlane supply even directly supports publishing on PlayStore and AppleStore (though that might need the structure to be slightly changed, see my Fastlane Cheat Sheet).
I guess it does not make sense to merge before there is a clear path to inclusion/publishing?
Depends on what sense you're looking for wink First, it doesn't hurt – and second, you could use the very same metadata for listing in other places, as Fastlane is considered quite standard. For example,
fastlane supplyeven directly supports publishing on PlayStore and AppleStore (though that might need the structure to be slightly changed, see my Fastlane Cheat Sheet).
Maybe I am missing something. The point of this PR was to get into F-Droid. Is that possible? If not, then the PR is not needed, unless there are plans to use it for other repos. Merging it without using it in practice does not make sense to me, it would just become a maintenance burden then without any benefit. You mentioned PlayStore, but the BitBoxApp is already there.
But you may merge this PR anyways and @IzzySoft could put it in his private repository perhaps?
What is that private repository and how does it relate to F-Droid? Sorry again, I am quite uninformed about the F-Droid ecosystem :innocent:
What is that private repository and how does it relate to F-Droid?
OK, full disclosure: it's my repo – and I'm one of the F-Droid maintainers. My repo currently is the largest 3rd-party F-Droid repo (and the second largest after F-Droid's own), with more than 1k apps listed, having a little less strict inclusion criteria. It often serves as stepping-stone for apps not yet fully ready to meet F-Droid's inclusion criteria, but also has it's "permanent residents".
You can read more about it here.
What is that private repository and how does it relate to F-Droid?
OK, full disclosure: it's my repo – and I'm one of the F-Droid maintainers. My repo currently is the largest 3rd-party F-Droid repo (and the second largest after F-Droid's own), with more than 1k apps listed, having a little less strict inclusion criteria. It often serves as stepping-stone for apps not yet fully ready to meet F-Droid's inclusion criteria, but also has it's "permanent residents".
You can read more about it here.
Nice! So if we merge this PR you can add it to your repo - i.e. it is also a per-requisite for that? If so we will go for it :smile:
So if we merge this PR you can add it to your repo - i.e. it is also a per-requisite for that?
That should be easily achievable. Let me perform a quick check… OK, my library scanner confirms there are no stoppers from that end. Which leaves the size limit, which your APK is slightly above. Could you provide per-ABI builds? Then I could pick one of those (you'd name if it should be armeabi which is supported by most devices, or rather arm64 which supports only 64bit devices but including those 64bit-only; as long as the versionCode of the latter is always equal or higher than that of the former, we could also start with armeabi now and switch to arm64 later).
For the full inclusion criteria of my repo, you can find them here. And yes, with the size question solved (and this PR merged), your app would meet those :smiley:
For the full inclusion criteria of my repo, you can find them here. And yes, with the size question solved (and this PR merged), your app would meet those smiley
Nice! In your link it says
IzzyOnDroid usually reserves up to 30 megabytes per app (exceptions are being made for larger apps, so this is considered as rule-of-thumb).
Maybe this could be such an exception? :innocent: What is a pre-ABI build? I googled and could find much.
What is a pre-ABI build?
A spelling error :see_no_evil: should read "per ABI build". I.e. separate APK files per architecture, like one for armeabi another for arm64, and so on. Guess that would be this, but I'm no Android dev…
// Specifies a list of ABIs for Gradle to create APKs for.
include("x86", "x86_64")
So you could first try with 2 APKs, one with both x86 (which I'd ignore) and one with both arm (which I'd take if it fits). If that still gets to big, we'd really need the one you want me to pick as separate build. But I rather guess that include line means "build one APK for each of these ABIs", so the try with "2 APKs" won't be available (and you'd have to include all ABIs here). Let me know then which one to pick.
Maybe this could be such an exception?
Haha, nice try – but no. We still have the option of separate APKs fitting into that limit, so we should use that first. There must be much better reasons to make an exception :wink:
do we have stats on % of Android x86 users? here I read "only a very limited number of devices, like Asus Zenfone 2, Genymotion/ Android emulator " use x86
https://android.stackexchange.com/questions/186334/what-percentage-of-android-devices-runs-on-x86-architecture