policy for handling Dependency Info Block (and other opaque block types)

See https://android.izzysoft.de/articles/named/iod-scan-apkchecks#blobs

---

See fdroidserver#1056 and android docs for background (bold mine):

When building your app using AGP 4.0.0 and higher, the plugin includes metadata that describes the library dependencies that are compiled into your app. [...] The data is compressed, encrypted by a Google Play signing key, and stored in the signing block of your release app. [...]

I think we should have a policy on how to handle this.

---

Some relevant discussuon from #fdroid-dev:

@TheLastProject:

So... AGP creates an encrypted list of libraries that only Google can read in every single APK? Come on, they could've shared this :(

@obfusk:

It seems most of our RB APKs now have a DependencyInfoBlock. I'm not exactly happy about that. IMO we should decide on a policy like asking devs to disable it.

I don't actually know if any apps built by us have this block. we do have a script to detect that now: https://github.com/obfusk/fdroid-misc-scripts#detect-blockssh
I assume not, since our signing process (using apksigner) should not be able to add the dependency info block AFAIK.

But we are publishing upstream APKs containing encrypted data that only google can read for most RB apps. I don't think we should.

@TheLastProject:

On the one hand, makes sense. On the other hand, I do worry that caring too much about these little things may annoy devs and I don't want F-Droid to be associated with "annoying to publish on because they want so many things" while currently Google Play is (rightfully) considered more annoying for most devs

@obfusk:

Fair enough. So far all I've said is "we should have a policy". Such concerns should inform what that policy will be. I'd prefer devs to remove this stuff. But we could also remove it ourselves (the APK would not be bit-by-bit identical then, but the upstream signature would still be valid). We could also use an anti-feature; this could be considered a non-free binary blob (we have no way of knowing what's actually in there since only google can decrypt it).