chore: Add fastlane for F-Droid

[CynthiaArmstrong]

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.

[thisconnect]

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

[thisconnect]

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?

[CynthiaArmstrong]

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?

[CynthiaArmstrong]

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.

[linsui]

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.

[CynthiaArmstrong]

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//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?

[thisconnect]

#2020 (comment)

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

[thisconnect]

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?

[IzzySoft]

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" 🙈

what is Triple-T structure?

A little more complex, and linked from the snippet you've just linked:

For Triple-T, see this snippet

😉

[Beerosagos]

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.

[IzzySoft]

/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.

[CynthiaArmstrong]

/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.

Alright, I updated the location of the folder.

[IzzySoft]

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).

[linsui]

Not sure if metadata/android/en-US does work

It doesn't work.

[benma]

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?

[CynthiaArmstrong]

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?

[IzzySoft]

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) 😜 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.

[benma]

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

[IzzySoft]

Yes, that one fooled me initially 🙈

[CynthiaArmstrong]

Do you need anything from me before continuing with the merge?

[benma]

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?

[IzzySoft]

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 😉 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).

[IzzySoft]

all else LGTM 😉

[IzzySoft]

while 48x48 is technically OK (it's the bare minimum size), it might not look that good on higher resolution devices. Is there a larger variant available (up to 512x512 is permitted; 192x192 would be fine and at least 96x96 desirable)?

[CynthiaArmstrong]

I did not find it in 512x512 unfortunately. @benma, may you provide me with the icon as 512x512 PNG?

[IzzySoft]

It's not a deal breaker. As I wrote: 48x48 is the bare (accepted) minimum. If there's a better resolution, yes please. If not: 🤷‍♂️

[IzzySoft]

Original from Play 😜

[thisconnect]

If it should be round then the one you posted is fine (I think), but this was changed for the desktop app, see 55006ff

and the new desktop icon: https://github.com/digitalbitbox/bitbox-wallet-app/blob/master/frontends/qt/resources/app_icon_source.png

the source of the logo: https://github.com/digitalbitbox/bitbox-wallet-app/blob/master/frontends/android/icon_source.png

let me know if you need anything else.

[IzzySoft]

@thisconnect the one I just posted was taken from the app's listing at GooglePlay, so it should be the correct one for fastlane/metadata/android. But of course your choice, it's your app 😉

[CynthiaArmstrong]

Thanks @benma. I updated the graphic.

[thisconnect]

Either one looks good to me, but I don't know if it has to be round on Android, but this shouldn't be a blocker I guess, lets see if this works.

we'll still need to look into the size issue of the app #2020 (comment)

[IzzySoft]

I don't know if it has to be round on Android

AFAIK both are fine. Especially when it comes to Fastlane, which is just to represent the app in "listings". For "Android internals" (e.g. show the icon in the app drawer etc), Fastlane is not used. So IMHO the choice here is up to you. And as pointed out: that round one is what is used by your PlayStore listing, so it should be fine here as well.

we'll still need to look into the size issue

Yupp, please 😉 Per-ABI builds should take care of that I guess.

[benma]

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).

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 😇

[IzzySoft]

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.

[benma]

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 😄

[IzzySoft]

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 😃

[CynthiaArmstrong]

You may merge it now. 👌

[benma]

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? 😇 What is a pre-ABI build? I googled and could find much.

[IzzySoft]

What is a pre-ABI build?

A spelling error 🙈 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 😉

[thisconnect]

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

[IzzySoft]

That's about it, yeah. Single-digit percentage AFAIK. With my repo I only consider ARM (very few exceptions). The last graphs I saw was armeabi (32bit) still slightly ahead of arm64 – but whichever of the two you choose, someone will complain. The arm64 builds cannot be used on 32bit devices (yes, there are still some around – like the Fairphone 2 I use) – and the 32bit builds do not run on a few devices which are "64bit only" (in general, most 64bit devices also support armeabi).

32bit devices will "die out" sooner or later (ARM just announced their new chips will be 64bit only). I still stick with 32bit builds for some apps to support longevity: I want to support people using their devices as long as possible, to help avoiding unnecessary "electronic waste". But if there are sufficient alternatives for an app (and there are several wallet apps around), I guess picking arm64 is the better choice. Decision is yours, though 😉

[CynthiaArmstrong]

Are you interested in continuing? 😅

[benma]

@CynthiaArmstrong I am afraid we don't have the resources to dedicate to this for the time being, unless our current releases or codebase (including this PR) can be used downstream for F-Droid releases as-is without any more changes/effort. We unfortunately don't have the resources to change our release process, as there are many other priorities we are focusing on.

[IzzySoft]

@benma maintenance required for this after the merge is almost negligible. Sure, you can add per-release changelogs each time you release a new version, but that's optional. The only thing to keep in mind is keeping description and screenshots matching the actual version of the app. But honestly, that's manageable; changes so drastic that updates are needed to that are rare. And if such happen, you'll want desc+pics updated – no easier way than doing that in the fastlane structure, which then gets picked up automatically.

And those per-release changelogs are quite helpful in cases where those using your app should take cautions before updating, as those changelogs are shown right next to the app description. So you could make use of them when needed and skip them otherwise.

[IzzySoft]

LGTM; I'd only remove 41.txt but that's up to you.

