versionCode

[IzzySoft]

I see 2 versions being tagged, but the newest one still identifies with versionCode: 1. Can you please increase that with each new release? It's what Android uses internally to tell versions apart. Thanks!

[alexrintt]

Hi! I can't see where the app is setting versionCode: 1 specifically, as described in this SO answer: stackoverflow.com/a/62864554/11793117, Flutter uses the pubspec.yaml -> version key to set the version code on Android.

But in summary the format is:

<version>-<optional-identifier>+<version-code>

And the v0.1.0-alpha (initial version) is using the version code set to 1:

https://github.com/alexrintt/kanade/blob/a9e1548e09ae6cd4a7527b6efb6b90422ab5fe44/pubspec.yaml#L4

And the subsequent version v0.2.0-alpha uses versionCode: 2, as you can see here:

https://github.com/alexrintt/kanade/blob/fde2ee46d3451dda14d794d88300a1f65a5e8682/pubspec.yaml#L4

The version number is passed to the build.gradle here:

https://github.com/alexrintt/kanade/blob/fde2ee46d3451dda14d794d88300a1f65a5e8682/android/app/build.gradle#L54

If you are talking about this specific lines:

https://github.com/alexrintt/kanade/blob/fde2ee46d3451dda14d794d88300a1f65a5e8682/android/app/build.gradle#L14-L22

the null verification only happens we do not specify the version code on pubspec.yaml.

I also tried to install the old version and then replace (without uninstalling the old one) with the latest one on Android 11 and it worked as expected.

Please, let me know if I am missing something, the same applies if you're having trouble to install or update the app, thanks!

[IzzySoft]

I can't see where the app is setting versionCode: 1

I've just run aapt d badging on the APK:

package: name='io.lakscastro.kanade' versionCode='1' versionName='0.2.0-alpha'

I've seen the version: 0.1.0+1 in your pubspec.yaml, and that should have done the trick (I know the problem with not specifying +<versionCode> always results in a 1) – so I wonder why it didn't. Could it be you've built the APK before creating 9b88c5736d968a0e093a1e7468e6b135ac0caf99 (which fixed that)? From the time stamps it seems not, though.

I also tried to install the old version and then replace

Yes, with adb install -r you can do that as long as the versionCode of the new APK is not lower than the installed one. But then you must know there is an update available. Which is only signaled if the code is higher. For reference: I'm talking about your app being listed in my repo. Users will automatically receive update notifications if an APK with a higher version is available there – but not if versionCode was not increased.

Can you please check the attached APK yourself to confirm? aapt d badging app-release.apk | head -n 1 will give you the line I quoted above.

[alexrintt]

I did release a new version v0.2.1 which update the app id and set the version code to 2.

Since the app id was updated there's no difference between versionCode: 2 and 1 for this release in specific (because it will be like a new whole app).

But between keeping the continuity of the versions and creating a new versioning from the new app id, I did choose the first option; sorry for this issue.

And since you're publishing to your repository, you can use this new app id: io.alexrintt.kanade as the original app, this was a unlucky and required change and will not happen again.

But this will not impact any feature, and thanks for letting me know about this issue! I'll now update it every release and create an CI to make it automatic.

• New v0.2.1 apk:

• Old v0.2.0-alpha apk:

It was really buggy and the versionCode was set to 1, idk why but probably because I did generate the apk before updating the version code in the pubspec.yaml, as you said.

[IzzySoft]

Since the app id was updated

That makes it an entirely new app then (users cannot simply update their install but must be aware of the new version and install it manually). You're aware of that? Is this intentional (reading between the lines it seems the answer is "yes")? Shall I simply replace the "old one" in my repo then?

But glad you were able to get the versioning fixed! As soon as I know whether to replace the original one I will take the appropriate action, just let me know. With the app added to my repo only very recently, I think replacing would be OK (were it listed for several months already, we might have needed a "parallel listing" to get users informed about the switch).

[alexrintt]

That makes it an entirely new app then (users cannot simply update their install but must be aware of the new version and install it manually). You're aware of that?

Yes.

Is this intentional?

Yes.

Shall I simply replace the "old one" in my repo then?

Yes, please.

This was an unlucky change I needed to made some months ago, but now it's stable.

Thanks!

[IzzySoft]

OK, then let's go:

package: name='io.alexrintt.kanade' versionCode='4002' versionName='0.2.1'

Hm, that split-APK issue again. If I put that in, users will have no chance to upgrade to arm64 one day:

package: name='io.alexrintt.kanade' versionCode='2002' versionName='0.2.1'

