labplus_for_gitlab

labplus_for_gitlab copied to clipboard

Could you please make sure versionCode is increased with each release? Currently it seems to be constantly set to 1, because of this:

version: 1.4.1+1

It's the part following the + sign. Android uses that internally to tell versions apart – so if an APK has the same (or even a lower) versionCode than the installed app, it's not considered as update.

While on it: would you consider per-ABI builds for smaller APKs? I'm looking to add your app to the IzzyOnDroid repo, where the per-app size limit currently is 30 MB, which the APK of the last release is already pretty close to. Dropping x86 from it however would bring it closer to about 22..23 MB, or a single arch (armeabi, arm64-v8a) to about 13..15 MB I guess.

Thanks in advance!

I honestly wasn't quite sure about the meaning of the +x. 1.4.1 is the version, but what does the +1 specifically mean. Does it still update if it's bumped to 1.5.0+1? Sorry if this is a noob question, but my previous experience was just normal semver (major.minor.patch) so I'm a bit confused by the + denomination

Also, just out of interest, what's the advantage of your Fdroid repo over the official one? Not saying I'm opposed, just need more information

• versionName: 1.4.1. This is what is displayed for humans to read
• versionCode: 1. This is what Android uses internally to tell versions apart. So if you have 1.4.1+1 installed and 1.5.0+1 gets released, Android will say: "Nope, that's not an update, that's already installed" and ignore it (tech-savy people know how to enforce such an update, but nobody would receive any update information – plus repositories would ignore/refuse it, Play wouldn't accept it etc.pp.). Which is why it's important to always increase it with each release.

what's the advantage of your Fdroid repo over the official one?

In several cases subjective, but for some basic facts see e.g. the FAQ (which omits "time to get your app listed: several weeks or even months – vs. several hours to days", as that's a one-time event). Also, inclusion criteria slightly differ.

Got it. Since 1.4.1 is the first one I am officially releasing into Stores, I'm gonna keep that at one and increase it from there on out.

I still plan on releasing this app in the Official Fdroid Repo (and at some point Google Play for that matter), does this prevent me from releasing to your repository. The FAQ says that it isn't an exclusion reason, but is "Having it more accessible to Users by being in the default repo" good enough of a reason to keep it in both?

Since 1.4.1 is the first one I am officially releasing into Stores, I'm gonna keep that at one and increase it from there on out.

Sounds good!

does this prevent me from releasing to your repository.

Not necessarily. As long as it still meets all inclusion criteria (see IzzyOnDroid App Inclusion Policy) it's welcome to stay. In the past I usually removed apps when they reached F-Droid.org – meanwhile I only do so if either explicitly requested or the APK got too big (there's still the size limit of ~30 MB per app at IzzyOnDroid).

Speaking of which: your APK already is at that limit. Would you mind establishing per-ABI builds, so I could pick either the arm64-v8 or, if you prefer, the armeabi-v7a for IzzyOnDroid? When doing so (and as you plan for F-Droid.org as well), consider overriding Flutter's crazy versionCode calculation ("ABI * 1000 + baseCode", resulting in versionCodes 1001,2001 for armeabi, arm64 so one could not go back to the "fat build") by a sane one (recommended: "baseCode * 10 + ABI", resulting in 10 for the fat one, 11 for armeabi, 12 for arm64 and so on).

is "Having it more accessible to Users by being in the default repo" good enough of a reason to keep it in both?

Add "faster updates" and "additional scans" to it and you have 3 reasons :wink:

Speaking of which: your APK already is at that limit. Would you mind establishing per-ABI builds, so I could pick either the arm64-v8 or, if you prefer, the armeabi-v7a for IzzyOnDroid? When doing so (and as you plan for F-Droid.org as well), consider overriding Flutter's crazy versionCode calculation ("ABI * 1000 + baseCode", resulting in versionCodes 1001,2001 for armeabi, arm64 so one could not go back to the "fat build") by a sane one (recommended: "baseCode * 10 + ABI", resulting in 10 for the fat one, 11 for armeabi, 12 for arm64 and so on).

I tried researching this for about 2 days now, but couldn't really find a solution on how to do this. Do you have a code snippet or something similar to achieve this

The per-ABI splits, or adjusting the versionCode calculation? I'm no Android or even Flutter dev, so afraid I cannot. But doing a quick search, some helpful hints might be:

How to assign different versionCode for multiple architecture apks built with flutter

Just instead of output.versionCodeOverride = variant.versionCode (which would assign the same versionCode to all ABIs, thus making it impossible to serve them all in a F-Droid repo should you one day decide to apply for inclusion with F-Droid.org) you'd apply the above calculation: output.versionCodeOverride = 10 * variant.versionCode + baseAbiVersionCode. With version: 1.4.1+6 this then should result in 61 for armeabi, 62 for arm64 and so on. The "fat build" ideally should have 60 then – if not (but it sticks to 6), a proper else branch might be needed:

if (baseAbiVersionCode != null) {
  output.versionCodeOverride = 10 * variant.versionCode + baseAbiVersionCode
} else {
  output.versionCodeOverride = 10 * variant.versionCode
}

No guarantees as I couldn't verify this, but it might be a good starting point :crossed_fingers:

I tried overriding this with the aforementioned method, but couldn't get it to work as also demonstrated in https://github.com/flutter/flutter/issues/62005.

Therefore I sadly can't override the crazy version code for now

I will in fact provide spllit APKs though

Just keep in mind you cannot decrease versionCode later. Apart from that… well, what can you do. Should be fine then, until a real solution shows up. I'd take a look myself, but that's outside my range unfortunately.

Yeah I need to look into it a bit more. This was the result of me researching and trying for 6h. Maybe I'll have some more luck later

The most recent release includes split per ABI APKs. These can be used to publish on your repo if you still want to do that

Thanks! Looking at it now. First finding brings me back to the initial post. Looks like you increased versionCode once then, but after that kept forgetting it as it is still set to 2: version: 1.5.0+2. This will lead to permanent errors with each update, which then never reaches those having a previous version installed.

So yes, I'd like to add it to the repo here – but that only makes sense if you keep increasing versionCode with each release. Will you? Then I'd go ahead with the inclusion, and pick the arm64 APK if you agree. Guess you use the Github workflow to build the APK?

While on it:

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

This can easily be avoided with a minor addition to the 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.