Availability outside of Play? about inure HOT 45 CLOSED

@IzzySoft The end goal isn't to force the users into paying, but to have enough revenue to make the development efforts worthwhile. The easiest option would be that I can simply add the APK in sponsors rewards or something like that and allow them to have access to link for unlocker file. I have already added the support for unlocker and all they have to do is just use the unlocker APK to activate the app, and it will be unlocked forever and there won't be a need to keep the unlocker file installed. It's a win-win I guess, the app gets to remain FOSS and I can provide everyone a simple unlocker file. No fancy validation, encryption, or anything. However, it's easy to break though.

from inure.

Right in time (a bit later, and my updater had picked one of the two at random). Thanks, set it to RegExMatch /github-release/i and ignore all else (especially /play-release/i). Please make sure the naming conventions remain, or inform me if you need to change them 😉

As the issue is solved now, I'm closing up here (feel free to reopen if you think it's needed, or call me from a different issue if my help is needed concerning my repo or F-Droid's). Thanks a lot!

from inure.

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

from inure.

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.

from inure.

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.

from inure.

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…

from inure.

Yes please sir it will be nice to be available also outside play store 🙏

from inure.

Created a request for packaging on F-Droid for Inure here.

from inure.

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

That sounds good! I am really absolutely willing to pay developers for their good/excellent/hard work, but I'm not willing to have a Google account on my phone and even give them 30% of the prize. And really unfortunately there is good software I use where I would like to pay for additional features, but it's only possible with Google Play Store :-(

from inure.

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.

Thanks for the info, I have made the unlocker app relatively simple. Just downloading it and clicking on activate would do the thing. I won't complicate it with so many validations and processing.

That sounds good! I am really absolutely willing to pay developers for their good/excellent/hard work, but I'm not willing to have a Google account on my phone and even give them 30% of the prize. And really unfortunately there is good software I use where I would like to pay for additional features, but it's only possible with Google Play Store :-(

I'm sure there will be a way to make the unlocker app be available outside the app stores. Maybe GitHub Sponsors or something, I'm not sure yet.

from inure.

So folks can buy it there, get an APK to side-load, sideloading it – and done?

Yup, that's pretty much it.

All the code of the main app remains libre?

Yes, so far so good, and I hope this approach will work for everyone. I will also be creating a separate flavors for GitHub/F-Droid and Play Store. So, make sure you use the GitHub/F-Droid build for your repo.

from inure.

@IzzySoft There wasn't any Non free assets to begin with, it was misunderstanding caused by how I specified my terms to use Inure trademarks in the licence section. I had removed it as soon as I was made aware of that.

from inure.

OK, removed as well then (with the next sync).

from inure.

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.

from inure.

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.

from inure.

@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… 😉

from inure.

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 😉

from inure.

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

from inure.

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.

from inure.

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.

from inure.

Build44 has been uploaded here

from inure.

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.

from inure.

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.

from inure.

due to android.permission.PACKAGE_USAGE_STATS and android.permission.QUERY_ALL_PACKAGES permissions 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 😉

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.

from inure.

@IzzySoft Do notify me if there's any update regarding the DexClassLoader issue.

from inure.

If I remember. My "do" list is quite well-filled 🙈 Maybe you subscribe to the issue there?

from inure.

@IzzySoft On GitLab? If the packaging team will reply there then that will do, I have it subscribed.

from inure.

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 😉

from inure.

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

from inure.

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

from inure.

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…

from inure.

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

from inure.

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.

from inure.

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

from inure.

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.

from inure.

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.

from inure.

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.

from inure.

I'm sure there will be a way to make the unlocker app be available outside the app stores.

Apart from Amazon Store, Galaxy Store and the likes (which again will require proprietary services on the users' side): how will you protect it against being downloaded without payment then? Just out of curiosity. Of course, in the end there's no such thing as 100% safety for/against anything 😉

from inure.

I'll be using Gumroad for providing unlocker file outside Play Store.

from inure.

So folks can buy it there, get an APK to side-load, sideloading it – and done? All the code of the main app remains libre? Sounds like a good solution then. Their website includes Google's tag manager and runs on Clownflare, but for the one-time purchase one can in the worst case use a separate browser (profile) and be done.

from inure.

@IzzySoft I've checked your repo and the Inure has AF NonFreeAdd and NonFreeAssets tags listed on the app page. Haven't these issues been addressed already and none of the AFs tags had to be stayed?

from inure.

They are not dropped automatically in my repo then – so thanks for your ping! Latest version in my repo currently is "build60_final". Are both issues solved for that one? IIRC the NonFreeAdd can definitely be removed as the unlocker was made FOSS, so I'll remove that right now (will be reflected with the next sync in a couple of hours today). NonFreeAssets was not quite clear to me if it has been fully resolved. What was the status with that?

from inure.

@Hamza417 with your app now listed on F-Droid.org, do you still want me to keep it in my repo? I see you list both badges in your Readme, so I thought I'd better ask before proceeding with the "default action" (which would be removing the app following a decent overlap).

from inure.

If that's default action, you can remove the listing. I'll update the links.

from inure.

If that's default action

Yupp, unless requested otherwise.

you can remove the listing. I'll update the links.

OK, will do. Should you need it back for some reason, it can easily be re-established then. Thanks!

from inure.