please maintain versionCode

[IzzySoft]

With your current settings, versionCode will always be 1 – as you do not specify any. That line currently should read:

version: 0.2.1+5

(with 5 specifying the versionCode – which now should be 5 or higher, as there are already 5 releases and, as explained, versionCode must be increased with each release. Otherwise, nobody will ever receive any update notifications, and it thus will be hard to keep the app up-to-date on your device.

[Myzel394]

Thanks for the hint. I'll add it to the next release.

[IzzySoft]

Thanks!

PS: on the topic we discussed, I found this (how to override the 1000 thingy). Just in case you need it one day.

[Myzel394]

@IzzySoft the new release has been released with the correct versionCode

[IzzySoft]

Ah, cool! Strangely it's not picked up:

$ iod repo get app.myzel394.locus
app.myzel394.locus: looking for 'https://api.github.com/repos/Myzel394/locus/releases'
app.myzel394.locus: checking tag 'v0.2.2'
app.myzel394.locus: lastRelNo set to '0.2.2', checking for files
app.myzel394.locus: Upstream file date (2023-05-23 17:54) not newer than ours (2023-05-23 17:54), skipping.
app.myzel394.locus: returning local appdata as ['0.2.1','',0]
app.myzel394.locus: 0.2.1 up-to-date.

Checking… Ah, that's why: no APKs at the release :see_no_evil: Looks like you had to recreate the release (it says created 5 min ago, while your post stating it's created is from half an hour ago). OK, then I wait a little before retrying.

Btw, look what was just brought to my attention:

ext.abiCodes = ["x86_64": 1, "armeabi-v7a": 2, "arm64-v8a": 3]
import com.android.build.OutputFile
android.applicationVariants.all { variant ->
  variant.outputs.each { output ->
    def abiVersionCode = project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))
    if (abiVersionCode != null) {
      output.versionCodeOverride = variant.versionCode * 10 + abiVersionCode
    }
  }
}

The snippet was taken from here. Just in case you want to play with it. If I understood correctly, given a version: 1.0.0+1 in your pubspec.yaml, this should spit out versionCodes 11, 12, 13 for x86_64, armeabi, arm64 then. If that works and you want to get rid of the 1000-steps, you could use it and start with a +500 or so in pubspec.yaml to make sure versionCode is above what it was before.

[Myzel394]

@IzzySoft yes I was facing some difficulties with the CI:CD. The correct files should be ready in about 20 minutes.

I personally don't care how the versionCode is formatted to be honest. If I understood you correctly, the correct concept from Flutter still works. I'd prefer to keep it that way, since maybe Flutter someday changes something that depends on the versionCode and then it'd be difficult for me to debug that issue.

[IzzySoft]

Yupp, your choice of course. What irks me (and not only me) is with the way Flutter implemented it, you will never be able to e.g. switch from arm64 to armeabi if needed, as they use the highest bit to indicate the ABI. The proposed mechanism would change that to using the lowest bit – so as described, all it would take for a "clean" switch to a "lower" ABI would be waiting for the next release of an app. :man_shrugging:

As for the release: I see there are two new releases, with v0.2.2 marked "latest" but a v0.3.0 also being there with APKs attached. v0.2.2 seems to be the newer one, which is a bit confusing. Also confusing: how is v0.2.2 marked "latest" while a higher versionName is not marked pre-release? Not sure what my updater will pick in that case. I assume v0.3.0 (as per sorting, that would turn up top and is no pre-release). Is that what you intended? Else yell in time :wink:

[Myzel394]

@IzzySoft v0.3.0 is the correct one. Not only did I mess up with the CI:CD, but also with the version at first 😂

[Myzel394]

@IzzySoft https://apt.izzysoft.de/fdroid/index/apk/app.myzel394.locus contains the incorrect version, can we fix this? Also, remember to remove the non free dependency warning :D

[IzzySoft]

When messing up, do it thoroughly :see_no_evil: Sorry, but the Github releases page got a mess a few years ago. This now is the 3rd repo where ordering of releases is broken. But here it seems to be entirely your fault (oops):

$ iod repo get app.myzel394.locus
app.myzel394.locus: looking for 'https://api.github.com/repos/Myzel394/locus/releases'
app.myzel394.locus: checking tag 'v0.3.0'
app.myzel394.locus: lastRelNo set to '0.3.0', checking for files
app.myzel394.locus: Upstream file date (2023-05-27 13:21) not newer than ours (2023-05-27 19:50), skipping.
app.myzel394.locus: returning local appdata as ['0.2.2','',0]
app.myzel394.locus: 0.2.2 up-to-date.

