anonfaded / FadCam

Seamless background video recorder for Android – ad-free and open-source, with customizable options.
GNU General Public License v3.0
191 stars 14 forks source link

versioning hint #1

Closed IzzySoft closed 2 months ago

IzzySoft commented 2 months ago

Please remember the versioning when making new releases. I currently see 2 releases, the latest being named 1.0.0 – but the APK identifies as

package: name='com.fadcam' versionCode='1' versionName='1.0'

versionCode should at least be 2. Increasing this is especially important as Android uses this to tell versions apart; not increasing it means nobody would receive updates as Android would think this version is already installed. versionName is what's being shown to humans. No big issue here if you follow semantic versioning, as then 1.0 and 1.0.0 would basically be the same.

While I'm here:

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

This can easily be avoided with a tiny adjustment in your 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.

Thanks in advance – and be welcome to pick a badge to link to the place where your app should show up with the next sync in about 2 hours :smiley:

IzzySoft commented 2 months ago

Oh, PS: Guess you could need the metadata in fastlane format, which I could send over with a PR from what I've just set up at IzzyOnDroid? I have the feeling sooner or later someone might ask for it, or already has :wink:

anonfaded commented 2 months ago

I currently see 2 releases, the latest being named 1.0.0 – but the APK identifies as

I m very new at all this so it was confusing. Right now i deleted all the releases and made a new one with tag 1.0. And in build.gradle.kts i made it like this:

    defaultConfig {
        applicationId = "com.fadcam"
        minSdk = 24
        targetSdk = 34
        versionCode = 2
        versionName = "1.0"

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

so i did all right? I want to go with 1.0 for simplicity so for new updates that i make, should i increment the version code with +1 and version name as 1.1 etc ? Like whats the best practice.

This can easily be avoided with a tiny adjustment in your build.gradle:

And i read the blog about this, as far as i understood the code block you gave that i added, it will make the apksigner in Android Studio to not include the Google lines? And in every project i need to add this code block? Before i was trying the fdroid commands from docs but nothing was working and later i opened that issue on GitLab. I have apksigner and all environment variables set but still it was showing error that no apksigner found, while the next command to check the version of that tool worked fine, so i can continue using the generating signed apk tool on Android Studio right?

Btw now also see if everything is fine and now app can be deployed to F-Droid, thanks for assistance.

IzzySoft commented 2 months ago

should i increment the version code with +1 and version name as 1.1 etc ? Like whats the best practice.

That sounds good. Just please don't delete releases once published (except when really needed). SemVer is best practice, but you are close enough to that.

the code block you gave that i added, it will make the apksigner in Android Studio to not include the Google lines?

Correct.

And in every project i need to add this code block?

Yes, as since around AGP 8.3 it's included by default otherwise.

so i can continue using the generating signed apk tool on Android Studio right?

If you refer to that blob: yes, the adjustments I gave you are accepted by Studio as well.

Btw now also see if everything is fine and now app can be deployed to F-Droid, thanks for assistance.

Gladly! It's already deployed at IzzyOnDroid as I pointed out above – F-Droid will take a bit longer. Also note what I wrote on the full_description.txt at the PR: F-Droid cannot properly handle Markdown in that file, so the outcome of your change won't be what you expected. No prob at IzzyOnDroid, where I just marked it as Markdown so it will be parsed properly. F-Droid lacks that feature.

anonfaded commented 2 months ago

Gladly! It's already deployed at IzzyOnDroid as I pointed out above – F-Droid will take a bit longer. Also note what I wrote on the full_description.txt at the PR: F-Droid cannot properly handle Markdown in that file, so the outcome of your change won't be what you expected. No prob at IzzyOnDroid, where I just marked it as Markdown so it will be parsed properly. F-Droid lacks that feature.

oh i changed it to html now 😅 and now i just need to wait untill F Droid adds it in their repo? Also is the IzzyOnDroid different than F Droid or are they linked? And how to get the F Droid get-it-on badge? (ok i found it here https://gitlab.com/fdroid/artwork/tree/master/badge)

IzzySoft commented 2 months ago

and now i just need to wait untill F Droid adds it in their repo?

That should happen via your RFP, LK and linsui will let you know when input from you is needed.

Also is the IzzyOnDroid different than F Droid or are they linked?

IzzyOnDroid is a separate repo, but compatible with the F-Droid clients. You can find some details on it here. It offers faster updates (taking the APK you provide, so there's no build cycle to wait for) and applies additional checks (see e.g. Ramping up security: additional APK checks are in place with the IzzyOnDroid repo).