feat: Add APK Downloading System with Plugin Architecture

[Aunali321]

Type

Functionality

Issue

Currently, there is no system in place for downloading APK files. It would be beneficial to have a flexible and extensible system in place that can be used to download APK files from different sources. This would allow developers to add support for new sources without having to modify the core codebase.

Feature

To address this, I propose adding a interface, IApkDownloadProvider, that defines a standard set of methods for downloading APK files. This interface can be implemented by developers as plugins to provide support for downloading from different sources.

The IApkDownloadProvider interface should at least include the following method:

getApkInfo(url: packageName): Promise<ApkInfo> - Retrieves information about the APK file using the package name, such as its version number, size, and download link.

In addition, the main codebase should include a DownloadManager class that acts as a central point for managing the download of APK files. This class should expose methods for adding and removing download providers, as well as starting and stopping downloads.

Motivation

With this system in place, developers can easily add support for new APK download sites by creating new plugins that implement the IApkDownloadProvider interface. This will make the codebase more modular and flexible, while also providing a better user experience for users who want to download APK files from different sources.

Additional context

No response

Acknowledgements

• [X] I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• [X] I have written a short but informative title.
• [X] I filled out all of the requested information in this issue properly.
• [X] The issue is related solely to the ReVanced Manager

[oSumAtrIX]

I don't think downloadApk will be necessary. ApkInfo should have a direct url to the download link.

[Aunali321]

Tracking branch - apk-scraper

[Ushie]

There must be consideration for metadata, things such as:

• App Icon
• App Name

These are needed for the downloadable apps to be integrateable with the existing installed apps list, with an indicator and/or a download action button in the ListItem, other than that it should not be treated differently from installed apps.

[bradhoschar]

This is crucial, since revanced is always 1-2 versions behind the latest apks in the play store.

[0-BlackSpectrum-0]

If not apk download atleast put the supported version out below the app name during app selection, it's too deep and only shows if the installed version doesn't support the patches, if it does but the version is old I won't know, so add the latest supported version as text near the app during selection that'd be helpful!

[antifarben]

A quick and still useful solution could add just a button opening the standard browser with useful search terms. Something like https://duckduckgo.com/?q="com.google.android.youtube"+apk+"18.19.35" and using/showing the suggested version (see also #876).

This way it doesn't need a dedicated scraper that might fail. A browser is probably available everywhere and users can decide about their sources like they prefer.

[Ushie]

Very good idea!

[oSumAtrIX]

If this is considered to be implemented, the search engine should not be hardcoded.

[yonggamer]

how about AuroraStore code

[oSumAtrIX]

Aurora store serves splits from PlayStore

[yonggamer]

what if you combine it with APKEditor

[oSumAtrIX]

Then it becomes a bigger problem, requires more RAM, time to convert it to a full APK, more patching time and luck so it doesn't fail

[yonggamer]

can a cach file help?

[yonggamer]

or split the the tasks and write to internal storage inbetween tasks?

[oSumAtrIX]

Split support won't be added this way. An interface will be provided where you can implement your own downloader if you want to.