chore: Merge branch dev to main

[github-actions]

This pull request will Merge branch dev to main.

[brosssh]

The repository name should be changed to revanced-manager-downloaders , as well as the description to 🔌 ReVanced Manager Downloaders.

[Axelen123]

The -downloader suffix seems unnecessary since the downloaders are inside the downloaders folder.

[brosssh]

Should the downloader APK file name start with revanced-manager-?

[Ushie]

Yes, as it is scoped specifically for ReVanced Manager

[oSumAtrIX]

We should probably change names to a better naming convention, like:

"ReVanced Manager v1.2.3.apk" instead of "revanced-manager-v1.2.3.apk"

For downloaders, I mentioned the naming question in another place i don't remember but i pinged the relevant parties

[brosssh]

We should probably change names to a better naming convention, like:

"ReVanced Manager v1.2.3.apk" instead of "revanced-manager-v1.2.3.apk"

For downloaders, I mentioned the naming question in another place i don't remember but i pinged the relevant parties

Is this blocking merge into main? What should be the naming convention for downloaders?

[oSumAtrIX]

Personally, I would like to see the following changes:

• The term "plugin" should be removed entirely. Currently, downloaders are referred to as "plugins," but unless we have other plugins apart from downloaders, this labeling is confusing. Please remove it from the code, as well as any references in strings, documentation, etc.
• The base name should be "ReVanced Manager downloader" (or "ReVanced Manager downloaders" once multiple APKs can be supported).
• Conventionally, the name for downloaders would be something like "ReVanced Manager APKMirror downloader." However, once more options are available, the name of the APK should follow the format "ReVanced Manager downloaders," for example, "ReVanced Manager Brosssh downloaders."

Here are some issues and questions to consider:

• In our case, it would be named "ReVanced Manager ReVanced downloaders." Should we omit "ReVanced"? If we do that, should we also consider omitting "ReVanced" in "ReVanced Patches"? Not doing so would create inconsistency etc.
• Simply using "downloaders" is ambiguous. We should specify "APK downloaders." Furthermore, we need to decide on the term: should it be "app downloader," "apps downloaders," or "app downloaders"? This could also lead to longer names like "ReVanced Manager ReVanced app downloaders."
• What should we name the internal packages? Here are some possibilities:
  • app.revanced.manager.downloaders.
  • app.revanced.manager.apkdownloaders.
  • .revanced.manager.downloaders.
  • And potentially others...

[Axelen123]

The term "plugin" should be removed entirely. Currently, downloaders are referred to as "plugins," but unless we have other plugins apart from downloaders, this labeling is confusing. Please remove it from the code, as well as any references in strings, documentation, etc.

What should we name the internal packages? Here are some possibilities:

  * app.revanced.manager.downloaders.
  * app.revanced.manager.apkdownloaders.
  * .revanced.manager.downloaders.
  * And potentially others...

We had lengthy discussions while the downloader system was still in development, and I am sure this was discussed at some point. Why is this being brought up again?
I see no issue with using the word "plugin" in code or here in Manager:

I don't think these two uses are confusing. The README does not use the term "plugin" at all.

The base name should be "ReVanced Manager downloader" (or "ReVanced Manager downloaders" once multiple APKs can be supported).

Conventionally, the name for downloaders would be something like "ReVanced Manager APKMirror downloader." However, once more options are available, the name of the APK should follow the format "ReVanced Manager downloaders," for example, "ReVanced Manager Brosssh downloaders."

The two downloaders in this PR seem to be following this already.

In our case, it would be named "ReVanced Manager ReVanced downloaders." Should we omit "ReVanced"? If we do that, should we also consider omitting "ReVanced" in "ReVanced Patches"? Not doing so would create inconsistency etc.

In that situation, "ReVanced Manager official downloaders" or just "ReVanced Manager downloaders" would do.

Simply using "downloaders" is ambiguous. We should specify "APK downloaders." Furthermore, we need to decide on the term: should it be "app downloader," "apps downloaders," or "app downloaders"? This could also lead to longer names like "ReVanced Manager ReVanced app downloaders."

