Submit the app to F-Droid

[Korb]

• Submitting to F-Droid Quick Start Guide
• Requests For Packaging

[shrimqy]

Yes, I was planning to last month then I couldn't do anything after my pc brokedown, which also halted all development, I only resumed working on this recently, I am planning to release a new version next week (hopefully) or by next month which should give a lot of Qol improvement upon the current version. I will get to submitting on F-Droid soon after that, thank you.

[IzzySoft]

Just adding it to the IzzyOnDroid repo now. There's one problem, though: the last version does not build. When trying to build from the last release tag, build fails stating

> Task :core:presentation:verifyReleaseResources
> Task :core:domain:lintVitalAnalyzeRelease
> Task :core:common:lintVitalAnalyzeRelease
> Task :core:presentation:lintVitalAnalyzeRelease

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':core:data:compileReleaseKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
   > Compilation error. See log for more details

Unfortunately, no details of what exactly fails or why. Do you have any idea?

[IzzySoft]

Btw, while being here, could you please clarify what the following permissions are needed/used for (scanner here reports "sensitive permissions" we use to make transparent)?

• android.permission.ACCESS_COARSE_LOCATION
• android.permission.ACCESS_FINE_LOCATION
• android.permission.MANAGE_EXTERNAL_STORAGE
• android.permission.QUERY_ALL_PACKAGES
• android.permission.WRITE_EXTERNAL_STORAGE

Further also:

Dangerous Filters:
------------------
android.accessibilityservice.AccessibilityService

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

The latter can easily be avoided with a minor addition to 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!

[shrimqy]

Just adding it to the IzzyOnDroid repo now. There's one problem, though: the last version does not build. When trying to build from the last release tag, build fails stating

> Task :core:presentation:verifyReleaseResources
> Task :core:domain:lintVitalAnalyzeRelease
> Task :core:common:lintVitalAnalyzeRelease
> Task :core:presentation:lintVitalAnalyzeRelease

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':core:data:compileReleaseKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
   > Compilation error. See log for more details

Unfortunately, no details of what exactly fails or why. Do you have any idea?

Thanks for reporting this. The version you're trying to build is really old, and I've since made significant changes to the codebase. Without more detailed error logs, it's difficult to diagnose the specific build issue you're encountering.

I'd recommend waiting for the upcoming release I'm currently working on, which has substantial architectural changes.

If you need a working version right now, you could try building from the main branch instead of the release tag, though please note it may contain in-progress changes, you would also need the corresponding latest working windows build as well, both have gone through a lot of changes, I will try to release a test build later as soon as I can.

Btw, while being here, could you please clarify what the following permissions are needed/used for (scanner here reports "sensitive permissions" we use to make transparent)?
android.permission.ACCESS_COARSE_LOCATION
android.permission.ACCESS_FINE_LOCATION
android.permission.MANAGE_EXTERNAL_STORAGE
android.permission.QUERY_ALL_PACKAGES
android.permission.WRITE_EXTERNAL_STORAGE

The location permissions are mainly for discovery, the current implementation checks connected wifi network ssid with the saved ones to see if the app should try to connect to the PC or not.

As for Query all packages, I need it to correctly get all the package names for syncing the notifications, or it might cause a few problems, such as app names being blank.

Write storage permissions are for remote storage functionality, which allows accessing the android storage directly from the PC.

Accessibility service, is for getting the clipboard data, before it was used for remote control the android device, I later removed that feature since it was pretty inefficient.

The latter can easily be avoided with a minor addition to 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 for the tip about the dependency metadata configuration! I'll add this to the build.gradle.

I appreciate your efforts thank you.

[IzzySoft]

The version you're trying to build is really old

According to the tag, just 4 months (Sep 29, 2024) – but well, time flies 😉

Without more detailed error logs

Unfortunately, the build doesn't give me such. Maybe it puts some at build-time; but our builders run in ephemeral containers, so I cannot access them at the end of the build as everything is gone by then.

I'd recommend waiting for the upcoming release I'm currently working on, which has substantial architectural changes.

OK, no prob. I see that will also come under a different packageName then. Any ETA already?

you could try building from the main branch instead of the release tag

Nah, that won't do: we ship the APKs built and signed by their authors. But we verify the builds, see e.g. Reproducible Builds, special client support and more at IzzyOnDroid. For that we need to build from the same commit the "official" APK was built from.

The location permissions are mainly for discovery

Why do you want to discover me? Or which location does the app want to discover? The app description does not mention location features. I mean, I do have an idea what it might be – but I don't want to place "guesses" in the user-facing documentation 😉

As for Query all packages, I need it to correctly get all the package names for syncing the notifications, or it might cause a few problems, such as app names being blank.

Makes sense, thanks!

Write storage permissions

Err, I must have been blind. That's right in the app description, apologies!

Thanks for the tip about the dependency metadata configuration! I'll add this to the build.gradle.

Great, thanks! I just see I have missed one item: usesCleartextTraffic. Could you please give some background for that as well?

[shrimqy]

According to the tag, just 4 months (Sep 29, 2024) – but well, time flies 😉

I meant that because the code is outdated and the whole architecture is different from that, but yes it isn't really that old in the typical sense.

Without more detailed error logs. Unfortunately, the build doesn't give me such. Maybe it puts some at build-time; but our builders run in ephemeral containers, so I cannot access them at the end of the build as everything is gone by then.

Got it! That definitely makes it tough to debug. I'll prioritize finalizing the upcoming release so you can work with the latest version, and I'll ensure build stability is tested thoroughly before publishing.

Any ETA already?

Ummm, I hope for next week's end, though that can change I had said that many times before and I keep delaying it TT.

Nah, that won't do: we ship the APKs built and signed by their authors.

Ok, that makes sense, thanks for the detailed info.

Why do you want to discover me? Or which location does the app want to discover? The app description does not mention location features. I mean, I do have an idea what it might be – but I don't want to place "guesses" in the user-facing documentation 😉

Ok so to make it clear, I will explain it again. The location permissions aren’t used to "discover" a user in the typical sense. Instead, they’re used to identify the currently connected Wi-Fi network SSID (According to Google, I should need these permissions for retrieving the SSID of the wifi network). This allows the app to determine whether it should attempt to connect to the paired PC automatically.

Thanks for the tip about the dependency metadata configuration! I'll add this to the build.gradle.
Great, thanks! I just see I have missed one item: usesCleartextTraffic. Could you please give some background for that as well?

The usesCleartextTraffic flag is included to enable communication with devices on the same local network that may not support HTTPS. This was used for that release because it wasn't using a secure connection nor did I use Https (it was a plain WebSocket connection) back then, I probably added it when testing out different stuff and forgot to remove it, sorry.

[IzzySoft]

because the code is outdated and the whole architecture is different

Got that meanwhile, thanks!

and I'll ensure build stability is tested thoroughly before publishing.

Speaking of which: when getting close to release, and you want to check if RB is achieved, you can give me an "early bird" to test against. All I'd need is a commit, and an APK built from a clean tree at that commit (i.e. no local changes or artifacts from previous build present).

I hope for next week's end

That would be FOSDEM time (I'm in Brussels then). But good to hear a goal has been set! So we could test the week following Feb 2nd. Just give me a ping when a (pre-) release is ready for testing!

they’re used to identify the currently connected Wi-Fi network SSID

Thanks! So my guess was right there (some Bluetooth and WiFi stuff requires location permission, as such things could be used to locate a device – looks logical on first glance, but I still find it the wrong approach; by that reasoning, you'd need COARSE_LOCATION whenever you request INTERNET, as the IP could be used with e.g. the MaxMind libraries to get the town you're in 🤷‍♂ So in fact, this makes things worse: to get the SSID, you have to request another permission which gives you even broader access. Privacy wise pretty much "meh").

OK, so I've updated those details:

Sefirah will be established as a new app then anyway (as the packageName changed), so we can adjust it again then.

Thanks for your help! Looking forward to your next ping then 😃

[shrimqy]

All I'd need is a commit, and an APK built from a clean tree at that commit (i.e. no local changes or artifacts from previous build present).
That would be FOSDEM time (I'm in Brussels then). But good to hear a goal has been set! So we could test the week following Feb 2nd. Just give me a ping when a (pre-) release is ready for testing!

Sure, Thank you.

by that reasoning, you'd need COARSE_LOCATION whenever you request INTERNET

Not really. Requesting INTERNET access isn’t equivalent to accessing WiFi or Bluetooth scans. This is because INTERNET permission simply allows network access without exposing nearby WiFi access points or Bluetooth devices. However, retrieving the WiFi SSID or similar information does require location permissions now, as accessing these details can indirectly reveal precise location data.

According to the documentation, we're expected to use ConnectivityManager's getNetworkCapabilities() method to get the Wifi info. Unfortunately, the documentation states

This will remove any location-sensitive data in TransportInfo embedded in NetworkCapabilities#getTransportInfo(). Some transport info instances like WifiInfo contain location-sensitive information. Retrieving this location-sensitive information (subject to the app's location permissions) will be noted by the system. To include any location-sensitive data in TransportInfo, use a NetworkCallback with NetworkCallback#FLAG_INCLUDE_LOCATION_INFO flag.

This means there’s no way around the requirement for location permissions when attempting to access certain WiFi-related information. Additionally, IP geolocation is much less precise and does not require active hardware scans, so comparing these two is not entirely accurate.

That said, this permission is not strictly required for the app’s core functionality. You can disable it if you prefer. However, if you don’t grant the permission, auto device discovery (not to be confused with general device discovery) will not work. This means that after the initial pairing, reconnections would need to be done manually.

If auto device discovery is needed, we would have to keep the UDP listener active all the time, which could be less efficient. By only activating the listener when a saved network is connected, we reduce unnecessary resource usage, making this approach more efficient. Ultimately, this feature is completely optional.

And also you can remove the usesClearTextTraffic tag since that is not being used anymore.

You can check the manifest

I have also mentioned another permissions, which might also flag your system

<uses-permission android:name="android.permission.RECEIVE_SENSITIVE_NOTIFICATIONS"
    tools:ignore="ProtectedPermissions" />

but this permission, can't be enabled anyway whatsoever without adb, so might as well point that out here.

[IzzySoft]

Wow. Thanks for all those details! Let me start at the bottom:

I'm really thankful for those details! I had no time yet to go over the new permissions in Android-15, so I was not aware. I've added them immediately to our scanner, and also included them with the permission descriptions here. It's funny that it's not (yet?) mentioned either on AndroidDeveloper's ManifestPermission page, nor in the source tree (values-de/strings.xml / values-en-rUS/strings.xml), while discussed in different places for quite a while already.

Seemingly, despite officially being bound to role|signature], it's possible to adjust via ADB and AppOps (see here and here. Fun.

OK, back to top-down:

Not really. Requesting INTERNET

Well, not the best comparison maybe. But INTERNET at least allows for a (very?) coarse location. And meh, I didn't want to start a flame war on this, it's just that those things are not always easy to follow. "Average folks" seeing the location permissions requested hardly understand without being explained explicitly, that connection (oops) is not exactly intuitive…

That said, this permission is not strictly required for the app’s core functionality. You can disable it if you prefer. However, if you don’t grant the permission, auto device discovery (not to be confused with general device discovery) will not work. This means that after the initial pairing, reconnections would need to be done manually.

Ah, good to know. Maybe that could (should?) be pointed out somewhere in the description?

Speaking of which: would you welcome a PR with Fastlane structures (not the binaries, just the metadata files: descriptions, screenshots and such), as currently set up at IzzyOnDroid for the app? You could then e.g. use the IzzyOnDroid Fastlane Documentation to build on that. Our updater would fetch any changes with new releases then, so description & graphics would stay up-to-date here automatically – and you could define how they should look like. PR takes me no more than 5 min, so no big deal.

If auto device discovery is needed, we would have to keep the UDP listener active all the time, which could be less efficient. By only activating the listener when a saved network is connected, we reduce unnecessary resource usage, making this approach more efficient.

👍

And also you can remove the usesClearTextTraffic tag since that is not being used anymore.

Our scanner will report when it's removed (and our repo browser won't show it anymore then even if we did not remove it from the "green list", as it only shows what's really there).

So again, thanks a lot!!! 🤗

[shrimqy]

It's funny that it's not (yet?) mentioned either on AndroidDeveloper's ManifestPermission page

Exactly, I got this issue when I upgraded to android 15 and was trying to find a way around it so adding this permission and giving the permission through the adb worked really well. But I'm still salty about how Google just wanted to do this and not give users a way around this directly.

Well, not the best comparison maybe. But INTERNET at least allows for a (very?) coarse location. And meh, I didn't want to start a flame war on this, it's just that those things are not always easy to follow. "Average folks" seeing the location permissions requested hardly understand without being explained explicitly, that connection (oops) is not exactly intuitive…

I just wanted to clarify more about the permission, since it indeed is a sensitive permission for some.

Ah, good to know. Maybe that could (should?) be pointed out somewhere in the description?

Yes, I should add that to avoid confusion.

Speaking of which: would you welcome a PR with Fastlane structures

Absolutely, I’d be happy to receive a PR.

Our scanner will report when it's removed

aa I see, I understand.

Thank you again.

[IzzySoft]

how Google just wanted to do this and not give users a way around this directly.

As unfortunately it is quite often. And I bet their own apps ("GApps") are set up with exceptions?

Absolutely, I’d be happy to receive a PR.

Done with #8 then (details there) 😃

And you're welcome! 🤗

[shrimqy]

As unfortunately it is quite often. And I bet their own apps ("GApps") are set up with exceptions?

I'm not sure but they should ig, and plus some OEM apps would also have exceptions yes.

Done with #8 then (details there) 😃
And you're welcome! 🤗

thanks

[IzzySoft]

I'm not sure but they should ig, and plus some OEM apps would also have exceptions yes.

So as usual: full rights for me, but no such for thee…

thanks

Gladly! Thanks for merging! Will now enable that here at IzzyOnDroid, so that… err, packageName will change… well, so that we are prepared then 😆