versioning issue

[IzzySoft]

Looks like the APK at the latest release (2.1.1) still announces itself as the very first release:

package: name='io.github.aerocyber.sitemarker' versionCode='1' versionName='1.0'

This is quite irritating in multiple ways: On can never see which version is really installed (as all are shown as 1.0) – plus Android would never update the app always thinking "I already have this version" (as versionCode never changes).

I wonder how that can be, as pubspec.yaml says version: 2.0.0 (which is still wrong, it should be something like version: 2.1.1+12 with the latest version being 2.1.1 and the 12th release).

Thanks in advance for checking and fixing!

[aerocyber]

Thank you for reporting this issue. I'll look into it and get back to you soon with a fix.

[aerocyber]

Looks like the whole mess happened due to how I generated signed APKs. I used Android Studio for Android builds as it took care of signing without me doing anything. Of course, I had to use the release profile.

The issue is that Android Studio used the default version string 1.0.0(?) as the variable flutterVersionName was not accessible from it. That would not have been the case had I used Flutter CLI for the build.

I am now adding the signing logic to the build.gradle file so as to add signing logic.

[IzzySoft]

Thanks a lot @aerocyber! While you're at updating build.gradle, may I bring one more thing to your attention? Here's what one of my scanners reports:

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

That's easily avoided by a slight modification to build.gradle:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains. More details can be found e.g. here: Ramping up security: additional APK checks are in place with the IzzyOnDroid repo.

Would be great if you could do that at least for the APK (includeInApk = false).

[aerocyber]

Oh, that's a weird thing. And of course, anything which cannot be verified even by a developer can be a security issue. Thanks for mentioning this. I'll be sure to add them.

[IzzySoft]

Thanks! Looking forward to the next release then. Ping appreciated when it's available :smiley:

[aerocyber]

Sure thing!

[aerocyber]

@IzzySoft thanks for reporting the issue! With the latest release (2.1.2), the issue is [hopefully] resolved. Also, I've built the APKs with the configurations you mentioned before. I'm closing this issue as it stands resolved, but feel free to reopen if it persists.

[IzzySoft]

Almost there:

package: name='io.github.aerocyber.sitemarker' versionCode='1' versionName='2.1.2'

versionCode is still 1. Most likely as you specify none – add a +13 to that line (version: 2.1.2+13) as otherwise Flutter defaults to 1.

That said, want to pick a badge to add to your Readme? Assuming the next release will have the versionCode fixed, I've prepared this:

which should show up here in about half an our, when the next sync is through. True, the description could need a few more details… If you want to, I can send you a PR with the app metadata as set up here, using Fastlane format, so you can e.g. use the IzzyOnDroid Fastlane Documentation to build on that. Which has the advantage that your changes would be pulled automatically with each release.

[IzzySoft]

PS: Where does the app store the bookmarks? Locally – or is there any network service involved (and if so, which)? I see the app requests the INTERNET permission, which it would not need when working entirely local. Apart maybe from fetching favicons.

[aerocyber]

Almost there:

package: name='io.github.aerocyber.sitemarker' versionCode='1' versionName='2.1.2'

versionCode is still 1. Most likely as you specify none – add a +13 to that line (version: 2.1.2+13) as otherwise Flutter defaults to 1. ...

According to the Android developer documentation:

versionCode A positive integer used as an internal version number. This number helps determine whether one version is more recent than another, with higher numbers indicating more recent versions. This is not the version number shown to users; that number is set by the versionName setting. The Android system uses the versionCode value to protect against downgrades by preventing users from installing an APK with a lower versionCode than the version currently installed on their device.

And I did plan to increment versionCode only on newer build of the same version. Say, I'm going to provide a more updated APK for the version 2.1.2, then I increment versionCode. Otherwise leave it as it is. Hence the unchanged versionCode.

[aerocyber]

PS: Where does the app store the bookmarks? Locally – or is there any network service involved (and if so, which)? I see the app requests the INTERNET permission, which it would not need when working entirely local. Apart maybe from fetching favicons.

It's actually stored locally on device. The internet permission is used to check if a newer version of the app is released. If it is released, a notification will be shown to users.

Do note that the notification does not download the APK but links to the releases page.

[aerocyber]

PS: Thanks for the repo. I'll be sure to update my README

[IzzySoft]

Hence the unchanged versionCode.

Ah, OK then – thanks!

The internet permission is used to check if a newer version of the app is released.

Oops… well, that's against the IzzyOnDroid App Inclusion Policy (and F-Droid's as well) – though only slightly, as you only show a notification and do not download the update. Can you make that check opt-in? Else I'd have to apply the NonFreeNet anti-feature, as the app reaches out to a non-free network (I assume you check Github releases?) without the explicit content of the person using the app.

Btw, when installed using an F-Droid client, that check would not be necessary: the F-Droid client would take care for that. With the IzzyOnDroid repo, updates become available within 24h of your creating a new release and attaching the APK to it (depending on the timing; daily update checks run at around 5:30 pm UTC (summer; 6:30 in winter due to DST bullshit), so if your APK becomes available at e.g. 5 pm, it's just about an hour).

Thanks for the repo. I'll be sure to update my README

Cool, thanks! So how about Fastlane (see above)?

[aerocyber]

Oops… well, that's against the IzzyOnDroid App Inclusion Policy (and F-Droid's as well) – though only slightly, as you only show a notification and do not download the update. Can you make that check opt-in? Else I'd have to apply the NonFreeNet anti-feature, as the app reaches out to a non-free network (I assume you check Github releases?) without the explicit content of the person using the app.

It's okay, I'm good. And Sitemarker is going through some major changes. And making it an opt-in feature is on the desk :smile:

Cool, thanks! So how about Fastlane (see above)?

I'm currently setting up Actions to do that. And considering I'm targeting Windows and Linux too, I don't think fastlane is necessary. Thanks for the suggestion though.

[IzzySoft]

making it an opt-in feature is on the desk

So just for information: planned for the next release? No pressure, just asking.

I'm targeting Windows and Linux too, I don't think fastlane is necessary.

I don't see the connection here. Fastlane would help with your listing for IzzyOnDroid – as you could ensure the app is always described correctly and the description as well as the graphics shown keep up with the app (as the updater would pull all these along with new releases). Fastlane supports Android and iOS at least (/fastlane/metadata/(android|ios) locations), not sure if it would cover Linux/Windows as well or could at least be used for those as well. My offer for a PR with a "starter package" still stands.

[aerocyber]

So just for information: planned for the next release?

Yes.

Regarding your offer for fastlane. I'd be glad if you can provide the PR. However, I am not targetting Apple devices so, please leave out iOS from it.