Downloader is not ambiguous in the context of ReVanced Manager, since it only deals with Apks.

[oSumAtrIX]

We had lengthy discussions while the downloader system was still in development, and I am sure this was discussed at some point. Why is this being brought up again?

I do not remember "discussions" on Discord. Discord is too volatile for me. Please rehearse me.

I see no issue with using the word "plugin" in code or here in Manager:

I mentioned the issue in the comment:

Currently, downloaders are referred to as "plugins," but unless we have other plugins apart from downloaders, this labeling is confusing. Please remove it from the code, as well as any references in strings, documentation, etc.

People will call downloaders plugins, and plugins downloaders, people will ask what plugins exist, when only downloaders exist, people will say plugin, but some will not understand downloaders are meant, terminology here is extremely confusing and this issue is reflected by the code as well. Do we add "plugin" in the name of downloaders, do we use them in packages, do we omit them? This issue even bleeds to the UI. One section "plugins" which only mentions "downloaders"? What is the point of that.

In my opinion this abstraction may come at a later point in time if we plan any other pluggable systems apart from downloaders. Even the current abstraction is invalid. Right now there is no interface for plugins, only downloaders, therefore there exists no abstraction for plugins. If you'd want to "plan" ahead for plugins, you'd need to create an interface for plugins and implement it in the downloader API. E.g:

interface IPlugin { val: name, ... }
interface IDownloader implements IPlugin

Less abstraction if possible is good. As of now I don't see any direction manager would head to that would call for the need of IPlugin and therefore no abstraction for it. It isn't only easier in code and UI, but also for users as there is no confusion between those two terms that would be used for the very same thing interchangeably (e.g. the same issue with bundle vs patches).

I don't think these two uses are confusing. The README does not use the term "plugin" at all.

Even worse! The UI suggests other plugins exist. Yet, the only that does is downloaders. This term has no use both, in code, nor to the user.

The two downloaders in this PR seem to be following this already.

You misunderstand me. We once discussed that one APK shipping multiple downloaders scales better than one APK per downloader for the reason of API having to serve only one downloader just like one patches file instead of adding a new entry everytime a new downloader or patch is added. For this reason one downloader APK would for example be called "ReVanced downloaders" because ReVanced is the publisher of the APK, just like its called "ReVanced Patches". Brosssh would call his APK "Brosssh downloaders". Here is where naming is a problem. Refer to my comment to this regard. (Read below before your reply to this)

In that situation, "ReVanced Manager official downloaders" or just "ReVanced Manager downloaders" would do.

How would Brossh call theirs then? Also the name is suggestive of downloaders downloading ReVanced Manager which doesn't make sense when instead it downloads APKs (e.g. ReVanced Manager APK downloaders). If you decide for a name, we'll need reasoning on why its chosen. (Read below before you reply to this)

Downloader is not ambiguous in the context of ReVanced Manager, since it only deals with Apks.

Well, that can be said for "ReVanced downloaders" too, because in ReVanced context is it unambiguous. This naming scheme would allow what i said above, e.g. Brossh downloaders, whereas "ReVanced Manager downloaders" wouldn't. However "ReVanced downloaders" is quite unspecific, whereas "Brossh downloaders" doesn't even mention ReVanced at all. A verbose "correct" name could be "ReVanced Manager APK downloaders" whereas others would choose "Brosssh ReVanced Manager APK downloaders" for example. Not sure how to proceed from here on, a lot of brainstorming, maybe chatgpt can come up with something.

Here is chatgpts take:

---

1. Guiding principles

• Clarity → the name should make it clear what the APK contains (downloaders for APKs, not for Manager itself).
• Consistency → same pattern across ReVanced and third-party publishers.
• Scalability → works whether there’s 1 downloader or many, and whether the publisher is ReVanced or someone else.
• Brevity vs. Verbosity → short enough to be usable, descriptive enough to avoid ambiguity.

---

2. Proposed naming convention