Well, if the newer file has the older timestamp, what do you expect? Ah, I guess me fixing it manually. Now… I've manually downloaded https://github.com/Myzel394/locus/releases/download/v0.3.0/locus-armeabi-floss.apk – and guess what my scanner finds?

Offending libs:
---------------
* Google Mobile Services (/com/google/android/gms): NonFreeDep

1 offenders.

So sorry, cannot remove the anti-feature :cry:

[IzzySoft]

PS: Hahaha, nice joke. "When messing up, do it thoroughly" – full load. Here's how the APK from above identifies:

package: name='app.myzel394.locus' versionCode='1007' versionName='0.2.2'

Seems like you've also attached the wrong APK files :man_shrugging: Cannot check against the onve from v0.2.2, as you've already deleted that release…

[Myzel394]

@IzzySoft that's really strange, as this would mean that something else is dragging GMS in. I'll have to check whether the FLOSS variant works on GMS based phones again (just as a reminder for myself).

[Myzel394]

Note for me: https://stackoverflow.com/a/73715568/9878135

[IzzySoft]

this would mean that something else is dragging GMS in

There's always flutter pub deps to find out. That SO finding sounds helpful if it's that – but it rather looks like "when implementing GMS, leave out SafetyNet" (scroll up a bit and you'll see that they even explicitly implement Firebase Analytics and more).

[Myzel394]

Okay wtf now the FLOSS variant works flawlessly on both GMS and non-GMS AND even inside buildings?!? No idea if the satellites were really bad the other day or if I did something else now, but it works. 🤷 That means I'll upload only the FLOSS variant to GitHub. @IzzySoft could you change the file name locus-armeabi-floss.apk again? :D

There's always flutter pub deps to find out.

Unfortunately this did not work for me. No dependency showed GMS at all :/

That SO finding sounds helpful if it's that

That did do the trick. I excluded gms and according to the analyze tool from Android Studio there's no more Google Play Services included. Please let me know if there is still some.

I will create a new release (v0.3.0) and ping you once the files are ready.

[Myzel394]

No wait it doesn't work on Xiaomi devices. So we will still have to use the GMS and FLOSS variant. You don't need to change the name @IzzySoft

[IzzySoft]

Okay wtf now the FLOSS variant works flawlessly on both GMS and non-GMS AND even inside buildings?!?

:+1: Matches my experiences with other apps, as detailed in another place.

Unfortunately this did not work for me. No dependency showed GMS at all :/

:eyes: that's strange. If you didn't explicitly specify it, something must be dragging it in – and that's called "dependency", and flutter pub deps should show "deps" aka dependencies. :thinking:

That did do the trick.

Nice! I was a bit sceptical. As I always say, I'm no Android dev so I often cannot be sure I read things correctly. And that really looked like "when implementing GMS, leave out SafetyNet". But maybe after excluding the element, there was nothing more left and thus the entire thing was dropped altogether :man_shrugging: Still wonder why something is included automatically despite of not being needed. Are you using proguard? If so, Minify android app but do not obfuscate it could be interesting to you. It basically uses proguard to kick out unused code.

[IzzySoft]

I will create a new release (v0.3.0) and ping you once the files are ready.

As v0.3.0 wasn't picked up anyway (for discussed reasons), it will automatically be picked up once you've attached new APKs to it (including the one matching the configured regEx) :wink: But yes, please give me a ping so I can check if that anti-feature can finally be removed.

[Myzel394]

@IzzySoft ping for v0.3.1 :D

[IzzySoft]

Already pulled, see my comment on the other issue. All fine now, congrats!

[IzzySoft]

Eh, you did it again it seems:

Binary files /web/ftp/repo/fdroid/repo/app.myzel394.locus_1011.apk and /web/ftp/repo/fdroid/repo/app.myzel394.locus_0.5.0.apk differ

That means there was already an APK with versionCode: 1011 in my repo when v0.5.0 was pulled today. Can you please put a hot iron on that "release" button so you think twice, @Myzel394? :speak_no_evil: :dash:

[Myzel394]

Sorry, should be fixed on 0.5.1

[IzzySoft]

Happens. Thanks for fixing!

But remember what Ian Fleming stated (in "Goldfinger"): "Once is happenstance. Twice is coincidence. Three times is enemy action". So: iron in place? :wink: (yes, I'm repeating that for "embarrassment" – but with well-meaning, having the hope this helps you remember :stuck_out_tongue_winking_eye: