versionCode decreased?

[IzzySoft]

Looks we've got a problem here.: v0.12.0 had versionCode: 10000012000. Now comes v0.13.0 and has versionCode: 101300, which is a huge decrease. So whoever had v0.12.0 installed, won't receive the update or be able to force-update manually as Android would consider that a downgrade and not permit it. So there are two options here:

• increase versionCode beyond 10000012000 and keep it that high (increasing further with future releases)
• tell everyone they have to uninstall and re-install, then continue from 101300 upwards

Problem with the second variant is that not everyone will receive the news.

So what's your suggested way forwards here? Currently, updates are rejected by my repo as it considers them "older than the oldest version we have", so we're stuck there. If you will take the first variant, the next release would fix that. Otherwise I had to manually remove v0.12.0 here so v0.13.0 gets accepted, so whoever actively checks will at least see the new version – but probably have no clue why it's not offered as update…

If it's relevant: I'm talking about the exo-only build variant (the others exceed the per-app size of my repo).

[IzzySoft]

PS: I've disabled updates here for now until this issue is solved, as otherwise v0.13.0 gets downloaded and deleted over and again by my updater (it sees the newer timestamp, but only finds out about versionCode after downlaod).

[yuroyami]

@IzzySoft Thank you for bringing this to light. This is an oversight from my part, I forgot that the app would be tracked via its versionCode; I've changed the version code semantics this time to a smaller integer to force users to perform a clean install in order to avoid any regressions or incompatibilities, albeit not really necessary.

I can re-upload the exo-only variant to contain version codes that match the same old semantics, or we could wait until a 0.14.0 is released probably a few weeks from now. I don't want you to do any extra work on your part so let me know which option here saves your time and effort.

[IzzySoft]

OK, so you will go with the higher versionCodes for the exo-only variant? In that case, both actions are fine. Once the appropriate APK is available at the latest release let me know, I'll then re-enable updates and it will be pulled. Re-enabling updates would have to be done in either case, so on my end this would be the way taking the least effort. But that would require you to stick to the "large versionCodes" also with future releases.

[ivy-reps]

@IzzySoft Thank you for bringing this to light. This is an oversight from my part, I forgot that the app would be tracked via its versionCode; I've changed the version code semantics this time to a smaller integer to force users to perform a clean install in order to avoid any regressions or incompatibilities, albeit not really necessary.

I can re-upload the exo-only variant to contain version codes that match the same old semantics, or we could wait until a 0.14.0 is released probably a few weeks from now. I don't want you to do any extra work on your part so let me know which option here saves your time and effort.

Interesting workaround!

[IzzySoft]

While working around: my scanner just got some additional checks and reported (when it pulled v0.13.0 again today):

! repo/com.reddnek.syncplay_101300.apk declares flag(s): usesCleartextTraffic
! repo/com.reddnek.syncplay_101300.apk declares sensitive permission(s): android.permission.READ_EXTERNAL_STORAGE android.permission.SYSTEM_ALERT_WINDOW

Could you please clarify those, @ivy-reps? My guesses are that usesCleartextTraffic is for the local network only (where it's hard to have proper SSL certificates), that READ_EXTERNAL_STORAGE is for accessing (and playing) local media files (storage permissions on Android are a mess, especially from 5 to 10) – but SYSTEM_ALERT_WINDOW? A floating window or something?

[ivy-reps]

While working around: my scanner just got some additional checks and reported (when it pulled v0.13.0 again today):

! repo/com.reddnek.syncplay_101300.apk declares flag(s): usesCleartextTraffic
! repo/com.reddnek.syncplay_101300.apk declares sensitive permission(s): android.permission.READ_EXTERNAL_STORAGE android.permission.SYSTEM_ALERT_WINDOW

Could you please clarify those, @ivy-reps? My guesses are that usesCleartextTraffic is for the local network only (where it's hard to have proper SSL certificates), that READ_EXTERNAL_STORAGE is for accessing (and playing) local media files (storage permissions on Android are a mess, especially from 5 to 10) – but SYSTEM_ALERT_WINDOW? A floating window or something?

I'm sorry @IzzySoft, I'm not developer of that app and Android world in common sadly. I'm just very impressed that @yuroyami, made this app and sent him localization.

[IzzySoft]

Uh, sorry – and thanks for sending them a ping from your comment!

[yuroyami]

@IzzySoft

My guesses are that usesCleartextTraffic is for the local network only (where it's hard to have proper SSL certificates)

usesCleartextTraffic flag is necessary when trying to establish plain HTTP connections. In syncplay-mobile's context, users may need to load media over insecure HTTP or over LAN.

SYSTEM_ALERT_WINDOW? A floating window or something?

Correct. This flag is necessary when attempting to launch an activity in Picture-in-Picture (PIP) mode. I am not 100% sure if this flag can be dismissed on some APIs but afaik it should be declared whenever an app has a PIP feature.

[IzzySoft]

Thanks @yuroyami – added that accordingly:

As for the DEPENDENCY_INFO_BLOCK shown in the screenshot, that's easy to get rid of:

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.

[yuroyami]

@IzzySoft The issues should be resolved in v0.14.0

[IzzySoft]

@yuroyami confirmed:

$ iod repo get com.reddnek.syncplay
com.reddnek.syncplay: looking for 'https://api.github.com/repos/yuroyami/syncplay-mobile/releases'
com.reddnek.syncplay: checking tag 'v0.14.0'
com.reddnek.syncplay: lastRelNo set to 'v0.14.0', checking for files
com.reddnek.syncplay: Upstream file date (2024-04-13 04:23) is newer than ours (2023-07-29 20:39).
com.reddnek.syncplay: returning ['v0.14.0','https://github.com/yuroyami/syncplay-mobile/releases/download/v0.14.0/syncplay-0.14.0-exo-only.apk',1712974997]
com.reddnek.syncplay: 0.12.0/v0.14.0, https://github.com/yuroyami/syncplay-mobile/releases: https://github.com/yuroyami/syncplay-mobile/releases/download/v0.14.0/syncplay-0.14.0-exo-only.apk
- Grabbing update for com.reddnek.syncplay: OK
- Checking 'repo/com.reddnek.syncplay_1000014000.apk' for libraries and malware …
- Checking the app's AndroidManifest.xml …
com.reddnek.syncplay: check if repo contains FUNDING.yml
com.reddnek.syncplay: looking for 'https://api.github.com/repos/yuroyami/syncplay-mobile/contents/.github'
com.reddnek.syncplay: Github reports "Not Found" for https://api.github.com/repos/yuroyami/syncplay-mobile/contents/.github
com.reddnek.syncplay: looking for 'https://api.github.com/repos/yuroyami/syncplay-mobile/contents/'
com.reddnek.syncplay: looking for 'https://api.github.com/repos/yuroyami/.github/contents/'
com.reddnek.syncplay: Github reports "Not Found" for https://api.github.com/repos/yuroyami/.github/contents/
com.reddnek.syncplay: no FUNDING.yml detected.
com.reddnek.syncplay: no Fastlane configured, skipping Fastlane check.
$

So I'm re-enabling daily update checks again. Thanks a lot!

PS, just in case you wonder:

• no FUNDING.yml detected => FUNDING.yml
• no Fastlane configured => see my Fastlane Cheat Sheet. I gladly provide you with a starter package with what is set up here, e.g. via PR.

Both are optional, so up to you 😉