APK Download?
Closed this issue · 7 comments
Would you consider making your app available outside of Google's walled garden, so those without access there can use it as well? You could e.g. tag your Releases and attach it there. Thanks in advance.
+1, albeit for a different reason. IMO there's in-garden value since Google Play lacks a mechanism for rolling back to a stable build from an unstable one (e.g. #5 and #6 in 3.0.3). I'm seeing quite limited .apk downloads for basically only OpeNoise 2.0.3, 3.0.3, and 3.0.4 that are plausibly trustworthy. Not having tracked OpeNoise, I'm unsure if there's a release between 2.0.3 (June 2018) and 3.0.3 (August 2023).
It would be simpler and safer, I think, to distribute through GitHub releases than to rely on third party .apk caching sites.
No either/or needed, and I was also thinking about possibly adding the app to my repo (where the updater would fetch new releases within 24h of their becoming available) and thus giving people even more choices 😉
Good morning, everyone,
we are considering your proposal, but we need more time to figure out how to implement it safely.
Please consider that the old versions of the app are no longer compatible with the latest versions of Android (Goggle had removed the pre-3.0 version of the app from the store), so there is no point in being able to download them.
In addition, we were forced to rewrite the code and change the way the analog-to-digital conversion of the noisy signal takes place, as the libraries and frameworks used in the pre-3.0 versions were also no longer updated.
This repository contains all the code and any help in improving the app is welcome.
Thanks for the suggestion
Haven't used OpeNoise 2.0.3 much on Android 13 yet, but it appears to work fine if that's what's being referred to. Updating to current libraries and having an updated build after five years is great but I'm not seeing how that connects to not posting 2.0.3, 3.0.3 3.04... .apks here.
Since I've rolled back to 2.0.3 for production use I'd like to also suggest a beta distribution channel (some apps do this by creating two entries in Play but downloading a .apk from a GitHub beta release works just fine too). That would enable running, for example, 2.0.3 and 3.0.5 beta side by side and simplify providing the traces which have been requested.
@Arpapiemonte thanks for your response! As @twest820 just confirmed, 2.0.3 seems to work at least on Android 13. And just to mention, I bet the majority of Android users are still on Android 12 and below anyway. Google removing versions from PlayStore IMHO is not a reason against making them available here, but rather a strong argument in favor of it.
Further, the idea raised by @twest820 to establish a beta channel is a good one, too. Making APKs available here (using a specific applicationId for those, e.g. suffixing the "normal one" with .beta) would be a first step. The APK being available here would also enable me to add it to my repo (if a scan confirms it meets all other criteria). This not only adds the possibility of a new distribution channel (especially for folks without access to PlayStore), but also for discovery, as my repo meanwhile gained some popularity.
I understand and second your concerns on safety. Availability in my repo would also add a layer of trust, as APKs are scanned there by multiple means and the results are made transparent.
May I suggest reopening this issue until a final decision is made – and letting me know when the APKs become available here? Thanks!
Ok, we published the releases here: https://github.com/Arpapiemonte/openoise-meter/releases
Thanks a lot, @Arpapiemonte! Integrating it with my repo now, as pointed out above. The app will become available here at around 6 pm UTC then. Be welcome to pick a badge pointing there e.g. from your Readme then 😃
One thing to mention is my scanner reports a non-libre (aka proprietary) component in the APK:
Offending libs:
---------------
* Google Mobile Services (/com/google/android/gms): NonFreeComp
1 offenders.
Is that included on purpose, or was it "accidentally dragged in" by some dependency? For now, I'm applying the NonFreeComp (aka "non-free component inside") anti-feature with the reason pointed out. If we can get rid of that, I'll of course remove that "mark" as well.