[IzzySoft]

Maybe remove 41.txt unless it's really the "initial release". It's probably not the latest one either, so nobody'll see it anyway, with build.gradle having 45 right now.

[benma]

@IzzySoft I was more referring to the effort related to splitting the APK (i.e. change our build processes), testing that each works, building and releasing for multiple Android architectures, etc.

[IzzySoft]

That should not keep you from merging Fastlane I guess?

[benma]

As mentioned in #2020 (comment), I prefer not to merge it unless it will be used in practice, otherwise it becomes purely a maintenance cost with no benefit.

[IzzySoft]

BTW: Scan results for the APK from the currently latest release look fine:

Libraries detected:
-------------------
* Android Support v4 (/android/support/v4): Development Framework, Apache-2.0
* Android Jetpack Annotations (/androidx/annotation): Utility, Apache-2.0
* Arch (/androidx/arch): Utility, Apache-2.0
* AppCompat (/androidx/appcompat): Utility, Apache-2.0
* Asynclayoutinflater (/androidx/asynclayoutinflater): UI Component, Apache-2.0
* Android Support Library collections (/androidx/collection): Utility, Apache-2.0
* Constraint Layout Library (/androidx/constraintlayout): Utility, Apache-2.0
* Coordinatorlayout (/androidx/coordinatorlayout): UI Component, Apache-2.0
* Androidx Core (/androidx/core): Utility, Apache-2.0
* AndroidX Cursor Adapter (/androidx/cursoradapter): Utility, Apache-2.0
* Android Support Library Custom View (/androidx/customview): UI Component, Apache-2.0
* Documentfile (/androidx/documentfile): UI Component, Apache-2.0
* Drawerlayout (/androidx/drawerlayout): UI Component, Apache-2.0
* AndroidX Fragment (/androidx/fragment): UI Component, Apache-2.0
* Interpolator (/androidx/interpolator): UI Component, Apache-2.0
* androidx.legacy (/androidx/legacy): Utility, Apache-2.0
* Lifecycle (/androidx/lifecycle): Utility, Apache-2.0
* Loader (/androidx/loader): Utility, Apache-2.0
* AndroidX Local Broadcast Manager (/androidx/localbroadcastmanager): Utility, Apache-2.0
* Print (/androidx/print): Utility, Apache-2.0
* Slidingpanelayout (/androidx/slidingpanelayout): UI Component, Apache-2.0
* Swiperefreshlayout (/androidx/swiperefreshlayout): UI Component, Apache-2.0
* Vectordrawable (/androidx/vectordrawable): UI Component, Apache-2.0
* Android Jetpack VersionedParcelable (/androidx/versionedparcelable): Utility, Apache-2.0
* Viewpager (/androidx/viewpager): UI Component, Apache-2.0

No offending libs found.

Split-APKs would be welcome of course, but at least for F-Droid.org would be not "mandatory" (for my repo, the size is quite on the "red line", though): it's beyond the 30 MB "soft limit" and scratching on the 32 MB limit of one of the APIs I use.

And as I said: I don't see any maintenance cost – though I get what you mean. But with fastlane available, @CynthiaArmstrong could reach out to F-Droid with an RFP (request for packaging), as at least my library scanner sees no show stoppers (no guarantee F-Droid's code scanner might find one, though).

[benma]

There was the issue about how we can't get into F-Droid because we bundle the BitBox02 firmware binaries.

#2020 (comment)

Did something change?

Are there other requirements? The BitBoxApp binaries are afaik not reproducible, would that be a blocker?

[thisconnect]

There was the issue about how we can't get into F-Droid because we bundle the BitBox02 firmware binaries.

In an email I got firmware binary errors, ping me if I should forward it. Probably because I am subscribed to the RFP GL issue

[IzzySoft]

because we bundle the BitBox02 firmware binaries

Ah – that's not covered by my scanner indeed. My scanner only sees the resulting APK and thus what got there. F-Droid looks at the source tree and thus sees how it will get there.

Well, no: nothing changed regarding that. F-Droid will still insist to build from source (or pull from a Maven repo it trusts. And I'm afraid there's no such Maven shipping those binaries – and neither you can provide the source code to build them from 😢

The BitBoxApp binaries are afaik not reproducible, would that be a blocker?

If F-Droid can build them, but not reproducible? No, that IMHO would not be a blocker. As long as the process then produces an APK that works as expected. If you use the same approach for your builds, that APK might even be reproducible (so F-Droid then would ship it with your signature) – but even that is not mandatory, though strongly suggested.

[thisconnect]

and neither you can provide the source code to build them from 😢

probably I am misunderstanding you, but here we provide:

• firmware source code: https://github.com/digitalbitbox/bitbox02-firmware
• firmware reproducible build instructions: https://github.com/digitalbitbox/bitbox02-firmware/blob/master/releases/README.md

[IzzySoft]

@thisconnect Thanks! In that case: @linsui can you have a look if that could be integrated with a build recipe, and what would be needed for it (e.g. git submodules, or srclibs) – in a way it works out for F-Droid buildservers?

[CynthiaArmstrong]

Awesome, I am so glad to see progress here. 😊

[linsui]

It's possible but I don't know if we can build it reproducibly since we don't use docker. We can have a try.