feat: Impement github as a remote source

[secp192k1]

Remote source flow

1. When a github link is detected it converts the dialog text from Add to Next.

Picture Preview

2. After clicking next, it will fetch the latest release and latest pre-release (if applicable).

Picture Preview

Note

The only files allowed to be picked are .apk and .rvp

3. After selecting a version, wait for it to download.

Picture Preview

Logcat Preview

Note

The logcat above has a DownloaderEntity which is the external github downloader

Page of added external patches

[oSumAtrIX]

This could cause limitations in the future. If API adds features for manager that github cant satisfy on its own, manager would fail to properly handle the sources under a common interface

[oSumAtrIX]

Using GitHub as a source will exhaust the API and can lead to rate limits

[secp192k1]

Using GitHub as a source will exhaust the API and can lead to rate limits

How about a warning informing the user of this? Or do you have any proposals in mind?

[oSumAtrIX]

The only way to increase the limit is with an github api key. I wouldnt add github as a source at all. The API/json source is already a very opaque layer providing a transformation layer for manager. You can make that json point to github if you want to use github as a source effectively, which is also what we currently have with our api. This also offloads the api calls to the api/json instead of github. Without a transformation layer like API you lose an important control point in the infrastructure and strongly depend on the target platform in this case github.

[secp192k1]

Telling the user to provide an github api key to "unlock" this functionality effectively is a bad idea, since its too many steps and way too complex for the average user; and yes it would make the manager dependent on github if this functionality is being used, limiting the requests that can be made by the manager is way to mitigate this but its your call osum

[Ushie]

This could cause limitations in the future. If API adds features for manager that github cant satisfy on its own, manager would fail to properly handle the sources under a common interface

In that case revanced manager should offer an API for sources, like it has for downloaders, and GitHub/GitLab etc can be officially implemented while still allowing for future modularity

[Ushie]

Using GitHub as a source will exhaust the API and can lead to rate limits

You would have to make 60 requests an hour to hit the rate limit, it used to be an issue in ReVanced Manager alpha because everything depended on the GitHub API but it's only one request per patch bundle in this case here

[oSumAtrIX]

With every source you add, you drastically reach the limit

[Ushie]

You're unlikely to reach 60 GitHub sources, besides for users who are that deep into it, I'd say asking for a scoped GitHub PAT isn't an issue, when the GitHub plugin faces it's first ratelimit it can ask for a token then

[oSumAtrIX]

It doesn't need 60, for example 30 sources means refreshing once to hit the limit.

[Ushie]

Refreshes shouldn't be done carelessly by the manager, at most the user should be allowed to force refresh a single source, otherwise manager can just dictate all sources being refreshed once in an hour timespan

[oSumAtrIX]

This was just an example of a pitfall that was not previously considered before I named it. There's definitely many more like this that in sum speak against this and in favor of a proper solution with an API that provides a transformation and control layer for sourcing, preventing any unforseen issues as the two I just named and potentially others

[secp192k1]

@oSumAtrIX perhaps a switch in the settings page, Allow external sources, and just like other switches, explain to the user the (api) limitations and other warnings before turning on
Edit: obviously this will be disabled by default