Questions on releases and permissions

[IzzySoft]

I've just checked the releases here, and was a little confused: they all have multiple/different APK files attached. So e.g. v7.1 has APKs for 7.0.2, 7.1.0 and 7.2.0 – and v8.0.1 two different APKs for 8.0.0. Shouldn't the APK versions match the tags? Currently, I've had to disable my updater which always thought there'd be a new version available (have: 8.0.0, found: 8.0.1 => downlaod => oh, it's 8.0.0 still => delete).

Also at v8.0.1: Will future releases have these very same 2 build variants with matching file names? With their sizes quite apart, what speaks against taking the smaller one (which also supports more Android versions it seems), or what makes the bigger one preferable?

Next, running my scanner over the bigger one, and it reported:

Permissions:
------------
* android.permission.CHANGE_WIFI_STATE
* android.permission.NEARBY_WIFI_DEVICES
* android.permission.ACCESS_FINE_LOCATION
* android.permission.ACCESS_COARSE_LOCATION
* android.permission.CHANGE_NETWORK_STATE
* android.permission.INTERNET
* android.permission.ACCESS_NETWORK_STATE
* dev.spiegl.flyingcarpet.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
* android.permission.CAMERA

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

Permissions it highlighted (as they are defined to be sensitive) are NEARBY_WIFI_DEVICES (which is clear for the purpose of the app), ACCESS_*_LOCATION (which is not entirely clear to me as the app requires at minimum Android 11 – I know one of those is needed with lower Android versions if you request Bluetooth, but what is the connection here?) – and then especially CAMERA. Checking the code I see qrcode.js, so I assume there's a QR code scanner integrated?

Last concern is the DEPENDENCY_INFO_BLOCK. What are you using to sign your APKs? Background: that block is an opaque blob, supposed to just hold a copy of your dependency tree in binary form. But as it's encrypted using a public key owned by Google, nobody can check if it's really that and only that. As it's needed by Google only and of no use outside the PlayStore (remember, nobody but Google can read it), it would preferable to not have it in the APK.

Thanks in advance for clarification!

[Rihcus]

CAMERA. Checking the code I see qrcode.js,

When:

• sending to another android, linux, and/or windows
• recieving from linux, or windows

flying carpet creates a hotspot (or adhoc not sure if term is right) on those platforms and android connects hence why you get a scan.

When:

• send to ios or macos
• recieve from android, ios, or macos

Android creates a hotspot and other devices connect to the android hotspot (Androidshare_xxxx)

Maybe other perms are there for similar reasons? (I'm not a dev not sure what they do)

[spieglt]

The version numbers on the releases page mainly track the Linux, macOS, and Windows versions. As there have been bugs with the Android version, I've had to release new APKs and bump the version. Major versons (such as 8) are compatible, so any binaries within a single tag on the releases page are compatible with each other.

Will future releases have these very same 2 build variants with matching file names?

No, I added the _minimum_SDK_19 version in response to https://github.com/spieglt/FlyingCarpet/issues/59. I have no intention of keeping the same naming scheme for future versions. Usually I'd just name it like android_FlyingCarpet_8.0.0.apk, and if the SDK 19 version is working for people, I'll compile it that way in the future. I don't know why they differ in size so much.

Regarding permissions, from https://developer.android.com/develop/connectivity/wifi/localonlyhotspot:

If your app targets Android 13 (API level 33) or higher, you must request the NEARBY_WIFI_DEVICES to use a local-only hotspot, as shown in the following code snippet. Apps that target an earlier version of Android must request ACCESS_FINE_LOCATION instead.

And yes, camera permissions are for the QR code scanner, though the code for the Kotlin app is not in this repository and is not public.

I use the normal "Generate Signed Bundle / APK" feature of Android studio. The DEPENDENCY_INFO_BLOCK is news to me, and I don't believe Android Studio offers me an option to omit it.

[spieglt]

Oh, and the current release was renamed/retagged from 8.0.0 to 8.0.1 because I made a mistake in the desktop version and it wasn't worth keeping the buggy 8.0.0 desktop binaries. If I ever make the code of the Android version public, I'll probably put APK releases there. Otherwise, it might be the case in the future that the Android version gets a minor version bump and the desktop versions don't, or that the desktop version gets bumped and the Android version doesn't. May I ask what updater you use that's looking at the release tags?

[IzzySoft]

though the code for the Kotlin app is not in this repository and is not public.

Oof. Then I'll unfortunately have to remove the app again from my repo, which is restricted to Android apps that are fully open source :cry:

I use the normal "Generate Signed Bundle / APK" feature of Android studio. The DEPENDENCY_INFO_BLOCK is news to me, and I don't believe Android Studio offers me an option to omit it.

It does, though not via the GUI but via your build.gradle.kts file:

android {
    dependenciesInfo {
        includeInApk = false
    }
}

If I ever make the code of the Android version public

Then please give me a ping, and I'll add it to my repo again! One idea to keep tag names in sync (apart from the Android app using its own repo) would be using dedicated tags, especially when a release for another platform does not necessarily mean a release for this. You could use prefixes, like android-8.0.0 for the Android v8.0.0 release. Just to name an option; as my updater no longer has to look out here with the app unfortunately removed again, I'm no longer affected by this.

May I ask what updater you use that's looking at the release tags?

The one for my repo. It's source code can be found here.

Thanks for your details, Theron! Especially concerning the hotspot permissions. Those dangling differences between the Android versions is hard to keep track of (it's even wilder with the storage perms :see_no_evil:)…

[spieglt]

@IzzySoft The Android source is now in the repo.

[IzzySoft]

Thanks @spieglt – then I can see to reestablish the app's listing. As currently auto-updates would probably fail as you attach multiple different versions to the same tag, I'd like to verify in advance: will future releases remain like that, or will they stick to the APKs matching the tag name (e.g. tag v8.0.2 only having the APK of version 8.0.2), so I can enable auto-updates? Manual updates would be much delayed.

[spieglt]

Now that the Android codebase lives in this repo, I could have each tag reflect the most recent version of either the desktop or Android version. So that if the Android version is bumped, I'd update the tag and just leave the desktop versions as they are. That would mean an update would trigger if I released an Android bugfix. It would still mean, however, that if I have to fix a bug in the desktop versions, I'd bump the tag without necessarily updating the Android version, leading to the situation you described initially. I'll think about it but I don't want to make a separately-tagged release for every bugfix, nor update the version in the Play Store for something that only changes on desktop.

[IzzySoft]

Would it make sense using prefixes for the tag names maybe? e.g. android-1.2.3 for an Android release, desktop-1.2.3 for a desktop release of v1.2.3? I could then advise my updater to only consider those tags having the android- prefix. Not sure if that contradicts your "I don't want to make a separately-tagged release for every bugfix" – but a release labeled v1.2.3 housing versions 1.2.0 to 1.2.5 is a bit confusing (apart from my updater not being able to deal with).

[spieglt]

That's an idea, I'll think about this again when I get closer to the next release. This probably won't happen until I get Bluetooth working on all platforms, which will be a long time from now.

[IzzySoft]

Thanks! Please let me know when I shall check again then.

Btw: Funny thing that I got a notification for the reopen, but not for the comment. So notifications still getting lost partly (and I'm not the only one with this issue). So should I not respond within a day or two, that would be another notification having missed my inbox…

[spieglt]

@IzzySoft Now that it's in F-Droid, I'll be sticking to the APKs matching the tags, starting with v8.0.2.

[IzzySoft]

Thanks for letting me know! As your app was removed here in 1/2024, does your ping mean you want me to add it back?

[spieglt]

Sure, it's your repo so up to you but I certainly don't mind it being listed in more places.

[IzzySoft]

I don't mind adding it back then. Just checking the APK, I see our issue from above is still present:

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

Would you mind shipping the APK without that then? Quoting from above with some complementation, this is what you'd need 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. For my repo it's sufficient having the includeInApk = false, if you want to keep it in the AAB ("bundle") for e.g. PlayStore.

Permissions:
------------
* android.permission.CHANGE_WIFI_STATE
* android.permission.NEARBY_WIFI_DEVICES
* android.permission.ACCESS_FINE_LOCATION
* android.permission.ACCESS_COARSE_LOCATION
* android.permission.CHANGE_NETWORK_STATE
* android.permission.INTERNET
* android.permission.ACCESS_NETWORK_STATE
* dev.spiegl.flyingcarpet.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
* android.permission.CAMERA

Most of those are already clarified, just the location permissions would be open. Guess they are needed because of WiFi (on "lower Android versions")? Deducing this from android:maxSdkVersion="32" being set for fine location and android:usesPermissionFlags="neverForLocation" for Nearby, but missing it at coarse location, hence the question.

Btw: your Fastlane structure lacks an icon.png, so I'm using this icon. And if you wish, you can add a video.txt with https://www.youtube.com/watch?v=-RKiSmo-Bns as content next to your descriptions – plus I could provide you the de locale for short and fulldesc.

Meanwhile, FlyingCarpet is integrated again here and thus should show up with the next sync around 6 pm UTC – so above "requests" are for the next release then :wink: Welcome back!