Why is armv7 having the higher versionCode by default? I'll never understand that. So I'll pick the universal one for now:

package: name='io.alexrintt.kanade' versionCode='2' versionName='0.2.1'

and instead of 3 versions I can only keep 1 (per-app limit: 30M). 2 would fit if x86 would be omitted I guess (I just see that was the original setup as the previous releases did not have any per-ABI APKs). Should you feel it worth the trouble and manage to have a ARM only (armeabi + arm64, but no x86) APK without "prefixed versionCode" just let me know: being "on base" now a switch should be possible anytime.

[alexrintt]

I recommend using the universal apk, the abi-specific apks will be available to be downloaded directly from the source (this repository) only for convenience and maybe I'll omit in the future although unlikely to happen (let me know if it is a issue for your repository).

that split-APK issue again

I think this is an intended behavior, because I went through the Android docs to find what actually what a versionCode is and I found this page https://developer.android.com/studio/build/configure-apk-splits#configure-APK-versions; and as expected this is also the Flutter defaults: generation of different version code range for each abi to prevent duplicating the versionCode (the old issue).

I also found someone mentioning this 'issue': https://github.com/flutter/flutter/issues/39817#issuecomment-528656921.

But I get your point, someday people will be forced to update the app to a non-universal abi which will lead to installation issues (due to the incompatible architectures).

Why is armv7 having the higher versionCode by default? I'll never understand that.

Arbitrary range values, it's not that the version is "higher", it is required to avoid duplicating the versionCode through the different abis.

and instead of 3 versions I can only keep 1 (per-app limit: 30M)

