feat: Publish to IzzyOnDroid [F-Droid without the complications]

[ahnaf-rayem]

Feature description

Hey Team!

In issue #79, I understand the complexities involved in publishing the app on F-Droid, which might deter many developers. However, I'd like to suggest a better option: The IzzyOnDroid Repository.

IzzyOnDroid is often described as "F-Droid minus the hassle." It offers a curated selection of F-Droid apps, bypassing the need for individual app review and simplifying the publishing process.

Since a large portion of users already have the IzzyOnDroid repository added to their F-Droid clients, publishing there would ensure convenient updates and maintenance for both users and developers.

As a passionate supporter of this project, I kindly request you to consider publishing the app on IzzyOnDroid.

Motivation

This will provide the community to update the apps from clients like Droid-ify, making it easy to have all the installed open-source apps updated from one place.

Additional context

NOTE: Adding it to the IzzyOnDroid repo wouldn't mean you can't publish it here too. You can publish the same app in both GitHub release AND IzzyOnDroid. Adding it to the IzzyOnDroid would mean when the repository gets updated in each user's client, they will be notified, and it'll be very convenient to download all updates from one app, instead of monitoring the GitHub or using ReVanced's self-update feature.

Additionally, you also go the Cromite route, and create your own repository link as it is much simpler.

Acknowledgements

• [X] This request is not a duplicate of an existing issue.
• [X] I have chosen an appropriate title.
• [X] All requested information has been provided properly.
• [X] The issue is solely related to the ReVanced Manager

[oSumAtrIX]

Assuming we have in app notifications for updates, for what purpose would we want to use IzzyOnDroid

[Ushie]

Hi Ahnaf,

Thank you for suggesting an alternative to suit us, IzzyOnDroid sounds like a great option.

I have just a few questions about it:

1. Is the same policy about signing keys present? so if we attain reproducible builds, can we use our own signing key? Or will the user be forced to use IzzyOnDroid to update their ReVanced Manager, as the in-app update functionality wouldn't work

2. How often are builds? As this is a rapidly growing project, certain releases are timed together to avoid complications

3. What is the stance on being strictly FOSS? For example, are things like notifications accepted? or are we expected to use FOSS implementations for notifications

[Ushie]

Assuming we have in app notifications for updates, for what purpose would we want to use IzzyOnDroid

Assuming there's little to no handicaps of using the IzzyOnDroid release, having a single place to manage, update apps (automatically) etc is nice, plus it would increase discoverability rather than relying on word of mouth

[oSumAtrIX]

With in app updates you have a single place for updates. That was the assumption taken before your comment, so I don't see how you conclude the necessity of using IzzyOnDroid for something that we already would have.

[Ushie]

Droid-ify can make use of app ownership to automatically update ReVanced Manager to latest with no user interaction, ReVanced Manager can't own itself

[validcube]

Is the same policy about signing keys present? so if we attain reproducible builds, can we use our own signing key?

As far as I know, IzzyOnDroid repository provides APK that's originally signed by the developer, they're less strict than F-Droid repository.

Will the user be forced to use IzzyOnDroid to update their ReVanced Manager, as the in-app update functionality wouldn't work

To update the application, the user can use our own official updater or an F-Droid client.

What is the stance on being strictly FOSS? For example, are things like notifications accepted? or are we expected to use FOSS implementations for notifications

They're less strict than F-Droid repository, but ideally they recommend that we should include not more than two proprietary components and it has to be reasonable to include them (tracker are allowed).

[shuvashish76]

I have just a few questions about it (IzzyOnDroid):

Ping @IzzySoft for the clarifications

Unlike official F-Droid repo, Izzy has limited resources hence apk size limit is just 30MB (see their requirements)

Exceptions can be made if other requirements match but it solely depends on IzzySoft's decision.

[IzzySoft]

they're less strict than F-Droid repository.

Let's agree on "differently strict" :stuck_out_tongue_winking_eye:

but ideally they recommend that we should include not more than two proprietary components and it has to be reasonable to include them (tracker are allowed).

Hm, let me point to the IzzyOnDroid App Inclusion Criteria here. Trackers are tolerated to a degree, yes – "allowed" (or "accepted") are different pairs of shoes. But let's have a look first:

The APK at the latest release is 42 MB, which is quite a bit over the 30 MB per-app limit here. In such a state apps are not accepted into the repo (as they tend to grow further instead of getting any smaller). Having per-ABI (split) APKs could get around that as the current "fat build" contains 3 ABIs with ~20 MB native libs each, compressed to ~50% – so kicking 2 of them out should get the APK size down below 30 MB.

Now for the scanner results: no proprietary or otherwise "offending" libs detected. The only thing my scanner complains about is:

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

which can be easily avoided:

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.