• Format:

  <Publisher> <App/Module> <Component>
  

  where:

  • Publisher → ReVanced, Brosssh, etc.
  • App/Module → Manager (if tied to Manager) or omitted if not necessary.
  • Component → APK Downloaders (plural, since one APK can contain multiple downloaders).

• Examples:

  • Official: ReVanced Manager APK Downloaders
  • Third-party: Brosssh ReVanced Manager APK Downloaders

This keeps “APK” explicit to avoid confusion, and keeps “downloaders” plural since it scales.

---

3. Handling redundancy ("ReVanced ReVanced …")

• If the publisher is ReVanced, then repeating “ReVanced” looks redundant.
  → Use ReVanced Manager APK Downloaders.
• If the publisher is not ReVanced, then including “ReVanced Manager” makes sense to show compatibility:
  → Brosssh ReVanced Manager APK Downloaders.

This mirrors how open-source ecosystems work (e.g. “JetBrains Kotlin Plugin” vs. “Foo Kotlin Plugin”).

---

4. Internal package naming

For consistency and readability:

• Official:

  app.revanced.manager.downloaders
  

• Third-party:

  com.brosssh.revanced.manager.downloaders
  

If APK distinction is needed internally (to avoid collisions with potential future “media downloaders” etc.):

app.revanced.manager.apkdownloaders
com.brosssh.revanced.manager.apkdownloaders

---

5. Summary

• Official APK name: ReVanced Manager APK Downloaders

• Third-party APK name: <Publisher> ReVanced Manager APK Downloaders

• Package names:

  • Official: app.revanced.manager.apkdownloaders
  • Third-party: com.<publisher>.revanced.manager.apkdownloaders

This avoids ambiguity (“Downloader” vs. “APK Downloader”), avoids redundancy (“ReVanced ReVanced…”), and scales to third-party publishers.

---

I'd be okay with chatgpts reasoning here, except maybe "apkdownloaders" since we call them "downloaders"

[Axelen123]

We had lengthy discussions while the downloader system was still in development, and I am sure this was discussed at some point. Why is this being brought up again?

I do not remember "discussions" on Discord. Discord is too volatile for me. Please rehearse me.

Discord search sucks, so I am not going to try to find it. It is best to keep the discussion here on Github so it won't get brought up again, since I can't be bothered to discuss this a third time.

I mentioned the issue in the comment:

Currently, downloaders are referred to as "plugins," but unless we have other plugins apart from downloaders, this labeling is confusing. Please remove it from the code, as well as any references in strings, documentation, etc.

People will call downloaders plugins, and plugins downloaders, people will ask what plugins exist, when only downloaders exist, people will say plugin, but some will not understand downloaders are meant, terminology here is extremely confusing and this issue is reflected by the code as well. Do we add "plugin" in the name of downloaders, do we use them in packages, do we omit them? This issue even bleeds to the UI. One section "plugins" which only mentions "downloaders"? What is the point of that.

Having the term plugin in Kotlin/Android package names doesn't generate confusion by itself. Plugins are named by their developers, not us. They will simply choose a name that they think makes sense for their project regardless of what we think. For UI, see below.

In my opinion this abstraction may come at a later point in time if we plan any other pluggable systems apart from downloaders. Even the current abstraction is invalid. Right now there is no interface for plugins, only downloaders, therefore there exists no abstraction for plugins. If you'd want to "plan" ahead for plugins, you'd need to create an interface for plugins and implement it in the downloader API. E.g:

interface IPlugin { val: name, ... } interface IDownloader implements IPlugin

Less abstraction if possible is good. As of now I don't see any direction manager would head to that would call for the need of IPlugin and therefore no abstraction for it. It isn't only easier in code and UI, but also for users as there is no confusion between those two terms that would be used for the very same thing interchangeably (e.g. the same issue with bundle vs patches).

I don't think we are going to have other plugins in the future. We do not need an interface for plugins right now nor does the use of the term plugin imply that we need one.

I don't think these two uses are confusing. The README does not use the term "plugin" at all.

Even worse! The UI suggests other plugins exist. Yet, the only that does is downloaders. This term has no use both, in code, nor to the user.

