APK download
Closed this issue · 21 comments
just wondering: will you make the APK available here as well, now that your CI creates tags?
I'm working on it :D should be working soon.
Cool, great to read! Your app might be helpful for the Gadgetbridge project, especially for all those "new device requests". The "average Joe" (like me) has no idea how to provide a BTSnoop – your app seems to provide that, among other things. I gladly take your app into my repo as soon as the APK is available – and as soon as you consider it "stable enough", I gladly assist bringing it to F-Droid if you wish.
The APK is now available under: https://github.com/mx0c/Android-BLE-Monitor/releases. If you are testing our app feel free to report any kind of bug or improvement requests.
Thanks a lot! I'm just adding it to my repo now, so it will become available here with the next sync in about 8 hours from now. Will then tell the Gadgetbridge crew to take a look and guess they'll "promote" it – and surely point here for reports.
May I suggest to somehow bring tag names and app versioning in sync, if possible? Easiest way would probably be using the current "tag name number" as versionCode. Not a must, just a suggestion, as that's (the tag name being in sync with either versionName or versionCode) seems to be considered "good practice".
Well, today's release again had versionCode: 1. That means: no update notifications, Android will think nothing changed, users have to find out there is a newer version and force-update manually. Also versionName is still "1.0", so there's not even a "visual indicator". And there'll never be more than one version available in my repo, as each update would overwrite the previous version (packageName+versionCode act as "unique key"). Can you please increase versionCode with each new release? Thanks!
you're right, thanks for the feedback. Gonna fix this soon!
Great, thanks! Btw: Gadgetbridge devs are currently taking a look at it, now that it's available in my repo. First impression (reading the description and seeing the screenshots) was, let me quote while translating on the fly: "that looks interesting, I definitely must give it a try" 😃 I'll report back when I hear about the "second impression" 😄
Ugh… my updater complained again. Looks like the one you've attached to v1.0.1 not only still has versionCode: 1 – but also versionName: "1.0.0" – indeed:
package: name='com.huc.android_ble_monitor' versionCode='1' versionName='1.0.0' compileSdkVersion='29' compileSdkVersionCodename='10'
As the former needs to be increased with each release, and the latter should match the tag name, I would have expected:
versionCode='281' versionName='1.0.1'
Somehow your new "auto bump" failed: gradle.properties wasn't updated. Taking a look at the commit it seems it only reads the current values – but I don't see where it is writing the new ones. Besides, couldn't that take place in build.gradle itself? Would make it easier if one day you want your app in the F-Droid.org repo.
Shall I disable auto-update until it's fixed (or everyone starts to be confused)? I could move your app from daily to monthly check, for example.
Thanks in advance!
well, my idea was to automatically increment the versionCode and versionName in the deploy process which doesnt make any sense, because the files are already comitted and pushed. So now we need to manually increment the versions. If not the release is overwritten. Sry for the inconvinience.
Well, you never know before you try… Thanks for checking. Whichever approach your using – it will be fine as long as it works.
Just brainstorming here: I'm not sure how you've set up your "release process" – but if tagging locally, you could e.g. use a small "tag script" which takes care for the details: RegExReplace versionCode&versionName, commit, tag, push. So basically a script expecting 2 parameters: versionName & versionCode. It first checks the specified values are "greater than" those currently in build.gradle – then either abords (not greater) or performs the steps. Last step then is a git push --tags – but then the APK wasn't yet dealt with…
yup, but tagging is done server side. I think for now the solution we have is ok. but thanks :)
As long as it works, it should be fine, yes 😄 Have you replaced the APK at v1.0.1 already – or will my updater fetch the "wrong one" again in 2 hours?
Should be an updated version 😄
Afraid that is wishful thinking. The one at v1.0.1 still represents itself as
package: name='com.huc.android_ble_monitor' versionCode='1' versionName='1.0.0' compileSdkVersion='29' compileSdkVersionCodename='10'
(and is dated 2020-11-26)
My bad should work now, forgot some old code fragment. 😒
But the APK at v1.0.1 looks still the same…
in theory it should be overwritten but made a new release precautionary.
Not sure what you did, but according to my logs from today…
com.huc.android_ble_monitor_1.apk already exists and is identical to the one we downloaded; ignoring it
I don't see a new release either, so it probably was the very same APK from the same release again.
I'm setting your app to "Static" now – makes no sense to download the very same APK file each day (Static means it will only be checked once a month). Please let me know once you've got the issue fixed, have a tag with the correct APK, and have verified this. You can easily verify the APK using
aapt d badging app-release.apk | grep "package:"
Once everything is fine, I can re-enable daily update checks. Thanks!
after a lot of trial and error our ci now only creates a new release after creating a new tag, every other commit just builds the app without deploying it. So if you want, you can change your system to rechecking for new versions every day. Gonna close this issue for now. Thanks for your patience 😄.