Hamza417
Availability outside of Play?
Will the app be available outside the walled gardens of Play Store? Seeing it deems to depend on Firebase, it's unlikely to show up at F-Droid – but maybe the APK could be made available here, e.g. attached to the corresponding tagged release? Thanks in advance!
I do not have any plans for releasing the app outside Play Store at the moment. My only focus right now is the development of the app and using Play Store saves me a fair amount of time and efforts.
And, this app doesn't use any Firebase APIs, so if tracking or anything related to data collection is concerned this is free from all of them.
I do not have any plans for releasing the app outside Play Store at the moment.
That's a pity, as it excludes all those users not having access to it.
And, this app doesn't use any Firebase APIs
Funny: Appbrain reports the app includes Firebase. But good to know no tracking is meant – though it still means F-Droid cannot build it (as Firebase is proprietary). I could take it into my repo, though, easily making it available to those outside Play – but for that I'd need the APK…
That's a pity, as it excludes all those users not having access to it.
I'll think about it later.
And, I'm not sure to why AppBrain listed Firebase as one of the APIs, however you can refer to app's build.gradle file to check the dependencies the app uses.
Yes please sir it will be nice to be available also outside play store 🙏
@Hamza417 I cannot check that as I have no build environment (I'm no Android dev). Yes, I can investigate it by reading, but that doesn't include a dependency tree (gradle :app:dependencies) which might reveal Firebase as a dependency of a dependency. I could however tell if there were an APK I could run through my scanner. Which btw is how Appbrain acquires such details, by scanning the app when installed on the device of a user having their scanner app installed as well.
I'll think about it later.
That'd be great, thanks! Nothing to lose that way, you can only win: new users, updates available immediately even when stuck in Google's review queue… :wink:
@Hamza417 I cannot check that as I have no build environment (I'm no Android dev). Yes, I can investigate it by reading, but that doesn't include a dependency tree (
gradle :app:dependencies) which might reveal Firebase as a dependency of a dependency. I could however tell if there were an APK I could run through my scanner. Which btw is how Appbrain acquires such details, by scanning the app when installed on the device of a user having their scanner app installed as well.
I checked and found the Firebase API inside the added indirectly, and I'm not sure how. I'll investigate and have it removed by the next update.
Looks like a dependency of a dependency of a dependency: gms:play-services might have dragged it in. But no idea what might have dragged in those in the first place… However, good find – and thanks for taking care!
Btw: With your app in my repo, you'd have an "early warning system" for such things – I have a scanner in place that raises an alarm if something proprietary or privacy-invasive was found to "sneak in". But with Firebase and GMS removed, you could also be ready to apply at F-Droid.org directly :wink:
Hi @Hamza417, I think you can remove androidx.core:core-google-shortcuts:1.0.1 safely (no need to find alternative), because you not using it inside your app source code. Also you can use Dependency Analysis Gradle Plugin to detect unused and misused dependencies.
I try it at this branch.
@ratabb thanks for the heads-up on this issue, It was added by mistake and I thought ShortcutManagerCompat was a part of this library. It's removed now.
The *.jar file might be a stopper there. If the source for that is available, maybe include it as a submodule (we can then scandelete the JAR and build it from the submodule – but setting up that build recipe will be up to a packager more experienced than I).
F-Droid will also need tagged releases to build from (so we know what commit is considered a release). If you could start with that now (tagging the commit of the last release) and add the corresponding APK (signed with your key), I could see if I meanwhile take it into my repo until it's ready at F-Droid.
The *.jar file might be a stopper there. If the source for that is available, maybe include it as a submodule (we can then scandelete the JAR and build it from the submodule – but setting up that build recipe will be up to a packager more experienced than I).
It's removed from the app now.
F-Droid will also need tagged releases to build from (so we know what commit is considered a release). If you could start with that now (tagging the commit of the last release) and add the corresponding APK (signed with your key), I could see if I meanwhile take it into my repo until it's ready at F-Droid.
Noted, I'll tidy up the next build and publish a release with proper tags here.
Thanks! Then let me trigger the bot again at your RFP so its report reflects the changes… done. Let's see what it says this time.
The issues were gone but the DexClassLoader.java issue still persists and due to android.permission.PACKAGE_USAGE_STATS and android.permission.QUERY_ALL_PACKAGES permissions the app was also marked as Trackers.
due to
android.permission.PACKAGE_USAGE_STATSandandroid.permission.QUERY_ALL_PACKAGESpermissions the app was also marked as Trackers.
May I correct that slightly: potential trackers. Those are reports by the bot to draw special attention to for the review. I may semi-officially state that neither of the two permissions are "stoppers" for your app but are considered "fully justified" (and I might even say needed) for what the app is intended for. Disclosure in this context: I'm one of the F-Droid maintainers, so you can believe this statement being true :wink:
As for the DexClassLoader: I vaguely remember that one coming up in the past – but I have to leave word on this to my team-mates with better background on this topic. As with the other "warnings" given by Issuebot, this one is not set into stone IMHO.
@IzzySoft Do notify me if there's any update regarding the DexClassLoader issue.
If I remember. My "do" list is quite well-filled :see_no_evil: Maybe you subscribe to the issue there?
@IzzySoft On GitLab? If the packaging team will reply there then that will do, I have it subscribed.
That's how it works, yes: if questions arise they'll be voiced there – from your side as well as from ours. And the "other side" then hopefully responds :wink:
Yes please sir it will be nice to be available also outside play store
Is it really a problem? It is possible to downlaod the apk from GitHub and install it. OK, updates have to be checked manually, but I think that GitHub can notify when a new release is available (I haven't tried yet).
notify when a new release is available
That's what happens automatically with the app in my repo (update-notifications are handled by the F-Droid client on the users' devices). A listing at F-Droid itself would be more trusted even, as it guarantees the APK was really build from the sources and was checked for "unwanted content" (like proprietary libs etc).
Btw @Hamza417 could you please remember the per-release changelogs in fastlane when tagging a release? There were none since the initial one. I just noticed when checking the logs here…
@IzzySoft Yeah, sure. I forgot.
There's one thing I have been thinking about. The app will move to a stable state soon and I'll be adding in app purchases in favour of supporting the development after a few builds when I think it's ready. Having an open source project is acceptable since many learners could take benefit from it but releasing a build without any returns is not very cost effective for me. You might have to stop updating the app on your repo or remove from it altogether due to its use of proprietary APIs.
Thanks for the advance information! What kind of proprietary libraries do you have in mind – and are you sure there are no alternatives? You could scan my library definitions for payment libraries which are FOSS, for example (type:Payment in libsmali.jsonl, and match the id against that in libinfo.jsonl for the license), there are several:
# get the library packageNames
grep '"type":"Payment"' libsmali.jsonl |awk -F, '{print $1}'|awk -F: '{print $2}'|less
# use that for a loop to find the licenses
for lib in $(grep '"type":"Payment"' libsmali.jsonl |awk -F, '{print $1}'|awk -F: '{print $2}'); do
grep $lib libinfo.jsonl | grep license | grep -iv proprietary | awk -F, '{print $1 "," $NF}'
done
Here are the results:
{"id": "/android/didikee/donate", "license": "MIT"}
{"id": "/com/adyen/checkout", "license": "MIT"}
{"id": "/com/anjlab/android/iab/v3", "license": "Apache-2.0"}
{"id": "/com/braintreepayments/api", "license": "MIT"}
{"id": "/com/dooboolab/RNIap", "license": "MIT"}
{"id": "/com/github/jberkel/pay/me", "license": "Apache-2.0"}
{"id": "/com/miguelbcr/io/rx_billing_service", "license": "Apache-2.0"}
{"id": "/com/playseeds/android", "license": "MIT"}
{"id": "/com/revenuecat/purchases", "license": "MIT"}
{"id": "/com/stripe/android", "license": "MIT"}
{"id": "/io/octo/bear/pago", "license": "Apache-2.0"}
{"id": "/moe/feng/alipay/zerosdk", "license": "Apache-2.0"}
{"id": "/org/solovyev/android/checkout", "license": "Apache-2.0"}
{"id": "/org/sufficientlysecure/donations", "license": "Apache-2.0"}
Not that many I admit. Their corresponding repositories can again be found in the first file (libsmali.jsonl). (just a quick hacked statement to find them, you probably can do better – but given the few results, I've rather taken the lazy approach). Note that while those libraries themselves are FOSS, they might still rely on proprietary services – I see some using Google's IAP, Stripe, AliPay.
This one
{"id":"/com/android/billingclient","path":"/com/android/billingclient","name":"BillingClient","type":"Payment","perms":"","url":"https://developer.android.com/reference/com/android/billingclient/api/BillingClient"}
And checking from the list, it's proprietary.
{"id": "/com/android/billingclient", "emphasize": 1, "details": "Google Play Billing Library", "mwid": "", "anti": ["NonFreeDep","NonFreeNet"], "license": "Proprietary"}
Yes, that's Playstore Billing. And won't work on google-free devices, as it requires the Playstore app to be present. Will hence cause the NonFreeNet and NonFreeDep anti-features to be set.
Yes please sir it will be nice to be available also outside play store 🙏
I support this wish!!
I have no problems checking for updates myself, download an apk and install it. Thats what I do with your app presently anyhow, using Github releases. Probably there is a not too time-comsuming way to get a Google-free payment realised.
If it would not be possible at all, would it be possible that you realise a Google Play mechanism so that a purchase can be done on a dummy rooted mobile having Google Play Store and then the app is transfered to the real phone having microG and fakestore using some backup/restore software (e.g. Neo Backup) and it works there.
If it would not be possible at all, would it be possible that you realise a Google Play mechanism so that a purchase can be done on a dummy rooted mobile having Google Play Store and then the app is transfered to the real phone having microG and fakestore using some backup/restore software (e.g. Neo Backup) and it works there.
There's. I can create a separate unlocker apk and leave the original app untouched and free from any proprietary APIs. There's still time to this, I was just updating @IzzySoft about the future of the app.
Making the unlocker app paid at Play and leaving the main app untainted would be a good option as well.
Other options could include "unlock codes" one could buy by any payment means available, bound e.g. to an email the code is then sent to. As your app has the necessary permissions, you could even cap that using an online check to make sure there's no license key publicly shared (e.g. performing a one-time online check when the license is entered and not accepting it if there already were more than X pings in a given time frame, say 10 a day and 50 a month, to give enough room for more than one device and some failures, but not enough for spreading it around.