Using tags

[IzzySoft]

May I recommend you using tags for your releases? That brings several advantages:

• one can clearly see when there's a new release (and thus makes updates easier)
• the APK could be attached to it instead of sitting inside the repo, making the repo lighter (think of collaborators)
• the app could be brought to F-Droid (if you remove fabric, or make a build flavor that comes without it; currently, it is available in my repo thanks to your providing the APK – F-Droid would build it from source)

What do you think?

[azizkayumov]

Thank you for your interest. I have just released it on Github, may I ask you to check: https://github.com/AbduazizKayumov/Flashcard-Maker-Android/releases/tag/v0.0.10 I was thinking of switching to Firebase Crashlytics instead of Fabric, so if I make a release build with Firebase Crashlytics, would F-Droid build it from source?

[IzzySoft]

First thanks for the tag, @AbduazizKayumov! That works great. I still wonder if you changed the package name? The "pro" ending wasn't there before. And the version was already higher (3.2 is the last one I have).

As for Analytics: Sorry, no. F-Droid doesn't accept any proprietary component – so no Firebase, no Crashlytics, no Flurry etc. If you really want a "snooper" in the app, please chose one ot the FOSS variants: e.g. ACRA and Matomo would be accepted.

[azizkayumov]

Thank you for suggestions, @IzzySoft!
I changed its package name because I lost a keystore for this one: https://play.google.com/store/apps/details?id=com.piapps.flashcard Then I released a new app: https://play.google.com/store/apps/details?id=com.piapps.flashcardpro Anyways, that was a valuable lesson 😄 Both of them are available on Google Play. Regarding to analytics: sorry, I can not change to FOSS variants, I think Firebase or Fabric are more reliable for crash reporting.

[IzzySoft]

Thanks for the details! Then I'll adjust that in my repo accordingly.

As for Firebase/Fabric: By sticking to them, your app won't ever be available in the official repo – and never used by privacy proponents like me. Please reconsider your decision – and at least make a FOSS flavor. The majority of users probably will install your app from Playstore anyway (so you get your precious analytics), but we privacy aware then at least had a "clean version" (those Analytics packages do not only upload crash reports, they "call home" on many other occasions as well. And have access to everything your app has access to).

[azizkayumov]

Thank you for clear explanation, @IzzySoft! I will try to make both clean (for F-Droid) and 'dirty' (for Google Play) versions in the next releases and upload both of them on Github. The thing is my app does not deal with sensible users' data, only data created by users themselves, so I did not pay attention to security. Once I add new features that may require sensible data, I will gladly remove Fabric (or Firebase).

[IzzySoft]

Thanks! May I suggest to use clear "identifiers" to keep the two APKs apart? You could e.g. use app-release-play.apk for the Playstore version, and app-release-foss.apk for the "real FOSS version". Then I'd tell my updater to always grab the !foss! version (RegEx). Once you have that foss flavor working, we could see to get your app into the official repo, too.

Once I add new features that may require sensible data, I will gladly remove Fabric (or Firebase).

I hope then you still can do so (well, starting with a FOSS version now should ensure that). What often tends to happen is "ah, that's offered by X as well, so I can use it right from there" – and finally your app really depends on proprietary components, and it means a huge rewrite to get rid of that. That's why I recommend to keep proprietary stuff out from the beginning; you cannot really say "my app is FOSS" else – you'd have to say "it's mostly FOSS" or even "it's partly FOSS" :wink: