Accessibility service and package installer?

[IzzySoft]

In January my scanner got a few additional checks. So on today's release it reported:

! repo/com.kieronquinn.app.ambientmusicmod_232.apk declares intent-filter(s): android.accessibilityservice.AccessibilityService
! repo/com.kieronquinn.app.ambientmusicmod_232.apk declares sensitive permission(s): android.permission.REQUEST_INSTALL_PACKAGES

Could you please clarify what for Accessibility Services are used – and what packages your app wants to install? Thanks in advance!

[KieronQuinn]

Accessibility is used for the lock screen overlay. Install packages is used for updates & installing now playing.

Both of these permissions need explicit user opt-in at a contextual moment, there is no need for ahead of time clarification.

[IzzySoft]

Accessibility is used for the lock screen overlay.

Thanks! I assume that's the only way to achieve those nowadays, so I'll add that as explanation there.

Install packages is used for updates

You mean a self-updater? That would conflict with the inclusion criteria (of my repo as well as F-Droid's). Is the update check (and the updating itself) opt-in?

there is no need for ahead of time clarification.

No offense meant, but I slightly disagree. There are folks checking such things in advance and rather skip apps with such permissions. Which is why it's a good idea to have their reasons clearly visible, even before install (and in case of Ambient: do you know if AccessibilityService would be able to grant runtime permissions by "hitting approve"? I wouldn't be surprised if they were). This is how that looks currently for Ambient:

Oh, and if you want to get rid of that DEPENDENCY_INFO_BLOCK, that is easy:

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.

[KieronQuinn]

Accessibility is used for the lock screen overlay.

Thanks! I assume that's the only way to achieve those nowadays, so I'll add that as explanation there.

Correct, normal overlays cannot display over the system

Install packages is used for updates

You mean a self-updater? That would conflict with the inclusion criteria (of my repo as well as F-Droid's). Is the update check (and the updating itself) opt-in?

I don't host the app on F-Droid or any repositories officially. If you decide to host it on your repo, that is your choice. The self updater is the main update functionality of this and all my apps.

[IzzySoft]

The self updater is the main update functionality of this and all my apps.

And you would not even consider making it opt-in? The functionality would still be available then. A popup on first start asking the users' choice and then store (and honor) that would be all that's needed.

[KieronQuinn]

I don't adapt my apps for stores I don't officially upload them to, sorry.

[IzzySoft]

OK, that's your decision then. It bypasses the extra screening (mistakes happen to the best of us, and more than once it was the extra screening in my repo revealing "lapses"), which those using repos like F-Droid's or mine expect. If they install apps from there, they expect the updates come from there as well. Of course they are free to choose a different source, but the choice should be theirs.

So no bad feelings; but if you insist to keep the updater enforced, I'll have to remove the app from my repo unfortunately – which also removes one option of discovery (people browsing their local catalog of apps in their clients to find apps – or using the online "repository browser", where above screenshots are coming from).

[IzzySoft]

As today's update rang the alarm bells again: your "No" remains? I've now set it for removal on the next round should I've not heard otherwise from you.

[KieronQuinn]

Todays update would make it worse for F-droid if anything, it now automatically grants a permission using Shizuku. I almost never do this, but the user annoyance that has come about due to the restricted settings permission and how awkward they made it to grant has meant I'm auto granting it wherever I can.

It's still a no.

[IzzySoft]

OK, thanks. That leaves me no chance then but to remove AmbientMusicMod from my repo. It will be unlisted with the next sync then (around 7 pm UTC). I happily take it in again if there's a solution for this problem.

Thanks for the open communication – and as I wrote above: no bad feelings.