Refer to the image in my previous comment. If we replaced "Plugins" with downloaders, a user who is not familiar with the system would have questions like "Why are there no downloaders here?" or "How do I get/enable downloaders?". By using the term "plugin", it is more clear/obvious that they are external software that you have to look for. This problem would be worse if we decide to ship builtin downloaders, since users might think that the builtin ones are the only ones you can use even though that is not the case.

The two downloaders in this PR seem to be following this already.

You misunderstand me. We once discussed that one APK shipping multiple downloaders scales better than one APK per downloader for the reason of API having to serve only one downloader just like one patches file instead of adding a new entry everytime a new downloader or patch is added. For this reason one downloader APK would for example be called "ReVanced downloaders" because ReVanced is the publisher of the APK, just like its called "ReVanced Patches". Brosssh would call his APK "Brosssh downloaders". Here is where naming is a problem. Refer to my comment to this regard. (Read below before your reply to this)

It has been a while since I made that comment. I didn't like having multiple downloaders in the same Apk before because it didn't feel right, but now I have a good argument as for why we shouldn't. Having multiple patches in the same bundle makes a lot of sense. The reason why it doesn't for downloaders is because APK sources are far less numerous compared to the possible modifications you could make to an Apk. The ability to share code is also not a justification, because this repo demonstrates that you can share code even if you have multiple Apks.

Regarding the RV API, I plan on delegating almost all of the update checking logic to the plugin itself. Developers can implement updating via that API or use an external store such as Obtainium or F-Droid. Obtainium only requires you to make releases on Github and it will handle the rest, so we are not burdening plugin devs here. The benefit here is that we are not forcing developers to use one thing in particular.
Official plugins would use the RV API as the source for their update information. The API is already aware of manager and patches, so it is not wrong to make it aware of plugins as well. This repo could have an info.json in the release assets, which the API could consume to know which plugins exist, their version and their corresponding Apk asset. The information could then be exposed like this:

/v5/dl/list -> ["apkmirror", "aurora"] (might not be necessary, idk).
/v5/dl/info?name=aurora -> {"version": "va.b.c", "link": "https://my_url"}

This is just a concept and can be changed if needed. If you still think having multiple downloaders in the same Apk is a good idea or you don't like my plan with updates, please open a separate issue so we can unblock this PR. The name of this monorepo can still be discussed here though.

In that situation, "ReVanced Manager official downloaders" or just "ReVanced Manager downloaders" would do.

How would Brossh call theirs then? Also the name is suggestive of downloaders downloading ReVanced Manager which doesn't make sense when instead it downloads APKs (e.g. ReVanced Manager APK downloaders). If you decide for a name, we'll need reasoning on why its chosen. (Read below before you reply to this)

The individual downloaders can be named after their Apk source just like we are doing now in this repo. The naming of a monorepo containing multiple downloaders is up to the author, not us.

Downloader is not ambiguous in the context of ReVanced Manager, since it only deals with Apks.

Well, that can be said for "ReVanced downloaders" too, because in ReVanced context is it unambiguous. This naming scheme would allow what i said above, e.g. Brossh downloaders, whereas "ReVanced Manager downloaders" wouldn't. However "ReVanced downloaders" is quite unspecific, whereas "Brossh downloaders" doesn't even mention ReVanced at all. A verbose "correct" name could be "ReVanced Manager APK downloaders" whereas others would choose "Brosssh ReVanced Manager APK downloaders" for example. Not sure how to proceed from here on, a lot of brainstorming, maybe chatgpt can come up with something.

The individual Apk names in this repo are fine to me, and they can also be used by third parties if they desire. Naming the monorepo itself is trickier, but I don't have a better idea than the one we are already using in this PR. ReVanced Manager Downloaders can be misinterpreted as something that downloads ReVanced Manager, but so can ReVanced Manager APK Downloaders.

[oSumAtrIX]

Having the term plugin in Kotlin/Android package names doesn't generate confusion by itself. Plugins are named by their developers, not us. They will simply choose a name that they think makes sense for their project regardless of what we think. For UI, see below.