If the limit is 30mb we will need to rely to the universal apk (even the appbundle solution can't help in this case, because it has the same size of the universal apk, the difference is noticed only by the final user).

Should you feel it worth the trouble and manage to have a ARM only (armeabi + arm64, but no x86) APK without "prefixed versionCode" just let me know: being "on base" now a switch should be possible anytime.

Nah, as I said before, your repository can rely only on the universal apk, the specific abis will be there only for convenience and maybe I'll omit in the future, but the univesal apk will be always available as kanade-v<version>.apk; let me know if there are problems with the specific abis being available on the release.

[IzzySoft]

let me know if it is a issue for your repository

No, no issue – I've simply told my updater to ignore them (RegEx on file names, so it will work as long as you keep that nameing pattern with the ABIs inside).

generation of different version code range for each abi to prevent duplicating

I get the idea. But why does armeabi get a higher prefix than arm64? Consider I'm using an arm64 device and initially installed the armeabi variant (e.g. because the arm64 was not available at the time). Technically, I could update to arm64 – but with that having the lower versioncode, Android won't let me do that. So I've picked the universal now for this very issue (can be updated to any of the ABI specific ones if we want to switch).

it's not that the version is "higher"

Sorry, but it is: 4002 > > 3002 > 2002 > 1002. Android doesn't know of the prefix, it just sees the integer.

even the appbundle solution can't help

Sure not, as F-Droid doesn't support that (yet) :wink:

As for the issue I see with only having 1 version in the repo, let me explain it by example: Today my client updated its index. 2h later, your app gets updated in the repo and a new index is created. Another 2h later I see your app in my client and want to install (remember, I'm still having the old index). Install will fail as the linked APK is no longer there. I'm frustrated and move on, ignoring your app. Or I start complaining to whomever that "things are broken". This situation is not as rare as you might think :wink: Thus having 2+ versions is a good idea. Not strictly required, but recommended.

[alexrintt]

Ok, nice; so the only left pending issue is the version count (recommended 2+), right? I can make some implementations throughout the next week and then release (v0.3.0+3). In the pre-built binary scope, the v0.3.0+3 will be identical to this one v0.2.1+2 (1 fat apk that you'll use to upload, and 3 per-abi binaries that will be ignored).

Let me know if it applies as solution.

[IzzySoft]

version count (recommended 2+), right?

Always larger than with the previous release. How much larger is up to you – just remember you can never ever decrease, so better don't increase too much :wink:

Let me know if it applies as solution.

Sounds good to me, thanks!

[alexrintt]

Hi! I did finish pre-release.

The current apks of this release are:

• Universal apk target of your repository crawler bot.

---

• Specific-abi apks that will not be included in your repository as discussed earlier (you can ignore these screenshots, it is here for log purposes).

So here we are:

• 2 versions (0.2.1+2 and 0.3.0+3).
• 2 universal apks (< 21mb each).
• App ID: io.alexrintt.kanade.

Since it is a pre-release, let me know if there's anything that is still missing or wrong, so we can fix before the release, thanks.

[IzzySoft]

Fits. YAML on my end has:

ApkIgnore: /(arm64|armeabi|x86)/i

which matches the 3 per-ABI APKs but not the universal one – so the latter would be pulled while the former 3 would be ignored. LGTM :smile:

[alexrintt]

Thanks for confirming! I did set as latest release rn.

If there's anything else you wanna discuss, just ping me.

[IzzySoft]

Perfect – that worked out fine:

$ ./getRelease -vp io.alexrintt.kanade
io.alexrintt.kanade: looking for 'https://api.github.com/repos/alexrintt/kanade/releases'
io.alexrintt.kanade: checking tag 'v0.3.0'
io.alexrintt.kanade: lastRelNo set to '0.3.0', checking for files
Upstream file date (2022-11-14 22:05) is newer than ours (2022-11-11 19:36).
io.alexrintt.kanade: returning ['0.3.0','https://github.com/alexrintt/kanade/releases/download/v0.3.0/kanade-v0.3.0.apk']
io.alexrintt.kanade: 0.2.1/0.3.0, https://github.com/alexrintt/kanade/releases: https://github.com/alexrintt/kanade/releases/download/v0.3.0/kanade-v0.3.0.apk
- Grabbing update for io.alexrintt.kanade: OK
- Checking 'repo/io.alexrintt.kanade_3.apk' for libraries and malware …
io.alexrintt.kanade: check if repo contains FUNDING.yml
io.alexrintt.kanade: looking for 'https://api.github.com/repos/alexrintt/kanade/contents/.github'
io.alexrintt.kanade: replacing 'build/io.alexrintt.kanade/FUNDING.yml'
io.alexrintt.kanade: no Fastlane configured, skipping Fastlane check.

If you're interested, we could work on that last line. I could offer sending a PR with what I've set up here, so you can maintain your metadata (description, screenshots etc) using fastlane structures (metadata only, no binaries needed) in your repo yourself and such are in control of how your app is presented.

[alexrintt]

Seems pretty interesting! I'll be waiting for your PR while reading about fastline.

[IzzySoft]

There you go!

[IzzySoft]

And please don't break fastlane. short_description.txt e.g. is limited to 80 chars (as the details behind my above link say), so your 150+ char ones will simply be truncated, looking quite a bit ugly now :wink: I've left a comment on that commit, please revert back/fix and let me know I can pick it up again.

[alexrintt]

Thanks, I've added an action that will prevent this to happen in the future.

I'm going to fix these linter errors:

Including the folder lang name de -> de-DE:

Tell me if you see any error, thanks.

[IzzySoft]

PlayStore is stupid. de is fully legit. What if I'm from Austria and have set to use de-AT? If that's not found, the fallback would be de. Not there? Oh, what a pity… Here you have en-US, the final fallback always present :see_no_evil:

"Icon must be…" => a square with at least 48x48px and max 512x512 – so 96x96 is perfectly fine. Well, my updater will downsize it to that anyway if it gets too large (exceeds 20kB) :man_shrugging:

Screenshots: Well, cannot hurt. Rumors have it the iPhone 25 will have the same width as the iPhone 6, but will be 20 times as long – we certainly don't want such screenshots, right? :see_no_evil:

Thanks!

[alexrintt]

Perfectly! I did adjust the action to skip PlayStore lang code checks and did revert the de-DE to de.

Is there anything else?

[IzzySoft]

Thanks a ton! Wow… And no, I'm currently not aware of anything else. Those shortdescs just turned up when I improved my local scanners to cover that topic.

Looks like we've (well, you've) covered everything now, right? Time to close the issue? :smiley:

[alexrintt]

Those shortdescs just turned up when I improved my local scanners to cover that topic.

I see, are those local scanners open-source? Throughout the issue development I was wondering what your magic tools looks like; but if it's not, no problem.

Looks like we've (well, you've) covered everything now, right? Time to close the issue?

Happy to hear that, man!

Any other warning or issue with the app or repository, feel free to open another issue.

Feel free to close this issue as your wish.

[IzzySoft]

I see, are those local scanners open-source?

Most of them can be found in my corresponding repo, though some parts are just local scripts building on top of that. But for the shortdesc part it's just a simply local snipped walking all the short_description.txt and checking their character length.

Happy to hear that, man!

Happy to state it :smile:

As for the rest: will do. Thanks for your fast response and tackling!