The "confusion" is causing them choosing arbitrarily between using "plugin" or not in the package name. For devs and users alike using two terms for the same thing is redundant and confusing. If you instead omit "plugin", all devs will be able to choose "downloader" as the term and call it that way without having to decide to use plugin, downloader or both.

I don't think we are going to have other plugins in the future. We do not need an interface for plugins right now nor does the use of the term plugin imply that we need one.

Bingo. No other plugins, so why not just have downloaders. Remove the "plugin" terminology if you don't have any use for it, other than downloaders.

Refer to the image in my previous comment. If we replaced "Plugins" with downloaders, a user who is not familiar with the system would have questions like "Why are there no downloaders here?" or "How do I get/enable downloaders?". By using the term "plugin", it is more clear/obvious that they are external software that you have to look for. This problem would be worse if we decide to ship builtin downloaders, since users might think that the builtin ones are the only ones you can use even though that is not the case.

This is not a problem. You solve this by: In the UI show a label that says "you don't have any downloaders installed" or similar. The terminology "plugin" is thus redundant to convey that downloaders are external components that plug into manager.

The reason why it doesn't for downloaders is because APK sources are far less numerous compared to the possible modifications you could make to an Apk. The ability to share code is also not a justification, because this repo demonstrates that you can share code even if you have multiple Apks.

I am not sure what you mean "APK sources are far less numerous". You mean there are only a couple of sources that provide APK files? Not only is a scale like this something you shouldn't consider, nor is it small. There are countless of APK sources, from users, decentral systems, stores and probably many more in the future. You should design the system for an array of N and not a fixed count. Also, even 2 sources justify a single APK file. It is scalable as well as we merely add a new downloader to the APK and push, and it would be available to the user.

The ability to share code is also not a justification, because this repo demonstrates that you can share code even if you have multiple Apks.

It involves gradle, and it also duplicates the shaded library code, if e.g. i update a downloader, others wouldn't benefit from the library code updates as its separate, so if there's a bug in the lib, you'd need to update all single APK files. One APK shipping multiple downloaders means, user only needs to subscribe to the author of choice, and the author handles the rest, e.g. new downloaders, updates etc. You can STILL ship one downloader per APK just fine for any reason you want, this is not changed at all.

Regarding the RV API, I plan on delegating almost all of the update checking logic to the plugin itself. Developers can implement updating via that API or use an external store such as Obtainium or F-Droid. Obtainium only requires you to make releases on Github and it will handle the rest, so we are not burdening plugin devs here. The benefit here is that we are not forcing developers to use one thing in particular.
Official plugins would use the RV API as the source for their update information.

It is okay to design an API for update checking in downloader as long as you can implement the API so that the "official" method is to check for updates from ReVanced API. E.g. an interface "downloadAvailable()" and you implement it with a call to revanced API. However now that update checking is done in the downloader itself, each downloader would have to duplicate implementations of checking for updates when one central code could do that, e.g each downloader contracts with manager with an API so that manager can call the check function to check if the downloader has an update. The downloader would for example provide an API URL that returns a response that manager contracted with so that it checks for an update instead of downloaders implementing that code every time.

If you still think having multiple downloaders in the same Apk is a good idea or you don't like my plan with updates, please open a separate issue so we can unblock this PR

Before manager is merged to main this needs to be done though, otherwise you have breaking API and itll be much more difficult for this to be realized. Given that, there is no need to "unblock" this PR before manager is merged to main.

The individual downloaders can be named after their Apk source just like we are doing now in this repo. The naming of a monorepo containing multiple downloaders is up to the author, not us.

I am asking for a naming scheme, I know that they can be named whatever, however we have to decide on a format.

but so can ReVanced Manager APK Downloaders.

Imo all are kinda mid, but this one is the best. That said:

" ReVanced Manager APK downloaders" contains e.g. "APKMirror downloader". ReVanced omits .
Internally we can use ".manager.downloaders" and a subgroup e.g. "com.apkmirror" (domain preferred or name is fine if no domain available, e.g. a local file downloader). Btw, we might use "downloader" instead of "downloaders", if "downloaders" is not correct english.